This document allows a style sheet to be associated with an XML
document by including one or more processing instructions with a
xml-stylesheet in the document's prolog.
This document has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from other documents. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
The list of known errors in this specifications is available at http://www.w3.org/TR/1999/xml-stylesheet-19990629/errata.
Comments on this specification may be sent to <email@example.com>. The archive of public comments is available at http://w3.org/Archives/Public/www-xml-stylesheet-comments.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
The Working Group expects additional mechanisms for linking style sheets to XML document to be defined in a future specification.
The use of XML processing instructions in this specification should not be taken as a precedent. The W3C does not anticipate recommending the use of processing instructions in any future specification. The Rationale explains why they were used in this specification.
This document was produced as part of the W3C XML Activity.
Style Sheets can be associated with an XML[XML10]
document by using a processing instruction whose target is
xml-stylesheet. This processing instruction follows the
behaviour of the HTML 4.0
xml-stylesheet processing instruction is parsed in
the same way as a start-tag, with the exception that entities other
than predefined entities must not be referenced.
The following grammar is given using the same notation as the grammar in the XML Recommendation[XML10]. Symbols in the grammar that are not defined here are defined in the XML Recommendation.
|||StyleSheetPI||::=||'<?xml-stylesheet' (S PseudoAtt)* S? '?>'|
|||PseudoAtt||::=||Name S? '=' S? PseudoAttValue|
|||PseudoAttValue||::=||('"' ([^"<&] | CharRef | PredefEntityRef)* '"'|
|| "'" ([^'<&] | CharRef | PredefEntityRef)* "'")|
|- (Char* '?>' Char*)|
|||PredefEntityRef||::=||'&' | '<' | '>' | '"' | '''|
In PseudoAttValue, a CharRef or a PredefEntityRef is interpreted in the same manner as in a normal XML attribute value. The actual value of the pseudo-attribute is the value after each reference is replaced by the character it references. This replacement is not performed automatically by an XML processor.
xml-stylesheet processing instruction is allowed
only in the prolog of an XML document. The syntax of XML constrains
where processing instructions are allowed in the prolog; the
xml-stylesheet processing instruction is allowed anywhere
in the prolog that meets these constraints.
NOTE: If the
xml-stylesheetprocessing instruction occurs in the external DTD subset or in a parameter entity, it is possible that it may not be processed by a non-validating XML processor (see [XML10]).
The following pseudo attributes are defined
href CDATA #REQUIRED type CDATA #REQUIRED title CDATA #IMPLIED media CDATA #IMPLIED charset CDATA #IMPLIED alternate (yes|no) "no"
The semantics of the pseudo-attributes are exactly as with
<LINK REL="stylesheet"> in HTML 4.0, with the
exception of the
alternate pseudo-attribute. If
alternate="yes" is specified, then the processing
instruction has the semantics of
stylesheet"> instead of
NOTE: Since the value of the
hrefattribute is a URI reference, it may be a relative URI and it may contain a fragment identifier. In particular the URI reference may contain only a fragment identifier. Such a URI reference is a reference to a part of the document containing the
xml-stylesheetprocessing instruction (see [RFC2396]). The consequence is that the
xml-stylesheetprocessing instruction allows style sheets to be embedded in the same document as the
In some cases, style sheets may be linked with an XML document by
means external to the document. For example, earlier versions of HTTP
[RFC2068] (section 18.104.22.168) allowed style sheets to be
associated with XML documents by means of the
header. Any links to style sheets that are specified externally to the
document are considered to occur before the links specified by the
xml-stylesheet processing instructions. This is the same
as in HTML 4.0 (see section
Here are some examples from HTML 4.0 with the corresponding processing instruction:
<LINK href="mystyle.css" rel="style sheet" type="text/css"> <?xml-stylesheet href="mystyle.css" type="text/css"?> <LINK href="mystyle.css" title="Compact" rel="stylesheet" type="text/css"> <?xml-stylesheet href="mystyle.css" title="Compact" type="text/css"?> <LINK href="mystyle.css" title="Medium" rel="alternate stylesheet" type="text/css"> <?xml-stylesheet alternate="yes" href="mystyle.css" title="Medium" type="text/css"?>
xml-stylesheet processing instructions are
also allowed with exactly the same semantics as with
REL="stylesheet". For example,
<LINK rel="alternate stylesheet" title="compact" href="small-base.css" type="text/css"> <LINK rel="alternate stylesheet" title="compact" href="small-extras.css" type="text/css"> <LINK rel="alternate stylesheet" title="big print" href="bigprint.css" type="text/css"> <LINK rel="stylesheet" href="common.css" type="text/css">
would be equivalent to:
<?xml-stylesheet alternate="yes" title="compact" href="small-base.css" type="text/css"?> <?xml-stylesheet alternate="yes" title="compact" href="small-extras.css" type="text/css"?> <?xml-stylesheet alternate="yes" title="big print" href="bigprint.css" type="text/css"?> <?xml-stylesheet href="common.css" type="text/css"?>
There was an urgent requirement for a specification for style sheet linking that could be completed in time for the next release from major browser vendors. Only by choosing a simple mechanism closely based on a proven existing mechanism could the specification be completed in time to meet this requirement.
Use of a processing instruction avoids polluting the main document structure with application specific processing information.
The mechanism chosen for this version of the specification is not a constraint on the additional mechanisms planned for future versions. There is no expectation that these will use processing instructions; indeed they may not include the linking information in the source document.