Over the past few weeks I’ve received a number of emails from visitors to CSS3.info regarding CSS3 validation errors when using vendor specific extentions, for example -moz, -webkit, to implement CSS3 in their websites.
This certainly isn’t a new topic, and in fact Joost de Valke first raised the issue on this website back in January 2007, however a glance over the W3C mailing-list archive highlights that this debate is still going strong, with a number of interesting ideas raised, and I thought it would make an interesting discussion point for the CSS3.info community.
The problem is that, at present, none of the CSS3 modules have yet receached the status of becoming an official W3C Recommendation, as such any of these specifications could in theory be changed at time, particularly those that are still in the early stage of development.
Obviously browser vendors (with the exception of course of our beloved friend Microsoft) are keen to support these up and coming CSS3 specifications, however as they are still at an “experimental” stage of development it is necessary for the various css3 properties to be implemented using vendor specific extensions in order to avoid any possible conflicts with current or future css specifications.
Web designers are equally keen to implement these latest CSS3 techniques in their projects as browser support, along with interest from the wider community, continues to grow – a quick search around the blogosphere shows countless new CSS3 tutorials being added to the web on a weekly basis, and sites such as CSS3Gallery.net showcasing web designers putting CSS3 to great use in their projects. However many are facing a catch 22 situation, weighing up the pros and cons between utilising the latest that CSS3 has to offer against the fact that their creations won’t pass the W3C Validator, with some web designers even going so far as to question the importance of validation.
When Joost De Valk brought this concern before the W3C back in January 2007, he was met with a somewhat muted response, however the debate has continued to intesify and a number of interesting suggestions have been put to the W3C:
- That the CSS3 Validator could offer the option to ignore vendor specific extensions,
- That the CSS3 Validator could highlight vendor specific extentions with a warning, rather than an error,
- Or my own personal favourite, that the validator could mark such code as ‘experimental’ rather than error, or warning
Either or these methods would allow web designers to continue to validate their pages, an important process for spotting any errors in your code, as despite some designers questioning the importance of validation, personally I think it’s a necessary and important tool.
In the meantime, several web designers have suggested their own personal ways of overcoming the problem, with many commenting out CSS3 code until they have validated their pages, so that at least they can check the accuracy of their CSS2.1 code.
In conclusion I’d like to say that, in my opinion, both sides of the argument present some valid points – obviously the W3c can’t be expected to validate what isn’t technically valid CSS, however perhaps the word ‘error’ is too strong, and marking vendor specific code with a ‘warning’ or ‘experimental’ status would be a happy medium between the needs of the W3C and designers eager to implement CSS3.
At the same time, I have to question whether or not the time has yet come for designers to be implementing CSS3 in their client projects. I think CSS3 is perfectly acceptable to be used in a designer’s own projects, and quite essential to promote the growth of CSS3, but is it really acceptable to sell a client experimental code that could cease to function at any time if the W3C ammends a specification, or browser vendors change the syntax with which a property is implemented?
Once again I turn the debate over to you, CSS3.info’s readers, how to you feel about this issue, and what’s the best solution from your point of view?
Chris
This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.
40 Responses to “The Big CSS3 Validation Debate”
“so that at least they can check the accuracy of their CSS2.1 code.”
There is a profile already on the W3C CSS3 validator for CSS3 (a dropdown in the ‘More Options’ area. That of course, won’t validate against browser specific CSS.
Regarding validation, while it is important to me, I’m able to look past the -browser-prefix validation errors. I think some people are letting their OCD get the best of them when it comes to 100% validation and -browser-prefix validation errors.
Another question is what to do with all the funky Microsoft specific CSS like CSS Expressions?
Thank you kindly for the mention, much appreciated. We are constantly on the lookout for new sites daring to use css3 in their design. Hopefully over the coming months more and more lovely websites will be crafted and created using css3!
If in the mean time you have any suggestions, please feel free to send them over to us.
Our website is currently being designed and developed to its full potential and will be released mid September.
All the best
CSS3 Gallery
While I have yet to move my own site into HTML5/CSS3, I have been testing client sites’ and new pages without any issues when utilizing -moz, -webkit, -khtml extensions. It may be the Validation Tool. I suggest, http://validator.nu/ . Check whether version 3 of the tool is loading.
Seems like a trivial issue… if they’re that worried about validation, simply include all of the browser specific, non-validating properties in a separate stylesheet, and either keep them there, or only integrate them with the other stylesheets after validation has passed.
[Or better yet, just keep them integrated, and learn how to read the validation output, skipping over warnings reported for the invalid properties caused by browser-specific names.]
That said, validation isn’t that important. It’s a tool that developers can use to help troubleshoot problems in their code. Passing validation isn’t a requirement for release.
I really don’t care about the validation service like before. How many years we have to wait for something to become standard? Sorry but I want to use what is available NOW not when IE6 dies, after 5 or 6 years! Of course I keep my html valid and watch my CSS to work without critical errors. IMO properties starting with -prefix should not be treated like errors. What error is border radius? Sometimes the people who are making the standards have to look far from their nose.
I strongly believe that there should be an option to use experimental features and still be valid. The purpose of validation is to spot errors, usually spelling errors, missed quotation marks, missed semi-colons, etc. Such real errors are hard to spot if they are hidden among tons of “not-really-errors”.
From a teaching point of view validation is an exceptionally useful thing. It really helps my students.
OTO, putting vendor specific code in separate files is a maintenance nightmare and does not work well in teaching situations.
Actually, the CSSWG recommends dropping vendor prefixes at the Candidate Recommendation stage (not waiting until the full Recommendation stage). See the 2007 CSS Snapshot for details: http://www.w3.org/TR/css-beijing/#experimental So, for example, features from CSS3 Color no longer need prefixes.
Like others have said, it’s not hard to simply skip over the vendor-specific errors when reading the validator’s output for your page, so I see it as a non-issue. It’s only an issue if you like to put validation icons on your site which I think are unnecessary – no-one’s really interested except other web developers.
I’m also not above using CSS3 on client sites. There’s plenty of ways it can be implemented to non-essential design elements that add enhancements for modern browsers without causing problems in IE, e.g. text-shadow, RGBa, rounded corners.
Like others have said, it’s not hard to simply skip over the vendor-specific errors when reading the validator’s output for your page, so I see it as a non-issue. It’s only an issue if you like to put validation icons on your site which I think are unnecessary – no-one’s really interested except other web developers.
I’m also not above using CSS3 on client sites. There’s plenty of ways it can be implemented to non-essential design elements that add enhancements for modern browsers without causing problems in IE, e.g. text-shadow, RGBa, rounded corners.
I think validation is very important, it has helped me find all sorts of subtle errors in my code. But it has frustrated me that the validator doesn’t have an “experimental” or “proprietary” flag for -vendor code.
I think it would be best if the validator says that:
A notice instead of a warning or error would be good.
CSS validation isn’t really that important compared to HTML validation. Seriously people who argue that you need a valid style sheet are just being anal retentive, I would suggest running it through the validator to double check syntax errors and that’s all it’s for really.
Indeed, the “experimental” tag would be really handy. I’m not using CSS 3 for client work – apart from the reasons you mentioned I also try to make things work for IE 6 and that’s where everything stops.
In my own projects I occasionally use some CSS 3 to add something extra (like text shadows) but the site doesn’t depend on it.
@Neal – CSS expressions got dropped in IE8 so there is no longer a need to bother about them.
@Ryan – In some countries (as far as I remember Australia is the case) every website / web application funded from public money need to validate against standards, so adopting newest CSS3 techniques seems to be a problem there. HTML validation is very important comparing to CSS validation which is a bit less but still important.
In my opinion either marking browser extensions with a warning or as experimental would do the trick and help us a lot in adhering to and evangelizing Web Standards.
I care about whether the syntax is valid (am I missing a semi-colon?) and whether the key:value properties are valid (I’m not passing a percentage to background-color.)
I don’t care so much about how vendor specific prefixes aren’t in the spec (of course there aren’t, they’re vendor specific)
They’re certainly not errors, and why would you warn someone about something that clearly has been intentionally implemented? Noting vendor properties is clearly the way to go.
Since I started implementing CSS3 on my site I keep each browser and it’s respective rendering engine version separate from my main CSS 2.1 style sheet.
There is simply no reason for all the ambiguity especially invalid warnings for things like “missing” background-color or color if one or the other is set…we KNOW as web designers that if something is not set text usually falls back to black and background-color (except on the body) falls back to transparent.
Since serving my site as XHTML 1.1 (as application/xhtml+xml) I’ve had very little reason to use the (X)HTML validator…but the CSS validator has simply become a long running bad joke in my honest opinion. Not to mention the only way to really communicate with the people running it is on public mailing lists wild open to email harvesting bots. Brilliant!
It’s time we saw some much more decisive leadership at the W3C in regards to these issues.
[...] The Big CSS3 Validation Debate [...]
@John: “There is simply no reason for all the ambiguity especially invalid warnings for things like “missing” background-color or color if one or the other is set…we KNOW as web designers that if something is not set text usually falls back to black and background-color (except on the body) falls back to transparent.”
Actually, this is not true. Some users do not have black text or white backgrounds as their default. You should heed these warnings because they are correct.
No need to have the W3C mess with their validator just to work with all the possible browser extensions. This would most likely introduce bugs and cause too much of a headache for them.
Here are 2 things you can do to get around the errors:
1) Put all your CSS3 files in a css3.css file and then when you validate everything in your regular .css files should pass and that one should fail.
2) Put a /*CSS3*/ comment for each CSS3 line you have in your file, so when it gives an error you know why. This would work best if you put all your css3 rules as 1 line each.
[...] is a post on CSS3.info, The Big CSS3 Validation Debate where I left a comment I figured I’d make into a post here. It’s about how adding CSS3 [...]
I’m working on a redesign of my companies corporate site and using -vendor code CSS3 for drop shadows, rounded corners and a few other bits and bobs.
We’re then supplying IE with a conditionally commented stylesheet that uses images to replace these effects. It’s a bit more work but seems to be holding up and allowing us to do nice things.
Older versions of FF/Safari/etc will default to no shadows and square corners which is acceptable to us for such a small market share.
Whilst it means the main stylesheet doesn’t validate, we get a better looking site via less bandwidth that way… cheaper for us and quicker for the user. Sometimes validation isn’t everything.
The CSS validation issues surrounding CSS3 and vendor-specific extension started to become a concern for me on a couple of recent projects. I crafted a nice solution to these issues by using jQuery to apply the styles via scripting:
$(document).ready(function() {
$(‘.someClassName’).css({
‘border-radius’:'12px’,
‘-moz-border-radius’:'12px’,
‘-webkit-border-radius’:'12px’
});
}
Obviously not ideal or useful for every context, but if CSS validation is an issue for you then this technique may help. I used jQuery for this example, but you could use any JavaScript library or roll your own script.
@Bille D.
I beg to disagree. That is not a “nice” solution.
Using JavaScript for the sole purpose of cheating the validator – CSS or HTML – is defeating the whole purpose of validation.
http://itpastorn.blogspot.com/2009/06/validation-and-doctype-myths-and.html
Your code also reminded me of another snippet I wrote:
http://itpastorn.blogspot.com/2009/06/do-not-put-experimental-features-last.html
Personally, I use validation as a trouble-shooting tool rather than a launch requirement. If an element on my page is behaving in an unexpected way, my first trouble-shooting stop is to validate the html, then the css, and finally the javascript. I’d say that around half the issues I run into can be solved that way. When I am using CSS3, I don’t find it’s much of a problem to just skip the errors it’s causing in the validation, though I think it would probably be fine to simply mark those lines with a warning and call them out as experimental. That might be really helpful depending on which problems you’re trying to troubleshoot.
I’ve also carefully started using CSS3, both in my own work and in work for clients. If the browser doesn’t support border-radius, then the page is not broken, it’s just lacking a rounded corner. In many cases, that’s perfectly acceptable both to me and my clients. As long as the CSS3 you’re using degrades gracefully in browsers that don’t support it, I see no issues with using it.
@Jakub – With IE8 still accounting for a minority of IE’s share of the market, I’d hardly say it was time to stop worrying about CSS expressions. Those will be causing validation errors for some time to come. Perhaps, those too, could be marked as experimental.
As long as it doesn’t damage brand integrity, then there is nothing wrong with gracefully degrading a clients website for older browsers.
[...] One interesting comment I read suggested that we separate the valid CSS and the CSS3 styles so that when css validation fails, we know why. Original article [...]
Validation isn't everything, but I do agree that it is a useful check that your code is semantic and correct. My personal approach is to keep all CSS3 elements in a separate file, thereby keeping my main stylesheet valid and "clean". The small hit on bandwidth is a small price top pay IMHO.
I liked when you mentioned :
- marking the code experimental; no warning or errors.
- developers should not sell css3 code to their clients YET
@Montoya Then that would be a suggestion, not a warning.
A competent web designer will set the text color for paragraphs and spans to black even if they are black by default.
So the warnings are completely out of context. At best these are suggestions and they are clearly and explicitly targeted at web designers who don’t understand this…yet they appear for everyone’s CSS. That’s like warning someone they could get in to a car accident just because they’re going to drive their car.
There’s a discussion about using CSS3 in production on linkedin: http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&gid=2071438&discussionID=6894020&goback=.anh_2071438
What I do to solve the problem of validation is similar to the following:
document.write(‘::selection {background: #ffb7b7; opacity:0.4; /* Safari */}::-moz-selection {background: #ffb7b7; opacity:0.8; /* Firefox */}’);
I insert the css3 code with javascript, so that it displays properly and can be validated
I just feel like they need to implement css3 already hell even css3 needs more stuff. There so many things that need to be worked on for CSS to be used efficiently and easily. Many of those codes are not available…so why are we still staying behind?
I think it’s important for developers to use CSS3, even at this “early stage”, to push the technology and encourage the W3C to speed up their approval process (or whatever it is) – why the heck is it taking so long to make simple things like border-radius and rgba colors official??
It does of course depend on the client. There’s nothing wrong with telling them – we can enhance this design using CSS3 but it may not look identical in all browsers. If that’s acceptable to them then why not do it, right. If they say no we don’t want that – well, it’s no sweat off my back.
I’ve been using CSS3 more and more in my projects, personal and professional, going even as far as using webkit-transition. It doesn’t even work in FF of course, but the small animations effects are not paramount to the design, while to those that do see them it adds a nice touch.
[...] http://www.css3.info/the-big-css3-validation-debate/# VN:F [1.6.8_931]please wait…Rating: 0.0/5 (0 votes cast)VN:F [1.6.8_931]Rating: 0 (from 0 votes) [...]
I don’t care about css validation, because when I forgot to add «quote» mark or bracket, code highlight goes crazy after error, and I immediately fix it.
And it’s not strong argument for me, not to use wendor-specific (like ::selection or -moz-box-shadow) properties, just because validator won’t pass it.
I want to know about css3 n what is benefit to work with
@matthew “What I do to solve the problem of validation is similar to the following:
document.write(’::selection {background: #ffb7b7; opacity:0.4; /* Safari */}::-moz-selection {background: #ffb7b7; opacity:0.8; /* Firefox */}’);”
This is the worst suggestion on this blog. Rubbish – do not use document.write. EVER. Use event handlers to run javascript as needed. NEVER use document.write. That is remedial school scripting.
And using script to hide css from a validator is a a bad idea, anyway.
[...] Article about CSS3 validation [...]
I don’t know if this has been mentioned, but a trick we learnt when developing our Joomla template framework Morph, is to include browser specific stylesheets, then add the vendor specific css there.
For example, -moz-border-radius would go in the firefox.css and -webkit-border-radius would go in chrome.css, safari.css or webkit.css. The neat part is because the validator is seen as its own browser “engine”, none of these browser specific stylesheets are included when the validation is done, thus any site using this method can take advantage of these vendor specific selectors and still have their site validate.
Important to mention that this doesn’t work on the local validation service built into the Firefox Webdev toolbar, but it works 100% on the online “live” version of the validator (which is the one that counts anyways).
Hope that helps ;)
Cheers,
Chris
I just faced the same problem, but in my opinion, the validation services is there to help, it’s not a goal to validate and then brag about it with a shiny (not so much) icon. If I write colour instead of color, the validator will tell me and I’ll change it, but if I use -moz-something-awesome, I know what it does and that it works, no need for me to care about the “invalidity” of my site.
Is there any other w3c valid way for overflow-x and overflow-y ?
Leave a Reply