Slashdot Mirror
Do You Care if Your Website is W3C Compliant?
eldavojohn wonders: " Do W3C standards hold any importance to anyone and if so, why? When you finish a website, do you run it to the validator to laugh and take bets, or do you e-mail the results to the office intern and tell him/her to get to work? Since Opera 9 is the only browser to pass the ACID2 test, is strict compliance really necessary?" We all know that standards are important, but there has always been a distance between what is put forth by the W3C and what we get from our browsers. Microsoft has yet to release a browser that comes close to supporting standards (and it remains to be seen if IE7 will change this). Mozilla, although supportive, is still a ways from ACID2 compliance. Web developers are therefore faced with a difficult decision: do they develop their content to the standards, or to the browsers that will render it? As web developers (or the manager of web developers), what decisions did you made on your projects?
Update: 05/20 by C : rgmisra provides a minor correction to the information provided. It is stated above that Opera9 is the only browser to pass the ACID2 test, however "This is not true - Safari was the first released publicly released browser to pass the ACID2 tests." -- Sorry about the mistake.
This very topic is the source of a constant argument between me and my boss. I work to make our product adhere to the standard, even if it means leaving out some nifty interface tweak. My boss wants me to *strive* for IE-only.
No, I don't care. The validator is a mechanical tool. It's inherently flawed, understanding nothing of semantics, easily tricked into validating things which never should validate, and in a number of cases throwing incorrect warnings and errors. Having your website validate is a first step. A guideline to doing things the right way. It's not completely necessary. The <canvas> element (as specified by the WHATWG, and implemented by Opera, Mozilla/Firefox/SeaMonkey and Safari (I'm reasonably certain)) will cause errors to be thrown, yet one can imagine cases where its use is already perfectly acceptable. (Just as long as you don't use it on a client website, or at least not without full understanding of the implications by the people there of using something which can change out from under them at any moment, and their responsibility to track those changes.)
Yes, I care. I'm a professional web developer. Of course my website validates, besides also being completely accessible and being as semantically meaningful as it can possibly be. It's just a little showcase of my technical expertise. And yes, I care, as in: if you as a fledging web developer come to me on IRC or on some mailinglist for help with your website, you'd better be damned certain that your website validates before bothering with me, as I'm not going to spend any time on what would otherwise almost certainly turn out to be a problem caused by your invalid code.
Those two points made: wow, what's with the harping on ACID 2? Yes, it's a nice test to spur browser makers on to come closer to being perfectly interoperable, but it tests a pretty arbitrary range of rendering bugs, and all browsers save for IE are pretty much interoperale on it at this point. (Firefox only on the reflow branch, to be sure, but that's set to land Real Soon Now, and as has been explained often, ACID 2 came at the worst possible time in the Mozilla development cycle.
On a more serious note, the only way to solve the problem is to have browsers shame non-complient pages. Specifically, if IE7 displayed a dialog that said, "This web site is constructed improperly and might not work as expected" every time it hit an invalid page, things would change VERY FAST.
No, I will not work for your startup
i'm working with xml and client-side xslt to render xhtml output on the client browser
it's almost impossible to make nonstandard code this way
the irony is that firefox and ie have no problems with this, while opera doesn't support xslt transforms at all
so the most compliant standard browser isn't up to snuff with the most compliant type of code methodology
(which, in a way, makes sense, because by avoiding xslt work, opera can continue to be the extremely lightweight browser it is... you can't support everything if your biggest selling point is how lightweight you are)
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
When theory and practice disagree, the theory is wrong.
You've got it backwards. Historically, especially in medicine, but
in other fields as well, practice never matches theory until the
generation that was practicing before the theory was developed is
replaced by the generation that was learning to practice once the
theory was mature.
Generally speaking, then theory and practice disagree, it's because
the practitioners are resistant to re-learning how to apply their craft.
If a theory is in fact wrong, it generally gets replaced by a new
theory before the practitioners get a chance to adopt it.
*sigh* back to work...
I think the big problem in web development, is that there's a much different mindset from other programmers. I'll admit to it, I first got into computers by making webpages, and doing some Javascript work. The way web developers think and work is much different from how, say, a C developer would work. In C if you have a syntax error, your code won't compile. You must fix it. With HTML/CSS, if you have invalid syntax it won't get fixed because some sort of hacky browser behaviour might compensate. There is no impetus to fix anything. Javascript errors are all over the place. When I open up Firefox's JS Console to work on a web app, it's filled with countless errors from many websites, many mainstream websites. How a webpage is developed is a lot different as well. Webpages are hacked together, haphazardly. Little thought or concern goes into the elements and attributes used. C developers (and other programmers) are so concerned with code as to have design patterns. There are no Javascript design patterns. Few care that it is better to use to emphasize text than to throw in a to italicize it. I have to say, when I started programming, it was quite the leap.
And that, my liege, is how we know the Earth to be bannana-shaped.
I'd be more inclined to follow the standards if the standards didn't suck. For instance, CSS is incapable of doing simple math. (Why can't I make a measure 5em+10 pixels? Seems obvious to me, especially since em isn't a constant, but CSS won't do it.) Why is it so difficult to center something vertically? With tables, it was trivial, but with CSS it's significantly harder. (I haven't found a way of doing it with less than 2 divs.) Why do CSS measures typically go by *screen* measures and not *page* measures? When I say I want a div 10 pixels from the bottom, I don't mean the bottom of the screen, I mean the bottom of the entire page, idiots.
Anyway, CSS is just frustrating as hell to use. IMO, it's not significantly better than doing layout using tables. Especially since WYSIWYG editors will show you the table layout in progress, but usually choke on CSS layouts.
Comment of the year
The way I look at it, making websites w3c compliant is like making code that generates 0 warnings on compilation. Sure, it doesn't guarantee perfection, and it's sometimes not that important, but it will also often turn up small bugs that might bite big later, it isn't all that hard to do, and it's good practice imho.
just my $0.02.
I have to say that I agree with you on all points. I've started to religiously follow standards whenever I'm in full control of a page now - if it's not in a W3C recommendation, I try not to have it in my page. Personally, I look at this as a case of "lead by example". The work I do gets limited exposure where I work, but my coworkers all know that I always strive for correct webpages (I even write them with the strict XHTML DTD). I hope it rubs off them eventually. If it rubs off on them, who else will it rub off on next?
Too much repetition my too much repetition!
It's a wee bit disingenuous to blame browsers for the lack of strictly validating web pages out there. I'd venture that upwards of 90% of the issues you see when you validate pages against the HTML 4.0 schema are not there because the author had to violate the standard in order to achieve the effect in some non-compliant browser. They are there because the author achieved the effect he wanted and did bother to check whether he had, or could, achieve it in a standards-compliant way. From the beginning, browsers tried to degrade gracefully in the face of invalid input, and as long they do that there will continue to be a lot of invalid input out there.
I'm afraid it doesn't really matter if I care about W3C standard or not... all the people that matter do already.
At work, I keep up the websites for a public government entity. It's been legally required since 1997 that any government agency web site (at least in NY, I'm a little fuzzy on the legislative aspects) is accessible to those with disabilities, and the first step to that is W3C compliance. It makes sense; have you ever seen a government building without a wheelchair ramp? Why should the web sites be any different?
On my own time, all of my sites comply because of Google. They have a tendency to give a much higher pagerank if your site is W3C compliant, or even if it follows the spirit of the standards. Search engine love the barebones HTML of a standards-compliant page.
If you write to the standard instead of the bugs you can avoid a suprise when the bugs are fixed.
Not that I expect IE rendering bugs to get fixed but a guy can dream can't he?
The obscure we see eventually. The completely obvious, it seems, takes longer. - Edward R. Murrow
You sound clueless tbh, like all people who complain that making valid websites is "tooo haaaaaard!!!". If you need a validator to check bulleted lists and can't write js without errors then you are in the wrong job. Or you are the office gopher who just happens to also like playing with frontpage.
Bush and Blair ate my sig!
Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care.
Sorry. If you're doing something more complicated than building a 10-page static site, or even something with a little PHP-driven database, then it will take longer. It'll limit your choice of available third-party modules, and you'll have to evaluate each one you consider for its standards compliance. You'll have to hire more competent developers when you outsource. You may have to redesign legacy code that's already on the site (I've just finished doing this for a text-html autoformatter that was in use on a number of sites my company maintains, and which produced the most horribly non-standard html you can imagine rendering correctly -- two days' work, and if I hadn't been able to justify it in terms of being able to extend the range of formatting options it supports, I'd never have got the finance to do it).
If WAI is an issue, you'll have to examine the text that has been supplied by people other than yourself, going through it and putting expansions of abbreviations and acronyms in place for screen readers using ABBR and ACRONYM tags, for example.
And developing a CSS-based layout that fits the specification the graphic designer has handed to you, rather than a deprecated table-based one, is often quite tricky.
No, for anything beyond trivial requirements, meeting web standards can be time consuming. Sorry.
Hi, I'm probably going to start a flame war with this, but ...
The app I use to build web sites is an HTML generator called Freeway - see Softpress for more details. It generates HTML and XHTML, and the code validates every time.
I know, I know: I should be typing my fingers to the bleeding knuckles instead of using a DTP like interface, but I'm a graphic designer, NOT a coder, and I find it much easier for me to visualise my work as I go. I like Freeway because of it's designer-friendly interface, and the valid code output is icing on the cake.
It's called taking pride in your work. Code run through the validator has a level of quality control and a higher likelyhood of surviving the various browsers it gets crammed through. The only page I have ever designed that wasn't 100% CSS and XHTML compliant is my personal blog and the few things that throw it off are things Blogger.com requires. For my professional sites nothing less than W3C compliance will do.
No animals were harmed in the making of this sig.
Well, there was that one puppy, but he is all better now.
As can be seen in this reference, none of those great CSS2 properties are supported by IE. As much as I would love to use them, they simply do not work for the 50%+ of one's audience that uses IE.
Hence, we are STILL stuck with table-based layouts as they are often the only thing that can reliably stretch to fit arbitrary content in a pleasent way. Sure divs and CSS1 work well for a lot of content where you know the sizes-of-components/lengths-of-text, but for building generic CMSs in which users can add arbitrary ammounts of content, often tables are the only (IE-supported0 option.
The day an IE that supports CSS2 comes out (or IE market share drops to <25%) is the day I remove table layouts. I wish I could do it sooner, but I can't. That said, I can still make sites that validate against XHTML Strict && CSS1/2, I just have to use tables for layout.
- Adam
"When ideology and theology couple, their offspring are not always bad but they are always blind." -- Bill Moyers