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

Re: CSS and XLink

From: Bert Bos <Bert.Bos@sophia.inria.fr>
Date: Tue, 27 Apr 1999 14:47:48 +0200 (MET DST)
To: www-style <www-style@w3.org>
Message-ID: <14117.40244.540866.414502@www43.inria.fr>
Ian Hickson writes:

 > After studying the situation, it appears to me that all the required
 > ideas for doing this have already been put forward, and it is actually
 > only a matter of stitching them together.
 > 
 > I have included below a suggestion which allows the current XLink [1] spec
 > to have its formatting and behaviour specified by stylesheets and action
 > sheets. In addition to the DOM [2], ECMAScript [3] and CSS2 [4], this
 > proposal assumes the adoption of NOTE-AS [5] (with one minor change
 > mentioned below) and one CSS3 suggestion [6].
 > 
 > [1] http://www.w3.org/TR/WD-xlink 
 > [2] http://www.w3.org/TR/REC-DOM-Level-1/
 >     and http://www.w3.org/TR/WD-DOM-Level-2/
 > [3] http://www.ecma.ch/stand/ECMA-262.htm
 > [4] http://www.w3.org/TR/REC-CSS2/
 > [5] http://www.w3.org/TR/NOTE-AS
 > [6] http://www.bath.ac.uk/%7Epy8ieh/internet/wwwstyle.html#replaced
 > 
 > Small disclaimer: I don't know ECMAScript or the DOM, so the script
 > one-liners may contain errors.

Thanks, Ian. I was just about to suggest that somebody present a
proposal. The time seems ripe for attacking the behaviour of
hyperlinks with a style sheet.

But I wonder if this can't be done without resorting to ECMAscript?
Scripts are nice for experimenting with things that cannot be done
with style sheets, but for important pages, those that should be
virus-free, user-customizable, accessible widely and for many years,
I'd rather not rely on them.

Besides (as you mention yourself), relying on 'onclick' means that the
target is unreachable without a mouse.

Some of the things you should be able to do with a hyperlink (and for
the sake of the argument, I consider IMG to be a hyperlink as well,
since it is not always shown automatically):

  - traverse to it: replace current view with a new one
  - expand it in-place: like in the old Guide system, and like is done 
    currently with delayed image loading
  - collapse in-place: the opposite
  - pop-up in temporary window
  - open in new top-level window

... and of course the reverse of all of the above: traverse back,
collapse, expand, pop-down, close; in short: the Back command.

It is much harder to specify *how* the user can activate the link.
'Onclick' is too specific. I think we need to think in terms of
higher-level events: activate, select, focus, cancel (cf. Motif). That
doesn't mean these have to appear as keywords in the CSS language,
though.

Also, CSS describes states, rather than events. Hence :hover rather
than onmouseenter/onmouseleave.

The 'content' property may not be the right place to put the
behaviours. We are not specifying the content of an element, but only
when/how the existing content appears/disappears from view.

 > 
 > 
 > Formatting Links
 > ----------------
 > 
 > CSS2 already features the ":link" and ":visited" pseudo-classes, which
 > differentiate between links pointing to visited and as yet unvisited
 > documents.
 > 
 > To make all links underlined, for example, one can use:
 > 
 >    :link, :visited { text-decoration: underline; }
 > 
 > CSS2 also has three pseudo-classes for addressing the interactivity
 > issues. For example:
 > 
 >    :hover { color: navy; }
 >    :active { color: red; }
 >    :focus { outline: dotted; }
 > 
 > 
 > This addresses the formatting and UI issues. 
 > 
 > 
 > Implementing X-Link Policies
 > ----------------------------
 > 
 > There are six possible combinations of the show and actuate axes.
 > 
 > 1. show=embed actuate=auto
 > This can be implemented using the replaced content suggestion:
 > 
 >    [xsl\:link][show=embed][actuate=auto] { 
 >       content: replaced(attr(href)), auto; 
 >    }

How about simply:

   [xsl\:link][show=embed][actuate=auto] { behavior: replaced }

What it is replaced by is implicit. For IMG it might be possible to
name the attribute, but OBJECT is far too complex.

 > 
 > 
 > 2. show=embed actuate=user
 > This can be implemented using the Action Sheets proposal:
 > 
 >    [xsl\:link][show=embed][actuate=user] { 
 >       onclick: "this.style.content = 'replaced(attr(href)), auto'"; 
 >    }

or:

   [xsl\:link][show=embed][actuate=user] { behavior: expand }

This says the element has two states. Initially it's content is shown
according to its other properties, in particular 'display', but the
user may toggle it back and forth between this and something very
similar to 'replaced'. (Again, what it is replaced by is implicit.)

Missing is the opposite behavior:

2a. show=<un-embed> actuate=user

   ... { behavior: collapse }

Same as above, but the initial state is with the linked content
expanded in-place.

For both 2 and 2a, you may want to add rules

   [xsl\:link][show=embed][actuate=user]:active { ... }

to specify how the element looks when it is expanded, resp. collapsed.

 > 
 > 
 > 3. show=replace actuate=auto
 > This can be implemented using the Action Sheets proposal, if the
 > proposal is changed to allow the 'onload' event to apply to all
 > elements:
 > 
 >    [xsl\:link][show=replace][actuate=auto] { 
 >       onload: "window.location = this.href"; 
 >    } 

This probably doesn't belong in a style sheet. Too much semantics for
my taste. I'd suggest a "301 redirect."

 > 
 > 
 > 4. show=replace actuate=user
 > This can be implemented using the Action Sheets proposal:
 > 
 >    [xsl\:link][show=replace][actuate=user] { 
 >       onclick: "window.location = this.href"; 
 >    }

or:

   [xsl\:link][show=replace][actuate=user] { behavior: traverse }

(Some people might object to using the general term 'traverse' in such
a specific sense. I'm open for other names. 'Behavior: normal'?)

 > 
 > 
 > 5. show=new actuate=auto
 > This can be implemented using the Action Sheets proposal, if the
 > proposal is changed to allow the 'onload' event to apply to all
 > elements:
 > 
 >    [xsl\:link][show=new][actuate=auto] { 
 >       onload: "window.open(this.href,'','')"; 
 >    } 

Hmm, a document that automatically pops up new windows, without any
user action? Not sure that should be possible at all.

If it really has to be, then how about this:

   [xsl\:link][show=new][actuate=auto] { display: window }

(Of course, in that case my user style sheet wil contain:

   [xsl\:link][show=new][actuate=auto] {
      display: inline !important; behavior: traverse !important }
   [xsl\:link][show=new][actuate=auto]:before {
      content: "Warning: automatic window!"; color: white; background: red }

that way I can still decide whether I want to middle-click or
left-click :-) )

 > 
 > 
 > 6. show=new actuate=user
 > This can be implemented using the Action Sheets proposal:
 > 
 >    [xsl\:link][show=new][actuate=user] { 
 >       onclick: "window.open(this.href,'','')"; 
 >    }

or:

   [xsl\:link][show=new][actuate=user] { behavior: create-window }

Still missing is the temporary (modal) window:

7. show=<pop-up dialog> actuate=user

   ... { behavior: popup }




Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Tuesday, 27 April 1999 08:47:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:53:59 GMT