- From: Paul Prescod <paul@prescod.net>
- Date: Mon, 12 Apr 1999 16:13:37 -0400 (EDT)
- 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 principles: 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 emphasis. 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 principles. 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 http://itrc.uwaterloo.ca/~papresco 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. http://www.economist.com/editorial/freeforall/19-12-98/index_xm0015.html
Received on Monday, 12 April 1999 16:44:48 UTC