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.
For commercial sites, it's all about ROI. So your PHB is unlikely to approve any spending unless you can prove significant loss of sales as a result of non-compliance.
On the other hand, if I'm building a site in my spare time, and it's targetted at Slashdot audience, I would be very careful with all the standards because (1) I can approve my own time and (2) I am more concerned about peers' feedback than ROI.
I guess it's the humanization of the site that makes you care about compliance.
Please stop entering code 2,2,7,6,6,4
I validate every page.
When you write a program, your compiler or interperter will tell you when you fuck up. When you write a website, your browser tries its best not to tell you when a page is fucked up.
It's a supremely bad idea to rely on whether a browser can display your site to determine whether it is designed correctly or not. Even the next version of the same browser might do something unpredictably different with your tag soup.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future. A non-standard with hacks might just aswell not render at all in 4 years.
I'm not religious about it, but I try to make it as compliant as possible as I go, run your pages thru the validator a couple of times and you'll pick up your errors quite quickly.
Nowadays, about 60-70% of my pages validates automaticlly on the first try.
Because the W3C validator doubles as a good error-checker. If the W3C validator rejects my page, then chances are I will have display problems of some sort on some browser I haven't tested yet.
Unfortunately the contrapositive is not true, if the W3C validator accepts my page then there is no guarantee I will avoid display problems. But it's a good first step.
As long as every browser shows it properly. There are quite a few times that being W3C compliant doesn't display properly in every browser (Hello Microsoft, you reading this? Please pay attention as there will be a quiz on this later).
Overall, I don't think W3C is the end all of web design, however. Even firefox was having a hard time rendering the W3C test page properly. However it does help make sure everything works, and then you can hack the code to fix bugs for broken (ie) browsers. The closer you can be to W3C the better you are over all for long term.
I believe your take on it is pretty typical. We all feel like we "should" compile the page to some gold-standard, but ultimately the most important thing (in the short term, at least) is getting the page to look right on the most-used browsers.
I will add to this, however, that I use the W3C validator as a way to help fix bugs. Often if something is not showing up correctly in one particular browser, it can be fixed by addressing one of the errors that the validator picks up. I highly recomend checking all your pages. Even if they don't always pass, the errors will give you insight into how your page is being parsed.
So in response to the original question "do you validate all your pages": I sure do! I check them all, and I fix any of the errors that are easy to fix. I also use it as an invaluable tool to get the page working in many browsers. Ultimately, however, if I have to depart from the W3C spec in order to get something looking right in an important browser, then I leave the errors in.
More specifically, if you run the article page through the validator it fails with 60 errors. The truth is that the vast majority of pages out there will fail. It's a catch-22: as long as browsers are not compliant, web-pages won't be compliant... and as long as web-pages are not compliant, what's the point in standards-compliant browsers?
Moreso, if I have a program generating HTML code, I want that code to be standard compliant. To me it's the easiest way to catch bugs in my code, because if I program it with compliance in mind, but the code gets warnings in the validator, I know there are bugs lurking around, even if the output seems to show up correctly in the browser. I even let generated code indent correctly, because this is another easy way to spot lines where your assumptions about what the code is doing are different from the actual behaviour.
And if there is ever the problem of being not displayed correctly in different browsers: For me starting with W3C compliance and then tweak the stuff to show up correctly in different browsers is more easy than coding for one browser and try do adapt to others. With the W3C compliance you know how the code SHOULD look like, and you can spot the browser dependencies better, thus bug fixing gets more easy.
but I don't think W3C qualifies as a "standard" - it's simply a guideline at this point, and as much as we all might like it to evolve into a true standard, it doesn't qualify when only one or two obscure browsers properly support it. Granted, IE's marketshare has fallen in recent years, but it still boasts a claim to well over 80% of the browser market, and as long as it maintains such a vast lead, IE compliance IS the standard whether we like it or not.
;).
Flame on, but remember that I am on your side here - just more of a realist
"Make it idiot proof, and someone will make a better idiot."
W3C compliance doesn't really translate to a net gain or loss of income if you're running a commercial site, nor a loss of traffic if a non-commercial site, nor does it provide you any legal protection no matter what kind of site you're running.
But if you're selling something, especially selling something to government entities in the US, or you're developing educational and informational sites for the public, compliance with web accessibility standards is of the utmost importance and trumps W3C any day of the week.
Of course, good W3C compliance makes it easier to retrofit non-508-compliant pages. And 508-compliant pages are much easier to make W3C compliant, conversely.
But at the end of the day, it's whether the site is accessible to everyone, not the coding standard, that really matters to the bottom line or the lawyers.
It's posts like this that are the reason Slashdot needs a +6 moderation, even if it costs 10 moderators worth of points to push it the final bit.
Anyone who answers "YES" to this headline without a "but..." isn't doing this for a living where making it work and look correctly is more important than standards compliance.
I follow the standards to the best of my ability and test in all major browsers until something breaks (thanks IE, thanks a lot) which is when I break out the hacks until the page works correctly for everyone.
So do I follow standards? Well, when you get right down to it, no, I don't. I follow them up until the point that they prevent me from doing my job, then they get tossed out the window.
This is not a sig.
Nuts. This is as bad as counting "security patches" as if all bug were equally important.
You link to the fact that Mozilla renders one character incorrectly, while ignoring things like the fact that MSIE fails to render large chunks of standard compliant pages at all. They just vanish, poof. If these were the only two bugs, I suspect you'd say that they were "equally standards compliant" wouldn't you? After all, they only have one bug each, right?
Bah I say.
--MarkusQ
no, when i *start* a website, i'm running it through the validator. producing valid html and css isn't some kind of bonus afterthought. it's something you do from line 1.
I have developed sites both using tag soup AND strict HTML and XHTML. It takes no longer to do things the standards way, and using standards will almost ALWAYS make maintenance easier and therefore faster. That's ROI.
Finally, I use Firefox's tidy validator. It takes no time to validate your code (literally, it gives you a status bar icon indicating success or failure) and I have found that more often that not, checking for validation errors helps you find logical errors in your scripting code (e.g. incorrect criteria with a loop over a recordset).
It pays to use standards. I speak from experience. That doesn't mean that you have to slavishly adhere to them in certain situations. 99% of the time, though, there is no real excuse to ignore them.
blah blah blah