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

Another approch to style hyperlinks

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Fri, 27 Jul 2001 22:10:37 +0200
To: www-style@w3.org
Cc: Bert@w3.org
Message-ID: <f4a3mt0evs7ia0tnmv40tde2abivvu5mt9@4ax.com>
Hi,

I came to the conclusion, that I don't like the @link rule syntax. The
current proposal [4] is one of

  @link Selector1                 = this(Attribute);  /* [link1] */
  @link Selector1                 = first(Attribute); /* [link2] */
  @link Selector1                 = content;          /* [link3] */
  @link Selector1 @with Selector2 = this(Attribute);  /* [link4] */
  @link Selector1 @with Selector2 = content;          /* [link5] */

the selector argument is misplaced here. The CSS way is

  Selector1 { @link ... }

i.e. the rule should go into the the ruleset. This is incompatible with
the grammar/syntax definition in CSS Level 2 and looks ugly, so why not
introduce new properties and functions for styling hyperlinks? Using
real selectors and not selector arguments could render this second
selector argument ([1]) superflous. Let's have a look at the definition:

[...]
  A rule of the form "@with Selector2 = this(Attribute)" says that the
  element is a link element if its parent has a descendant that matches
  Selector2 when the parent is considered the root element for the
  purposes of matching the selector, and if that descendant has the
  given attribute. The first such attribute is interpreted as a URI
  reference. 
[...]

All descendants of the parent with the given attribute, this means the
parent is the :subject of the selector. :subject cannot be implemented
[2] so the @link rule cannot be implemented. I however don't agree with
this definition, i don't see how siblings interact with the link
element, nor are there examples in the draft where this makes sense, so
why not take the selector1 as subject? Descendants and self could be
selected like this

  img[longdesc]   { }
  anchor go[href] { }

but wait, we need the subject pseudo-class here, i.e.

  anchor:subject go[href] { }

I strongly recommend to put the :subject pseudo-class back into the
draft. I and other supporters of this pseudo-class will happily provide
use cases to clarify that we really _need_ this feature. This is one of
those cases.

We'd need then a property to replace the @link rule. 'link' is a very
straightforward name. The link property takes either an attr() function,
a string, the content keyword or the keyword none; none is the initial
value, meaning that the element is no link at all. The attr() function
refers always to the first attribute found in the non-subjected selector
part, so we get rid of the this() and first() functions. The attr()
function takes the two parameter form as proposed e.g. in the Color
Module [3]. So we are here:

  Selector1                   { link: attr(Attribute, uri) } /*[link1]*/
  Selector1                   { link: attr(Attribute, uri) } /*[link2]*/
  Selector1                   { link: content }              /*[link3]*/
  Selector1:subject Selector2 { link: attr(Attribute, uri) } /*[link4]*/
  Selector1:subject Selector2 { link: content }              /*[link5]*/

Since we express what elements are links in CSS, the definition of the
:link pseudo-class must be changed to something like "all elements with
a computed value for the link property other than none".

This _greatly_ simplifies this whole link stuff, it's compatible with
the current CSS Level 2 syntax, the link-behaivour goes right were we
define that something is a link, the attr() function is consistently
used in all CSS Level 3 modules they it is supposed to, it's more
CSS-ish, since we use real selectors.

[1] The @with rule "inside" the link at-rule is incompatible with the
    current syntax, at-rules may only take %any or a %block and %any
    doesn't include %at-rule or %ATKEYWORD

[2] Yes, I'm somewhat disappointed that the :subject pseudo-class was
    removed from the W3C selectors draft, especially for the given
    reason...

[3] I don't like that section "13. The 'content' property" of the Box
    module draft uses the one parameter form, this leads to two
    different attr() functions, i.e. it's ambigious. I recommend to
    define the second parameter as beeing optional and the second
    parameter defaults to 'string'. The content property may take an
    optional 'string' parameter.

[4] Found in http://www.w3.org/TR/2001/WD-css3-box-20010726/#styling
-- 
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, 27 July 2001 16:11:32 GMT

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