Re: Will behaviors be added to CSS?

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