Re: CSS and XLink

On Tue, 27 Apr 1999, Bert Bos wrote:

>> 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 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-customisable, accessible widely and for many years,
> I'd rather not rely on them.

Hmm. It rather depends on what the script is doing.


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

The action sheets proposal could have several events added to its
repertoire, such as "onexecute", which would be triggered when an
element was selected (eg, clicked, "enter" pressed, right arrow
pressed, all depending on the UA).

This would then allow media-independent scripting.

Also, a new property could be introduced to CSS: tabindex. This would
specify the order for tabbing of controls, much like "tabindex" works
in HTML, now.

The 'tabindex' property would take either 'none', 'auto', or a number
as a value. If 'none', then the element would be a simple dumb, static
element. If 'auto' or a number, then the element would be able to have
focus, eg from the keyboard, or listable on a menu of controls in an
aural context. It would also decide if "onexecute" applied to the
particular element.


> 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.

Ok. These are our requirements. All of them are possible using the CAS
and replaced content proposals that have been proposed for months.


> 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.

Agreed. However, this is depicting _behaviour_, not _state_. Hence, it
is out of scope of CSS.

 
> 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.

For embedded content, the content property _is_ the right place. It is
the only place, in fact. For additional content (links that are not
embedded) the content property is indeed the wrong place, since the
additional content has no relevance to the current document (that
which is described by the stylesheet).


>> 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:
>> 
>>    [xml\:link][show=embed][actuate=auto] { 
>>       content: replaced(attr(href)), auto; 
>>    }
> 
> How about simply:
> 
>    [xml\:link][show=embed][actuate=auto] { behaviour: replaced }
> 
> What it is replaced by is implicit.

Because what is replaced is implicit. The whole _point_ of this
exercise is to tell the UA, in terms of everything _but_ XLink, what
should happen when an XLink is used.

When the replaced content property was initially suggested in
www-style, the troubles with "behaviour: replaced" (or much better,
display:replaced) were shown. They are:

 a. What are you replacing it with?
 b. What if that resource is not available?
 c. What about alternative text if the resource is not supported?


> For IMG it might be possible to name the attribute, but OBJECT is
> far too complex.

The OBJECT element is out of scope in this discussion, don't forget
that we are trying to declare how XLink is to be rendered and how it
is to interact. (In fact, OBJECT would be covered by the HTML section
of the UA, not by the XML code. Just like SVG cannot be described in
CSS, and is out of scope of CSS, so OBJECT's behaviour is the realm of
the HTML spec.)


>> 2. show=embed actuate=user
>> This can be implemented using the Action Sheets proposal:
>> 
>>    [xml\:link][show=embed][actuate=user] { 
>>       onclick: "this.style.content = 'replaced(attr(href)), auto'"; 
>>    }
> 
> or:
> 
>    [xml\:link][show=embed][actuate=user] { behaviour: 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.)

This has all the problems of "behaviour:replaced" with the following
additional problems:

 d. What causes this to expand?
 e. What height/width will it have when expanded?


> Missing is the opposite behaviour:
> 
> 2a. show=<un-embed> actuate=user
> 
>    ... { behaviour: collapse }
> 
> Same as above, but the initial state is with the linked content
> expanded in-place.

I agree that an "unexpand" behaviour would be good. This is already
covered by XLink: The fact that something can be embedded implies that
it can also be in the non-embedded state. Using action sheets, both
expand and collapse can be implemented using a script to toggle
between the two (someone who knows ECMAScript and the DOM would have
to write it, of course, I am not familiar with either).


> For both 2 and 2a, you may want to add rules
> 
>    [xml\:link][show=embed][actuate=user]:active { ... }
> 
> to specify how the element looks when it is expanded, resp.
> collapsed.

That is overloading the :active pseudo-class. If this was to be done
at all, a new pseudo-class would have to be invented.


>> 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:
>> 
>>    [xml\: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."

That is irrelevant (although I agree completely). The issue here is
that this combination of the show and actuate axes is allowed by XLink
and thus is a potential target for the challenge of describing XLink
in terms of CSS and CAS.


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

What does "behaviour:transverse" do? Does it make an element be of the
pseudo-class :link? With the effect that activating it replaces the
current document with some unspecifed uri? 


>> 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:
>> 
>>    [xml\: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.

That is an issue to take up with the XLink group. At the moment, they
allow it.

 
> If it really has to be, then how about this:
> 
>    [xml\:link][show=new][actuate=auto] { display: window }

Now CSS can access parts of the system outside the document???

What if the element in question is a container?

   <DIV xml:link href="..." show=new actuate=auto>
      Hello.
   </DIV>


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

*shudder*

That looks suspiciously like a scripting language to me. I thought
programming was out of scope of CSS?

 
> Still missing is the temporary (modal) window:
> 
> 7. show=<pop-up dialog> actuate=user
> 
>    ... { behaviour: popup }

Well, again, that is an issue to take up with the XLink group.


It seems to me, Bert, that the distinction between "formatting" (CSS's
domain) and "behaviour" (scripting's domain) is fast blurring. This is
very bad, as it would over complicate CSS dramatically.

Note in particular the following:

From CSS2's spec:
#   CSS2 is a style sheet language that allows authors and users to
#   attach style (e.g., fonts, spacing, and aural cues) to structured
#   documents.

From the Action Sheets note:
#   Action sheets provide a mechanism for separation of event-based
#   behaviour from the structure of HTML and XML documents. This is
#   similar to the way in which style sheets provide a separation
#   between visual presentation properties and document structure.


Also, on Tue, 27 Apr 1999, Simon St.Laurent wrote:
> One major issue in the current (ancient) XLink draft is that links
> can have more that a start point and an endpoint. Extended links are
> in fact sets of points, with no description provided for the
> relationships between those points beyond 'role' and 'behaviour',
> which are left conspicuously undefined. The attitude on xlxp-dev
> seems to lean toward letting style sheets figure out traversal paths
> - which points connect to which - and I'm still trying to figure out
> how this could work with CSS. 

It is my (very strongly held) opinion that path _traversal_ should be
firmly in the XLink ball park. If it is not, then what, exactly, *is*?

They don't take responsibility for formatting, behaviour, or
traversal? What else is there? Consistent DTD fragments? If that is
all there is, and its behaviour has to be defined in CSS anyway, then
there is no _need_ for it. After all, there is no spec saying which
element is going to be used to tag paragraphs in every XML language,
so what is special about links?!

Obviously, the one thing that _is_ special is path traversal...

-- 
Ian Hickson 
U+2642 U+2651
U+262E U+2603 U+263A

Received on Thursday, 29 April 1999 21:58:48 UTC