HTML & CSS
Article

The New W3C Website Goes Live … With Invalid CSS!

By Craig Buckler

W3C websiteFollowing requests for feedback in April, the W3C finally launched their sparkly new website on 13 October.

The World Wide Web Consortium (W3C) is an international community of organizations, full-time staff, and public members who work together to develop web standards and technology specifications (HTML, XML, CSS, DOM, RDFa, SOAP, SVG, semantic web, etc.).Until recently, those of a polite disposition would describe the website as functional rather than usable or attractive. The W3C hope the redesign will make the site easier to navigate and more pleasant to use.

The new site is undoubtedly an improvement. The design is clearer, far more attractive, and works on all modern browsers (as well as IE6). A flexible layout is used which switches to a “mobile view” single column when the browser viewport width is reduced below 481 pixels. It’s a nice touch, although I’m not convinced many mobile users have an urgent need to access the site?

The content is as thorough as ever, although it’s evident some pages are incomplete. The first sections I visited were browsers and authoring tools — these are of significant interest to developers, yet no content is available? It’s understandable that the site and specifications will evolve, but why provide a home page link to missing content?

Behind the scenes, the site uses XHTML 1.0 strict throughout and every page I tested passed validation. Ironically, the CSS does not validate primarily because of numerous IE6 hacks. Neither does the site pass automated accessibility validation: form controls have missing labels, there are linking issues, and descriptive meta tags are not used.

The “view: desktop, mobile, print” control at the top of the page is powered by JavaScript. Unfortunately, it lacks progressive enhancement: the control never appears if JavaScript is disabled or unavailable in your browser. That strikes me as slightly bizarre: a control which benefits mobile users will probably fail on many mobile devices?

The view control is the only JavaScript functionality I could find. So why does the site require the full jQuery library and a cookie plugin? I’ve nothing against jQuery, but a better standalone widget code could have been developed which was a fraction of the download size and supported more browsers.

Perhaps I’m being a little overly-critical, but shouldn’t the W3C lead by example? I like their new site, but it would be better if the developers had followed the guidelines they were publishing.

What do you think of the new W3C site? Should they fix the validation and accessibility problems? Or are they simply using the hacks and shortcuts many web developers use on a daily basis?

Links:

