Do you validate your CSS?

We all heavily evangelize the validating of HTML code and think it’s just a given, right? But how about the CSS code?

I think I can honestly say that it is very seldom that I validate the CSS code I write, and I’m not really sure why that is. Laziness? Perhaps. But I think it also comes from the default warnings you get with the online CSS validator, and that I got fed up with them and just stopped validating.

However, Rog wrote a good article some time ago, CSS Validator colour warnings are not errors, which basically explains that most of the warnings are superfluous and if you use CSS 2.1 or CSS 3 features, you can easily use More Options to customize your validation.

Looking at my own behavior, though, I just have to ask:

Do you validate your CSS?

Posted in CSS,Developing,Technology |

37 Comments

  • No, no I don't. It's good for detecting problems but having my CSS validate isn't a priority, and I owe that to the flexibility of the format. Plus, with some of the techniques I use, I can guarantee that some things simply aren't part of the spec and would therefore fail validation.

  • Lim Chee Aun says:

    Most of the time, no. Why? Because I am the validator. :D

  • Georg says:

    To find typos and other mishaps, yes.

    For "validity", no.

  • Eddie Welker says:

    No, I don't. When I am writing CSS, I am usually working on one specific object. When I am done applying styles, I check it. If I see that something isn't there, then I go back and look at why. 99 times out of 100, I see it instantly. If I don't, I usually find it the next day.

    I do, however, use syntax highlighting to make sure that what I am writing is correct. That could be considered a light-weight validation technique.

  • No, I don't. With the false warnings/errors the CSS validator gives it doesn't really help. If I have syntactical errors one look at the site will make that clear.

    Next to that, the use of non-standard css for certain browsers (that includes all -moz- etc style properties, not just IE stuff) practically invalidates all CSS I write.

  • Phil Nash says:

    I don't tend to validate my CSS, and even worse, I know there's a typo in mine that causes it to be invalid, even if the rest of it is ok!

    Why is it that HTML validation seems much more important that CSS validation? The same future proofing arguments exist, but admittedly JavaScript doesn't affect CSS like it does HTML, so it isn't such a potential point of failure. In fact, CSS is the decoration and behaviour doesn't really depend on it at all.

    At the end of the day, it's nice to have valid CSS, at the end of the day, it's another quality check that isn't hard, so why shouldn't we validate?

  • David Read says:

    I don't validate my CSS but think it should be done. If you manage large developer teams, it is a way of achieving consistent delivery.

    We validate markup why not CSS? (Phil is right it is a another quality check)

  • David Naylor says:

    I don't.

    I tend to lean on the browsers handling errors correctly. For instance I sometimes write compact CSS without spaces, which I'm guessing wouldn't validate?

    But the difference is this: Valid, semantic markup helps the user. If the CSS is valid or not doesn't really make any difference to the user, does it?

  • I dont't, for the same reason as David Naylor.

    I don't think my CSS would be more helpful to the user would it be valid.

    Also, like Kilian, I use just too much "invalid" CSS, which would make validating a pain.

  • Andreas says:

    I agree with David and Harmen. Invalid CSS harms no-one. If it works it works so who cares if it validates?

    I've also completely stopped using conditional comments to include separate stylesheets for IE due to the extra requests and the fact that the CSS can't be structured modular in the same way. Instead I consistently use the _-hack for IE6 and * for IE7.

    In addition to that i often use -moz and -webkit CSS-properties (border-radius etc) which doesn't validate either.

  • Jens says:

    Rarely, and only if I run into problems.

  • I do. It helps me catch errors caused by typos. Errors that may not be immediately obvious when checking the result in a browser. Errors that different browsers may treat in slightly different ways, like a forgotten semicolon or a missing curly bracket.

  • No, not really, FF's console catches most typos anyway.

  • Dan Shields says:

    I only do if I can't find an error in my stylesheet

  • Deborah says:

    I validate my CSS. I find there's always something I missed in the CSS (how to contain children correctly) or I've forgotten a semi-colon.

  • Robert Nyman says:

    Thanks for sharing, people! Quite interesting and diverse answers!

    I guess there's no reason not to validate, and it practically take no time. On the other hand, I do agree that valid HTML is more important than valid CSS.

    I guess the conclusion is that validating CSS is a good thing, though, to avoid misformatting and potential errors (I recently got stuck in a non-applied style in IE 6; the culprit was a rule looking like this: <code>#navigation a:hover;{</code>).

  • I do. Every time I finish a CSS job, I throw it through my validator.

    Haven't run into a validation error for two years though, since my ugly CSS is in the iefix.css file. Errors in CSS are typically healing themselves in form of weird rendering during development phase, which is fixed right away by the author.

    Aptana plugin for eclipse also do live validation, correcting me on misplaced or missing semicolons, typo and similar.

  • Jens Meiert says:

    As a matter of course, and neither only against CSS 1 nor without fixing eventual issues. :)

  • Erik says:

    I just turn on the "Display Page Validation" feature in the Web Developer firefox addon – it checks both html and css.

    I think that one of the reasons why css validation is rarely done is because they don't work if they're wrong!

  • Steven Clark says:

    I tend to validate my CSS. Why?

    Because the number of times that I had an issue and it turned out to be something like "margin-left: 0 0 20px 4px;" (yes that's just an error) in the CSS its just easier to have that link to the validator at the bottom in development. Rather than try to figure out whether its a bug or not. The truth is – shock horror – I'm not perfect and I sometimes inadvertently put little errors into CSS accidentally.

    Others have greater attention to detail than me and can live without it I expect. :)

    And, when you think about it, if we're pushing web standards as a thing you aspire to meet then dismissing css validation as uncool or unworthy is somehow saying "some specs are wood and some are stone".

    IMO whatever works for you I guess…

  • Tommy Olsson says:

    Not always. As others have said, using an editor with syntax highlighting catches most of the typos. If it were as simple as validating markup (Ctrl+Alt+V in Opera) then I'd probably do it more often. :)

  • bruce says:

    yes, I do validate my CSS – but often ignore the errors it tells me about (for example, vendor specific prefixes).

    But it’s amazing how often I’ve made typos which some more forgiving browsers ignore, and apply the rule, while others ignore the rule. (Wish I could think of an example…)

  • bruce says:

    yes, I do validate my CSS – but often ignore the errors it tells me about (for example, vendor specific prefixes).

    But it's amazing how often I've made typos which some more forgiving browsers ignore, and apply the rule, while others ignore the rule. (Wish I could think of an example…)

  • Peter says:

    I think it's a little hypocritical pushing web standards on people and only making sure the HTML is valid. My opinion is that you should do it, just as often as you validate your HTML. I don't use proprietary tags (like zoom: 1; or .htc files) so that certainly makes it easier for me. Most experienced developers will write valid HTML / CSS the vast majority of the time anyway, so it's not going to add that much time to your schedule.

    It's also made easy by common browser extensions:

    Web Developer for Firefox – Tools » Validate CSS)

    Web Developer for IE – Validate » CSS

    • CTRL+ALT+ V in Opera

    I've never used Safari as a Primary Browser so I don't know if Web Inspector has CSS Validation built in. If not, I'm sure there's an equally simple way with another extension.

  • Götz says:

    After I got my HTML valid I usually check the CSS. But often I do not check it again, when I changed my CSS file a little bit.

    But sometimes validating CSS does really help. A friend of mine runs a WordPress blog and well, he's not too much into HTML and CSS. Sometimes he asks me for some adjustments of his design, and then I'll tell him how he could achieve that. A few weeks ago we broke his CSS completely. I told him, that he should look at the validation result – as it was not valid. But I myself didn't pay much attention to the results because the errors seemed to me to be unimportant. But I didn't notice the actual problem, which the validator also reported between the few minor errors or warnings. After some searching in the code he found the missing } or something like that.

    If we both had paid more attention to the validation results, we would have saved some time.

  • Yes, although I know which warnings to ignore…

  • Ceriak says:

    Why should I? CSS is just too simple to do so.

  • mdmadph says:

    There's a such thing as "valid" CSS? :P Syntax-wise, maybe, because last I checked, even open browsers like Firefox had proprietary CSS properties for everything under the sun.

  • [...] about whether people validate their CSS, it made me wonder about how/if people ensure the quality of their JavaScript [...]

  • Robert Nyman says:

    Thanks for your input!

    Peter,

    While I agree that it is, to a certain extent, hypocritical to promote HTML validation and not CSS validation, I'd say that if you were to choose, HTML is widely more important.

    Personally, I use <code>zoom: 1;</code> or <code>height: 1%;</code> in a separate file served only to IE, since there are scenarios where that is the only solution to meet hasLayout problems.

  • Barney says:

    I don't see the prerogative in making the workings of my presentational code 'valid'. It would (not could) compromise the presentation.

    Honestly, what's the real incentive? Standards exist for reasons. Future proofing the code for how something is meant to appear for the idealistism of unambiguous, standardised readability is simply not a decent argument against making your site look good accross all browsers. Who wins from the trade off?

    Formless, unrewarding ideologies — not users.

  • Rob Mason says:

    Every time. Just forms part of my standard quality control checklist.

  • Stephen says:

    Yes & No.

    Stick it through the validator to catch typos, just for those doh! moments, and then ignore the errors you know won't validate like the * html, _ & -moz hacks… which are useful.

    But always validte HTML.

    S

  • Bangkok Food says:

    I dont think it's that important to have your site valid for the final work… but it is important to validate during development, to have your code as clean as possible and eliminate problems.

  • Nico says:

    Validating CSS and HTML I think is a must when it comes to standards and it does pull you up on mistakes that might have been made.

    But it annoys me when I know all my CSS is fine and through IE being a pain in the bum and having to use hacks and resets, many properties are not supported! and it is seen as a failure!

  • Spunky Jones says:

    I have checked out my CSS for a while. Just check SJ and the sociable plugin has broken the validation again. It happens every time the plugin gets updated..

  • SEO says:

    I can`t validate zoom 1 of CSS.
    Can you help me ?
    My site obsht.com

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>