Do You Care if Your Website is W3C Compliant? 624
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.
A relevant quote (Score:1, Insightful)
Depends on Usage (Score:5, Insightful)
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.
Because it's a good idea (Score:5, Insightful)
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.
That all depends... (Score:3, Insightful)
If it's for work, I'll get it done so it works in IE and Firefox. I'm not getting paid for adhering to the standards, and writing a standards-based site that will look right in freaking IE takes longer than it's worth.
Standards (Score:5, Insightful)
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.
I do (Score:3, Insightful)
I care (Score:5, Insightful)
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.
There's more than one reason to be compliant... (Score:3, Insightful)
Some people are obsessive about being W3C compliant and do it pretty much just so they can 'show off' the w3c comliant badge. I do it to make sure I didn't make any coding mistakes.
This validation happens to have the nice side effect of making a site render correctly in most decent browsers.
ABSOLUTELY! (Score:4, Insightful)
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.
Test then Hack (Score:3, Insightful)
Pretty poor practice, but likely the norm.
I'm overseeing a web site redesign right now for client whose members are largely Mac users.
The coding crew hired by the designers are working with Internet Explorer though, so nearly every feature and many design choices need to be fixed so that the site will work for our Safari users. Or even non-current versions of Safari.
We specified from the beginning that everything on the site be platform and browser neutral, and are becoming somewhat unpopular for continually saying "But it doesn't work in Safari..."
Ulitmately what is needed is for clients of web design firms to demand that all work be compatible with at least Safari, IE, Mozilla, and Opera. Only then will designers create sites that are cross compatible from the beginning, instead of "fixing" thinsgs after the fact.
Re:That all depends... (Score:5, Insightful)
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.
Using Flash = Validation Fail (Score:3, Insightful)
(oh and just because lots of sites and ads do annoying things with Flash, please don't assume that I do... like any tool it can be used or misused.)
Re:Standards (Score:4, Insightful)
Re:Oh, Irony... (Score:5, Insightful)
Re:That all depends... (Score:5, Insightful)
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.
Re:Because it's a good idea (Score:5, Insightful)
Debugging valid code in semi-compliant browsers is still much better than debugging invalid code in semi-compliant browsers.
If something doesn't look or work properly, the first thing you should do is test whether or not it is your code that is wrong. It gives you more certainty whether or not it is a browser bug you are dealing with, and how to research working around it.
I hate to break it to you guys... (Score:3, Insightful)
Flame on, but remember that I am on your side here - just more of a realist
Re:Using Flash = Validation Fail (Score:1, Insightful)
Re:Standards (Score:5, Insightful)
Sure, until a new non-compliant standard comes along or the big players have an economic motive to break it. There are no guarantees on the future of technology or future technology markets.
Acid2 and standards (Score:2, Insightful)
Acid2 feels like a step in the right and wrong direction at the same time.
Yes, and without hacks. (Score:3, Insightful)
I not only validate my pages, but I also don't use any HTML or CSS "hacks". Sometimes this means using tables for non-tabular data. Sorry to trample on current web dogma, but users won't notice "semantic code" - they will notice a site that doesn't render properly in their browser due to CSS hacks. I didn't have to change a thing to make my sites work in IE7. If you use hacks, you probably can't say the same.
Besides, if you truly want a semantic web, you should code your pages in OWL [w3.org]! It's the logical conclusion of the current trend. I specialized in knowledge representation and reasoning and I could never understand what that language was getting at.
I care if it's ADA 508-compliant, for disabilities (Score:3, Insightful)
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.
Re:A relevant quote (Score:2, Insightful)
Re:Reasons to validate (Score:5, Insightful)
Re:Anyone who answers "no" to this headline... (Score:5, Insightful)
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 like counting "security patches" (Score:4, Insightful)
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 [satzansatz.de] 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
Re:Depends on Usage (Score:3, Insightful)
Now, for ROI, I'm sorry, but if *ANY* user with a *FREE* web browser (or media player) can see and use your website, your ROI is going to be higher. Period. There is no logical argument for non-compliance with open standards for CSS and DOM designs; nor for any content being delivered over the web, or application being developed for the web. None, zippo, zero, nada.
I know, this is a debate/discussion that will rage for many years to come; until Microsoft is either brought to its knees on compliance, wiped from the market, or simply supplants the open standards (somehow). But, I develop sites, applications, and full end-to-end solutions. I do it with open standards compliance AND a reasonable amount of diligence paid to the MS IE standards as well for near matching rendered pages. You do it enough times, it's really not that hard to keep doing. The only pain is when you create a new look-and-feel template, and that's once a year at most. I'm also a firm believer in the creation of reusable parts!
when i *finish*? (Score:5, Insightful)
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.
Re:which makes the validator useless (Score:2, Insightful)
This useless string takes up bandwidth. Now, granted, one attribute isn't going to change much, but 1000 will. I don't see how you can blame someone else's code when it is your code that is wrong.
Re:A constant argument (Score:1, Insightful)
Re:Depends on Usage (Score:5, Insightful)
That's the end of my devil's advocacy.
Standards-based, accessible websites have a bigger ROI than is necessarily measurable. These sites tend to produce better search engine results, be faster to download, use less bandwidth, and improved usability. And if you have an altruistic bone in your body, such a site improves the overall quality of the web.
So the ROI is definitely there, if you know how to make the case for it.
I disagree; it does not depend on usage (Score:5, Insightful)
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 [mozilla.org]. 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.
Standards created lots and lots of.. fanatics (Score:3, Insightful)
Validation fanatics:
They believe that they should unconditionally comply with the W3C (and the other) validators and this means they did a good page.
They compare the validators to the compiler syntax checks other languages do before compilation. Of course, no compilator in the world will stop you from writing buggy crappy useless programs, but they don't like to talk about that.
Another thing many of them don't assess, is that validators are just a guide, not God, and like any software tool, they have bugs and can miss plenty of code flaw types, or print code warnings or even code errors where there are none.
An advice to validation fanatics: your web page won't be seen in a validator, it'll be seen in a browser.
XHTML fanatics:
Anything less than XHTML 1.1 Strict is crap. In certain cases they might do a great compromise and go for 1.0.
XHTML is just a rehash of HTML4 as an XML dialect. Unless you need to take advantage of your code being XML, there's no big advantage to using XHTML now* . All of the talk about future compatibility or how HTML 4 is obsolete is nonsense. Browsers will render HTML 1 for ages to come, same can be said for HTML 4.1, which still a nice, valid standard.
*exception: mobile browsers strictly requiring XHTML Mobile Profile this is still no XHTML 1.1 support, like many XHTML fanatics believe.
What XHTML fanatics forget is, it's not easy to write a real XHTML page nowadays, that would run in both existing and old HTML browsers (that actually includes IE6: over 85% market dominance) and XHTML browsers.
XHTML fanatics sometimes make basic mistakes, like putting contents of [style] or [script] blocks in comments, or forgetting to put them in CDATA blocks, in both cases, the resulting code is a broken XHTML page if it runs in strict mode. The reason they don't see it, is that XHTML browsers interpret XHTML like HTML, since it's served with the HTML MIME Type (if served with Application/XML, it'll break IE).
"No tables for layout" fanatics
So yes, W3C said it's not recommended to use tables for layout. And it's indeed not nice: the classic usage of tables for layot is a huge mess of plenty of table cells, 4-5 nested tables in one another, the code is unreadable and unmanagable without a WYSIWYG editor (and that in itself, spells trouble if the web dev/designer has no clue).
However, fanatics go further: they open the source of most site they visit, looking for "clues": if you do use tables for layout the site is marked invalid, the site author an idiot, and the site's actual contents discarded.
If you ask a "No tables for layot" fanatic for help and he sees you use a table, you can be laughed at, insulted, bashed on and so on.
The funny reality: CSS is still defficient as a layout tool for some pretty basic layout schemes. The workarounds include laughable stunts like 4-5 nested [div]-s or more (i.e. table tag mess in its new form), 3000px wide bitmaps with transparent areas and so on and so on.
So these types of fanatics will advise you to either go for display-type:table (not working in IE), go for the ugly hacks, or change your layout. The irony you need display-type:table in CSS is worth a separate post on its own.
Truth is, there's no drawback to using very simple tables styled with CSS for your layout, if there's no simple way to do it with CSS. No modern search engine or browser in the world has a problem with tables. No modern screen reader has problems with tables. No modern mobile browser has problems with tables. Try it in Opera (SHIFT+F11) and see how horizontal layouts made in tables are properly broken up vertically to allow for easy reading on a mobile device.
"Don't use crappy browser" fanatics
These guys believe it's their mission to talk, enforce, advice and so on their visitors to switch from their "crappy" browser (usually IE), to a better browser like Firefox. They also don't mind l
Re:Depends on Usage (Score:3, Insightful)
Right, but merely "shooting for compliance" and "actually getting there" can be the same thing as far as most of those roi benefits.
In other words, if compliance is an objective, and you actively endeavour to achieve it, even if you miss the green "your page is 100% valid" result, you usually reap most of the roi benefits you refer to, whether you fix all the "errors" or not.
Its sort of like ISO9000 and other "organizational" status symbols of achievement. Merely trying your best to run an ISO9000 compliant organization will reap you the benefits (e.g. "improved business performance" and "good quality controls"); but actually getting the certification itself is really only relevant if your clients literally require it. (e.g. FDA approved labs, military contractors, etc).
Simply shooting for ISO9000 compliance, just like shooting for W3C standards compliance gets you most of the roi. Actually getting the certifications by tying up every loose end and detail is a rapidly diminishing return unless you have some compelling client requirement to achieve it.
Re:Standards (Score:3, Insightful)
Comment removed (Score:2, Insightful)
Re:table vs. div (Score:2, Insightful)
Anyone with any moderately serious website would chuck the top of the table into a header and the bottom into a footer file and just #include it. I'm not saying you should use tables, but trust me, it IS a lot easier to do a 3 column layout with them.
Re:Depends on Usage (Score:3, Insightful)
Re:Depends on Usage (Score:3, Insightful)
The key is the unpopular site - small businesses, for instance - that want to compete in search engines but will never have thousands of visitors a day.
Standards-compliant websites do not necessarily make for better SEO. But the practices and culture around them do.
Accessibility generally results in improved SEO simply by 1) increasing the placement of relevant text within a page and 2) making the site more accessible to search engines. Things like alt text go a long way.
As for download speed, you're absolutely right. It's a matter of data size. But standards-based design lends itself toward smaller pages simply by removing the need for repetitive code likeIt's not the standards that make it work well, but the benefits that come along with the journey towards those standards.
Nowadays, if a client isn't willing to let my company develop an accessible, standards-based solution, he isn't going to be my client. I just won't waste my time on them.
The Handicapped (Score:1, Insightful)
Bobby:
-------------------
http://webxact.watchfire.com/ [watchfire.com]
Re:Depends on Usage (Score:1, Insightful)
Better search engine results:
http://www.google.com/support/webmasters/bin/answ
Faster to download:
You code will likely be smaller if you do it by hand, as you will avoid all the unnecessary junk code added by tools like Dreamweaver etc.
Use less bandwidth:
In addition to being smaller code to download, the css for your pages is cached by the browser. Hence, you only need to download the content aspect of the page, and not its presentation.
Improved usability:
I recommend you read the W3C guide to usability. You will see that having correct code is a step forward to being usable (most of them are priority 3). And with a little bit of work, you can achieve priority 1, being really usable for anyone.
A/C