Re: Another approch to style hyperlinks

28.07.01 02:05:48, Ian Hickson <ian@hixie.ch> 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
>what is a link?

XLink itself has a couple definitions that are useful here.

<blockquote cite="http://www.w3.org/TR/xlink/#N789">
   [Definition: An XLink link is an explicit relationship 
    between resources or portions of resources.]
   ...
   [Definition: A hyperlink is a link that is intended primarily
    for presentation to a human user.]
</blockquote>

Hyperlinking is in my view squarely in the domain of CSS. CSS doesn't *add*
links to a document, they are encoded in the XML itself, but it describes
how the UA, user and author want link handling.

An example here is the blockquote cite attribute. It is a link, but by 
default it is not activated. Using CSS you can have one of three cite 
behaviour, none, link (you can replace the current with the cited resource 
by activating the blockquote element) and replace (where you see the cited 
resource instead of the blockquote).

An analogy is CSS typography vs the FONT tag. The FONT tag describes what 
color and font-family the contained text will have, but has several 
limitations. It has bad accessibility, it is hardcoded and can't be 
retrofitted (if you want to change the font-family, you will have to rewrite 
the document). 

Furthermore, with CSS you can express conditionality (via selectors), 
something you can't do with XLink alone. It is for instance possible to 
express an HTML OBJECT this way. (I use the Håkon's Clink CSS syntax using 
"replace" instead of "content" as property name. As far as I can see, the 
@link syntax should work just as well, maybe a little less readable).

With this code fragment,

<!-- JPEG wrapped in PNG -->
<object data="image-1.png" type="image/png"> <!-- object 1 -->
   <object data="image-1.jpeg" type="image/jpeg"> <!-- object 2 -->
      [Image 1]
   </object>
</object>

<!-- PNG wrapped in JPEG -->
<object data="image-2.jpeg" type="image/jpeg"> <!-- object 3 -->
   <object data="image-2.png" type="image/png"> <!-- object 4 -->
      [Image 2]
   </object>
</object>

and one of these style sheets

/* STYLE SHEET 1: Supports PNG, not JPEG */
object[type="image/png"] {replace: attr(data)}

/* STYLE SHEET 2: Supports JPEG, not PNG */
object[type="image/jpeg"] {replace: attr(data)}

/* STYLE SHEET 3: Supports both */
object[type="image/png"], object[type="image/jpeg"] {replace: attr(data)}

/* STYLE SHEET 4: Supports neither */
object {replace: none /* initial value */}


Style sheet 1 matches objects 1 and 4, the content of these two objects will 
be replaced with the corresponding PNGs, i.e.

{image-1.png}
{image-2.png}

Style sheet 2 matches objects 2 and 3, the content of these two objects will 
be replaced with the corresponding JPEGs, i.e.

{image-1.jpeg}
{image-2.jpeg}

Style sheet 3 matches all objects, the content of the outer objects will be 
replaced with the corresponding images, i.e.

{image-1.png}
{image-2.jpeg}

Style sheet 4 also matches all object, but does no replacement and falls 
through to the "alternative" content, i.e.

[Image 1]
[Image 2]



Jonny Axelsson
Documentation,
Opera software

Received on Monday, 30 July 2001 12:46:09 UTC