[This is an historical document which is not currently being updated. The Opera browser supports a set of properties which have different names, but offers similar functionality: -o-link, -o-link-source, and -o-replace]
Clink is a simple language to describe links in existing markup languages. Clink borrows its syntax from CSS (from which it gets the initial "C") but goes beyond style sheets by identifying links, not describing how to present them. The proposal contains four new properties that attach simple linking information to XML elements and Clink is shown to describe links in HTML, WML, RSS and Open eBook.
This document is potentially the starting point for technical work within W3C, but it has no official status at this point. The work is being discussed in the CSS&FP WG.
This note specifies a simple way to describe different types of links in existing markup languages. Four properties borrowing the syntax from CSS are used to attach link information to XML elements. The properties can describe links in HTML [1], WML [2], RSS [3] and Open eBook [4] as well as other XML-based languages that share the same link model.
There are three key differences between Clink and Xlink [5]. First, Clink is a much simpler language not capable of describing the more advanced features of Xlink. Second, Clink does not require markup languages to change their syntax in order to describe their links. Third, Clink describes functionality not found in Xlink, namely HTML's LONGDESC attribute and BASE element.
By describing links, Clink goes beyond style sheets which traditionally describe fonts, colors, speaker volume and other presentational properties. It is arguable whether the Clink properties should be used in style sheets or in separate "link sheets".
This document has three parts: description of links in existing markup languages, formal definition of Clink properties, and implementation experience.
The most common links in HTML are hypertext links (using the A element) and embedded images (using the IMG element). In Clink, these links can be described as:
A { link: attr(HREF) }
IMG { content: attr(SRC) }
The link property on the A element identifies the HREF attribute as the holder of the URI which should be fetched when the A is clicked (or otherwise activated). Similary, the content property idetifies the SRC attribute as the holder of the URI where the image to be embedded is found.
In HTML 4.0, the CITE attribute was added to identify the source of quotations. Using the link property, the elements holding the quotes can easily be turned into links:
BLOCKQUOTE { link: attr(CITE) }
If the BLOCKQUOTE element contains an A element, there content of the A element will have two links attached to it. The conflict is solved by always giving priority to the most recent link, i.e. the one attached to the A element.
Two other Clink properties describe other kinds of links found in HTML:
BASE { link-base: attr(SRC) }
IMG { link-longdesc: attr(LONGDESC) }
Using the link-base property, the BASE element can be described. Its SRC attribute specifies an absolute URI that acts as the base URI for resolving relative URIs.
HTML's IMG element has a LONGDESC attribute to point to longer descriptions of the image. The link-longdesc property identifies the attribute containing the link to the long description.
Note that HTML has other link types that are beyond the scope of Clink. For example, the OBJECT element has five attributes that take URI values.
The Wireless Markup Language (WML) has several elements that contain hyperlinks. The a element is a short form of the anchor element. For example, the following markup:
<anchor>follow me <go href="destination"/> </anchor>
is identical in behavior to:
<a href="destination">follow me</a>
The anchor element poses a challenge since the URI is not found in an attribute of the element itself, but rather in an attribute of a child element (namely go). In Clink, the links can be described as:
a { link: attr(href) }
anchor { link: next-attr(href) }
The next-attr() value identifies an attribute in another element. The element isn't identified explicitly. Rather, the attribute that first matches the specified name is used. The scope of the search is the parent element and all its descendants.
By limiting the scope to child elements, the search becomes easier. However, this makes is impossible to find URIs in parent elements.
Also, WML shares the img element with HTML:
img { content: attr(src) }
The Open eBook package file (OPF) describes an Open eBook publication by identifying all other files in the publication and by providing descriptive and access information about them. Here is an OPF section:
<guide> <reference type="toc" title="Table of Contents" href="oeb1.html#toc" /> <reference type="glossary" title="Definitions" href="oeb1.html#glos" /> </guide>
And here is a style sheet to turn the content of the title attribute into a source anchor:
reference { link: attr(href) }
reference:before { content: attr(title) }
Note that the last rule is written in CSS2 which defines the content property for use with :before and :after pseudo-elements.
RDF Site Summary (RSS) is a metadata format for content syndication purposes. Here is a segment from an RSS document:
<item> <title>Giving the world a pluggable Gnutella</title> <link>http://writetheweb.com/read.php?item=24</link> <description>WorldOS is a framework on which to build programs that work like Freenet or Gnutella -allowing distributed applications using peer-to-peer routing.</description> </item>
RSS documents are not typically displayed in normal browsers. In Clink, however, it is possible to describe a presentation of RSS documents. Say, for example, that you want to make the title element a source anchor. Here is how you would specify this in Clink:
title { link: found-in(link) }
The "found-in()" function uses a selector ("link") to point to another element from where it fetches the URI. In the example above the name of the property happens to be the same as the selector.
Should the selector be in quotes?
If you, on the other hand, want to make description into the source anchor, you specify:
description { link: found-in(link) }
Another powerful possibility is to replace the content of, say, the description element with the destination anchor.
description { content: found-in(link) }
Given the example above, the User Agent would embed several documents into one presentation.
| Values: | none | attr(<attribute-name>) | next-attr(<attribute-name>) | found-in(<selector> [,<attribute-name>] ) |
| Initial: | none |
| Inherited: | no |
A value other than 'none' identifies the element as the source anchor of a hyperlink and declares the corresponding URI. The values are:
Note that this property does not describe the presentation of the hyperlink. CSS1 and CSS2 can describe the presentatinon of hyperlinks through the :link, :visited and :active pseudo-elements.
| Values: | none | attr(<attribute-name>) | next-attr(<attribute-name>) | found-in(<selector> [,<attribute-name>] ) |
| Initial: | none |
| Inherited: | no |
A value other than 'none' declares the element to be replaced and User Agents will typically replace the element with the resource pointed to by the corresponding URI. The attr() function is used to point to the attribute where the URI of the content can be found. The values are otherwise the same as for the link property.
Note that this property is an extension of the content property ( as proposed in the CSS3 UI draft), which in CSS2 only applies to :before and :after pseudo-elements.
| Values: | none | attr(| Initial: | none
| Inherited: | no, but setting applies to the whole document
| |
A value other than 'none' specifies where the base URI can be found. The base URI is combined with other URI fragments to create a full URI.
| Values: | none | attr(| Initial: | none
| Inherited: | no
| |
A value other than 'none' specifies where a URI pointing to a long description can be found.
Currently, this document does not specify how the long descriptions are presented, should we?
The Opera browser has added experimental support for Clink properties. This has allowed Opera 4.0 to support linking in WML with minimal changes to the program itself. For reference purposes, the definition of the supported properties are given below.
The definition of the Clink properties has changed somewhat based on the implementation experience. The most notable change is that the '-link-use' property has been replaced by selectors on the right-hand side of the 'link' property. Also, the '-replace' property has been renamed 'content'.
| Property: | -link-set | ||||||
|---|---|---|---|---|---|---|---|
| Values: | none | attr(| Initial: | none
| Inherited: | no
| Description: | This property sets the value of the 'link' variable which can later be used to generate a link through the '-link-set' property.
| |
| Property: | -link-use |
|---|---|
| Values: | none | current | next |
| Initial: | none |
| Inherited: | no |
| Description: | This property sets the element to be a source anchor and, if so, declares which value of the 'link' variable that should be used: the current or the next. |
| Property: | -replace |
|---|---|
| Values: | none | attr(x) |
| Initial: | none |
| Inherited: | no |
| Description: | This property declares the element to be replaced or not. If replaced, the attr() function is used to point to the attribute where the URI to the content can be found. |
[1] HyperText Markup Language (HTML), World Wide Web Consortium
[2] Wireless Markup Language (WML), WAP Forum
[3] RDF Site Summary, http://www.egroups.com/files/rss-dev/specification.html
[4] Open eBook, Open eBook Forum
[5] XML Linking Language (XLink) Version 1.0, W3C Candidate Recommendation