W3C home > Mailing lists > Public > www-style@w3.org > September 2001

Re: Another approch to style hyperlinks

From: Jonny Axelsson <jonny@opera.no>
Date: Fri, 28 Sep 2001 16:16:15 +0200
Message-Id: <200109281413.f8SEDHb32055@mail.opera.no>
To: Bjoern Hoehrmann <derhoermi@gmx.net>, bert.bos@sophia.inria.fr
CC: www-style@w3.org
28.09.01 07:23:21, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

>Application logic / document language logic is supposed to define what a
>link is and where it points to. Defining this in CSS makes the document
>rely on style sheets, this would be a threat to accessibility and make
>machine processing of some resource impossible, unless the "machine"
>also supports CSS. Think of search engine robots for example. I think
>links are some type of semantic, thus they should not be expressed using
>CSS, CSS is strictly for presentation and defining what a link is is not
>a presentational issue.

On the contrary, the greatest argument *for* CSS hyperlinking is 
accessibility. CSS doesn't add links. All links are a part of the markup and 
can be acted upon as natural for the UA, whether it is a browser or a robot.
Furthermore, since the cascade is built into CSS, hyperlinking can be made 
on the premises of the user as well as the author.

I have some musings and use cases on the subject [1].


>If you want to have links the document language didn't consider,
>you are lost.

In the sense of URIs not being in the markup, yes. In the sense of them 
being in the markup, but not acted upon no. The creators of a document 
language will rarely know all future uses of that language, and giving 
authors and users a mechanism to retrofit hyperlinking will make that 
language more powerful.


>>In fact, I could start right here, and echo something that somebody
>>showed me recently and that looks quite interesting:
>>
>>  Name:       link1
>>  Values:     <selector>? attr(<name>) | none
>>  Initial:    none
>>  Applies to: all elements
>>  Inherited:  no
>>
>>  Name:       link2
>>  Values:     <selector>? attr(<name>) [ , <selector>? attr(<name>) ]* | 
none
>>  Initial:    none
>>  Applies to: all elements
>>  Inherited:  no
>
>This implies that the document language already considered certain
>elements to be some kind of link or that the user agent is supposed to
>provide some mechanism to access that resource. If user agents don't
>implement such mechanisms, too bad for the users, if it is close to
>impossible to provide some working mechanism, the document language has
>to be reconsidered (this is IMO the case for some HTML features).

This is reminiscent of the discussion of a fixed or flexible vocabulary. 
Should you have a fixed markup for giving text a typeface (the FACE 
attribute of the FONT element) or should that be an attachable property of 
any element (CSS font-family). The UA at the time of writing may have 
implemented a certain number of vocabularies, but will have no way of adding 
new ones.

This is how and why Opera came to implement CSS type linking. We had of 
course HTML linking, but we needed to implement linking in WML, an XML 
vocabulary that used a different syntax. Instead of implementing a second, 
and certainly third and fourth and so on at a later stage, we used the Opera 
proprietary CSS properties -set-link-source, -use-link-source and -replace 
[2].

That not only shows that CSS hyperlinking is feasible, it also shows that it 
was needed. The syntax was a bit of ad hoc-ery and should be cleaned up and 
generalized, and unresolved issues should be resolved, but if this is done, 
this will add great value to hyperlinking in general.



>They would be relative to the element they belong to, consider xml:base.
>
>>Similarly, it may be necessary to allow the URL to be in the content
>>of an element, rather than an attribute:
>>
>>  <LINK STYLE="link1: REF content">
>>    <REF>http://www.example.com/here</REF>
>>  </LINK>
>
>Element content is to be rendered by applications and since one should
>not mention mechanics like URIs, this document language is just broken.

While URIs in attributes are a natural, and I rarely see any good reason for 
them being element content, it does happen. Two specs I can think of 
immediately is WML 1.2 and RDF syntax.


>PS: I'm playing a bit devil's advocate here, since I don't have proper
>counter arguments for someone else, who may argue that way :-)


On behalf of The Good Side,

Jonny Axelsson, 
Documentation,
Opera Software


[1] <http://web.opera.com/~jonny/w3c/css/linking/>
[2] "CSS extensions for XML", <http://www.opera.com/docs/specs/#css>
Received on Friday, 28 September 2001 10:13:31 GMT

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