Re: Another approch to style hyperlinks

Ian Hickson writes:
> On Fri, 3 Aug 2001, Bjoern Hoehrmann wrote:
> >
> > * Ian Hickson wrote:
> >> On Fri, 27 Jul 2001, Bjoern Hoehrmann wrote:
> >>>
> >>> I came to the conclusion, that I don't like the @link rule syntax.
> >>> [...]
> >>
> >> Personally, I do not really understand why we need this to be in CSS at
> >> all. Stylesheets are supposed to be optional, but links are an inherent
> >> part of the data. What's wrong with simply relying on XLink to tell us
> >
> > ...or semantics of the used document language...
> 
> agreed
> 
> >> what is a link?
> >
> > Well, authors would be able to add extended hyperlinking capabilities to
> > documents the document language didn't consider.
> 
> Thus XLink link bases.
> 
> > Take the longdesc attribute as example, HTML 4 defines it to carry an
> > URI but not if and how users may access the resource behind it, nor
> > how it should be presented to the user. I think another design goal is
> > to allow user agents, that don't know the used document language
> > and/or don't know XLink are able to present the document anyway in a
> > appropriate manner.
> 
> There are two issues here. Link identification, and link style and
> behaviour. I believe the first is out of the scope of CSS, and the second
> is very much _in_ the scope of CSS.

There is a lot of interesting stuff that XLink can do (complex links,
external link sets) for which inventing another solution would be a
waste of time, with doubtful benefit.

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. It doesn't have to be more
complex than 1, maybe 2 properties.

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.

So I'm in two minds about it. On the one hand there is the very
appealing example of Opera, which has experimental CSS properties[1]
for exactly this, and which seems to work well. (Although those
particular properties have some limitations, and some difficult edge
cases, but I believe something very similar can be defined that solves
that.)

On the other hand, how much overlap between specifications (in this
case CSS and XLink) is still healthy? At what point the duplication of
effort outweighs the argument of ease of use?

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.

The @link proposal in the current Box model was an attempt to solve
some of the problems of Opera's proposal, but I think it doesn't solve
them all, and it isn't as user-friendly. So I plan to work on a new
proposal that is based on properties again and not on @-rules.


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

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

Example:

    a { link1: attr(href) }
    img { link2: attr(longdesc) }
    blockquote { link2: attr(cite) }

For secondary links there is typically a pop-up menu, and thus it is
possible to have multiple secondary links.

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.

It may be necessary to change the syntax of <selector> a bit, to allow
attributes to be retrieved from a parent element as well, although
there may be so few document formats designed that way that we can
safely leave that feature out.

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>




Styling primary links can still be done with the ':link' and
':visited' pseudo-classes, but with the extra restriction that the
'link1' property may not occur in a rule with such a pseudo-class.
This avoids:

    xyz:link { link1: none }  /* !? */

(But that doesn't restrict the functionality in any way; you can
always use a different selector.)


[1] http://www.opera.com/docs/specs/#css



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 Thursday, 27 September 2001 16:35:13 UTC