More:
  • http://www.japenga.eu treurmars

    Yes, as leaders in the market they should lead. The switch to mobile browsing is a nice touch but is doesnt work in firefox 3.5.4 so why implement a nice gimmick for something that does not even work in a major browser?

  • http://www.optimalworks.net/ Craig Buckler

    That’s weird. The automatic mobile view was working in Firefox an hour ago?

  • http://www.japenga.eu treurmars

    Weird, when I turn off javascript (with the webdeveloper toolbar) it works fine.

  • Leandro (inkel)

    Ehem… the very same sir Tim Berners-Lee has an answer for you:

    http://twitter.com/timberners_lee/statuses/5420639169

  • Seba

    The CSS file has some IE6 hacks :)

  • http://fvsch.com Florent V.

    @treurmars, chances are you clicked one of the view links on the top, then the JS script stored this information in a cookie. It looks like when you’re in desktop view and the cookie says you choose desktop view, the automatic switch to mobile view won’t trigger anymore. Not sure if that’s the best solution but that’s understandable.

    Meanwhile, with no JS, i think Firefox is just using media queries or something like that.

    Should they fix the validation and accessibility problems?

    Accessibility, yes, if possible. Validation, no, or at least not for the sake of validation. Validation is a tool, not a goal.

    I don’t know how severe the accessibility problems are. Note that you can code a website that’s quite accessible and have it fail some automatic tests (descriptive meta tags? what a joke). And you can code a website that passes automatic tests, but that offers very low accessibility. So maybe the new W3C site is already a good example of an accessible website. ;)

    The most important problem right now for the overall quality of the website are the missing content issues. They should fix that first.

  • Jojo The Dancing Bear

    the word is disposition not deposition.

  • http://www.optimalworks.net/ Craig Buckler

    The accessibility problems aren’t major, but there’s no need for them. I’d love to see a report from accessites.org — if you think I’ve been picky, those guys will really dissect the site!

    As for the CSS, I agree that validation is a tool, but why are the W3C resorting to IE6 hacks? The design is simple enough for IE6 to handle.

    Shouldn’t the W3C practice what they preach?

  • Integralist

    @Craig Buckler “The design is simple enough for IE6 to handle” I’m afraid even the most simple designs can be heartache with IE6 so don’t hate them too much for resorting to hacks :)

  • http://www.optimalworks.net/ Craig Buckler

    @Jojo
    Whoops – now corrected. Thanks.

  • Anonymous

    The irony with this is proof of validating your pages is big bag of Bull****.

  • http://www.optimalworks.net/ Craig Buckler

    @Integralist
    IE6 is a pain, but it’s still possible to produce valid CSS without resorting to * and _ hacks. A little understanding of IE6’s issues goes a long way.

  • http://www.cemerson.co.uk Stormrider

    “Shouldn’t the W3C practice what they preach?”

    Since IE6 doesn’t practice what the W3C preach, I hardly think they can be blamed for using a couple of hacks to make sure more people can read their site!

  • http://www.optimalworks.net/ Craig Buckler

    A couple of hacks? There are 30 errors and 416 warnings!

    The fact remains that it could be implemented with no errors and still work in IE6/7. The design’s hardly cutting-edge and no one’s asking for pixel perfection.

    Incidentally, the automatic mobile view is working in Firefox again???

  • icantthinkofone

    If you follow the W3C blogs a couple weeks ago, you would have read that they were well aware of this and it was intentional in order to use….I forgot. I’d look up the link but I’m sure you can do it on your own.

  • http://www.optimalworks.net/ Craig Buckler

    Mmm, sounds like an excuse to me! Even so, it doesn’t explain the lack of progressive enhancement. Using jQuery was overkill too.

  • Integralist

    @Craig Buckler With regards to making CSS validate, yes I agree this is totally possible and something the W3C should have aimed for (it’s the W3C so they should be flag bearers). But I must admit I have experienced certain designs that just love to be the exception that disproves the rule.

    I’ve worked with IE since version 5 (anyone remember Tantek Çelik’s invaluable services) and yes experience & knowledge of these bugs obviously helps avoid the need for hacks, but more importantly I think what the W3C should have done was use conditional statements rather than hacks if they were having major issues.

    But I agree that on the face of it the design isn’t exactly ground breaking :)

    Wow, I just remembered a day, way back, when I was so happy to see the end of my company’s support of IE5/5.5! I can’t believe looking back how happy I was that I only had to develop for Netscape Navigator 4 and IE6 :)

  • Tim

    Maybe they finally figured out that even they can’t implement all of the standards they have in place. So many documents on that site, where are you supposed to start? It’s not exactly logically indexed from a problem solving point of view. It assumes you have a rough idea of what the “technology” is called that you are looking to implement.

  • Tim

    View the source of the home page and look through the comments. Looks like they’ve been using smarty templates.

  • one

    Visually the site looks better compared to the old version, but come one… using border for text decoration? wtf! And the IE hacks??? Those people are recommending something that they don’t follow themselves. It’s ridiculous!

  • USPatriot

    This proves, web-standards suck! The elitest are now the defination on hyprocrisy. Thats why I will ALWAYS use tables! Come get me CSS nazis. hehe

  • USPatriot

    Still by into the hype? Smoke and mirrors people, smoke and mirrors…

  • http://www.optimalworks.net/ Craig Buckler

    Here’s the W3C blog post (thanks to Mr Tim Berners Lee for sending it!)
    http://www.w3.org/QA/2009/10/w3c_site_launch.html

    It claims the validation errors are a problem with the CSS Validator, but they’ll be evolving toward valid CSS. The site’s been in beta for 6 months … how long does it take?!

    There’s no mention of the missing content, accessibility issues, and lack of progressive enhancement.

  • markmccorkell

    I think they should at least adjust their validator to take new things into account. Their validator spits up errors when it see’s CSS3 references, which is silly because it’s not wrong!

  • http://brianswebdesign.com skunkbad

    I’m pretty impressed with how the site switches to mobile view.

    Regarding their site validating… I see them as being kind of like the US government. Say one thing but do another. Yes, it does matter, but it’s not the end of the world. We shall live to be told what to do yet another day.

  • PCSpectra

    Absolutely lead by example.

    Or are they simply using the hacks and shortcuts many web developers use on a daily basis?

    I hate the word “hack” it drives me batty when people are lazy and use shortcuts/hacks to just get it done.

  • http://www.lunadesign.org awasson

    Here’s the W3C blog post (thanks to Mr Tim Berners Lee for sending it!)
    http://www.w3.org/QA/2009/10/w3c_site_launch.html

    It claims the validation errors are a problem with the CSS Validator, but they’ll be evolving toward valid CSS. The site’s been in beta for 6 months … how long does it take?!

    There’s no mention of the missing content, accessibility issues, and lack of progressive enhancement.

    Craig, I hope your developing skills are better than your reading and comprehension skills. The paragraph you are looking for where they talk about the missing content is marked with the number two (2).

    But seriously…
    I for one like the new site and appreciate the new design. I can only attribute the backlash by the various posters here as sensationalism, a need for attention, or a lack of awareness of how much of an improvement this is over the old site.

    I question whether some of the people who are critical of the new site actually tried to use the old site for research; I have. I used it at least ten years ago to get a handle on all of the technologies we take for granted today and I know it would have been much easier to use with the new design.

    Besides, if you want to make an improvement, the door is open. They want people to contribute: site-comment@w3.org

  • http://www.optimalworks.net/ Craig Buckler

    @awasson
    I don’t think anyone’s said that the new design is a backward step — it’s a significant improvement over the original.

    What surprises us (developers) is that they’ve not used valid code when many of us strive hard to achieve that. How can we extol the benefits of best-practice techniques and standards to other developers who then find the W3C’s own site doesn’t adhere to them? It’s disappointing and totally unnecessary.

  • http://www.lunadesign.org awasson

    Disappointing? Unnecessary? Are you having a hard time accessing the page? Is it rendering incorrectly when you use different browsers or platforms?

    It might be time to take a breath and think about what’s important. It’s a website and it has to render on a collection of imperfect browsers. The last time I checked none of the browsers were 100% standards compliant except maybe Opera which has a small user base compared to IE or FF. Even though most of the current browsers pass Acid 2 and some pass or almost pass Acid 3, there are definitely variances in rendering and positioning of elements in IE7/8 and unfortunately IE6 is still a player which makes it extremely difficult if not impossible to support while producing hack free, compliant websites. Regardless of how you do it, there will be CSS hacks to support IE6.

    After reviewing a number of pages, the markup code I’ve looked at appears to be 100% valid strict.

    The Blog entry mentions that they are working on the CSS issues. I went through the validator results which often repeat overlapping errors and out of 30 reported errors, I found 18, mostly to do with the IE6 asterisk hack.

    The easy way out would be to bury them in conditional comments but I’m sure if they did that, there would be just as much of an outcry by so-called purists. Besides, with the CSS errors in the open, it’s easier to repair them.

  • Vince

    Who the hell surfs the web with JavaScript turned off? Besides geeks who know what it is? It’s a degrading experience.

    It’s an old argument from the same people who praise the new features of CSS3 and HTML5, yet want the web to work with JavaScript turned off. It’s an essential part of a rich experience.

  • http://www.optimalworks.net/ Craig Buckler

    @Vince
    How many mobile devices offer a full JavaScript implementation which supports jQuery? The iPhone apart, I bet it’s not many. So why offer a widget that’s ideal for mobile users except many won’t be able to use it?!

    Around 5% of users disable JavaScript and many of those are security-concious (if a little paranoid) corporations.

    OK, so this is a minor widget on a mostly JavaScript-free website. But it’d be easier to implement without JavaScript, so why not go totally JS-free?

    @awasson
    Of course, it’s far more important to support more browsers than use valid code. However, the two objectives are not mutually exclusive.

    The site could have been implemented in IE6 and the other main browsers without breaking accessibility, without using conditional comments, and without using CSS which didn’t validate.

  • http://www.lunadesign.org awasson

    The site could have been implemented in IE6 and the other main browsers without breaking accessibility, without using conditional comments, and without using CSS which didn’t validate.

    First off, I don’t think they have broken accessibility. You’ll have to point that out for me. The markup is valid, it’s just that CSS browser hacks that provide legacy support are visible.

    As far as using CSS that doesn’t validate goes, it would relatively simple to hide the hacks using tricks we all know. Keeping it visible will certainly make it easy to see while they work on it rather than obscuring it with hacks (conditional comments, !important, height: 1%, etc…). Hacks are hacks even if they validate. We all use them to support IE6 so why the outcry? It sounds like sensationalism to me.

  • http://www.optimalworks.net/ Craig Buckler

    @awasson
    As mentioned, the view switcher fails without JavaScript and the pages fail accessibility validation. The problems may be minor, but they’re still problems that are easy to fix.

    As for “hacks being hacks”, I agree to some extent. However, I’d consider many hacks to be minor workarounds, e.g. “display:inline” on floated elements is still valid CSS — it shouldn’t be required but it fixes IE’s margin bugs without adversely affecting other browsers.

    Using * and _ hacks indicate to me that they’ve tested IE too late and have implemented quick fixes. Unfortunately for the W3C, few people would have noticed or cared had it had been any other website.

  • http://www.lunadesign.org awasson

    @Craig
    The switcher doesn’t fail without JavaScript, it just isn’t visible without JavaScript. That is a common and generally acceptable technique to support browsers that aren’t capable of dealing with technologies that the majority of visitors will enjoy.

    As far as failing accessibility goes, is that your opinion or have you tested it for accessibility? I’m not an accessibility expert but I’ve worked with a few so I know the gist of it. I tested a sampling of pages with several validation tools for WCAG and 508 and it either passed without comment or had warnings that were ambiguous at best. One validator failed the homepage for using the “i” tag but a cursory review of the source showed that it wasn’t the case and the validator was likely flawed.

    I can’t agree with you about the use of the asterisk and again, I suggest that is an opinion. We don’t know when they tested for IE6 but I imagine it would be fairly early on. Regardless, sometimes simple hacks won’t fix the issue so you’re either stuck with conditional comments or asterisks. If it were me and I were going to come back to fix the issue in the near future, I would probably use an asterisk to make it easy to find the errors but if I knew I wasn’t coming back, I would use a conditional comment to link an IE6 specific stylesheet but that’s just me.

    I still think this is a lot of smoke and no fire.

  • http://www.optimalworks.net/ Craig Buckler

    @awasson

    …it just isn’t visible without JavaScript. That is a common and generally acceptable technique…

    Sorry, I can’t agree with you there. It’s only a CSS switcher — that could easily be achieved server side. You could then use JS to provide a faster progressively-enhanced version. And you certainly don’t need 30Kb of code to do it.

    have you tested it for accessibility?

    I used the Cynthia tool. Automated accessibility testing should never be relied on, but it does pick up some issues such as missing form labels.

    sometimes simple hacks won’t fix the issue so you’re either stuck with conditional comments or asterisks.

    I’ve built dozens of sites and never resort to conditional comments or asterisks. That said, I’ve been using IE since version 2, so I know the issues and what to avoid. The W3C design is not that complex — there’s no real excuse.

    I agree that I’m being a CSS pedant, but I’d really have hoped the W3C developers were too.

  • Integralist

    @Craig Buckler
     
    Hi Craig, I feel that ideally the W3C shouldn’t have invalid CSS or be missing all the elements that they are currently (like labels for form fields etc) and I feel this because that is the responsibility of the W3C as the governing body of these so called ‘standards’. They should be representing the very values that they preach to the masses about.
     
    But…
     
    I was just reading your previous article (http://www.sitepoint.com/blogs/2009/03/05/5-reasons-to-avoid-css-hacks-and-conditional-stylesheets/) where you talk about avoiding css hacks and conditional css and although I never use hacks I have had to resort to conditional css to resolve slight browser compatibility issues. This is where I noticed that in that article you mention in point 5…
     
    “It is unusual to find a design that could not be created by an experienced coder using standard CSS that works in all the popular browsers (and, yes, that includes IE6). Minor rendering differences are always inevitable, but the CSS code can remain clean and valid for all browsers.”
     
    Now this is where the confusion started for me. Because originally I thought you were suggesting that conditional css statements were wrong and shouldn’t be used because you could get your designs to be perfect across all browsers! But after I re-read what you had *actually* said I realised the key component in your statement was…
     
    “Minor rendering differences are always inevitable”
     
    …can you elaborate what you mean by “minor rendering differences” as I think the concern most developers have is with exactly that, the minor rendering differences.
     
    Some developers (and I used to be included in this list, but thankfully no longer) don’t have that freedom to just say “well, it’s a pixel out give or take on IE6 but essentially it’s OK and I’m happy with it so lets get it live!” because that decision is outside of their control. Generally that decision goes to their MD or the team of designers.
     
    I know in my previous working environments that the designers (and more importantly the Managing Director) wanted pixel perfect websites across all browsers/versions which wasn’t possible to acheive without conditional css. Most of our clients are government based and so IE6 is essential as that’s what most of them have installed but our own internal system is a mixture of PC IE7/IE8/Safari/Firefox/Chrome and Apple Mac Safari/Firefox.
     
    I’ve had complex designs built that are identical across browsers but just slightly out of place in IE6 (and I mean so slightly that it really isn’t worth worrying about) and I’ve had it thrown back at me and been told to sort it out and make it work the same across all browsers because the people in charge can’t accept that these “Minor rendering differences” can occur and that it’s down to bad programming (sometimes that may be true, but it would be extremely naive to think bad programming was the cause 100% of the time – especially as your statement suggests you’ve encountered this problem yourself).
     
    I’m interested to know how you would resolve situations like I’ve mentioned here, as it sounds to me that based on your previous statement about “Minor rendering differences are always inevitable” that you have the freedom to enforce your opinion on how the design looks across browsers (unlike some design studios) which is great and I envy that fact :) but other people don’t have that freedom and so they have to resort to conditional css statements to target the offending IE version.
     
    Like I say, I’m happy to report I’m no longer in that boat, but for those who are, then throwing out conditional css statements just isn’t an option.
     
    What does everyone else think?

  • Integralist

    @Craig Buckler
     
    Hi Craig, I feel that ideally the W3C shouldn’t have invalid CSS or be missing all the elements that they are currently (like labels for form fields etc) and I feel this because that is the responsibility of the W3C as the governing body of these so called ‘standards’. They should be representing the very values that they preach to the masses about.
     
    But…
     
    I was just reading your previous article where you talk about avoiding css hacks and conditional css and although I never use hacks I have had to resort to conditional css to resolve slight browser compatibility issues. This is where I noticed that in that article you mention in point 5…
     
    “It is unusual to find a design that could not be created by an experienced coder using standard CSS that works in all the popular browsers (and, yes, that includes IE6). Minor rendering differences are always inevitable, but the CSS code can remain clean and valid for all browsers.”
     
    Now this is where the confusion started for me. Because originally I thought you were suggesting that conditional css statements were wrong and shouldn’t be used because you could get your designs to be perfect across all browsers! But after I re-read what you had *actually* said I realised the key component in your statement was…
     
    “Minor rendering differences are always inevitable”
     
    …can you elaborate what you mean by “minor rendering differences” as I think the concern most developers have is with exactly that, the minor rendering differences.
     
    Some developers (and I used to be included in this list, but thankfully no longer) don’t have that freedom to just say “well, it’s a pixel out give or take on IE6 but essentially it’s OK and I’m happy with it so lets get it live!” because that decision is outside of their control. Generally that decision goes to their MD or the team of designers.
     
    I know in my previous working environments that the designers (and more importantly the Managing Director) wanted pixel perfect websites across all browsers/versions which wasn’t possible to acheive without conditional css. Most of our clients are government based and so IE6 is essential as that’s what most of them have installed but our own internal system is a mixture of PC IE7/IE8/Safari/Firefox/Chrome and Apple Mac Safari/Firefox.
     
    I’ve had complex designs built that are identical across browsers but just slightly out of place in IE6 (and I mean so slightly that it really isn’t worth worrying about) and I’ve had it thrown back at me and been told to sort it out and make it work the same across all browsers because the people in charge can’t accept that these “Minor rendering differences” can occur and that it’s down to bad programming (sometimes that may be true, but it would be extremely naive to think bad programming was the cause 100% of the time – especially as your statement suggests you’ve encountered this problem yourself).
     
    I’m interested to know how you would resolve situations like I’ve mentioned here, as it sounds to me that based on your previous statement about “Minor rendering differences are always inevitable” that you have the freedom to enforce your opinion on how the design looks across browsers (unlike some design studios) which is great and I envy that fact :) but other people don’t have that freedom and so they have to resort to conditional css statements to target the offending IE version.
     
    Like I say, I’m happy to report I’m no longer in that boat, but for those who are, then throwing out conditional css statements just isn’t an option.
     
    What does everyone else think?

  • http://www.optimalworks.net/ Craig Buckler

    @Inegralist
    Pixel perfection is a myth. HTML/CSS is not postscript – it suggests a layout, but it’s up to the browser to do what it thinks is best.

    At an extreme level, would you expect a page to be identical in IE and Lynx? What about a screen-reader? OSs have differing browsers, font types, rendering methods, screen resolutions, colour depths, etc.

    Even once you’ve accounted for all that, the user is in full control: they can change their text size, alter window dimensions, switch off JavaScript, block page items, and even replace your stylesheet.

    If your manager is complaining about a 1px problem, they are the ones who don’t understand the web. Would they expect a Windows developer to get their new desktop application working in Windows 98 (which was still popular when IE6 was launched)? Would they expect a 9 year-old browser to have the same feature set as one released yesterday?

    The important thing is to make your pages functional in as many browsers as possible. The W3C have achieved that (except for the lack of progressive enhancement for non-JS users). IE6 looks subtly different to others, but that’s to be expected. They could have achieved it without the * and _ hacks, though.

  • http://www.lunadesign.org awasson

    @Inegralist
    Thanks… I was thinking along the same lines.

    @Craig
    I’m really old too but IE2 never supported CSS.

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in Front-end, once a week, for free.