W3C home > Mailing lists > Public > www-style@w3.org > April 1999

XLink and Style

From: Paul Prescod <paul@prescod.net>
Date: Mon, 12 Apr 1999 16:13:37 -0400 (EDT)
Message-ID: <37116C99.21A70E3F@prescod.net>
To: www-style@w3.org
> 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.

Actually, I don't think we need to look at or care about XLink in
particular at all. Not all standards can be orthogonal but when they can
be that is best. Instead of looking at XLink, we can proceed from first

XML is designed to allow the separation of semantic content from
presentation. This allows the two to be separately persistent or
ephemeral. This separation applies as much to links as to paragraphs and

Therefore a stylesheet language should be able to express a wide range of
presentations for the link ends of links. Ideally, we would use the HTML
presentational features as a starting point (as we do for presentation)
and add more sophisticated stuff over time.

This implies that a stylesheet language should be able to express the
presentation and behaviour of the HTML A element type and the HTML IMG
element type. The LINK element type has never achieved popualarity in user
interfaces so it is arguably out of scope.

> * Handling inclusions, transclusions, and new windows because of the show
> and actuate axes of XLink.

The stylesheet language should handle inclusions, transclusions and new
windows *in spite of* the show and actuate axes of XLink. Those are only
presentational hints, not instructions.

As the XLink specification says, "ideally behavior is handled in a
stylesheet" (paraphrased).

"However, XLink does provide a few very general behavior mechanisms
because they are commonly considered to reflect major or invariant
semantics of link types."

If the XLink spec did not exist then there would be no question that
linking behaviors belong in the stylesheet language (as they do in the
dozens of existing SGML and XML stylesheet languages). If the spec. did
not mention behavior at all then it would be similarly easy to see that
behavior is a stylesheet's responsibility. That follows from the first

But the spec does mention behavior. Nevertheless, it is pretty clear that
the intention is not to let stylesheet languages abdicate their roles as
style determiners. I would say that the behavior attributes should be
observed only when there is no stylesheet or the stylesheet has nothing to
say about link presentation.

Even given the behavior attributes in the spec, there are many different
possible implementations for each. As the XLink spec says: "These are used
to express policies rather than mechanisms."

> 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 main problem is that you are not supposed to be forced to embed the
processing information in either your document or your document type. You
may want to embed definitions in one view of the document and make
hyperlinks to them in another view. Different stylesheets should be able
to express the different views.

Consider also the problem of print. If you use any combination of XLink
attributes *other than* show="embed" and acutate="auto" what does that
mean to a print rendition of the data? I hadn't thought of this much
before but I find it fairly disturbing. A more media-agnostic view would
be a single attribute: xml:link-type="embed|reference". Then the
stylesheet could handle replace versus new and auto versus user.
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

By lumping computers and televisions together, as if they exerted a 
single malign influence, pessimists have tried to argue that the 
electronic revolution spells the end of the sort of literate culture 
that began with Gutenberg’s press. On several counts, that now seems 
the reverse of the truth.

Received on Monday, 12 April 1999 16:44:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:26:50 UTC