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.

Comments

Depends on Usage

[foundme]

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.

Re:Depends on Usage

[Dan Ost]

Can you please explain your sig?

Re:Depends on Usage

[multimediavt]

I'm going to chime in on this thread. I'm going to assume that when you say 'usage' you mean the target audience of the site? If so, that's really *NOT* an excuse, logical argument, nor valid defense for non-compliance. There is only one excuse for non-compliance and that is a mandated use of Microsoft technologies by management for the development of a website. Notice I did not call that a logical argument, nor a valid defense.

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!

Re:Depends on Usage

[lukewarmfusion]

It's important to note the difference between increased revenue and ROI. Just because more people can access your site and become customers doesn't mean that the business will make more than they spent making the site compliant.

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.

Re:Depends on Usage

[eyeye]

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.

Re:Depends on Usage

[vux984]

So the ROI is definitely there, if you know how to make the case for it.

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:Depends on Usage

[greggman]

Gawd I hate this BS

>sites tend to produce better search engine results, be faster to download, use less bandwidth, and improved usability

This BS meme is repeated all time and yet with ZERO proof. None of the most popular sites validate. Not google, not yahoo, not cnn, not msnbc, not flickr, not myspace, not even our sacred slashdot. none!

They show up in search engines just fine, download speed is a matter of data size not standard compliance as is bandwidth and as well, you can follow all the standards and still not be usable and you can break all the standards and have a more usable site than others.

As long as standard zealots keep using lies to try to get people to support standards no one is going to listen.

Re:Depends on Usage

[protohiro1]

Very popular sites are going to show up in search results no matter how bad their html is. The thing about standards is that crossing every t and making sure every image has an alt tag might not be worth it. Because validation is not the goal. Semantic html is the goal. It doesn't really take any more effort to make a layout with no tables and relatively semantic markup. Which is better than just letting frontpage make all the decisions.

Re:Depends on Usage

[lukewarmfusion]

Of course popular sites show up fine without validating. They're popular.

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 like

<font face="Arial,Helvetica,sans-serif" size="2">

It'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.

Re:Depends on Usage

[DesertWolf0132]

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.

Re:Depends on Usage

[RedSteve]

They show up in search engines just fine, download speed is a matter of data size not standard compliance as is bandwidth and as well, you can follow all the standards and still not be usable and you can break all the standards and have a more usable site than others.

I'm working on a redesign of a site that is a perfect example of what happens when you let developers write code that "just works". Our pages are served out of a CMS that is provided by a little company in the Pacific Northwest that you may or may not have heard of (the name starts with 'M' and ends with 'icrosoft'). The templates we currently use are the bastard child of using their out-of-the-box output methods combined with template designers who used every table and spacer widget trick in the box to deliver their templates in as short a time frame as possible.

According to half the comments I've read in this thread, this is how it should be: we should be focused on the end result for the user, and to hell with standards; they're nothing but esoteric junk that waste back-end developers' precious time.

Of course, this great time-saving philosophy has resulted in the following results:

• Template modifications are ridiculously hard to make without breaking the output. Because our template developers nested table after table and inserted seemingly random spacer gifs in order to get the layout 'just right', and then we had to split our template into components to ensure that the right pieces get fed at the right point in the logic, making updates are a laborious, time-consuming chore that regularly break , requiring further break fixes.
• Our pages are bloated and slow-loading. Our home page is our lightest page, and the HTML document itself weighs in at over 63K -- to present all of 500 words. The bulk of that HTML? Javascript to sniff for different kinds of browsers and to feed dropdown menus. With all the spacers and image widgets, the total page load is over 120K.
• We have to re-code templates over and over. For every alternate use of the same set of content -- printer-friendly, handheld, audio, braille -- we have to write similar templates that exclude the cruft of the browser-based view. Given our audiences, we cannot ignore these uses.
• We pay a shitload for traffic. In the case of our home page, we served that page -- and all 500+ words contained upon it -- 670,000 times in the last year. Multiply that by the number of overall pages we serve a year (8.6 million), and our bandwidth costs for serving pages weighing 120-200K each are enormous. Even with users caching previously visited pages in their browser, we still serve a ton of traffic.

Now, as I said, we've been developing a redesign around standards that should improve our lot in life significantly, and our conclusions have been based on data, not a BS meme.

