XHTML & hyperlinking opinions (long, sorry)

During this discussion on the XLink/HLink controversy, I've been 
(mostly) just listening.  Major thanks to the people who've taken the 
trouble to listen to each other and to offer their opinions and analyses.

I guess I should outline my opinions.  As Roy Fielding points out, the 
TAG is not a hive-mind, and while on Nov. 23rd we unanimously felt that 
XHTML should use XLink for user-interface-oriented hyperlinks, it's 
quite likely that different people thought this for different reasons.

So the following is my *personal* take on the technical issues, and 
there's no guarantee how much of it is shared with other TAG members. In 
preparation, I went back and re-read all of the XLink recommendation and 
the HLink Working Draft. For those who haven't done this recently, I 
recommend the exercise.

I'm going to start with by reproducing the a bit of the XLink spec, 
starting with the second sentence:

"XLink provides a framework for creating both basic unidirectional links 
and more complex linking structures. It allows XML documents to:

     * Assert linking relationships among more than two resources
     * Associate metadata with a link
     * Express links that reside in a location separate from the linked
       resources"

These are all things that HTML, up through XHTML 1.1, doesn't really try 
to do.  We all know about <img src="this" longdesc="that"> but that's a 
very hard-wired kind of multi-ended link.  XLink explicitly envisions 
people making up links that point at a bunch of different arbitrary 
things, with titles and preferred traversal routes between them.  It 
envisions links that are bundled up out-of-line and don't have any of 
their ends where the elements are.  This is fairly new stuff.

So it's time to start driving some stakes into the ground.  I believe 
the following quite strongly:

<main-theses>
1. If you want to extend XHTML to do any of the three things that XLink 
claims to be designed to do, then XLink is a good way to do it.

2. This would be a good direction to extend XHTML in.

3. If you want to extend HTML in other directions, not contemplated by 
XLink, it would be surprising if XLink were much help.

4. If you want to devise a formalism for describing the syntax and 
semantics of the existing hyperlink idioms in HTML, then XLink isn't 
going to help.  Everyone agrees that this was one of the original design 
goals of XLink, and that XLink failed to meet it.

5. "View Source" is terribly important.  I know a huge number of people 
who know HTML at varying degrees of expertise and for every one *without 
exception*, "view source" provided a large part of their education.  So 
I think that when arguing about XHTML, we should do a lot of imaginary 
"view source" operations.
</main-theses>

Now a bunch of theses, loosely in support of the above. Not in any 
particular order.

- If the XHTML WG wants to write down a formalism for capturing the 
syntax and semantics of their existing markup, I don't see why anyone 
should try to stop them.  I suggest they should investigate existing 
mechanisms like RDF, ISO Architectural Forms, and various existing 
schema languages, but nobody can possibly be against more precision and 
formalism in specifications.

- HLink is trying to do something really, really hard: to provide a 
formalism which encompasses the existing ad-hoc incremental 
never-planned-by-anyone markup used in the HTML of today, and 
simultaneously serve as a nice clean basis for designing new kinds of 
markup syntax.  This has produced things like "onRequestSecondary" and 
"target", which seem a bit ad-hoc; and if you try to support image maps 
you're going to have real work to avoid further ad-hockery. I'm not 100% 
sure it can be done, and I'm really unconvinced that it's a good idea to 
try to do both these things in one place.

- There has been quite a bit of rhetoric, and strong assertions that 
users will never accept this or positively require that.  How can we 
know?  I also have some strong opinions about what users might and might 
not go for, but two decades of shipping software have taught me a lot of 
humility, and I expect to be wrong a lot in such predictions.  The 
solution is to measure.  Take your analyses and insights and intuitions 
out there and try them on the real world.  You will probably be 
disappointed by how rarely you're right.  I know I have been.  The 
bottom line: I frankly have little time for what seem to be 
arguments-by-assertion from anyone about what people will and will not 
put up with, until someone shows me some usability studies and 
measurements.  Argument by historical parallel is not as good but is 
probably better than asserted intuition.

- Having said that, it is *my* intuition that if a major browser vendor 
had implemented multi-ended extended XLinks with slick slide-sideways 
menus, about 5 million HTML hackers would have done one "view source", 
squinted their eyes for about 45 seconds, said "oh that's how they do 
it", and started writing their own.

