Re: Another approch to style hyperlinks

* Bert Bos wrote:
>On the other hand, I've heard from several people that they want
>something simpler than XLink for the 80% of cases where links are like
>in HTML: simple links in XLink jargon, whose URLs are already present
>in the document and which have just one target. And since you have to
>write a style sheet to set their look and behavior anyway, why not
>also do link recognition at the same time.

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.

>And then there is the argument that, as powerful as XLink is, it
>cannot be retrofitted to document formats that were designed without
>it, because they have differently named attributes, maybe multiple
>links per element, etc.

HTML has for example the 'a' element, applications know 'a' elements
with a href attribute are links, this is supposed to work for other
document languages aswell. However, such document languages are in
general less accessible, since they violate some guideline in
http://www.w3.org/TR/xmlgl that recommends to reuse existing
vocabularies, CSS should not try to fix broken languages.

>I'd like for ':link' to match elements that are links because some
>external link set in XLink says so. But I'd also like to have a way to
>create (simple) links without relying on XLink, or even in addition to
>the links provided by XLink.

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

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

>'Link1' is the normal kind of hyperlink, the one you activate with the
>left mouse button. 'Link2' gives secondary hyperlinks, the ones for
>which you have to do something special, such as shift-click or right
>click.

This won't work. First, those keyboard/mouse controls are already
associated with some other functionality, second this raises
accessibility issues.

>The values of the attributes should be treated as URI references,
>which means, inter alia, that they are relative to the base URI of the
>document.

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.

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 :-)
-- 
Björn Höhrmann { mailto:bjoern@hoehrmann.de } http://www.bjoernsworld.de
am Badedeich 7 } Telefon: +49(0)4667/981028 { http://bjoern.hoehrmann.de
25899 Dagebüll { PGP Pub. KeyID: 0xA4357E78 } http://www.learn.to/quote/

Received on Friday, 28 September 2001 01:23:57 UTC