State of the Validation 2002.

February 22, 2002 9:32 AM

State of the Validation 2002. Off the 506 W3C members, only 18 (3.6%) have sites that validate with the W3C validator as either HTML or XHTML! 141 members' sites have definite markup errors. 342 members' sites don't even include the DTD, therefore they can not be tested. [via the big orange Z.]
posted by riffola (26 comments total)

Only 3 out of 18 use XHTML
Istituto di Elaborazione della Informazione
Enosys Markets Inc.
MITRE Corporation

Ravisent is now Axeda and Axeda's site doesn't validate.
posted by riffola at 9:48 AM on February 22, 2002

It's great to see this criticism of the W3C members - they're asking for it.

To be fair though, there are loads of sites that don't validate (would like to see some real numbers, but I wouldn't be surprised if that slim percentage was similar in a survey of the top 100 sites on the web).

MetaFilter doesn't validate either, but I can understand why. There are some margin tags that Netcsape 4 requires and newer browsers ignore that the validator doesn't like. Also, for dynamic sites, the validator trips up on urls with the '&' character in it.

Still, I do my best to make sure my sites validate (or come as close as possible) and the pressure should be put on all popular sites to do the same. It should go without saying the W3C members should be striving to comply.
posted by stevengarrity at 9:54 AM on February 22, 2002

opera.com validates!
first thing that came to mind.

so it can be done!

i am coming to the conclusion that the w3c mission statement: 'Leading the Web to its Full Potential...' by promoting 'Universal Access: To make the Web accessible to all by promoting technologies that take into account the vast differences in culture, education, ability, material resources, and physical limitations of users on all continents'

is as difficult as it sounds. even for them.
posted by asok at 10:38 AM on February 22, 2002

342 members' sites don't even include the DTD, therefore they can not be tested.

No, the validator can't detect(obviously, since it's not there) what DTD they are using. This means the person has to manually select what level of markup is being used when submitting the URL to the validator. It's that little drop-down that says "Document Type: detect automatically." Click it.

To not bother testing roughly 70% of the sites, and then make a sweeping generalization like that is totally irresponsible. This person was lazy, apparently wrote a script or somesuch that obviously didn't even try any of the DTD-less sites more than once with say, the HTML4 and XHTML1 options, and then drew a conclusion.

DTD's are not absolutely required at this time.
XHTML is not that big a deal, and is generally only worth doing as an experiment to see if you can. It's geek cred.


He's talking out his ass, plain and simple.
posted by Su at 11:03 AM on February 22, 2002

...not to mention that he's got "book antiqua" in his font tags. that's just crack-addled.
posted by patricking at 11:07 AM on February 22, 2002

Okay, um...so why is a table used for this guy's nav layout?
Remember, folks, the validator checks the markup syntax, not whether its usage is proper.
posted by Su at 11:12 AM on February 22, 2002

Good points, I agree about the misuse of tables for layout and that he should have have checked the sites without the DTDs for valid HTML. When i saw this I found it interesting that the members themselves aren't adhering to the standards. Also I was thinking about it in terms of XHTML, where the DTD is needed, but you are right that the sites could be valid without the DTD.
posted by riffola at 12:00 PM on February 22, 2002

Su, a DTD is required. A document without a DTD cannot be a valid document, though you can assess the validity of the rest of the document by hand selecting the document type with the w3c validator. However if you do, you get this message:

Please note that you have chosen one or more options that alter the content of the document before validation, or have not provided enough information to accurately validate the document. Even if no errors are reported below, the document will not be valid until you manually make the changes we have performed automatically. Specifically, if you used some of the options that override a property of the document (e.g. the DOCTYPE or Character Encoding), you must make the same change to the source document or the server setup before it can be valid. You will also need to insert an appropriate DOCTYPE Declaration or Character Encoding (the "charset" parameter for the Content-Type HTTP header) if any of those are missing.

posted by ericost at 12:08 PM on February 22, 2002

the validator trips up on urls with the '&' character in it.

It doesn't like & along side anything that's not a character entity. Putting '&' singularly in an URL is invalid (and ambiguous) but & is correct.

the validator checks the markup syntax, not whether its usage is proper.

Validator.w3.org should take some blame for that. There's no effort on its part to define it's limitations, or to distinguish between syntactic compliance and standards compliance.

Hell, you may as well use CSS to change the information on a page like webstandards.org promoted.
posted by holloway at 12:08 PM on February 22, 2002

Not only is it doable to validate but it's also a good thing. I've found that the 6.x generation of both IE and Netscape seem to interpret XHTML in pretty much the same way. As a result, if you validate, you reduce the number of problems between the two.