- Generalizing, it is my suspicion that for the view-source-dependent 
HTML practitioner, XLink is at least as easy to figure out by looking at 
it as HLink.  Looking at <foo bar="x.html"> might lead to imagine that I 
can do <baz bar="x.html"> and it will just work, which it probably 
won't.  Looking at <foo xlink:href="x.html"> will lead me to suspect 
that <baz xlink:href="x.html"> will just work, and it will.

- Further on this line, it needs to be borne in mind that HLink is 
really a radical departure; a new kind of element that says "this 
element is now a hyperlink and this attribute is now a URI holder". 
Nothing like this has been done in HTML before.  I wonder how people can 
be confident that users would run screaming from namespace prefixes but 
be comfortable with dynamic syntax remapping?

- I like a lot of stuff in XHTML2, but I'm troubled at losing <img>.  I 
am as big a fan of flexibility, generality, and so on as the next geek, 
but I always that that Marca was right, <img> hit an important 80/20 
point and provided a concise and friendly idiom for an incredibly common 
operation: "put a bitmapped picture here."  It's about as broadly 
recognizable and as thoroughly implemented as a markup idiom can 
possibly be.

- On a similar track, I hope there's no risk of losing <a href="">. Once 
again, it's a nice idiom for an incredibly common case and is widely 
recognized and miplemented. Yes, it's logically equivalent to <span 
href="">, but still.

- The preceding two points run me smack into one of the issues I've 
never, never, understood, so forgive me for raising it again.  Given 
that <img> and <a> are two of the most successful 
markup/publishing/rendering constructs in the history of the universe, 
why do we need to fool with them or pretend they're XLinks or write a 
new syntax like HLink for defining them?  Why not just leave them the 
way they are?  I find the descriptions in the last 2 or 3 generations of 
*HTML recommendations entirely satisfactory and the implementation by 
popular software to be extremely interoperable and good.

- In case it's not obvious, I'm pretty convinced that extended links 
should be used in XHTML for the kinds of things extended links are 
designed to do.  I'm much less convinced that there's any value-add in 
trying to replace <a> and <img> with simple XLinks.

- Having said that, if you want to support turning every element into a 
potential hyperlink, why not do it by enabling "xlink:href=" rather than 
just "href="?

- And if you believe that, why not specify that you can write either <a 
href="foo"> or <a xlink:href="foo"> and they both work?  It would take 
the browser vendors about 15 seconds to support this, and hey-presto, 
you've bought yourself some consistency, and now <a> has special status 
as the element that has its *own* URI holder.

- And for extra credit, why not specify that you can write either <img 
src="foo" or <img xlink:href="foo"> and they both work!

- If we're going to argue about this, can I issue a plea that the 
arguments include lots of examples?  We've seen some of that on www-tag 
and it's really helpful.  If we can lay out a bunch of problems that we 
think we want HTML to solve, and then look at a bunch of different 
markup design alternatives, we probably end up way ahead.  Once again, 
pretend you're doing a "view source".

- I'm pretty sure that I disagree with some of the HTML WG folks about 
the interpretation of XLink.  I'm perfectly comfortable, in a 
well-defined vocabulary like XHTML, with defaulting away as much 
syntactic apparatus as you can, and leaving out all the xlink:type= and 
arc elements and so on unless you need them - a lot of examples of 
what's wrong with XLink seem to me almost like deliberate attempts to 
make things look ugly.  Has anyone who actually likes HTML and likes 
XLink made a good-faith effort to try to put it to use in a friendly 
kind of way?  I haven't seen the evidence, but then I haven't been 
watching the HTML process that closely, so I may have missed it.

- We've heard lots of assertions that it's terribly important to be able 
to have multiple links on one tag, i.e. they have to be attributes not 
subelements.  To date I haven't heard any justification aside from "we 
know that's what users want".  Um, how?  Let me make my own assertion: 
if you have variable numbers of things that you want to pack up into an 
element, and you want to have extensibility, and you want to have good 
apparatus for dealing with i18n issues, then decomposition into 
subelements is the conventional wisdom, and I think the conventional 
wisdom is right.

Once again, pardon the extreme length of this.  -Tim

Received on Friday, 4 October 2002 12:21:31 UTC