This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at: http://www.w3.org/pub/WWW/TR
Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The HyperText Markup Language (HTML) is a simple markup language used to create hypertext documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of applications. This specification extends HTML to provide support for rendering instructions expressed in separately specified notations. It is no longer necessary to extend HTML when new forms of rendering instructions are needed. Rendering instructions can be included with individual HTML elements to which they apply, or grouped together in the document head, or placed in associated style sheets. This specification does not specify particular style sheet notations, leaving that to other specifications.
There are several approaches for associating HTML documents with separate style sheets:
In HTML it is also possible to put style sheets in-line in the document. HTML is extended with a new element and a new attribute (both called STYLE), as described below. No matter how style sheets are applied, the user should be made aware that a particular style is in force and should have the option of turning it off.
Styles may often be designed for a restricted range of media, e.g. for graphical user interfaces with scalable fonts and millions of colors; for A4 paper media; for speech output; or for simple terminals with fixed pitch single font and 80x24 character displays. This proposal doesn't provide an explicit means to state the conditions under which a given style sheet is applicable.
Style sheet notations may themselves provide support for media dependencies. Another approach is to use a generic URL to reference a style sheet, and to make the binding to a specific URL according to the media required. This will be described in a separate working draft.
In HTML, the LINK element is used to create a typed hyperlink between the document and some other resource. The REL attribute defines the type of the link. With REL=stylesheet, the LINK element can also be used to link to a style sheet.
Authors can use LINK elements to offer readers a choice of style sheets, e.g:
<LINK TITLE="Traditional" REL=stylesheet HREF="old.style"> <LINK TITLE="Modern" REL=stylesheet HREF="modern.style"> <LINK TITLE="Wacky" REL=stylesheet HREF="wacky.style"> <TITLE>ACME Widgets Corp</TITLE> <H1>ACME Widgets Corp</H1> <P>If your browser supports style sheets, try our new look in traditional, modern and wacky styles. ...
Another approach is to use a generic URL for a LINK which maps to a set of alternative style sheets. A separate working draft will describle how resource descriptions can be used for this purpose.
This specification builds upon the definition of the LINK element in HTML 2.0 in the following respects:
<!ELEMENT LINK - O EMPTY> <!ATTLIST LINK href CDATA #REQUIRED -- Universal Resource Locator -- title CDATA #IMPLIED -- advisory title string -- rel CDATA #IMPLIED -- forward link type -- rev CDATA #IMPLIED -- reverse link type -- media CDATA #IMPLIED -- Internet media type -- >
Note that the order of such LINK elements in the document markup does not signify preference order!
A single STYLE element may be included in the document head. It allows authors to include style rules within the HTML document, e.g.
<HEAD> <TITLE>Title</TITLE> <STYLE NOTATION="application/css" SRC="weird.css"> H1 { color: brown } P { color: blue } </STYLE> </HEAD>
In the example, the CSS notation is used. The STYLE element specifies color overrides to the "weird.css" style sheet for H1 and P elements. The STYLE element is formally defined by:
<!ELEMENT style - O (#PCDATA)> <!ATTLIST style notation CDATA #REQUIRED -- Internet media type for style -- src CDATA #IMPLIED -- URL for separate style sheet -- title CDATA #IMPLIED -- advisory title for this style -- >
The attributes are defined as follows:
This attribute is needed for the extremely common case where a linked style sheet is overridden by a few rules in the style element or by properties given by the style attribute on particular elements. In the absence of the SRC attribute you would need to include the style element, a link element and a means for selecting which link element to use.
CSS supports the ability to cascade several style sheets so that their effects are blended together. The STYLE element can be used with CSS to cascade style sheets using the CSS @import command, e.g.
<HEAD> <TITLE>Title</TITLE> <STYLE NOTATION="application/css"> @import "house-style.css" @import "draft-report.css" H1 { color: red } -- override cascaded style sheets -- </STYLE> </HEAD>
When the STYLE element occurs together with one or more LINK elements that specify linked style sheets, the user agent should consider the STYLE element in preference to the LINK elements.
The content model for the STYLE element precludes SGML tags, and the end tag of a STYLE element can usually be omitted, e.g. when the STYLE element is followed by another element. Instances of the characters "&", "<" or ">" within rendering instructions should be escaped using SGML entities, e.g. & < and > respectively.
Note that if we later decide to allow multiple STYLE elements in the document head, e.g. to cater for alternative styles, then we will need a different way of specifying the style notation in use for STYLE attributes for elements in the document body. The suggested choice is an attribute on the BODY element, e.g. "stylenotation", with the same definition as the "notation" attribute for the STYLE element.
To support effective use of style sheets with HTML documents a number of common attributes are proposed. These can be used with most HTML elements. In general, all attribute names and values in this specification are case insensitive, except where noted otherwise.
<!ENTITY % attrs "id ID #IMPLIED -- element identifier -- class NAMES #IMPLIED -- for subclassing elements -- style CDATA #IMPLIED -- rendering annotation -- lang NAME #IMPLIED -- as per RFC 1766 -- dir (ltr|rtl) #IMPLIED -- I18N text direction --">
For example:
<TITLE>Test Document</TITLE> <STYLE NOTATION="application/css"> <P STYLE="color: red; font-style: small-caps">This text should be in small capitals and colored red!
The end tag for the STYLE element has been omitted here since the element is unambigously ended by the <P> start tag.
en, en-US, en-uk, i-cherokee, x-pig-latin.
The DIR attribute specifies an encapsulation boundary which governs the interpretation of neutral and weakly directional characters. It does not override the directionality of strongly directional characters. The DIR attribute value is one of LTR for left to right, or RTL for right to left, e.g. DIR=RTL.
<!ELEMENT c O O (%text)*> <ATTLIST c %attrs; -- id, class, style, lang and dir -- >
Sometimes it is desirable to apply a style to some text which doesn't have a structural role. For instance, the first few letters or words after a drop down capital may be rendered as small capital letters. In such situations it is inappropriate to use an existing tag such as <EM>. On existing user agents, the first letter would appear normally, but the next few would be mysteriously italicized. The new <C> tag is recommended instead, as it has no effect on existing user agents.
An example based on CSS:
<TITLE>Title</TITLE> <STYLE NOTATION="application/css"> P { text-effect: drop-cap, font-size: 12pt, alt-font-size: 24pt -- assuming leading is zero -- } C { font-style: small-caps } </STYLE> <P>T<C>he first</C> few words of an article in The Economist..
This would be formatted to look something like:
___ | HE FIRST few words | of an article in the Economist..
While on an existing user agent it would look like:
The first few words of an article in the Economist..
In an interactive user agent, if an external (i.e., not built into the user agent or supplied by the user) style is being applied, the user should be made aware of it and be given the option of turning it off, or of selecting a different style, either for this document only or for all future documents as well. A flag in the corner of the window or an option button in the menubar should be enough.
It may be possible for the user to combine several of the available style sheets. At least it should be possible for the user to choose a personal style instead of, or maybe in combination with, external style sheets.
When a user agent applies a style sheet to a document while the author of that document has indicated a preference for a different style sheet, the user agent may have to alert the user to that fact. Exactly how and when that is done is outside the scope of this report. E.g., the CSS style sheet language gives precise rules for the conditions under which a user is allowed to override the author's choices.
The introduction of style sheets will give authors and users much greater control over the appearence of documents. It will also remove the pressure on vendors to extend HTML itself when ever a new rendering feature is needed. However, it will take time for widespread deployment of support for style sheets. What are some of the deployment issues?
Traditionally, HTML user agents have silently ignored unknown start and end tags, or unknown attributes. Very few user agents support the LINK element. As as result:
As a result it is recommended that during the transition phase, authors avoid placing rendering instructions within the STYLE element. This leaves authors free to place rendering instructions within STYLE attributes on specific HTML elements and to use separate style sheets, linked via the STYLE element or one or more LINK elements.
This restriction may be lifted if vendors adopt another proposal by the World Wide Web Consortium for specifying variants of network resources. The resource variants mechanism would allow authors to serve up two versions of a document, one designed for old user agents and one for new user agents. The choice is made by the user agent based on descriptions of resource variants. The resource variants mechanism is the subject of a related working draft.
Some people have voiced concerns over performance issues for style sheets. For instance, if the user agent has to wait until it has finished down loading lengthy style sheets, before it can start to display a document, then users will start to complain. A similar situation arises if the document head includes a lengthy set of style rules.
The current proposal sidesteps these issues, by allowing authors to include rendering instructions within each HTML element. The rendering information is then always available by the time the user agent wants to render each element.
In many cases, authors will take advantage of a common style sheet for a group of documents. In this case, distributing rendering information through out the document will actually lead to worse performance than using a linked style sheet, since for most documents, the style sheet will already be present in the local cache. The public availability of good style sheets will encourage this effect.
The ability to override style sheets with information in the document head, or on individual HTML elements, increases the effectiveness of the local cache. Small changes to the document style can be kept out of the common style sheet, thereby allowing the same style sheet to be used with more documents, which in turn increases the chances of finding it in the cache.