Interestingly enough, you can still use tables for layout in XHTML, as long as you mark it up as transitional XHTML. That's what I do on TNL.net and it still validates properly. There seems to be a misconception out there that all XHTML has to be handled via CSS...
posted by TNLNYC at 12:14 PM on February 22, 2002

Ericost: My mistake about the DTDs, sorry. I thought the HTML4 spec still didn't require them. I pretty much skipped it to the XHTML one.

TNL: Your site validating was exactly my point. The validator has no way of knowing you used the table for layout. It just checks that all your tags are paired up properly, include the correct attributes, etc. Transitional or not, tables are still meant for tabular data, not layout. It's never been proper to use them for layout. It's a trick graphic designers came up with when proper HTML didn't give them the visual control they wanted. There's actually a (rather elaborate) replacement for table layout being developed for CSS that looks really nice, if you can follow all the markup.
And besides, his site is marked at Strict *grin*

Holloway: I sort of remember the page had a link to a list of limitations and stuff. Does anyone else, or am I just on crack?
posted by Su at 12:34 PM on February 22, 2002

Su: You actually point out an interesting thing and this is a question I have for the group as whole. Considering that we all want to support *most* web browsers out there, how long until we can chug the table structure and move completely to a CSS based layout?

One of the main reasons I'm still doing table formatting is that I want to still have a site that looks *reasonably* good on Netscape 4.x.
It's been a while since I've moved to a completely modular approach (each of the page component is broken out to ease the way I present thing) and it would be relatively easy to move to an all-dancing all-singing CSS version of the site.
Yet, I'm not doing it because I'm not seeing the return on time-investment.

How many MeFi users out there do pure CSS formatting? And what about XSL? Has anyone out there completely abandoned the table layout? And if yes, what was your experience in terms of browser support?
posted by TNLNYC at 2:18 PM on February 22, 2002

i don't think people need to quit using tables -- i think there are times when using tables is the right thing to do. that said, CSS works best for me when i try not to do much with it. if you make heavy use of floating divs or skew the margins and padding as often as possible, you will run into problems: definitely. i know i did. XSL looks like a horrible mess to me, and for my purposes (a personal website) it's just not worth diving into.
posted by moz at 2:34 PM on February 22, 2002

TNLNYC, I'm doing pure CSS formatting on some of the pages/sites at my job (pierce college - the home page has a couple of dorky hacks, just because there are so many NN4.x devotees on staff), and I'm trying to make the (X)HTML as structural as possible.

it's a slow process of retrofitting one piece at a time, but I'm finding that I like it, and that I like the results as well. (I had fun this week rewriting some alt attributes to make them more meaningful!)

actually, I should thank holloway for his snarkiness in an earlier thread that I don't have time to search for...it gave me food for thought.

onto the topic: I tested a couple of the sites that didn't have DTDs, and it's not like that would've helped. :) (check out adobe, if you have time; it hurts my head.)

and the idea of giving up html presentation hacks (tables, font, etc.) is a little bit like walking on the tightrope with no net for some...you have to let go and realize that not everyone gets an identical visual experience, and that that's okay.
posted by epersonae at 3:10 PM on February 22, 2002

XSL is good for transforming to and from documents that consist of XML but that's very few formats. You'll go to escape single quotes in an HTML javascript function call and you can't do it without a kludge. Try getting © in the output HTML of half the processors out there.

For the NZ E-government site I've been writing XSLT to transform XML documents into HTML. Many of the problems were to do with Microsoft's XSL parser but it can't take all the blame.

If you just want to move about between XML formats then XSLT is well suited but soon you'll want search/replace, or to just push through a character without it being converted, or you'll want a dorky hack because there so many NN4.x devotees, and the language just won't help you (XSLT allows you to replace one character with another, but not one character with two characters). The language just isn't a general purpose text/XML wrangler.

Because of this you'd need to tack on a search/replace script on the XSL output. And because of this client-side XSL is limiting.

