CSS and XLink

The XLink work at the W3C (latest draft, which is getting ancient:
http://www.w3.org/TR/WD-xlink) seems to be throwing a lot of work in the
direction of style sheets.

>XLink does not provide mechanisms for controlling link 
>formatting because it is considered to fall into the 
>domain of stylesheets. Link behavior should ideally also 
>be determined by rules based on link types, resource roles, 
>user circumstances, and other factors.

It's not clear what the full scope of the work handed to style sheets will
involve, but it is clear that this work will involve more than describing
formatting for link ends.  The work may involve:

* Formatting link ends (easy)
* Determining the traversal paths between link endpoints (complex, save for
later)
* Handling inclusions, transclusions, and new windows because of the show
and actuate axes of XLink.

To put it simply, XLink provides three options for show: embed, replace,
and new. Embed adds the content of the target resource to the document
(though it remains sort of a visitor), replace replaces the resource
(document) making the link with the target resource, and new displays the
target resource in a new window.  The actuate axis provides auto and user
as options.  Auto means that the embed/replace/new activity should take
place automatically, while user means to wait for 'an explicit external
request for traveral' - like a mouse click.

Using these tools, we can recreate the HTML IMG element as:

<img href="mygraphic.gif" show="embed" actuate="auto" />

(I haven't taken the step to convert href -> src, which complicates things
a bit.)

The question that XLink leaves unanswered, and which CSS doesn't deal with
directly, is the conversion of this element to a graphic on the screen.  In
HTML, this was an explicit property of the IMG element, but in XML, you can
replace IMG with anything:

<myFunkyCoolGraphic href="mygraphic.gif" show="embed" actuate="auto" />

This should still work, just like IMG did.

In my opinion, mechanisms like MIME types should be capable of handling
this.  The application hits the element, sees that it's an XLink, retrieves
the resource, sees text/gif as a MIME type, and displays it as a graphic.
Not that difficult.  Maybe a "display:graphic" option would help it along,
if so desired.

Other people see this as an enormous problem for CSS, more evidence that
CSS isn't a good fit for XML (see
http://lists.w3.org/Archives/Public/www-svg/1999Apr/0011.html for an
example). 

What do people think? There's going to be a lot of work to do in this
field, once the XLink working group gets cranked up again.  XLink has
truckloads of potential, but I'd like to make sure it gets implemented
right and that its implications for other fields (style sheets in
particular) are clear.

Simon St.Laurent
XML: A Primer
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Monday, 12 April 1999 10:10:23 UTC