• Fact: we will simplify our template files significantly. Without having to dig through partial tables and being able to store semantically significant chunks within the development environment, our developers have to spend less time reconstructing bad HTML to preserve a rickety template. Modification times in development have been easily cut in half.
• Fact: we will serve less data to represent the same amount of content. Our html files are now up to 1/5 the size that they used to be, and the total size of all associated files for each page are now literally half of what they used to be. We don't sniff for different browsers, and our drop-down menus that once took hundreds of lines of javascript are accomplished with a few :hover declarations in the style sheet in the CSS and a 12-line javascript snippet to make IE behave correctly.
• Fact: Our redevelopment time will take significantly less time in the future, and will not require us to re-code enti

Safari 2

[m0rph3us0]

IIRC, Opera 9 is not the only compliant browser. I believe Safari 2 is also compliant.

Re:Safari 2

[Ant P.]

And Konqueror (which Safari is based on), and iCab...

Re:Safari 2

[Anonymous Coward]

Safari and other webkit based browsers miss out one style on the acid2 test. Something to do with the scrollbars IIRC. So, although safari is extremely close to compliance, only Opera actually passes.

Re:Safari 2

[chasingporsches]

you do remember correctly. actually, safari passed it long before opera did.

Because it's a good idea

[GigsVT]

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.

Re:Because it's a good idea

[styrotech]

Agreed.

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.

Re:Because it's a good idea

[BigCheese]

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?

That all depends...

[Spaceman40]

If it's my own personal site, I want it compliant. Must be the OCD in my family, but I also feel like if you "compile" the site it should return with no errors.

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.

Re:That all depends...

[kebes]

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.

Re:That all depends...

[Sique]

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.

Re:That all depends...

[soliptic]

It's actually not as hard as many people make out to make a standards-compliant site that renders correctly in IE.

First: this is assuming "correctly" is not defined as "pixel perfect", which was not and is not the point of the web. I concede that in many real world situations, the client expects a pixel perfect recreation of a PSD they give you, in which case you may run into problems. Things like the 3 pixel jog will screw you over. But if by correctly you just mean "looks exactly the same so long as you don't literally measure pixels", it rapidly gets easier.

Broken box model? No problem. Just don't use padding, and use an extra internal div with margin instead. Yeah, the hardcore purists say will say "but that extra div isn't semantic". But... let's face it... your first div probably wasn't semantic, was it? Furthermore, what's better - one extra div, or an enormous maze of tables (the old school approach), or standards-busting deliberate CSS hackery (seemingly the preferred method of standards junkies, which always completely puzzled me. Let's just say I'm slightly smug now they're all sh*tting themselves trying to fix their deliberate CSS hacks in advance of IE7).

I think one extra div is no small price to pay and voila, box model is sorted.

I'd say there are pretty easy, non-standards-breaking workarounds for most of IE's quirks. If you MUST use alpha transparent PNGs then you'll be stuck. But if you're not bound by a designers' PSD it's not actually as bad as all that.

Standards

[grazzy]

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.

Re:Standards

[neoform]

Not only that, but it means that anyone else who takes control of the site and works on it will have a much easier time reading and understanding the code.

Re:Standards

[ClosedSource]

"A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future."

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.

Re:Standards

[Xugumad]

Specifying an alt tag of "" explicitely indicates the image has no content. Not including that alt tag could mean it has no content, or you just didn't think about it; as someone pointed out, Lynx specifically renders it is [IMAGE].

And seriously, is alt="" that much bloat?

Oh, it's also not the validator's fault, it is part of the HTML 4.01 standard. Argue with the W3C if you don't like it.

Re:Standards

[DerekLyons]

A standard compliant website more or less guarantees that your website will work atleast decently now, tomorrow and in the far future.

Sure - as long as those far future browsers can render any tags that you've used, that have been deprecated between the time you wrote the page and the browser was coded.

I do

[gEvil (beta)]

I do. However, neither my employer nor the guy who has a long-term contract to develop our website have any idea what web standards are. For them, if it works in IE then it's "standards compliant." Thankfully I've been making progress (in teensy tiny little chunks) with my boss over the past two years...

I care

[Anonymous Coward]

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.

A constant argument

[Kithraya]

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.

There's more than one reason to be compliant...

[nacs]

When I design and code a site, I do it by hand (usually vim or kate) and when I'm done, I always run it through the W3C validator to make sure I didn't leave out a closing or some syntactical error somewhere.

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.

Re:There's more than one reason to be compliant...

[pete-classic]

