Hixie's Natural Log

2002-06-13 21:59 UTC Buzz: Third shot disintegrates

Simon has replied to my response to his reply to my comments about the WaSP site:

"When CAN we start using XHTML?"

"When can we start using CSS1?" is an equally valid question which we've only just recently started to seeing the answer to. CSS1 came out in 1996, 6 years ago, and the most popular browser (WinIE) is only now starting to show an inkling of the start of the beginning of a hint of something that might be described as semi-solid support for CSS1. So let's assume it takes as long for us to be able to use XHTML: 6 years. XHTML came out in 2000. So that gives an estimated answer of: 2006.

Of course, the difference between CSS1 and XHTML is that you can't use parts of XHTML, it's an all (text/xml) or nothing (text/html) deal. So in practice it'll be longer, since you won't be able to use rely on backwards compatability tricks like with CSS1.

If by serving content with a text/html header I can create pages in future-proof, easily parsable XHTML and have them accessible to virtually every browser ever [released], XHTML it shall be. Then when browser support catches up I'll be ready, and so will my websites.

But you won't be ready. Your site doesn't validate. When you switch to sending your site as text/xml then boom, your readers will just get XML validation errors. In any case, there's no reason to switch legacy documents to new formats. Do you see anyone going out of their way to change old "HTML 3.2" documents (specifically, the tag soup mess that they claimed was HTML 3.2) to HTML 4.01 Strict? And do you think browsers are going to stop supporting text/html any time soon?

And Minh Nguyễn: thanks for agreeing with me but your Web site doesn't validate either.

XHTML is a good thing, on the long term. However, the bandwagon that everyone is jumping on is ridiculous.

2002-06-13 16:08 UTC Buzz: One shot stuns, two shots kill

Simon Willison suggests that I may have been too rough on the WaSP:

Some of his points seem overly picky [...] I would not consider any of them to significantly dilute WaSP's message.

The message may not be diluted... I simply think it is very bad form for a group that is claiming to champion the standards to be making any mistakes at all on their site.

I checked a site Hixie mentions as sending the correct text/xml content-type header in NS4 and, as I suspected, NS4 popped up a "download" box and failed to render the page.

Which is correct behaviour, since Netscape releases prior to 6.0 didn't support XML. In fact, IE doesn't support XML either (check the site and see if it looks like a web page to you). This is why using XHTML at this time is inappropriate! You don't see people writing Web pages using XLink, or MathML, or SVG, and there is a good reason for that: Web browsers don't yet support those specs! So why do people insist on using the equally unsupported XHTML? (Of course the question Tantek would have us ask is "Why are those specs not still in CR?".)

I also checked out the W3's XHTML home page - XHTML1.0 strict and a content-type header of text/html.

The W3C site is a terrible example of good standards compliance. They have trailing vertical bars in their <link> element titles, they abuse the <address> element, and worst of all, they use a table for layout purposes.

2002-06-13 13:08 UTC Hedgetrimmers were necessary

Today I got my hair cut.

So for I've had three prolonged looks of consternation, one "fucking hell", one "it's about time", one "Hixie!", one "I almost walked past you", and one "Something's different... I just can't quite put my finger on it".

2002-06-12 10:36 UTC Buzz: Shooting the messenger

The Web Standards Project recently unveiled themselves again. This time their message seems aimed more at Web authors and Web users than Web browser developers.

Isn't it sad, then, to see that their own Web site has several common errors? Sure, it validates, but that's only because the validators are merely checking that the documents follow the relevant DTDs, not that they are following all the rules of the specs. (In their defence, this site is better than most. However, given their message, they should be perfect.)

Let's take a look at the www.webstandards.org markup. The first thing we notice is that it is sent as text/html, but it contains XHTML. While that's technically allowed by the specs, it makes no sense... XHTML and HTML are technically incompatible. (For example, <br/> in XHTML is actually equivalent to <br>&gt; in HTML.) What really makes no sense is that the whole point of XML (the basis of XHTML) was that it should avoid the mistakes that tag soup created... all XHTML markup on the web should be valid. But if you send XHTML as text/html, then browsers will treat it as plain old HTML (i.e. tag soup) and not complain about errors! You can see this demonstrated very well by mpt's Web log (see what the validator makes of it). XHTML is great; but if you use it, sending it as text/html totally defeats the point. (It's XML. Send it as text/xml. Like this site.)

The next thing we notice about the WaSP's markup is their stylesheet.

It contains mistakes such as not setting backgrounds and colours together, setting hover rules for anchors as well as links (David Baron has written a nice page explaining this issue), and positioning blocks using pixels instead of ems or percentages, which is why the site fails at unusual font sizes.

Back to the XHTML markup, we start noticing some much more serious problems.

<div id="Header">

Excuse me? What is <h1> for?

<img id="logo" ... alt="Web Standards Project logo" />

Rather inappropriate alternate text... the image doesn't say "Web Standards Project Logo", it says "Web Standards Project".

Below that we find a paragraph of text that is left semantically neutral (it should be wrapped in a <p> element). Then, only a few lines lower, we find presentational classes: <div class="padder">. That's followed by an <h1> just above an <h3>, skipping an entire level of headings (<h2>). We're also faced with a bunch of empty paragraphs, which makes no semantic sense.

In conclusion, while the message is the right one, the messenger is confused. Standards Compliance is a laudable goal, but it's not blind obediance to the validator which will bring us that; it's structurally correct markup with well written stylesheets, using appropriate technologies at appropriate times.

2002-06-10 19:48 UTC Why humanitarian eugenics wouldn't work in practice

Nadia points out the main reason why humanitarian eugenics wouldn't work in practice: it can't be policed effectively without going beyond what people would accept. In an ideal society, we could get everyone to buy in to the system, but in our society...

Well, I guess our hopes are all pinned on genetic engineering then.