On valid XHTML and CSS
Until now, I always made sure that the XHTML and CSS for this web site would be 100% valid. Writing valid XHTML and CSS is an important step in ensuring consistent behaviour amongst different platforms. Even though every platform has its own quirks and bugs, making sure your code is valid is a good way to start. Fixing problems on different platforms is far easier with a solid foundation.
There is, however, one thing about valid code, especially CSS, that is rather unfortunate. Insisting on valid code makes using some modern techniques impossible, because some of those techniques haven’t made it to official specs yet, so they will not validate. A good example of this is the border-radius property. It is bound to be included in CSS3, but since CSS3 is not even draft-status yet, that doesn’t help today’s projects.
Many modern browsers (IE and Opera being the notable exceptions) are, in fact, already aware of the technique, and it is available for use in those browsers, be it that in all cases I’m aware of, support still experimental. Usually the browser doesn’t support the border-radius property per se, but has a similar property in a “namespace” specific to the rendering engine, like -webkit-border-radius or -moz-border-radius. There are also some syntax differences between different browsers, like -webkit-border-top-left-radius vs -moz-border-radius-topleft. The same goes for more of those techniques that haven’t made it to spec yet. It’s a minor downside of using them, but no more than that.
So, using these techniques is interesting, because they suddenly make a lot of things that used to be fairly problematic or complex to implement, as simple and straightforward as setting a background image. If you’ve ever attempted to create a box with rounded corners that is fluid both horizontally and vertically in pure valid CSS, and then examined the border-radius property, you know exactly what I mean.
They also tend to degrade gracefully (being completely ignored) on browsers that don’t support them. But on the other hand, using them will inevitably mean invalid CSS. The CSS spec doesn’t know about engine-specific properties and values (nor should it), so neither does a validator.
Now there are of course all kinds of nasty hacks so one can use these techniques, and still have the site as a whole validate, simply by hiding the non-standard stuff from validators. For instance, on this website, a small CSS file that applies border radius to some elements, among other things, is loaded through JavaScript, so a CSS validator will never see it. But of course, in the end, you’re only fooling yourself when resorting to such tricks.
That’s why I have been thinking about this for the new design for this site that I’m working on. I’ve decided that perfectly valid code is no longer a requirement for my future designs, nor will I claim to use valid code in them (no more “valid XHTML” and “valid CSS” links in the footer). The reason is simple, validation is a means, not a purpose in and of itself. In my reconsidered opinion, there’s nothing wrong with invalid code, as long as you know why it’s invalid, that there’s no practical way to achieve the same while maintaining 100% validity, and your code remains semantically correct.
Conclusion: In my upcoming designs, I’ll have no hesitation to use such engine-specific properties, or simply properties that haven’t made it to official spec yet (i.e. text-shadow). I will still run my stuff through a validator, but I will no longer care about errors or warnings merely caused by using these techniques. I know that they’re invalid, I just chose to use them anyway, secured with the knowledge that any browser will simply ignore whatever it doesn’t understand.
P.S. This also means that when using a browser that doesn’t support a certain technique used for a minor aspect of the whole, you’ll be plain out of luck.
As long as everything remains functional and only some visual niceties are lost, I won’t care. That’s something I decided a while ago, and is already visible in the current design of this web site. The rounded corners on the yellow notices, for instance, are accomplished using CSS, so IE and Opera will simply display them as plain rectangles. Firefox, Safari, Chrome or anything else Gecko or WebKit-based, though, will display a box with nicely rounded corners with a radius of 5 pixels.
I’m curious as to the opinion of other web developers on this topic. If you are one, please comment.
Nice work, you made it to the front page of google when searching for “border-radius invalid css”!
I totally agree with you. I’ve used border-radius and text-shadow in my last few projects and I couldn’t give a damn if it doesn’t validate or is not visible in IE. Looks good to me and offers another reason why IE people should change their browser.
However, my current website of which I have only just started working on (taken over from someone else) has a “Valid CSS” link at the bottom of the page and now with my new fangly curved CSS corners, it no longer validates
So I might have to hide it with JS like you suggested… Or, convince the company to remove the Valid CSS link
// I don’t think many companies around here would know or care what it means anyway…
Agreed, most companies don’t give a damn, so long as it works. Just try to run a few random corporate web sites through a validator, there aren’t many that will get away without errors.
Of course, hiding stuff with JS is still a very viable option. It’s nasty, but heck, a particular web browser whose initials are IE is far nastier. We web developers can’t help it that people still want use that hideous thing.