I always run it through the W3C validator to make sure I didn't leave out a closing [sic]
or some syntactical error somewhere.

"Preview" is the Slashdot equivalent to the W3C validator.

-Peter

ABSOLUTELY!

[scronline]

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.

Oh, Irony...

[werewolf1031]

The article's webpage breaks if you change the text size in your browser.

Ok, so maybe not so much "ironic", but considering the topic, that is pretty damned funny... or sad, depending on your perspective.

Re:Oh, Irony...

[kebes]

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?

No, Konqueror's good

[bssteph]

The latest release of Konqueror (3.5.2) does not incorrectly show scrollbars, so it "actually" passes.

Test then Hack

[rueger]

I suspect that most people write for their favorite browser, then test with alternatives and hack the code to make it work.

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.

No and Yes.

[savala]

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.

do i care?

[bitkari]

nope.

Re:do i care?

[Ant P.]

I hate to point this out, but *both* of those are in the current CSS3 draft.

Acid2 is NOT A "Complaince" Test

[mattdev121]

What people need to stop doing is comparing how a browser renders the Acid2 test to its compliance with web standards. If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.
To me, compliance is very important. Not only can you be sure that it will render properly in every proper, compliant browser, but it will also be easy to add on to and change stuff.
Besides, as long as you aren't trying to jump through IE css-fix hoops, compliance is usually as easy as encasing all of your variables with quotes.

Re:Acid2 is NOT A "Complaince" Test

[Bogtha]

If you bother to read the Acid2 page, you'll see that its purpose is to see how a browser renders INCORRECT code.

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?

Reasons to validate

[JimDabell]

Reposted from something I wrote a while ago

You cannot prove anything about the future... but you can identify trends.

Before Netscape 1.2 came out, it was a common, non-standard hack to use multiple title and body elements to get crude animation. Netscape 1.2 came out, and screwed these pages up. Following standards ensured forwards compatibility with Netscape 1.2.

Before Netscape 2.0 came out, missing quotes on the end of an attribute were detected as errors by Netscape 1.x and compensated for. Netscape 2.0 came out; it did not. Large sections of pages disappeared. Following standards ensured forwards compatibility with Netscape 2.0.

Before Netscape 3.0 came out, people were careless with their ampersands, failing to correctly encode them in URLs, for example. These were detected as errors by the current browsers, and compensated for. Netscape 3.0 came out; it did not. Lots of broken links everywhere. Following standards ensured forwards compatibility with Netscape 3.0.

Before Netscape 4.0 came out, people were still careless with character entities, omitting the trailing semicolon (I believe this was a property of many graphical editors, such as Frontpage). This was detected by the current browsers, and compensated for. Netscape 4.0 came out; it did not. Following standards ensured forwards compatibility with Netscape 4.0.

Before Netscape 6.0 came out, people used a variety of non-standard Javascript techniques and layer elements, detecting Internet Explorer, and serving them alternative code. Netscape 6.0 came out, it didn't support the proprietary Netscape-isms of previous releases. Following standards ensured forwards compatibility with Netscape 6.0.

More recent problems include stylesheets served with an incorrect content-type header, and table-layout images being broken up with lots of little gaps.

This list only includes Netscape behaviour, as that is the only list I have to hand. (Thanks to this article). I'm sure similar things apply to other browsers.

There is plenty of evidence that sticking with standard code results in forwards compatibility.

There are really only two important properties of future browsers:

• They are likely to support at least as much of the specifications as the current version
• Nobody can test in them

Thus, my overwhelming desire is to simply treat future browsers as I would any other browser I couldn't test in: code to standards, and when I get a chance to test, fix up what is necessary.

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.

Re:Reasons to validate

[Bronster]

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.

Using Flash = Validation Fail

[Andy_R]

Last time I looked, there was no way of embedding Flash in a page that validates and actually works in most browsers. Therefore, I gave up on validation.

