One day PNG’s
technical and licensing
superiority over GIF will make it ubiquitous.
But not yet.
Update (4 Nov. 2001). I have now
started using
PNGs
on the site—though I have not
yet taken the trouble to convert the existing GIF files yet.
Update (15 March 2002). Today as
I convert my old site at
http://www.alleged.demon.co.uk/ to its new home on
http://www.alleged.org.uk/,
I have been converting most of the remaining GIFs to PNGs. I guess
I now have confidence in the support for this format.
It turns out my front page did not work on
Mozilla—the division containing the main text started at
the top of the screen rather than 76px down from the top (as
I has expected, given that its top margin was 76px).
I changed this, but in order to test on Mozilla (which
takes some minutes to start up on my K6/233) I needed to
persuade thttpd to serve
CSS marked as type
text/css. (This is necessary because the W3C specs
require that web browsers believe what web servers tell them,
and it it says a file is text/plain it is not a
style sheet.)
In theory I did this months ago
(edit mime_types.txt, rebuild, reinstall). Testing
this is a pain as well—Mozilla 0.9.7 does not give any
easy way to find the content-type of auxillary files, so you
have to type HTTP requests in to TELNET by hand... In the end
it ocurred to me to run TELNET in an Emacs buffer so at least
the retyping of HEAD /mumble/foo/bar.css HTTP/1.0
could be done almost-automatically... In the end it turns out
that I needed to do make clean to force a
complete rebuild, otherwise changes to
mime_types.txt made no difference :-(.
The
TAG
rejects HLink, not many dead
scream the headlines. Is this the end for XHTML 2?
What’s XHTML 2? It is the next step in the bridge
from HTML 4.01 to the futuristic world of
‘pure’ XML documents. XLink is a recommendation
from the W3C for how XML documents should express links to other
resources. HLink is a new proposal from the XHTML committee for how
XML documents should express links to other resources. In
effect, they are saying that XLink is inadequate and they need
to replace it. TAG
have
expressed an opinion that XLink should be used instead,
presumably on the grounds that we don’t want to have
two W3C recommendations for one and the same thing.
Can XLink replace the special-purpose linking attributes in
HTML? I suppose we can imagine replacing img
and object
tags with something like
<object
xlink:type="simple"
xlink:show="embed"
xlink:actuate="onLoad"
xlink:href="myLogo.gif"
width="400" height="300">
My Logo
</object>
In principal the first three attributes (which would be the same
for all images) can be given default values in the DTD. This is
the approach used in SVG
and MathML.
The problem is that it
prevents the XML document in question from being stand-alone.
That is, the DTD must be downloaded and parsed before the
document can be rendered. SVG fudges this; SVG documents often do
not have DOCTYPEs, and SVG viewers
in effect use a DTD compiled in to the software. All very messy.
There’s another problem: the HTML tag img
also allows for URIs for the low-res version
(lowsrc attribute), a long description
(longdesc), and an client-side image-map
(usemap). XHTML 2 also wants to add an
href attribute to all elements (so any element in
the document can be a link). I’m not sure that XLink
defines xlink:show values for all of these. Even
if it does, we cannot have more than one simple XLink link per
element (since we can only have one xlink:href
attribute). We could possibly follow the same system as XTM, with one child element per link:
<object style="width:400px; height:300px;">
<source xlink:href="myLogo.gif"/>
<usemap xlink:href="#logoMap"/>
[My Logo]
</object>
(Here we are assuming that the DTD is used to generate default
values for the other Xlink attributes—but do we really
want to rely on all XML browsers being validating
browsers...?)
The question is, will this work? Yes, if we are using a
specialized XHTML-2-savvy browser (one which understands
object and source, and knows how to
interpret them). If the aim is to make XHTML 2
implementable using only XML + CSS 2 + XLink + XBase, without
making XHTML a special case, then the answer is no.
The upshot of this is that, if the
W3C want to make
XHTML 2 just another XML format, displayable in a generic
XML browser, then it looks like XLink is not quite right for the
job. It may well be that I am missing something, and the
above example can be reworked to work with XLink. It might be
that lowsrc and longdesc are dumb
features that no-one wants to carry over in to XHTML 2
anyway. But my naïve understanding of XLink and the nascent
XHTML 2 suggests that the XHTML working group might have a
point.
How is this going to end? Right now it looks to an outsider
like the question is being discussed less in terms of technical
issues like what XHTML’s goals are, and more in terms of
committees and procedure and politics and such-like. We may end
up with an XHTML 2 that requires a specialized XHTML 2
browser (requiring upgrades to existing browsers that recognize
the XML namespaces or the DOCTYPE, or any of the
other stupid heuristics in use today to distinguish different
flavours of HTML). The dawn of XML as a fully-fledged hypertext
mark-up language will delayed by a few more years...
I really should not be writing about this—I have
plenty of other things to work on. I just find it
difficult to tune out all these arguments about XHTML when
that’s what I work with every day...
