CSS3 rules bring lots of interesting features.
Take border-radius, for example. The standard says that if you write this rule:
div.rounded-corners {
border-radius: 5px;
}
I should get a 5px border radius.
But neither mozilla nor webkit implement this. However, they implement the same thing, with the same parameters, with a different name (-moz-border-radius and -webkit-border-radius, respectively).
In order to satisfy as many browsers as possible, you end up with this:
div.rounded-corners {
border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
}
I can see two obvious disadvantages:
Copy-paste code. This has obvious risks that I will not discuss here.
The W3C CSS validator will not validate these rules.
At the same time, I don't see any obvious advantages.
I believe that the people behind mozilla and webkit are more intelligent than myself. There must be some good reasons to have things structured this way. It's just that I can't see them.
So, I must ask you people: why is this?
The -moz-border-radius describes Mozilla's semantics. If CSS3 gets published with different semantics, then Mozilla can always implement border-radius using those semantics and they won't break anyone's website.
Meanwhile, if they just used border-radius directly, then if CSS3 gets published with different semantics, Mozilla has to choose between breaking people's sites, or forever supporting nonstandard CSS.
They do this because its not fully supported. It much like having that code in beta. Eventually they will add support for border-radius.
It more obvious when you look at the linear gradients.
background-image: -moz-linear-gradient(100% 100% 90deg, #2F2727, #1a82f7);
background-image: -webkit-gradient(linear, 0% 0%, 0% 100%, from(#1a82f7), to(#2F2727));
Notice they don't use the same syntax. When they finally agree on a standard then both with add support for linear-gradient and use the correct syntax.
Simple. The proprietary variants -moz and -webkit were there before the border-radius became written into the CSS3 recommendation. They had their own implementations but didn't know whether these would match W3C's final recommendation. Thus, they didn't use the now-official name at that point, either, so as not to break things later on.
Note that as of 2010-09-14, the -moz prefix has been removed from border-radius. This means that Firefox 4 will support border-radius with no prefix.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Many front-end developers know that valid HTML has a positive effect on SEO. But does a valid CSS affect SEO?
On the Google website on the page https://support.google.com/webmasters/answer/100782?hl=en it says: "Clean, valid HTML is a good insurance policy, and using CSS separates presentation from content, and can help pages render and load faster. Validation tools, such as the free online HTML and CSS validators provided by the W3 Consortium, are useful for checking your site, and tools such as HTML Tidy can help you quickly and easily clean up your code."
But if you look at the world’s most popular front-end component library, for example, you can see that even it contains a lot of errors and warnings from the W3C validator.
:root{
--blue:#007bff;
--indigo:#6610f2;
--purple:#6f42c1;
--pink:#e83e8c;
--red:#dc3545;
--orange:#fd7e14;
--yellow:#ffc107;
--green:#28a745;
--teal:#20c997;
--cyan:#17a2b8;
--white:#fff;
--gray:#6c757d;
--gray-dark:#343a40;
--primary:#007bff;
--secondary:#6c757d;
--success:#28a745;
--info:#17a2b8;
--warning:#ffc107;
--danger:#dc3545;
--light:#f8f9fa;
--dark:#343a40;
--breakpoint-xs:0;
--breakpoint-sm:576px;
--breakpoint-md:768px;
--breakpoint-lg:992px;
--breakpoint-xl:1200px;
--font-family-sans-serif: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
--font-family-monospace: SFMono-Regular, Menlo, Monaco, Consolas, "Liberation Mono", "Courier New", monospace
} ... <= This is just a small part of the file bootstrap.min.css.
The validator https://jigsaw.w3.org/css-validator/ says there are 30 errors and 670 warnings in the Bootstrap. But this CSS is used on many successful sites. Would they be even more successful in SEO if they used a valid CSS?
In their general guidelines for browser compatibility, Google mention the W3C validation tools for writing good, clean code.
They also state the following:
Although we do recommend using valid HTML, it's not likely to be a factor in how Google crawls and indexes your site.
So we can assume this also is the case for CSS.
Keep in mind that there are a lot of other things in your CSS that will affect the search ranking, like mobile-friendly styles, and factors that causes slower loading times like selector specificity, file size, imports etc.
I am working on a firefox fork and would like to duplicate -moz-apperance as appearance. I have tried duplicating it as a shorthand property but this throws errors at the compile stage using ./mach build The documentation seems cryptic.
There's documentation about implementing new CSS properties, which might be hard to follow, but browsers are complex pieces of software.
(Currently this question is too broad to provide an answer that's not link-only.)
update: an actual answer from dbaron (via mozilla.dev.platform):
by adding entries to:
https://mxr.mozilla.org/mozilla-central/source/layout/style/nsCSSPropAliasList.h
I just sent this to Alexis Sellier <self#cloudhead.net> but it bounced back, prompting me to seek answers here:
Hi Alexis,
First and foremost, thanks for a great Java support for the lesscss library!
I am and have been for a while on version 1.7.0.1.1.
I was attempting to use the extend feature which worked when used as:
.button-a {
&:extend(.button-base);
.rounded-corners-top(7px);
}
but not when used as
.button-a:extend(.button-base) {
.rounded-corners-top(7px);
}
further more, the first case does not work if button-base well looks like this:
.button-base {
...
&:hover {
background-color: white;
color: #ff3c1f;
}
}
The hover stuff never gets active from extended contexts. Does this work in the JS version?
I tried to peek into the java package and it seems you have merged
what I believe to be the JS library with some other Rhino JS code,
making it hard to upgdrade to the latest JS version.
It is not clear from the Java library what version is being used either.
I have myself written another js library and successfully used Rhino,
EnvJS and my JS library, and I choose to approach it a bit
differently, namely that the JS can be supplied separately, as an
argument to my java class which takes care of merging it all.
Is that something you think is possible? If not, how up to date with
the JS code is the current Java version?
What limitations do you see in going the approach I've mentioned above.
The .less library calls itself a port of ruby LESS library. Can I take away from that that they both are compilers for the same LESS file format or do they expect subtly different less code? Asked another way, am I locking myself in to the dotless library or can use dotless and the less javascript lib on the less files?
Dotlesscss is a straight (almost 1:1 port) of the JavaScript project less.js (a JavaScript implementation of LessCSS by Cloudhead the original author of LessCss for Ruby)
In 99% of the cases the same code that runs on dotlesscss will run on less.js and vice versa. If something works on less.js and doesn't on dotlesscss we consider that a bug and try to fix it if possible.
There are very subtle differences though as it is very hard to keep three different projects 100% synced up.
For one that would be different function names.
Examples would be the color manipulation functions that we implemented before the LessCss project, as we named these after their SASS equivalents..
But in general: the language though is 100% compatible.
You are not limiting yourself to one language. You should be able to move between different implementations fairly easily.
Also dotless runs on Mono so you are not locked to a specific OS either.
If you encounter any problems feel free to raise an Issue on our GitHub Page or through the Mailing List
They're supposed to be equivalent implemnentations however there is a hudge difference between
the server side implementations (ruby, .net, php ...)
the client side javascript implementation
The big difference is that with the client side implementation, you'll be able to use all the dom of the browser in your less files and this would never work with server side implementations :
#height: `document.body.clientHeight`;
More over, in the current version of dotless (1.2.4.0), javascript evaluation is not implemented and is rendered as [script unsupported] in the css output.
In Safari & Webkit, using only border-radius seems to work without adding the prefix -webkit- to it. Is it okay to leave -webkit- prefix for border-radius?
You miss the point of validation. You validate to avoid errors! These include: unsafe browser extensions, hacks, ie-hacks, and actual errors. By no means should you validate to make your code less cross-browser functional.
You should be aware there are such things as expected errors, and even valid code works with those. Browser extensions like -moz-, -webkit-, and -o- are expected errors. All browsers are designed to drop unknown rules. This is how CSS allows for backwards compatibility. A CSS2 supporting browser will drop the CSS3 border-radius rule. Being valid or invalid doesn't have anything to do with it, and by no means will any browser just break because of it (fortunately for us the idea of turning CSS into XML was squashed and never saw the light of day). Opera will drop -moz- rules and Firefox will drop -o- rules, this is not a error. This is expected behavior:
An initial dash or underscore is guaranteed never to be used in a property or keyword by any current or future level of CSS. Thus typical CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors. However, because the initial dash or underscore is part of the grammar, CSS 2.1 implementers should always be able to use a CSS-conforming parser, whether or not they support any vendor-specific extensions.
The w3c even defines how to write these "Vendor-specific extensions". The following are the current extensions well known ones:
-ms-, mso- Microsoft
-moz- Mozilla
-o-, -xv- Opera Software
-webkit- Apple
-khtml- KDE
There are also some you might have never even heard of:
-atsc- Advanced Television Standards Committee
-wap- The WAP Forum
Browsers implement draft-stage or partial implementations (ie. browser supports X, Y but not Z) of CSS rules, as extensions. This way they prevent any change in the spec from breaking previous versions of the browser. There have been cases where browsers have gone gun happy and implemented them as non-extensions, and the usual result has always been said browser has shot themselves in the foot, things like: "browser XXX version YYY has bad implementation of [...]". Most notably IE stands at the no.1 spot on this, but other browsers too have successfully managed to shoot themselves in the foot. When a draft becomes standard and the browser fully (or sufficiently) implements the spec, a rule is created with out the -xxx- prefix.
In recent years, all major browsers have adopted this as a de facto standard.
How and when to use -xxx- browser extensions? As usual the best practice is to design using only standards compliant code in the most advanced browser you have at your disposal then add all the safe extensions. Out of the extensions use the ones based on w3c standards or current working drafts. Don't use dropped standards/drafts or browser wannabe-standards (ie. some of the old Firefox ones). Also avoid any sort of tinkering rules unless it has a stable fallback.
In the case of the border-radius rule you have a stable fallback.
How to keep both form and function? In my opinion most people are not bothered by the "ohmygosh it's not valid" but rather the fact they are forced to write multiple rules for the same line. A simple solution to this is to use a template system. There are quite a few out there for CSS, as the problem of keeping your code DRY is a persistent one.
The are many many many different implementations out there. The basic idea though is to solve the problem using a mixin (ie. function):
=border-radius(!radius)
-moz-border-radius= !radius;
-webkit-border-radius= !radius;
-khtml-border-radius= !radius;
border-radius= !radius;
We can now write this everywhere:
.stuff
+border-radius(15px);
This code is much more flexible then just writing border-radius: 15px and hoping for the best. It's also maintainable (what no element should have more then 10px border radius? no problem).
You may run into css validation errors by doing so. - prefixed properties are regarded as optional extenstions, and thus have a lesser likelihood of causing problems.
I would suggest you keep the -webkit just incase, some browsers (IE) don't play nice when HTML/CSS don't validate. This is known as quirks mode.
border-radius supports safari 5 and later. -webkit-border-radius supports safari 3 and later.
So if you wish to have support for safari 3+ you have to use -webkit-border-radius