(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:Using Flash = Validation Fail

[Bogtha]

Last time I looked, there was no way of embedding Flash in a page that validates and actually works in most browsers.

Look again.

Re:Using Flash = Validation Fail

[Stalin]

There is the problem. You want the user to see what you see. The point of the web is to transfer information. It is possible to suggest how that information is presented, but, ultimately, the user decides how to "view" it. Fonts and moving pictures are pretty but they are distracting. I have a hard time reading unmoving text when there is something in view that is moving at all. So, your "right balance" is completely wrong for me.

Back to the original point of this thread. Those two links where the site is nothing but Flash are exactly what I was talking about. I don't feel any desire to find or read the content because it is too difficult get to. No, it isn't hard to (for me) to see the image that says something akin to "click here," click the image, and get the content. The difficulty is that I had already asked for the content. I shouldn't have to start clicking more things to get to it unless there is more content that would make sense to be on another page (like the pages of a book). And then when I do have to navigate to a new page, I should have to wait for a bunch of animations and loading screens. I should be presented with the meat of the content (readable text) while any images load. That way I get what I am looking for and the pretty stuff fills in as my connection allows.

Again, I'm not trying to attack you, but writing off validation because you don't understand its purpose is something that bugs me.

Anyone who answers "no" to this headline...

[Dracos]

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.

Re:Anyone who answers "no" to this headline...

[Blakey Rat]

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.

Re:Anyone who answers "no" to this headline...

[zx75]

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.

Re:Anyone who answers "no" to this headline...

[CestusGW]

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?

Re:Anyone who answers "no" to this headline...

[Anonymous Coward]

...I should write a book about XHTML/CSS/web usability. I've read the standards, I know the standards, and I know how to avoid browser bugs rather than hack around them after the fact.

heh heh heh... 208 errors

table vs. div

[Lauritz]

I would like to ask a follow-up question: Do the replacement of tables with div-elements really help anybody (besides giving job security to web developers)?

Note that I am not at all against css. But I just find the table-tag very usefull for layout. If you need to do a three-column layout it will be much easier and give cleaner code to just use a table, than to use one of the many css "hacks" needed to give the wanted result in most browsers. If you want the layout to do something "extra" (eg. "make the center column 400px wide, but allow it to grow if the cell contains a wide image, pushing the right column") it will (probably) be impossible using divs, but trivial using tables.

One reason to not use tables, that is usally given, is that tables should only be used to tabular data and not for layout, as to not create problems for blind users. But just an empty alt-attribte on an image signals to the user-agent that the image is for layout only, a empty summary -attribute on a table could for example be used to signal that the table is for layout only. My guess is that, that convension would be much easier for user agent implementors to use that to parse through all of the css hacks. I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

Re:table vs. div

[Bogtha]

Do the replacement of tables with div-elements really help anybody

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>.

If you need to do a three-column layout it will be much easier and give cleaner code to just use a table

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.

I also feel that it would be semanticly much cleaner to have a table with one row and three cells than to have three or four divs nested and floated in strange ways.

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.

Re:table vs. div

[Bogtha]

The topic was html, not xml, so it is not about marking every bit of information up precisely.

Actually, it's HTML that has semantics, XML is just a markup syntax, so it's definitely about marking information up precisely.

It is about presenting a pice of information for easy consumsion for a human (blind or otherwise).

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.

Re:table vs. div

[Valacosa]

"With tables, you have to hack up stupid s and s for each and every page you do."

Not true, due to the magic of PHP and server side includes. Sure, the table may be ugly, but I still only have to hack it once.

NOTE: I use CSS. However, I have found it's much easier to flog tables into doing what I want, DIV's have never been that co-operative for me. CSS beats <font> tags any day, though.

Re:table vs. div

[kiddygrinder]

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 s and s for each and every page you do. Mindless, boring, repetitive work.

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:A relevant quote

[globalar]

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.

I hate to break it to you guys...

[firegate]

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 ;).

Re:konqueror also passes

[gdchinacat]

So, I had to try this out and see it for myself. And, sure enough it rendered correctly. Then I started noticing the problems.

Here is a screenshot after "scrolling" using either the scroll wheel or up/down keys (despite the fact — as you point out — that there are no scroll bars).

And another one after a resize of the window. I restarted konq before doing the resize, so the issues aren't left over from the scrolling.

Also, note in the resized screenshot that the progress bar is stuck at 37%.

So, IMO, close, but not quite. However, close is better than most of the other browsers out there.

Re:A relevant quote

[ErisCalmsme]

This is a Yogi Berra quote. "In theory there's no difference between theory and practice. In practice there is." ;)

Re:A relevant quote

[Frogbert]

Sure that makes sense in theory, but in practice it probably doesn't.

Re:konqueror also passes

[Mornelithe]

From the Acid2 page:

If the Acid2 page is scrolled, the scalp will stay fixed in place, becoming unstuck from the rest of the face, which will scroll.