(this is for XSL1, I'm told XSL2 will fix many of these problems)
posted by holloway at 3:26 PM on February 22, 2002

interesting. I've been chewing over the possibility of using XML & XSLT to do some work with our bulletin, which is a pain in the ass to put together. now you're making me wonder whether it's going to be worthwhile.... :P I'm not going to give up on it, though, whatever weird stuff we'd have to go through has got to be better than the "enter it 3 times in 3 separate formats, then reformat it in InDesign, then copy & paste in HTML" that we're doing now!
posted by epersonae at 4:04 PM on February 22, 2002

Transitional or not, tables are still meant for tabular data, not layout. It's never been proper to use them for layout.

An oft-repeated lie. The original 3.2 spec: “HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents,” a claim that is no longer true and hasn’t been for years.

The HTML 4 spec: “Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media.” Should not does not mean must not, and here too there are essentially no such problems anymore.

CSS is nice. Tables are not so bad. And I am telling you right now the accessibility defects of tables are overblown or outright false.
posted by joeclark at 7:26 PM on February 22, 2002

Well then, joeclark, I respectfully suggest you spend a day surfing with a browser designed for the disabled. With your eyes closed. Hmmph. Thought so.

I gave up trying to point out blatant accessibility problems on popular websites ages ago. I'd invariably get a response like, "You're the only one who's complaining. You should install the latest version of [insert designer's favorite browser]. Looks fine on my machine."

Table layouts, fixed-size fonts, and low-contrast color schemes are just a few of the accessibility faults I find on almost every single site I visit. I thought that most web designers would welcome constructive critique since it's nearly impossible to test layouts on every conceivable platform, but almost every one of my emails was met with defensiveness, if with any response at all.

I know how difficult it is to accomodate the staggering disparity in modern browser rendering, but even the digerati (especially the digerati) have been surprisingly reluctant to relinquish their old-school HTML techniques for the updated standards. It's as though we refuse to suffer through the entire learning process again, or don't have the patience to explain the long-term advantages to our employers.

What troubles me most is that the next generation of web literates are using our source as their tutorial. If it's well-nigh impossible to convince Kottke to examine his accessibility, imagine trying to teach the ocean of wannabe bloggers emulating his site to do the right thing. "If [insert favorite blogger] uses pixels in her stylesheet, why shouldn't I?"

I'm glad to see the recent attention being paid to practical CSS/XHTML layouts by talented web designers, and I encourage all of us to help set the correct example by incorporating their experiments into our own designs. The web will be a far better place because of it, and our skills won't be obsolete so quickly.
posted by johnnyace at 12:17 AM on February 23, 2002

reluctant to relinquish their old-school HTML techniques for the updated standards.

You see, you started your post with what works for users, then you go into how new standards fix this. It's broken logic.

For most using CSS layouts does more harm than good (despite being an updated standard). What works and what provides best for users isn't new standards at the expense of the old.
Legacy browsers demand what they were built for, and it's not the latest thing. What provides best for users is a smart mish-mash of old and new. It's the same old choice. Program for browsers, or program for standards and jerk yourself off that you're going to be sitting pretty come five years later. What works best in the browsers out there isn't any one standard that validates at validator.w3.org. I wish it wasn't so.

"You're the only one who's complaining. You should install the latest version of [insert designer's favorite browser]. Looks fine on my machine."

You seem to dislike this type of attitude. Yet in a XHTML/CSS page I'd need to upgrade to [insert programmers favourite browser] or suffer usability problems too.

I have many usability concerns for users of older browsers in a change to CSS layouts in particular. And for what, print style sheets? Maintenance? If a site has a backend it makes no difference whether they fill a DIV or a TD with dynamic content. The CSS layouts that work in 4/5+ browsers are one inelegant hack after another (though they are syntactic compliant hacks, granted).

I could do abbr, acronym, title and accesskeys while designing the rest of my page with HTML 3.2/4.0 the occasional font tag and liberal use of CSS without nested tables so the javascript image mouse over bug in N3 didn't come up. In the (few) tests I have done on my commercial sites the usability benefits were clear. For the moment, XHTML/CSS is too bleeding edge to be appreciated by anyone but programmers.

Of course programmers matter too, and they should make decisions on behalf on their users, but not all new standards have a payoff for your audience.
posted by holloway at 1:35 AM on February 23, 2002

holloway, I'm the first to concede that dealing with the staggering number of browser exceptions has limited the practical use of validated XHTML/CSS for all but the simplest of designs (everyone tired of accomodating NN4.x raise your hands). And I also agree that changing the transform template for a database-driven site to generate the HTML flavor of the month is trivial.

However I take issue with your assesment that CSS does more harm than good. If nothing else, the separation of presentation style from semantic content is the most important development we as web architects must embrace. Consider the day when all that's left of our sites are spidered archives, long after the database that generated them has been retired. Without strong semantic markup clearly delineated from presentation, those records will be lost to future generations due to the sheer volume of information lost amongst reams of obsolete display code.

