- From: Bert Bos <bert@w3.org>
- Date: Thu, 24 Jul 2003 19:05:48 +0200
- To: "Chavchanidze Giorgi" <chav@ictp.trieste.it>
- Cc: www-style@w3.org
Chavchanidze Giorgi writes: > > > I usually refer to the work on behaviors in CSS as "dormant." There is > > no new draft in sight, but no formal decision to abandon it either. If > > a compelling idea comes up (and somebody to champion it), it may yet > > wake up. > And how about CSS linking extensions implemented in Opera? These extensions > seem to be very useful and provide very flexible linking mechanism for XML > documents. It would be nice if they will be included in CSS3. There will be a module in CSS3 that deals with hyperlinks and another that deals with replaced elements ("transclusions" in Ted Nelson's terminology). It is clear that we need to control what happens on link traversal: replace the current document, expand in place, pop-up a temporary window, open a tab in the background... It is less clear how far CSS has to go in defining which elements are links and what they link to. HTML, e.g., already defines which elements are links and what their targets are. All CSS should do with an HTML document is say whether the target is displayed and if so how. It should not create new links. Many other other document formats also have their own definitions, e.g., SVG borrows the syntax from XLink. In principle, CSS should not be used to change the semantics of a document. However, there is the question of what to do with documents in a format that the browser doesn't know. If it is an XML-based format and it has a style sheet, it makes sense to display it as best you can. The browser may not know what else to do with it, but maybe the human reader can get some sense from it. It would be nice if the document not only displayed reasonably, but also had links that worked, at least as far as images and hyperlinks are concerned. If it has XLink attributes, you could use those. But if it has not, it would be rather convenient if something like Opera's CLinks could simply be added to the style sheet. In terms of separating style and structure, putting such properties in CSS is not ideal. A separate "link sheet" would be cleaner. In terms of convenience on the other hand, not much can beat CLink-like properties. So, the issue is still open. It is not so hard to invent three or four easy properties to add to CSS, that allow a lot of simple links to be expressed. It could be made to work for HTML-like formats (though not for parametrized links, such as the OBJECT element), for RSS, for WML1, etc. On the other hand, the model of CSS has so far been different. CSS has a ':link' pseudo-class, that matches elements that are hyperlinks and thus that info is supposed to come from outside CSS. What if somebody says: '*:link {link: none}'? But assuming that we find no better way to determine what the links are and we have to add a 'link' property to CSS, how do we say that you cannot change the links of a format like HTML, that the UA already has full knowledge of, but you *can* specify the links of 'text/xml' or 'application/xml' documents? Does ':link' do anything in such documents? Note that we in fact have a similar situation with bidirectional text. The recommended way to explicitly specify right-to-left or right-to-left text (if the automatic rules for Unicode text are not enough) is to use mark-up. That's why HTML has a DIR attribute and a BDO element, and that's also why CSS specifies that the corresponding CSS properties should *not* be used for HTML and that browsers may ignore them when rendering HTML. CSS only has them to deal with formats that lack mark-up. For reference: The latest draft of replaced elements[1] describes the 'content' property, which allows, among other things, this syntax: IMG[SRC] { content: attr(SRC, url) } The 'attr()' is currently a placeholder in the "values and units" module[2], but it is likely to become a generalization of the attr() of CSS2. This would be CSS3's way to express that the IMG element is a link that is to be displayed as a replaced element and that the URL to use is the one from the SRC attribute. Opera's CLinks are documented on Opera's site[3]. They allow, e.g. A { -o-link: attr(HREF); /* Which attribute to use */ -o-link-source: current; /* Use own attr, as opposed to other elt's. */ } Opera's '-o-replace' property will most likely not be used, since 'content' is more powerful. HLink[4] is a language propsoed by the HTML WG. It can be used as the "link sheet" language that I mentioned above. It lists all elements that can be links and says what kind of link they are. At the moment it is not clear how to use HLink with other formats than XHTML and extensions of XHTML. Maybe the same style PI and HTTP header could be used for as for style sheets: XML: <?xml-stylesheet href="linksheet.hlink" type="text/hlink+xml"?> HTTP: Link: <http://example.org/linksheet.hlink>; rel="stylesheet" The definition of the A element in HTML could look like this in HLink: <hlink namespace="http://www.w3.org/1999/xhtml" element="a" locator="@href" /> It's not CSS, but it's not too ugly... :-) I guess you can omit the "namespace" attribute if there is only one kind of "a" in your document. It doesn't allow the "element" attribute to be a selector, so there are no context-dependent semantics, but for most documents that should be enough. [1] http://www.w3.org/TR/2003/WD-css3-content-20030514 [2] http://www.w3.org/TR/2001/WD-css3-values-20010713/#attribute [3] http://www.opera.com/docs/specs/#css [4] http://www.w3.org/TR/2002/WD-hlink-20020913 Bert -- Bert Bos ( W 3 C ) http://www.w3.org/ http://www.w3.org/people/bos/ W3C/ERCIM bert@w3.org 2004 Rt des Lucioles / BP 93 +33 (0)4 92 38 76 92 06902 Sophia Antipolis Cedex, France
Received on Thursday, 24 July 2003 13:05:54 UTC