Should you validate CSS?

Vendor specific / Proprietary extensions

[httpwebwitch]

I'm on a mission to validate via the W3C.

All my HTML is fine, but I get warnings from the CSS, like this one:

"Property -moz-border-radius-bottomleft doesn't exist"

"Property -webkit-border-radius doesn't exist"

How disappointing. I like using -moz border stuff. It looks pretty.

What can I do about this?

[quesera]

I think you have three options:

1. Drop the vendor extensions and just use the ratified property names, which won't work as desired in all browsers.

2. Run your own copy of the validator code and teach it to recognize vendor extensions.

3. Ignore the spurious warning reports and keep going.

:)

[SuzyUK]

I agree with #3 :) quesera!

@witch, vendor extensions are not W3C "standards" so they will never validate, they are often a step to speeding a property to a standard (i.e. you will be able to use it without the extension so that it will validate) - So as you said you like using them, as long as you know they are progressive enhancement "pretty" stuff then read #3 again.. carry on!

[g1smd]

I use the validator to tell me about errors such as typos for property names and the usage of non-valid values and missing units.

If you know an error or warning is caused by using a browser-specific feature then you can generally ignore it.

[alt131]

I vote for this:

Run your own copy of the validator code and teach it to recognize vendor extensions.

;)

More seriously, nothing much at this stage, because, as suzy says, proprietary extensions are, by definition, not standard, so will never validate - unless someone discovers a valid way of hiding them from the validator as we do for ie using conditional comments.

So I'd ask what you are trying to achieve by validating.

I have just one coding goal: To deliver accessible, useable content available to 100% potential users regardless of platform/device/ua. Validation is one tool available to facilitate that aim, so I use it similar to g1smd - but it remains just one tool given it is possible to have valid but unhelpful code: display:none being the classic example. I rarely use non-standard code, but if I do, I don't worry when the validator objects once I have assured myself the code will not detract from my priority aim.

However, if the end goal is validation for it's own sake - as it is for some govt departments where policy explicitly specifies this as an unqualified priority - then you're stuck without vendor extensions.

If you aren't in a govt-depart type scenario, then what you decide has political implications - I think there have been several sea-changes over the years: (1) Once they were common (at least their forebears - as the only way to get anything done), (2) then despised as deviating from the standards, (3)then only ie treated as deviating, (4) now increasingly more accepted given the delays in css development. Coupled with that the really influential coders seemed to have moved from demanding ua's comply with the standards - back at (2), to using them. as suzy says to reinforce the property is desired, and help speed introduction of the property as standard per (4).

So, if your basic code delivers content to all users, the vendor extensions are part of planned and managed "progressive enhancement", and you don't mind the political implications, there is little reason to avoid them. However, just be aware, this ties you to the individual vendor development programme. Keeping up to date with the status of all the css modules can be bad enough, without taking on the burden of browser and version specific property-level implementations like this: moz-border-radius [developer.mozilla.org]. That can make for a lot of reviewing work - or pushing wads of out-of-date code down the pipes unecessarily.

[SuzyUK]

I wanna tell you a story.. [Max Bygraves echoes.]

it's just not that simple anymore, as in clicking a button and getting green tick, in the past we had to "hack" to make things work, or more rightly in order to use "progressive enhancement" - hacks would never validate either but they made things happen and enabled folks to use the "pretty stuff" of the day..

however they didn't have things like vendor extensions then [in those days] so the recommendations, or recommended way to do things, was usually good enough.. that was until a particular browser decided to implement something/a property a little differently to another vendor.. then the hacks had to get a bit more complex because you had to browser "sniff" .. enter all those complex hacks or some JS, though obviously CSS Hacks for a CSS enhancement would be preferred

then everything stagnated, but in a good way, all browsers agreed on how to implement most things .. yippee we had a "standard" of sorts and IE well it had conditionals which would serve to hide it's proprietary syntax from validators anyway.. all was good in the world of perfectly validated code, outwith "standards" it was still good as a tipping point was reached

but.. that wasn't much good really was it because all those forward thinking browsers who'd done so much good as far as CSS progression is concerned were now told to stop, unless they used a browser specific "vendor" extension.. that's Ok too as it will still mean things will progress, they can carry on "introducing" functionality but we authors now have the hoops to jump to be bothered to type all their extensions..

this progression however is now more "transparent" than it was before, instead of the browsers competing and following the "winners" success they will now, in all likelihood, retain their extension for longer in the hope that their interpretation of the recommendation will be right.. Major Brownie Points!