I argue that it's our responsibility to eschew pixel-perfect browser-accomodating design in favor of gracefully-degrading flexible layouts. I know that not every commercial project is the appropriate venue for advocating new technology, but if we don't educate those who make the decisions, who will?
posted by johnnyace at 3:52 AM on February 23, 2002

Well then, joeclark, I respectfully suggest you spend a day surfing with a browser designed for the disabled. With your eyes closed. Hmmph. Thought so.

Yo, fuckwit. In deference to the general discouragement of autobloggatio ruthlessly enforced against people like me (but never the Kottkes), I went out of my way to avoid mentioning that I am the author of a book about Web accessibility. I am an expert on media access of 20 years' standing.

And newsflash: Every screen reader in current use save for OutSpoken for Macintosh can handle tables perfectly. Oh, and as for surfing with my eyes closed? I run Lynx every day of the week.

Put that in your pipe and smoke it. Do please trundle off and do something you're good at, apart, I suppose, from publicly exposing your ignorance, which we're already familiar with.
posted by joeclark at 5:19 AM on February 23, 2002

joeclark, pardon me while I remove my foot from my mouth. It figures that the one person I take to task for probably never having even seen a screen reader is actually a usability expert. Imagine my chagrin.

However you of all people should know then that deeply nested tables used exclusively for page layout by novice designers with no consideration for browser versions other than their own can wreak absolute havoc on a site's accessibilty. Of course you can use table layouts effectively, but would you not agree that the vast majority of novice designers cannot?

I appreciate that you felt I was insulting your intellect and qualifications with my dismissive response, but the "fuckwit" personal attack was uncalled for.
posted by johnnyace at 5:58 AM on February 23, 2002

Consider the day when all that's left of our sites are spidered archives, long after the database that generated them has been retired. Without strong semantic markup clearly delineated from presentation, those records will be lost to future generations due to the sheer volume of information lost amongst reams of obsolete display code.

Such odd scenarios demand examples. The Windows platform has been sufficiently reverse engineered to run Netscape 3/4 on Linux. It's entirely safe to say that, due to the amount of software on Windows that people want to run, we'll have a bucket load of old crappy browsers with them in five and ten years time. Microsoft themselves have kept up with their legacy support. Show me an example whose information is lost without cleanly seperated style/content, then show me a page that exists right now that would be affected. This argument has no merit.
posted by holloway at 10:38 AM on February 23, 2002

On the specific question of nested tables, yes, they can be quite a bother with a screen reader, but typically only in the case where a subtable is used to create what looks like a sidebar or a pullquote on the page. If you have to place all your text within one table that is itself within a single table cell of another table (as is often necessary to centre a column), it takes another step to pass from one cell to another in a screen reader, but it is merely inconvenient. A "Skip to main content" link can solve that problem. Further, badly nested tables of that sort are most often the result of rogue authoring programs (COUGH FrontPage COUGH), in my experience.
posted by joeclark at 11:48 AM on February 23, 2002

I was a bit tough on XSLT. It's great for mangling XML. Just don't expect to be able to do it all on its own.

more
posted by holloway at 3:53 PM on February 24, 2002

thanks for the link!

myself, I'm happy to remove the tables not so much, or just, for Lynx, screen readers, etc. as for myself. which tables/cells are the navigation hoo-hahs in? did I/they (previous designer(s) - often novices/students) put different chunks of the main content into different cells? which of those "shims" and "clear1px" images are necessary, and which can be pulled safely? joeclark, is there a good free/share screenreader that you'd recommend?

and not every site with loads of content is running off of a database, alas. I have <checks folder> over 700 pages in the "core" part of the site that I work on - some old versions of pages that I hold onto so the URL won't die, some temporary, or previous class schedules - but many in current use, and that doesn't count the projects for other departments. none of it runs off of a database...I imagine I'll be heading in a direction that separates layout from content even further as the years go on, but I'm not there yet.

so all I have, in terms of being able to peel apart the layers of my site, is PHP includes, (X)HTML, and CSS (oh, and I'm using a bit of Flash & JavaScript as well).

and I like I said, using it in a way that lets the XHTML handle the meaning, and the CSS handle the look, and the PHP handle the common stuff (navigation elements & the like) makes my life a little easier - and I'd like to think makes it easier for me to make the content better for our users/visitors as well.

(sad but true: I dreamt the other night about a change to the site that I think will make it more usable and reinforce the navigation scheme. I'm thinking it will only take me about a half-hour today to pull it together, after a bit of testing on my sample page...as opposed to the weeks it would've taken me with the state the site was in when I started working here 1 year+ ago.)
posted by epersonae at 9:07 AM on February 25, 2002