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
IIRC, Opera 9 is not the only compliant browser. I believe Safari 2 is also compliant.
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.
nope.
Reposted from something I wrote a while ago
There are very few good reasons these days to write invalid code. Mostly it's just ignorance and apathy that causes people to write invalid code.
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.
Is a fool who doesn't deserve to be involved in web development.
The Web would never have been much more than an academic experiment without web standards. Anything that has a sufficiently large group of people that use it at various levels needs standards. Think road traffic is bad now? Imagine if there were no lines on the roads, no standardised street signs, or even pavement. Getting anywhere would be total chaos, and most of us would be doing it on foot.
Sure, Opera 9 is the only browser released for public use that passes acid2, but the Gecko codebase achieved this a few weeks ago. Unfortunately, we'll likely have to wait for Firefox 3 in order to experience it.
IE7b2 is complete as far as standards compliance is concerned, so you might as well go ahead and test it now. It still has the worst compliance compared to all other non-MS browsers.
The distance between any W3C recommendation and the browsers is a result of 2 things: vagueness in the document, and how any browser vendor decides to interpret it (if at all).
The biggest threats to web standards aren't MS, WHATWG, Motorola, or any other entity.
Number one: Quirks Mode. As long as browsers try to correct invalid documents, there is not real incentive for valid documents to be produced. Interoperability can't be fully achieved, and machine-to-machine exchange of data remains tenuous.
Number two: Nomenclature and Authority. Part of the W3C's problem is the terms they use to identify the stages of a standard. "Draft" is understandable, but labeling a final document "Recommendation" almost begs people to ignore it at will. Furthermore, the W3C just produces documents, and there is no body anywhere to monitor and enforce standards compliance among browser vendors. I believe the W3C should be absorbed into an existing technical organization which people actually respect, probably IEEE.
Anyone who doesn't care about web standards might as well go back to 1998-99 and try to keep riding the bubble.
Have you actually bothered to read the Acid2 page? Because I hear this repeated all the time, and it's downright misleading.
There is a checklist of about a dozen things the Acid2 page tests. Incorrect code is just one of them. It is necessary to include incorrect code in a test like this. How else are you going to check whether a browser follows the CSS error handling rules?
It's incorrect code, sure, but it's incorrect code that has a defined rendering according to the CSS specifications. It's not something a compliant browser would trip up on. There is a correct way to parse the incorrect code, and the Acid2 page tests to see if a browser parses it correctly - among many other things it tests for.
Where are you guys getting this idea that the Acid2 test is all about error handling? It's a very small part of the test, but plenty of Slashdotters seem convinced that the test revolves around broken code and nothing else. Was there a weekly meeting I missed wher eyou all got this myth drilled into your heads?
Bogtha Bogtha Bogtha
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?
Look again.
Bogtha Bogtha Bogtha
You're asking the wrong question. It's not about replacing <table> elements with <div> elements. It's about using the most appropriate element type and leaving the presentation up to CSS. Sometimes that means using a <table> element, sometimes that means using a <div> element, and sometimes it means using something completely different, like <ul>.
The thing is, it's not easier or cleaner. In fact, it's usually the opposite. With CSS, you develop the layout code once, and apply it to all the pages on your site simultaneously. With tables, you have to hack up stupid <tr>s and <td>s for each and every page you do. Mindless, boring, repetitive work.
This sentence makes no sense. Semantics describe what individual parts of the page mean and are encoded with HTML elements. They have nothing to do with the layout or CSS. Why would "floating something in a strange way" be semantically wrong? Floating things happens on a completely different conceptual level to the semantics. On the other hand, describing something as a table, when it's really a heading or an image, is obviously semantically wrong.
Bogtha Bogtha Bogtha
Aside from the all-important issue of "does it look right?", there is the professional issue of what sort of standards you should apply to your work. It's difficult to come close to a more extensive (and yet simple to implement) baseline metric of quality control with HTML/CSS than the W3C parser. Sure, I could go through and decide how I am going to do everything, but that's time-intensive and inflexible. Running something through the parser gives me a fast and consistent report. I can do whatever I want with the results, but they are there.
It does not solve problems for you or guarantee much of anything, but it allows you to see your formatting code in a more objective way. As a bonus, it can help you spot potential problems, mistakes, and open your eyes to some of the structure you are relying upon.
I always use the Tidy Firefox extension. It is a little friendlier than the online W3C parser interface. Disclaimer: not a professional web designer.
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.
Actually, it's HTML that has semantics, XML is just a markup syntax, so it's definitely about marking information up precisely.
Yes, and in order to decide upon the best presentation, a user-agent (e.g. a browser) needs to know what kind of information it is getting. Hence marking up tables as tables, headings as headings, and lists as lists, not marking up everything as tables.
Bogtha Bogtha Bogtha
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
The latest version of Safari is Safari 2.0.3. It's not in beta, and has been available to users since Mac OS X Tiger was released. It's not available for download from the Apple site, for the same reason many other Apple applications aren't available for download--current applications come as part of the operating system, and are automatically updated via Apple's Software Update. If a user needs to reinstall, they are suppose to go back to the OS disk.
I should also mention that if you perform a search for Safari on the Apple Support website, you will also get a link to Safari 1.3.2 and Safari 2.0.1 both newer versions than the one you pointed to, which is legacy software.
Microsoft has yet to release a browser that comes close to supporting standards
This is often shouted and an easy way to bash MS. It's also completely wrong.
Every web browser released by Microsoft from IE3 onwards has been more standards-compliant than any Netscape browser released around the same time. IE3 was the first major browser (outside of W3C testbeds) with CSS support. IE4 brought CSS-P support, while NS4 introduced the totally non-standard LAYER tag, then made a bad stab at implementing CSS-P under sufferance. IE5/Mac was easily the most standards-compliant browser on the Mac for years. The Mozilla project had been going for a while when IE6 came out, and Mozilla might be considered the better browser of the two if you rate standards compliance several miles above stability and speed.
The reason IE6 is bashed so hard by designers these days is not that IE6 was a particularly bad release. It's that it's bad by today's standards, and nothing's been done to fix it. This is a different issue, and one that the IE7 team has been loudly busting a gut to address. (There is also the utterly shameful issue of IE6's many security problems, which is a different argument, but it's one of the main reasons I've been using Mozilla-based browsers since 1.0)
And if you're still not convinced of anything other than Firefox's total superiority over IE in all standards-related matters, how about we dig up an issue of HTML4 compliance which IE's had right for years, and Mozilla/Firefox never has.
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.
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.
Please, please *don't* write HTML as if it's XHTML. Self-closing tags in HTML is totally invalid and screws up the parsers. Pretend you're a HTML (not XML) parser and parse:
<html><body><script src="..."/>Lots of stuff</body></html>
Your <script> tag never gets closed (remember, this is *not* XML!). Wee, no content....
If you are actually sending it with some sort of XML MIME type, yes, go ahead and do self-closing tags. Just don't pretend it works when you're being HTML.
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