loge.hixie.ch

Hixie's Natural Log

2002-11-13 15:42 UTC Markup Challenge 1: Bed and Breakfasts need not apply

While the old school continue to throw up horrendous markup and publish invalid gibberish, there are some of us who are trying to lead the way to writing semantically rich, valid markup that is accessible and free of presentational markup.

However, it seems that even respected champions of standards compliance have their weak moments. To wit:

<script type="text/javascript"> // sneak 'target' attributes past the validator.
for (var i=0;i!=document.links.length;i++) { 
 var L=document.links[i];
 var c=L.className; 
 if (c=='local') {L.target='_top';} 
 else if (c=='photo') {L.target='z';}
 else if (c!='plink') {L.target='lockon';}
}
</script>

Come on! Actually I think it's still technically valid, although it's definitely treading on controversial ground. The "semanticness" of such markup is certainly suspect. And please. If I want to open a link in a new window, I'll do it myself!

What's really sad, though, is that in my search for sites to use as links in the "such as us who are trying to lead the way" bit, I could only find two sites that qualified as closer to perfect than the one I quoted — and mine was one of them. (And I'm not happy about the number of <div> elements and class attributes I use.) Surely someone out there must have a completely valid, semantically rich, no-presentational-markup, strictly compliant Web log? I hereby challenge people to send me links to their Web logs if they think they do. A word of warning, though, if yours isn't, I won't hesitate to use it to humiliate you!

Pingbacks: 1 2 3 4

2002-11-08 19:21 UTC CSS3 Lists Module: Call For Comments

Today the latest draft of the CSS3 Lists Module was published on the W3C Technical Reports page as a Working Draft. I am therefore now soliciting comments and discussions of this draft. Please send your review comments to the www-style@w3.org public mailing list (archived) (see subscription instructions).

I'm especially interested in comments regarding the algorithms, as well as any possible solutions to the open issues listed in the document. See my www-style post for more details.

2002-11-08 14:53 UTC Content negotiation in heterogenous XML environments

I recently came across RFC 3023, specifically appendix A. It normatively updates RFC 2048. RFC 3023 is a well written RFC, clear and understandable.

The problem that this specification tries to solve is what MIME types to use in the presence of XML documents that contain mixtures of namespaces. For example, a server could serve one URI as five different documents: pure XHTML, XHTML+SVG with the root element being XHTML, SVG+XHTML with the root element being SVG, XHTML+MathML with the root element being XHTML, and some typical RDF with embedded XHTML. (Typical RDF documents have about 329 namespaces in them.)

In the past, I'd been of the opinion that text/xml should be the True XML MIME type, so there would just be one MIME type for all five. RFC 3023 points out that some applications might want to process documents based only on their overall type, especially for something like images, so it would label the XML documents as follows:

MIME types of XML documents
Document MIME type
XHTML application/xhtml+xml
XHTML+SVG application/xhtml+xml
SVG+XHTML image/svg+xml
XHTML+MathML application/xhtml+xml
RDF application/rdf+xml

Basically, the most important namespace is what decides the MIME type. This is often, but not always, the namespace of the root element; XSLT compound documents are an example where the most important namespace (XSLT's) is not the same as the root element's (probably nothing or some private namespace which the XSLT transformation sheet can turn into a well known namespace). The important thing to remember, though, is that in this model, the MIME type isn't really that important — the +xml suffix is the key. A UA like Mozilla, which is basically a generic XML+CSS UA with some special support for certain namespaces, would treat all MIME types ending with this suffix in the same way, only using the namespaces to dispatch the data to the right processor.

So you could label an XHTML document as application/rdf+xml and it really wouldn't make any difference to generic XML processors. (Of course, doing so would be incorrect, since XHTML is not RDF.)

The first problem with all this is that it doesn't really help with content negotiation. If you have a UA that supports XHTML and SVG, you could make it say so by claiming:

Accept: text/xml,application/xml,application/xhtml+xml,image/svg+xml

However, this wouldn't help the server know whether to return the XHTML version, the XHTML+SVG version, the SVG+XHTML version, or the XHTML+MathML version, because they are all labelled as recognised MIME types.

This problem could be solved by an approach such as that given in Simon St.Laurent's xmlns Media Feature Tag proposal, except Media Features (see RFC 2295 and RFC 2533) are not well implemented and are massively more complicated than necessary. (These two statements are probably related.)

The second problem with saying that there should be an arbitrary number of MIME types is that it would result in excessively large Accept headers. It also means that each time a new XML type is registered, every generic XML UA has to be updated to know about it.

So what we need is two-fold. First, UAs should be able to state that they support XML, any XML. Something along the lines of the following (but note that this is invalid):

Accept: text/xml,application/xml,*/*+xml

Secondly, we need a simple way for UAs to explicitly state the namespaces they support so that servers that support XML can know which documents to serve when there are multiple alternatives.

Pingbacks: 1

2002-11-06 14:09 UTC Support request 200211061406ish

I was having a problem with my hard disk recently, with disconcerting scraping and clunking sounds, read/write errors, and intermittent errors during boot whereby the disk would not be found. The first two of these problem were resolved by changing the hard disk. Unfortunately, after several hours with the new hard disk the system would no longer boot. That disk was recently replaced by a third disk.

I installed this third disk but did not immediately use it. Instead, I simply left it installed, unformatted, while I continued to use my laptop using the removable hard disk in my media bay. I therefore expected no problems.

However, I have noticed some intermittent symptoms which seem to indicate that not all is well. First, even though this disk is being left untouched, unformatted, usused and unformatted, I occasionally hear it making noise, as if it was undergoing heavy use. I have recorded a sample of this sound.

Secondly, while it is making this sound, the entire machine occasionally locks up for a period of a few seconds, and any CD activity is stopped. I have seen this stop music playing, and it has resulted in one CDR being corrupted (as the internal disk started and then the computer hung while the CD was being burned, causing the CDR process to give errors and abort).

Oh well. Let's see what Dell have to say about this...

2002-11-01 16:16 UTC Doodling with the Gimp

While working on a custom background for yet another a CSS test, I started playing around with the Gimp's filters. Wow! Very quickly I had made myself a groovy subtle green background, and after a few more filters and contrast and colour adjustements, I suddenly stumbled across a landscape of maroon mud flats. While there I ran a couple of filters and found a damaged metal surface as well.

My aimless wondering didn't really find any new pretty patterns for a while after that, so I simply ran filter after filter until I noticed that a hue change would get be these lovely blue crystals. Two clicks later, I had myself a green canvas version of the same picture, an abstract pattern which I called Busy Green.

At this point my journey was nearly over, because after creating some cloth, one of the Gimp filters died quietly and the ensuing corruption of Gimp's internal state caused me to shut it down, at which point I just got on with writing the test which started all this.

The Gimp filters are quite something. I'm definitely a fan of the Colormap Rotation plugin, and the Make Seamless filter is simply amazing. The various "render" plugins and filters are also a great time-saver for those of us with no artistic talent! On the other hand, the thousands-of-windows interface needs some work. Also, having to do everything through context menus (even if you can tear them off) is a little tedious.

Now back to finding bugs in browsers...