Changing the size of the window has similar effects. Konqueror is exhibiting correct behavior; the test wasn't designed to keep the face constant after scrolling or forcing the browser to adjust the positioning by resizing the window. It's just supposed to display correctly after you click on the link that jumps you down to the face.

Only if...

[GWBasic]

Only if it doesn't compile.

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.

Re:Only if...

[Threni]

> If you were a CEO and your company displayed such an error, what would you do?
> Those are the people who the error message targets.

Depends if I thought I'd lose money over it. Imagine if eBay, google, or whichever company you use to get PC components displayed that message. You'd still use the site. You'd just disable it. It's a meaningless message - nobody cares if a browser is compliant or not. You're just not going to get the public en masse to start emailing the owner's of websites who aren't compliant demanding change - ain't gonna happen.

It would be a crazy decision for Microsoft or Mozilla or whoever to make - to have the message displayed as default. It would just generate thousands of support calls or annoyed emails etc, and absolutely no gain.

I've used many browsers and visited many websites over the years and I simply have no interest in knowning whether or not a site/browser is compliant. Some sites I couldn't visit because of their reliance on Active-X controls, but the idea that my mother cares whether or not LeetBlogSpot.html has a missing semi colon 45k down the source code is laughable.

Acid2 and standards

[RC_Car]

Isn't Acid2 a test on how a browser handles errors? If all browsers handled errors the same way, then couldn't some errors end up turning into standards?

Acid2 feels like a step in the right and wrong direction at the same time.

oh, the irony

[circletimessquare]

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)

Yes, and without hacks.

[Metasquares]

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! 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.

Opera 9 and Safari 2 are both beta

[MojoStan]

I don't know why the article submitter said Opera 9 was the only compliant browser when the ACID2 Buzz page clearly shows other browsers (at least in beta form) have passed the test.

Anyhoo, the ACID2-compliant versions of Opera and Safari are beta releases and not displayed on their main download pages. Opera's download page displays Opera 8.5.4. Safari's download page displays Safari 1.2. IMO, I don't think ACID2 compliance is something to brag about if your compliant browser isn't stable enough for release.

Re:Opera 9 and Safari 2 are both beta

[allgood2]

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.

Re:A relevant quote

[Dan Ost]

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.

It's the Mindset

[RobertF]

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.

I care if it's ADA 508-compliant, for disabilities

[Anonymous Coward]

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.

Standards compliance

[SlashBoot.org]

Yes I care about W3C standards compliance. I take pride in my work and do not settle for bodges. There are also benefits to producing clean code, in bandwidth and processing savings. More sites and publishers should be making the effort to ensure that the pages they present are in compliance to accepted standards. My site http://slashboot.org/ is standards compliant and I take pride in that. I prefer XHTML Strict, as I see this becoming a future standard of choice for the majority of people who also take pride in their work

Re:A relevant quote

[codewarren]

Those are 8 proofs that the "standards" are not the standards.

Microsoft and web standards support

[yoz]

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.

Don't blame the browsers

[ichin4]

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.

This is like counting "security patches"

[MarkusQ]

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

Who cares what I care?

[elwin_windleaf]

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.

when i *finish*?

[croddy]

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?

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.

Abides by HTML standards, not W3C

[kyndig]

I've read many of the comments on here, and man am I feeling like a heel. I know I'm not the only web developer that doesn't give a hoot about that little W3C compliant icon. As long as the site operates properly in Firefox, Safari, Opera, and IE ( as I've designed it to operate ), then that suites me fine. After 5 years of developing the same site, the only complaints I receive on it are ones about my poor design.

