A tip for those with CSS3 and/or vendor errors

[johnmaguire2013]

If you use things in your CSS that begin with -moz or -webkit, etc. you will probably get some errors on these during validation. If you are validating manually on W3C's Jigsaw service, simply hit "More Options" and change "Vendor Extensions" to "Warnings." Presto, gone. Additionally, CSS3 is listed in the same place.

The funny thing is, no matter how you set your options on that page, the CSS button it gives you is NOT going to follow that. It will follow the defaults. However, you can manually change the link to your liking. Here's an example: http://jigsaw.w3.org/css-validator/check/referer?profile=css3&vextwarning=true

Notice the GET variables profile=css3 and vextwarning=true. These will make sure that W3C validates your stylesheet correctly.

Additionally, if you're using HTML5, you can find a nice valid icon here (http://notepad.patheticcockroach.com/1733/a-valid-html-5-button-plus-a-valid-css-one/), which also provides a similar CSS one.

Hope that helps!

[digitxp]

Do you know if the judges will follow those links, or will they paste in the URL themselves?

I've been paranoid and assumed that they would just paste in the URLs themselves and have been using PrefixFree (http://leaverou.github.com/prefixfree/)...just in case.

[johnmaguire2013]

Do you know if the judges will follow those links, or will they paste in the URL themselves?

I've been paranoid and assumed that they would just paste in the URLs themselves and have been using PrefixFree (http://leaverou.github.com/prefixfree/)...just in case.

Very interesting link, I hadn't seen it before. But it still doesn't account for using CSS3 when the default is CSS2.1. I'm hoping the judges know enough to check properly. :)

[subrc]

I noticed this as well a while back, and changed our "CSS" link in our footer like you did. Turned out our stylesheet still had some errors in it thanks to normalize.css. I'm not too bothered by it though, and here's why.

There's technically no accessibility benefit to using completely valid CSS. CSS is just a presentation tool after all. Valid HTML is important because it allows your website to target browsers which you don't usually think about, such as search engines and screen readers. Valid CSS doesn't let you do this.

I have a hard time thinking you need to worry about whether you get errors for using vendor extensions in your CSS. Or about whether or not you are using hacks in your CSS, for that matter.

So right now, our website doesn't have valid CSS, and I'm not too bothered to change that. I'd love for someone to prove me wrong here and get me to fix that.

[johnmaguire2013]

I noticed this as well a while back, and changed our "CSS" link in our footer like you did. Turned out our stylesheet still had some errors in it thanks to normalize.css. I'm not too bothered by it though, and here's why.

There's technically no accessibility benefit to using completely valid CSS. CSS is just a presentation tool after all. Valid HTML is important because it allows your website to target browsers which you don't usually think about, such as search engines and screen readers. Valid CSS doesn't let you do this.

I have a hard time thinking you need to worry about whether you get errors for using vendor extensions in your CSS. Or about whether or not you are using hacks in your CSS, for that matter.

So right now, our website doesn't have valid CSS, and I'm not too bothered to change that. I'd love for someone to prove me wrong here and get me to fix that.

I have two counter-comments: First of all, if your CSS isn't valid, it will display differently in different browsers (even if they aren't the most commonly used ones) and even if it doesn't, you are supporting non-standardized code. Non-standardized code is what led to the <blink> and <marquee> tags. I also can't find the link right now, but there is a page which talks about how even vendor extensions are bad, because some users only use, for example, -moz-border-radius, instead of using the other browser's implementations, or the standard one as well, and other browsers are eventually going to start supporting each other's vendor extension implementations because it's the only way their users can see the same thing on particular websites. This is an issue because they are now adding in faux standards to the CSS specifications.

Additionally, I believe if you are going for the website award, valid CSS is a part of the rubric.

[subrc]

Ironically, the only reason we have to use invalid CSS is to increase browser support. border-radius and box-shadow are a part of the CSS3 spec by now, but older browsers only support the prefixed versions. After all, the whole point of using normalize.css was to get things to look consistent between browsers.

You make a great point about vendor prefixes, but I can't blame browser vendors for implementing features faster than they are standardized. It's certainly better than being the other way around. I have faith for now that the scenario you point out will never happen.

Also, non-standard code also led to some useful technologies like AJAX. The blink and marquee tags just tell one side of the story. Just pointing that out. :P

I care about standards as much as anyone and I understand FIRST's intention, but I think it makes sense to stretch the rules a bit.

[johnmaguire2013]

Ironically, the only reason we have to use invalid CSS is to increase browser support. border-radius and box-shadow are a part of the CSS3 spec by now, but older browsers only support the prefixed versions. After all, the whole point of using normalize.css was to get things to look consistent between browsers.

You make a great point about vendor prefixes, but I can't blame browser vendors for implementing features faster than they are standardized. It's certainly better than being the other way around. I have faith for now that the scenario you point out will never happen.

Also, non-standard code also led to some useful technologies like AJAX. The blink and marquee tags just tell one side of the story. Just pointing that out. :P

I care about standards as much as anyone and I understand FIRST's intention, but I think it makes sense to stretch the rules a bit.

I guess my other point is that increasing browser support via vendor extensions (i.e. prefixed versions) isn't invalid CSS. If I remember correctly, it's actually stated in the CSS3 spec that vendor extensions are valid.

And that's true, about AJAX, although isn't that pretty standardized now (despite the fact that all browsers use a different way of doing it... again, an annoyance, much like a "new feature" done during the browser war.)

I agree. :) I just don't think vendor extensions are stretching the rules, haha.

[johnmaguire2013]

And a link (http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords) for the spec stating that vendor extensions are valid. (Even in CSS Level 2.1, no less.)

[digitxp]

I also can't find the link right now, but there is a page which talks about how even vendor extensions are bad, because some users only use, for example, -moz-border-radius, instead of using the other browser's implementations, or the standard one as well, and other browsers are eventually going to start supporting each other's vendor extension implementations because it's the only way their users can see the same thing on particular websites.

For anyone who can't seem to find the link, the original source of this news was actually a co-chair of the CSS working group on a blog post (http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-FOR-ACTION%3A-THE-OPEN-WEB-NEEDS-YOU-NOW).

[johnmaguire2013]

Thank you. While not the site I found originally, you're definitely right that it's the original source for sure. The site I found even had a similar title, if I remember correctly. :)