NOTE-style-link-970128
NOTE-style-link-970128
Currently for information to the HTML-ERB only. This may become a NOTE...
Relationships between documents are most commonly expressed with the LINK element (at least when one of the documents is in HTML). One type of relation is between an HTML document and a style sheet. This article explores the various interpretations of that relationship, in particular: what are the sub-types of this relation? what does it mean to have 0, 1 or more linked style sheets? what actions can be associated with this relation (automatic actions, hyperlinks, interactive vs non-interactive applications, etc.)?
The role and interpretation of links (expressed through URI's) has been a constant subject of investigation since the inception of the Web. In the early years, however, most actual browser implementations limited themselves to just two link roles: hyperlinks (presented to the user for clicking on) and embeddings (in particular of images). Other relations that have been implemented in some browsers include: authorship (the Lynx browser), previous/next (CSO's on-line help browser), style sheets (Arena, NaviPress/GNNPress). The action associated with an authorship link was to offer the user the option of sending mail to the author. The action for previous and next was to offer the user a button to jump to the linked document. The action for style sheets was non-interactive: the style sheet was automatically applied to the document. [add lots of refs]
More recently, in the discussions to define "Cougar" (or HTML version 4), the precise meaning of the style sheet relation has come under scrutiny again. It is expected that typed links will play a much larger role in the net generation of browsers (and other Web applications) than they have done thusfar. Style sheets especially are expected to become widespread. The precise meaning of, and the typical actions a Web application may associate with a style sheet link have to be defined rigourously now.
Experimental implementations, in NaviPress/GNNPress (now renamed AOLPress), Arena, Amaya, Microsoft Internet Explorer, SoftQuad's HiP and Emacs-W3, have given a number of different ways of using style sheet links and in reaction a number of new ideas have been proposed to reconcile the various interpretations and also allow new ones. [add refs]
Eventually, a single but flexible model should come out of the discussions and either become an integral part of HTML 4 or become a specification in its own right. The present article, however, is not meant to be that specification. It only presents and comment on the various ideas.
Some style sheets may be applicable only when the output is on a certain medium, say a printer or a speech synthesizer. There are various ways of indicating this constraint:
Each of these has its pros and cons. The most important question is how the media attribute fits in the general model for relationships on the Web, but we keep that question for the the end of the article. Other question relate to efficiency (in particular network efficiency), ease of maintenance, independence of style sheet format and the possibile role in HTTP "content negotiation."
Some style sheet languages may have a way of indicating the output medium for which they are designed. CSS1 doesn't have this capability, but it is likely that some future version of CSS will have it. A rule starting with a keyword "@media" has been proposed for this. [ref CSS]
Advantages of this method are that a single style sheet can contain styles for multiple media (not certain, but very likely); that information about the style sheet is inside the style sheet itself and not in (possibly many) other documents, where it is hard to find and hard to keep up to date; and that it is only applications that process style sheets anyway that have to read this information.
Disadvantage is that a browser might download a style sheet only to discover that it was written for the wrong medium. Another disadvantage is that it only works with style sheet formats that do indeed have their own syntax for declaring a medium.
It also doesn't allow "content negotiation," the process whereby a single URI points to a set of documents (style sheets in this case) and the server returns the one from the set that best matches the client's profile. HTTP currently allows a client to express preferences for (natural) language, content-type and character set. Style sheets with media declarations inside them cannot be distinguised along these dimensions. [ref content-negot]
Every resource on the Web has a certain format, usually referred to by the MIME header used to describe the format inside e-mail and HTTP: Content-type. For example, CSS style sheets have a Content-type of "text/css." [ref MIME]
The content-type is usually the first information a browser looks at to determine what to do with a certain document. An HTML document is typically formatted and displayed, a sound file is played, a "tar" file is saved to disk, etc. Content-types can be parametrized, with parameters that depend on the particular type. For example, HTML files can have a "charset" parameter that tell the application roughly what characters are used in the document and how they are encoded. Typical values are ASCII and ISO-8859-1.
One could imagine a scheme where CSS files get a parameter "medium," that tell the application what medium the style sheet is designed for:
Content-type: text/css; medium=speech
Advantages are that this is a very general solution that depend neither on HTML nor on the style sheet language. It could be used equally well in other contexts, such as e-mail.
Disadvantage is that an application has to download at least the information about a style sheet (the MIME or HTTP "header") to find the content-type. Content negotiation also doesn't work at the level of parameters, at least not in current HTTP. That may change, if HTTP develops a way to pass client profiles between client and server.
To make current content negotiation work, the parameter has to be promoted to a content-type in its own right. If the content-type were:
Content-type: text/css-speech
a client could request from an HTTP server only those style sheets that are meant for speech.
One could put the information about the intended medium in an attribute in the LINK element:
<LINK REL="stylesheet" MEDIA="speech,print" HREF="url">
This would give the application early access to the information, without the need to download the document first.
Disadvantage is that this adds something to HTML that seems to have no application to other types of links, so the attribute appears somewhat wasteful.
If the number of different media isn't very large, one could consider giving every medium its own type of relation:
<LINK REL="print-stylesheet" HREF="url">
<LINK REL="speech-stylesheet" HREF="url">
The relation "stylesheet" would then mean a generic style sheet, without a-priori restrictions to a certain medium.
Like the MEDIA attribute, this avoids unnecessary downloads. Question is if this scheme is flexible enough. There is work going on to define much finer grained medium descriptions, so that a client can give a server a very detailed profile of its capabilities. It is not clear if that work, if is continues, can co-exist with the rough categories introduced by a handful of predefined relations.
It has been suggested (by Tod Fahrner), that the medium may not be so important in itself, but that selection should be based on the medium's capabilities along a number of different dimensions, such as resolution, physical size, number of colors, interactivity, etc. When considered along these lines, the various media may have overlaps. [ref msg by Tod]
If there was at most one style sheet associated with a document, the interpretation wouldn't be that difficult. But there are reasons to put in multiple links to different style sheets. Unfortunately, the reasons are incompatible with each other, necessitating something new to distinguish the usages.
Style sheets (or at least style) can be associated with a document in three ways, which can be combined. A fourth way has been proposed:
The proposal involves the addition of a SRC attribute to the STYLE element (and possibly a TITLE as well).
The first interpretation is to view a style sheet link as something that is automatically applied (an automatic action, no user-interaction required). If there is a single link, that is not problematic, but if there are two or more there are problems:
The interaction between the linked style sheets and the STYLE element also needs to be defined: is the STYLE element combined (cascaded) with the linked styles and if so, in what order (see below)?
Another interpretation is that all style links are independent. There is also no automatic action associated with them. In an interactive application, the user may be given a choice of applying one or more of them. This is an easy interpretation, that avoids having to define relationships between style sheets whose only known relation is that they are related to the same document.
As a variant of this interpretation, a browser may randomly pick a link and apply it, while still offering the alternatives to the user. This has the benefit that the "right thing" happens automatically when there is only one style link (which is probably going to happen often.)
The disadvantage is that somebody who does want style sheets to cascade will have to use the means provided by the style language and cannot express his wish in HTML. But since cascading is a property of CSS only, and not necessarily available in all style sheet formats, this might be just as well.
A proposal for combining the previous two interpretation relies on grouping style sheet links together. One way to do that is to use the TITLE attribute of the LINK element: if two links have the same TITLE, they are in the same group and are to be cascaded. Other (new) attributes could also be used, but TITLE seems the easiest. This example gives two alternatives, using three LINK's:
<LINK REL="stylesheet" TITLE="Azur blue" HREF="azur1">
<LINK REL="stylesheet" TITLE="Azur blue" HREF="azur2">
<LINK REL="stylesheet" TITLE="Forest dreams" HREF="greenish">
Disadvantage is still that the order of the links is not guaranteed to stay the same in the transfer from server to client. Plus the problem that cascading is a CSS-specific operation.
The STYLE element allows an author to put a style directly into an HTML document. There can be only one STYLE element. The expected action of the application (in the absence of any other style information) is to automatically apply the style.
The interpretation of STYLE in the presence of one or more linked style sheets is not clear. The possibilities are:
A desire has been expressed by some people to use both LINK and STYLE and have the STYLE cascade with the LINK. If it is decided that LINK's do not automatically cascade, then there are three possible answers:
Independent links ("ilinks") are relations between documents that are expressed by a third document. An ilink allows document A to state that document B is a style sheet for document C. Neither document B nor C have to be edited to insert a URI.
There is work going on to define an HTML-like document format for "Web collections," which are sets of documents with explicit links between them. Essentially, a Web collection contains a list of URI's pointing to documents and for each URI it has something very much like an HTML <HEAD> element that contains links (<LINK>) and meta information (<META>) for the referenced document. In this way, a Web collection is able to state relations among document in the set and also between documents in the set and documents elsewhere, such as style sheets.
The currently proposed name for this HEAD-like structure is "ABOUT." The exact syntax is not decided yet, but proposals include the following:
Option 3 is the least flexible: the info is associated with a URI, not with a particular usage of that URI, as in 1, 2 and 4. Both 2 and 3 can be ambiguous, in case there is more then one <ABOUT> for the same link. 1 is easy to use, but 4 allows the <ABOUT> to be put in the HEAD or even in a separate document. 4 is also the only one allowing daisy-chaining of <ABOUT> elements and "client-side redirection," i.e., redirection without the need to configure an HTTP server. The best solution may be to use both 1 and 4: 1 for easy cases, 4 for the more demanding ones.
An <ABOUT> element in a Web collection can thus serve as an ilink, associating a style sheet with a document, without the document's "knowing." The question then is the same as in the case of multiple style links in a document: what if the document already has one or more style links of its own?
For the interpretation of multiple links to style sheets, there is a clear solution: view all links as independent and don't assume any relation between them. This avoids a number of hard problems and doesn't appear to make anything impossible that the other interpretations offer. It also makes the task of the HTML parser easier.
The interpretation of the STYLE element as an "unrolled" LINK is appealing. It then fits in the same simple model for style links. On the other hand, it may be more intuitive when a STYLE element is always applied, like the STYLE attributes are always applied. But intuition is a function of experience, so intuition may change.
The situation around the choice of medium is less clear. a content-type based solution allows HTTP content negotiation and is also usable outside HTML. Parameters on the content-type look like the most flexible solution, in case unexpected medium types appear on the scene.
Bert Bos