This brings to mind the software developers that howl about their Interface Standards ( I can't even remember the acronym they use for these standards ) I've supported the development of software for the past 3 years, and have yet to look at these Interface Standards.

I focus on the end-users eyeballs. If some developer comes along and wants to complain about my syntatical correctness - they can either copy/past my HTML to make it better - or provide a patch for my software. The regular users are quite satisfied.

Re:which makes the validator useless

[hahafaha]

No, that makes your code useless. The point of an attribute is to describe the behavior of a tag. If the attribute is unknown, then the tag does not behave the way in which you told it to. That makes that attribute, a part of your code, completely useless.

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.

yes, we do care

[nkeric]

our company has a specialist of html (a girl:) who spends tons of time ensuring our projects' web pages work properly across multiple major browsers/versions and pass the w3c html/css check.

we believe that it's a good habit to make web pages w3c compliant, that ensures your web pages work properly with w3c compliant browsers. meanwhile, we will take care of browsers such as IE which has buggy html/css support by using some tricks/workarounds to make it render properly too.

*ahem*

[Anonymous Coward]

"Acid2 Goes on Safari

Yesterday Dave Hyatt posted news that Safari now passes the Acid2 test, making it the first browser to do so. Patches to enable Acid2 related support have been made available in Hyatts announce post, linked above. Under the circumstances, I thought it would be unfair to simply announce the news, so I ...

By Ben Henick | April 28th, 2005" ...and... BTW this version(of safari) was released shortly after this...

Re:And besides...

[Myen]

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 disagree; it does not depend on usage

[hobo sapiens]

For commercial sites, it's all about ROI

Aaargh! You imply that developing a website using web standards takes longer. False! It _does_ require that you exercise more care. Do it for more than one website and it'll become second nature, meaning things like using closing tags on everything, quoting attributes, and properly nesting tags.

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.

Re:I disagree; it does not depend on usage

[julesh]

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.

Re:I disagree; it does not depend on usage

[adamfranco]

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

+1 Insightful

[Neoncow]

If you're looking to Slashdot for peer approval, you're just asking for a nightmare.

+1 Insightful
..

Oh wait..

Theory and Practice

[mysta]

We're straying off-topic now, but that sounds a lot like this quote from the Danish computer scientist Jan L. A. Snepscheut (1953-1994):

In theory, there is no difference between theory and practice. But, in practice, there is.

Browsers and Standards

[pavera]

I attempt to follow standards as much as possible, however because IE is so hideously broken, it almost doesn't matter. I recently developed a site, ran the validator on it, it passes fine, it all works in firefox and opera, displays how its supposed to, everything's great right? Open it in IE, totally broken, things don't line up, the spacing is wrong, everything looks like crap... go through everything to fix it, get it so it displays "right" in IE, run the validator again.... oops errors all over the place...

In short I don't think its possible to write a standards compliant page and have it display in IE properly, as long as this situation persists, it will be impossible to push "standards" on the internet. If the standards don't display correctly on 90% of the computers, what are you supposed to do?

Re:And besides...

[hacker]

The problem isn't HTML vs. XHTML and passing self-closing tags as HTML, the problem is that 99.999% of people using XHTML content in their pages, are not sending the proper XHTML Content-type for those pages.

There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

Thankfully, MSIE doesn't even support XHTML at all, so we're safe there... for now.

This writeup is very clear on the matter.

Standards created lots and lots of.. fanatics

[suv4x4]

There are several types of them:

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:And besides...

[Enrico Pulatzo]

Actually, most tags can be closed in that way in HTML without problems. The script tag for some reason demands itself to be closed with an explicit end tag. img, object, br, hr all work fine with the XHTML style in HTML (they even validate). meta and link require exactly no end tag in HTML, and are invalid if you add it in.

Re:FireBug

[kadnan]

FireBug is a good Firefox extension to catch evil tings in your page.It has a builtin validator as well.

Re:And besides...

[Bogtha]

There is ONLY ONE valid Content-type for XHTML content, and that is application/xml+xhtml, not text/html.

This is simply not true. RFC 2854, the definition of text/html, explicitly permits XHTML 1.0 documents that follow Appendix C to be transmitted as text/html.

Doing so causes Mozilla and Opera to parse it as HTML and not XHTML, but that doesn't mean it's "invalid" or non-standard in any way.

What about accessibility and disability

[Information Architec]

The W3C initiative started out as a concern that geeky sites were fine for, well, geeks but there are a lot of people out there from blind and sight-limited users to more people who just can't stand or get their heads around the shoddy interfaces of poorly designed sites... Thee is nothing on this thread so far about how you address this. Yes many badly designed sites are popular but that doesn't make it right that a substantial proportion of users, or potential users, are effectively locked out because good, accessible design was never thought about at the beginning or, at best, was just a few tweaks bolted on at runtime. The big advantage for Microsoft over OSS is precisely that they can act as a single interlocutor with blind and disabled associations, something the OSS community cannot provide: to paraphrase Kissinger: I'll work with the OSS community if you can give me their phone number... Microsoft does actually test much of its software with such groups but I've yet to see anyone promoting OSS solutions to take that trouble. Call it a market grab if you will, but it seems to make good business sense as well as being "politically correct".