so IE conditonals (-ms- extension introduced to certain degreee in IE8.. likely to be more prevalent in 9!) -moz, -o and -webkit we have.. let the battle commence ;)
and hope, yet again, that common sense will prevail


if you want a recent (ongoing, in a geeky interesting kind of way) example of this check out the linear gradient property..

IE have had it since 5.5 through a filter, mozilla adopted the recommendation, but rightly still used their -moz prefix, -webkit (Apple Safari and Chrome) introduced their own way, but still usable because of the vendor prefix, but they have recently kow-towed to the -moz, W3C recommended syntax, Opera haven't even gone there yet, surprisingly?, though they have introduced their own method (SVG), which interestingly IE9 also apparently supports.. it's only gonna get more fun from here on in!

I even found an instance where Chrome (webkit) treats a box-shadow differently than Safari (webkit) what's up with that then? no hack nor browser extension is fixing that one, so is it back to browser sniffing if this type of thing becomes prevalent :o

In all this is very special time, the pretty things are going to happen, are happening, and the how is playing out in real time :)

So go for it, the 'validator' simply can't keep up ;)

[alt131]

Nice story - but did browsers really get told to "stop" development?

this progression however is now more "transparent" than it was before, instead of the browsers competing and following the "winners" success they will now, in all likelihood, retain their extension for longer in the hope that their interpretation of the recommendation will be right.. Major Brownie Points!
...
I even found an instance where Chrome (webkit) treats a box-shadow differently than Safari (webkit) what's up with that then? no hack nor browser extension is fixing that one, so is it back to browser sniffing if this type of thing becomes prevalent

This is the fundamental flaw in the "speeding a property to standard" argument. More so since ie lost complete dominance so more browser manufacturers are able to come to the table arguing their market share means "their way' should be the "new way", and refusing to conform to any "standard" that isn't. I guess this is a good idea if you have never faced a BSOD caused by NN4 choking over a simple style effect because proprietary javascript got served in the wrong sequence.

The way forward is to continue to insist that browsers conform to the standards/recs. That was the way out of the mess, and it worked. Things went wrong because coders demanded browsers conform, then failed to demand the standards/recs continued to evolve.

Using browser non-conformance to resolve the issue of the recommendations stagnating is using the wrong tool for the job - and a tool already known to create complete chaos. The illogic just addles my brain - the recs/standards did not stagnate because browsers conformed, they stagnated because they were allowed to stagnate. That isn't fixed by lauding non-conformance and encouraging browsers-wars, it is fixed by ensuring the recs/standards do not stagnate.

And if anyone cares, section 4.1.2.2 lists 13 vendor-specific prefixes. Happy code maintenance ;)

[alt131]

Ouch!
Suzy, my opening doesn't read like it sounded in my head! The sentiment it should have conveyed was more like:
Nice story - thanks ;)
But, hey ... did browsers really get told to "stop" development?

[SuzyUK]

no of course not Karen :) just a bit of dramatisation, artistic licence in my wee story.. what is more correct is that they 'had to' start implementing support for not-yet-standard properties with their -vendor-prefix (that is actually in the recs somewhere I think)- for the best reasons? who knows, though I think intentions are good;

At least now there should be no need for browser sniffing, no scramble to find OS specific parse hacks - we still get to use the stuff as support arrives, and as far as clients and validators go it should be understood that the use of vendor-prefixed bit of CSS is an enhancement, a stylesheet with vendor prefixes looks (a wee bit!)nicer than one full of /**// (), hacks and is actually more legible

BUT..
the transparency may well lead to a more public (source code wise) battle of wills & a lot of

Happy code maintenance

:)

[SuzyUK]

actually should have added, and back to the topic.. it should be easy enough to get the validator to ignore/skip lines of code with a vendor prefix you would have thought?

just like we don't bother validating IE conditional sheets, you could always put the "extra" code in another sheet too and not bother running that past the validator - but really what's the point! I somehow don't think that would play out anyway as even in big apps developers still prefer to use 'in sheet' parse hacks for IE.

oh and if you think the -vendor-prefixes are a nightmare, the other way to do it would have been IE style sacrilege perhaps, but I'm not the first to say that out loud - conditionally fed CSS by browser, I believe that was suggested btw, think of it, many sheets instead of extra lines! - CSS Browser sniffing :o

CSS did need a method, to stop the stagnation alt131 speaks of, just in case the browser a's interpretation of a "standard" syntax recommended property differed from browser b's on implementation, like it used to be.. but the browsers are again leading the way in pushing the recommendations forward to a new "accepted" standard - leading by doing

guess the way to see if this logic is working or not is to see if anyone is using the 'new' stuff ;)