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.
<script type="text/javascript">// sneak 'target' attributes past the validator.for (vari=0;i!=document.links.length;i++) {
varL=document.links[i];
varc=L.className;
if (c=='local') {L.target='_top';}
elseif (c=='photo') {L.target='z';}
elseif (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!
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.
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:
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.
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...
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.