Abstract

A document that uses polyglot markup is a document that is a stream of bytes that parses into identical document trees
(with some exceptions, as noted in the Introduction) when processed either as HTML or when processed as XML.
Polyglot markup that meets a well-defined set of constraints is interpreted as compatible, regardless of whether it is processed as HTML or as XHTML, per the HTML5 specification.
Polyglot markup uses a specific DOCTYPE, namespace declarations, and a specific case—normally lower case but occasionally camel case—for element and attribute names.
Polyglot markup uses lower case for certain attribute values.
Further constraints include those on void elements, named entity references, and the use of scripts and style.

Status of This Document

This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.

This specification summarizes design guidelines for authors who wish their XHTML or HTML documents to be conforming whether parsed as HTML or as XML.
The document is intended to be useful to web authors, in particular those who want to serve receivers without concern for whether they have XML or HTML parsers available.
Such concerns may, for instance, arise in content syndication or when receivers are on legacy systems.
HTML polyglots facilitate migration to and from XHTML,
including transition from XML 1.x to HTML5, and this document serves to accurately specify the requirements of a UTF-8 based profile for such documents.

No recommendation is made in this document or by the W3C regarding whether or not to publish polyglot content.
In general, authors are encouraged to publish HTML content using HTML5 syntax and media types
(either HTML syntax and text/html, or XHTML syntax and application/xhtml+xml).

This document is not a specification for user agents and creates no obligations on user agents.
Note that this document does not define how HTML5-conforming user agents should process HTML documents.
Nor does it define the meaning of the Internet Media Type text/html.
For user agent guidance and for these definitions, see [HTML5] and [RFC2854].

Please submit bugs for this document by using the W3C's public bug database (
http://www.w3.org/Bugs/Public/) with the product set to HTML WG and the component set to
HTML/XHTML Compatibility Authoring Guide (ed: Eliot Graff).
If you cannot access the bug database, submit comments by email to the mailing list noted below.

This document was published by the HTML working group as a Candidate Recommendation.
This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to
public-html@w3.org
(subscribe,
archives).
W3C publishes a Candidate Recommendation to indicate that the document is believed to be
stable and to encourage implementation by the developer community. This Candidate
Recommendation is expected to advance to Proposed Recommendation no earlier than
17 October 2014.
All comments are welcome.

Publication as a Candidate Recommendation does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other than work in
progress.

1. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
and notes in this specification are non-normative. Everything else in this specification is
normative.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY,
and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

2. Introduction

This section is non-normative.

It is sometimes valuable to be able to serve HTML5 documents that are also well formed XML documents.
An author may, for example, use XML tools to generate a document, and they and others may process the document using XML tools.
The language used to create documents that can be parsed by both HTML and XML parsers is called polyglot markup.
Polyglot markup is the overlap language of documents that are both HTML5 documents and XML documents.
It is recommended that these documents be served as either text/html (if the content is transmitted to an HTML-aware user agent)
or application/xhtml+xml (if the content is transmitted to an XHTML-aware user agent).
Other permissible MIME types are text/xml, application/xml,
and any MIME type whose subtype ends with the four characters "+xml". [XML-MT]

2.1 Scope

Polylglot markup is a robust – but entirely optional – profile of the HTML vocabulary.
All web content need not be authored in polyglot markup and it is primarily an option
for authors wanting increased robustness of their documents.
Polyglot markup works best, and can be a beneficial option, in controlled environments and for authoring tools.

Polyglot markup is ideal for publishing when there's a strong desire to serve both HTML and XML tool chains
without simultaneously having to maintain dual copies of the content: one in HTML and a second in XHTML.
In addition, a single polyglot markup output requires less infrastructure to produce than to produce both HTML and XHTML output for the same content.
Polyglot markup is also be beneficial when lightweight processes—such as
quick testing or even hand-authoring—are applied to content intended to be published both as HTML and XHTML,
especially if that content is not sent through a tool chain.

Note

XML-based HTML tools or systems intended for the most general contexts of use cannot depend on polyglot input: for maximum flexibility,
such tools should use the technique of using an HTML parser that produces an XML-compatible DOM or event stream.

2.2 Robustness

The goal of polyglot markup is a syntax that is robust the way the Web Content Accessibility Guidelines (WCAG) 2.0 describes it: ”Maximize compatibility with current and future user agents, including assistive technologies. [WCAG20]

Authors need not understand the benefits of robustness in order to benefit from the syntax of polyglot markup. However, in order to promote its benefits, it is necessary to understand that polyglot markup does not add semantics, and as such is not any more or less semantic than other flavors of HTML. Polyglot markup does, however, work to preserve semantics, including during the authoring process. Polyglot markup also does not ensure accessibility,as it does not add any accessibility requirements that other relevant specifications have not already added. But polyglot markup can work to preserve accessibility through adherence to required practices.

Polyglot markup approaches robustness by defining constraints on the serialization of a DOM tree in a manner that is likely to retain semantics when that serialization is reparsed using a variety of parsers, be they full featured and bug free HTML5 parsers, somewhat HTML-aware parsers, and even XML parsers.

For the most part, polyglot markup is just a pure deduction of the validity constraints and syntax requirements that HTML and XHTML each dictate, many of which took "polyglotness" into consideration when they were added to HTML5. However, for reasons of robustness, this specification sometimes goes further than the principle of the lowest common denominator would have required.

For instance, included in the set of constraints on the serialization is the requirement to use the UTF-8 encoding. While not the only theoretical possibility, the choice of UTF-8 as the sole option is justified by the underlying principle of robustness. E.g. if someone opted to use the KOI8-R, encoding, then, as a side-effect of HTML-conformance and XML well-formedness requirements, the author would be forced to rely on a higher protocol (such as MIME Content-Type) in order to support XML parsers. By requiring UTF-8, that side-effect is avoided.

Using robust syntax can enable documents to be parsed more reliable in less capable parsers. But even if the document can be expected to be parsed and validated by tools that fully conform to HTML5, polyglot markup adds robustness. As an example, when serialized as HTML, the closing tag for the p element is entirely optional and will be inferred if not present. But inclusion of closings tags, as required by XML and, thus, by polyglot markup, cause no harm beyond a minor increase in transfer size (an increase often mitigated by compression), but does allow validators to detect situations where the implicit closing rules don't match what the author intended.

Note

Note that XML-based polyglot markup syntax is not the only way to increase robustness.
For instance, an HTML validator or an authoring tool could require all tags to be closed even if
this is not required by the HTML syntax.

3. Syntax

3.1 Principles

identical DOMs when processed as HTML and when processed as XML, with some notable exceptions:
HTML and XML parsers generate different DOMs for some xml (xml:lang, xml:space, and xml:base),
xmlns (xmlns="" and xmlns:xlink=""),
and xlink (such as xlink:href) attributes.
XML requires and HTML5 permits these attributes in certain locations and the attributes are preserved by HTML parsers.
The exception must not break the requirement to be a valid HTML document.

Polyglot Markup specifies a Robust Syntax, by which it is meant a syntax that maximizes support and minimizes authoring choice.

Support is maximized:

by supporting both HTML and XML parsing;

by utilizing code that, as far as possible, results in DOM equivalent parsing in generic as well as specialized parsers, including challenged parsers of various kinds;

because the code is ready to be reused/repurposed/redited/reparsed in any authoring tool or parser.

Auhoring choices are minimized

through strict syntax requirements partly dictated by the polyglot approach and partly motivated by the robust approach.

Polyglot markup is scripted according to the rules of XML (does not use document.write, for example)
and excludes HTML elements that are impossible to replicate in an XML parser (does not use the noscript element, for example).
Polyglot markup triggers non-quirks mode in HTML parsers,
as non-quirks mode is closest to XML-mode rendering, in regard to both DOM and CSS.
Polyglot markup results in the same encoding and the same language in both HTML-mode and XML-mode.

For XML, UTF-8 is an encoding default.
Documents served with an XML content type therefore do not need to use any of the HTML encoding declaration methods,
although if the document might be interpreted as text/html it SHOULD do so.

or in its alternative form: <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

Outside the document

By adding "charset=utf-8" to the MIME/HTTP Content-Type header [HTTP11], as the following examples show in HTML and XML, respectively:

Example 1

Content-type: text/html; charset=utf-8

Example 2

Content-type: application/xhtml+xml; charset=utf-8

Note that, when serving polyglot documents as XML, charset=UTF-8 can safely be omitted, due to the UTF-8 encoding default of XML:

Example 3

Content-type: application/xhtml+xml

Note

Both XML and HTML parsers are required to support the byte order mark.
The HTML encoding declaration has no effect in XML. When the HTML encoding declaration is
the only encoding declaration, the encoding default from XML makes XML parsers treat content as UTF-8.

The W3C Internationalization (i18n) Group recommends that one always include
a visible encoding declaration in an HTML document, because it helps developers, testers, or translation production managers to check the encoding of a document visually.

A Formal Public Identifier (FPI), if present, is a case-sensitive match of the registered FPI to which it points.

A URI, if present in the document type declaration, is a case-sensitive match of the URI to which it points.

If the URI is the string about:legacy-compat, polyglot markup includes the string in lowercase letters, as required by HTML5.

If the URI is an http URL, the URI points to the correct resource, using case-sensitive letters.

Note

For valid XML the document element named in the document type declaration must exactly match the top-level element
of the document, including in case.
This rule is relaxed for well-formed, rather than valid, XML documents.
Because XHTML requires a lower-case html element, Polyglot documents SHOULD use lower-case
html for the element named in the DOCTYPE declaration.
Bear in mind that a customized XHTML DTD with element and entity declarations inside the document type definition
subset within the document, or one that points to an alternate DTD, may have special case requirements.

Note that using about:legacy-compat in XML may yield unpredictable parsing results, depending on the XML processing pipeline.

Polyglot markup does not use document type declarations for HTML4, HTML3, or HTML2, regardless of whether they contain a URI or not and
regardless of their effect in HTML5 parsers, as these document type declarations are not compatible with XHTML.

4.4 Namespaces

4.4.1 Element-level namespaces

[HTML5] introduces undeclared (native) default namespaces for the root HTML element, html, the root SVG element, svg,
and the root MathML element, math.
Polyglot markup declares the following default namespaces, when the markup languages are included in the document, to maintain XML compatibility [XML10]:

<html xmlns="http://www.w3.org/1999/xhtml">

<math xmlns="http://www.w3.org/1998/Math/MathML">

<svg xmlns="http://www.w3.org/2000/svg">

Polyglot markup declares the default namespaces on the root HTML element, html,
the root SVG element, svg, and the root MathML element math,
and on any HTML elements used as children of SVG or MathML elements.
Polyglot markup does not declare any other default or prefixed element namespace, because
[HTML5] does not natively support the declaring of any other default or prefixed element namespace.

4.4.2 Attribute-level namespaces

[HTML5] introduces undeclared (native) support for attributes in the XLink namespace and with the prefix xlink:.
To maintain XML-compatibility, polyglot markup explicitly declares the XLink namespace:
xmlns:xlink="http://www.w3.org/1999/xlink"). [XML10]

For conformance with the HTML specification’s conformance rules, the declaration has to take place in each foreign content
section where it is used, typically on a such section’s root element (e.g. on the svg start tag for an SVG
section and on the math start tag for a MathML section) since the declaration must occur before using any of
the xlink: prefixed attributes,

xlink:actuate

xlink:arcrole

xlink:href

xlink:role

xlink:show

xlink:title

xlink:type

The xml: namespace prefix used in xml:base, xml:lang,
xml:space, and xml:id does not need to be declared in XML documents, and therefore
polyglot markup does not declare these prefixes via xmlns. The prefixes are implicitly declared
in XML and are automatically applied to the appropriate attributes in HTML.
See CSS namespaces [CSS3NAMESPACE] how to use CSS selectors with these attributes.

The fact that polyglot markup doesn’t operate with optional tags may create surprises for an author not used
to adding the tbody tags in their markup, for example,
or to someone accustomed to omitting the end tag of the p element.
However, the requirement to be well-formed with regard to tags is a key feature of polyglot markup
that makes the code robust against subpar parsers and authoring surprises.

4.5.1.1 A minimal HTML document

Every polyglot markup document therefore contains an html, head, title,
and body element.
The html element is the root element.
The head and body elements are children of the html element.
The title element is a child of the head element.
Therefore, the following is the most basic polyglot markup document.

4.5.1.2 Required element examples

Whenever it uses a tr element, polyglot markup always wraps the tr element inside a
tbody, thead, or tfoot element.
In HTML, if a group of one or more adjacent tr elements are not explictly wrapped inside a tbody, thead, or tfoot element,
the HTML parser creates and wraps a new tbody element around the tr elements.
XML parsers do not create the tbody element, thus offering the potential for creating different DOMs.

Correct:

Example 5

<table><tbody><tr>...

Incorrect:

Example 6

<table><tr>...

Whenever it uses col elements within a table element, polyglot markup explicitly uses a colgroup element surrounding groups of the col elements.
In HTML, if a group of one or more adjacent col elements are not explicitly wrapped inside a colgroup element,
the HTML parser creates and wraps a new colgroup element around the col elements.
XML parsers do not create the colgroup element, thus offering the potential for creating different DOMs.

Correct:

Example 7

<table><colgroup><col>...

Incorrect:

Example 8

<table><col>...

4.5.2 Excluded elements

Polyglot markup does not use the noscript element,
because the noscript element cannot be used in XML documents. [HTML5]

4.5.3 Case-sensitivity

The following apply to any usage of element names, attribute names, or attribute values in markup, script, or CSS.
Polyglot markup uses lower case letters for all ASCII letters.
For non-ASCII letters—such as Greek, Cyrillic, or non-ASCII Latin letters—polyglot markup respects case sensitivity as it is called for.

4.5.3.2 Attribute names

Polyglot markup uses lowercase letters in attribute names for all HTML elements;
all MathML elements except the lowercase definitionurl,
which polyglot markup changes to the mixed case definitionURL;
and all SVG attributes except the following SVG attributes, for which polyglot markup uses mixed case:

attributeName

attributeType

baseFrequency

baseProfile

calcMode

clipPathUnits

contentScriptType

contentStyleType

diffuseConstant

edgeMode

externalResourcesRequired

filterRes

filterUnits

glyphRef

gradientTransform

gradientUnits

kernelMatrix

kernelUnitLength

keyPoints

keySplines

keyTimes

lengthAdjust

limitingConeAngle

markerHeight

markerUnits

markerWidth

maskContentUnits

maskUnits

numOctaves

pathLength

patternContentUnits

patternTransform

patternUnits

pointsAtX

pointsAtY

pointsAtZ

preserveAlpha

preserveAspectRatio

primitiveUnits

refX

refY

repeatCount

repeatDur

requiredExtensions

requiredFeatures

specularConstant

specularExponent

spreadMethod

startOffset

stdDeviation

stitchTiles

surfaceScale

systemLanguage

tableValues

targetX

targetY

textLength

viewBox

viewTarget

xChannelSelector

yChannelSelector

zoomAndPan

4.5.3.3 Attribute values

For characters in attribute values, polyglot markup maintains case consistency between markup, DOM APIs, and CSS
when these attributes are used on HTML elements.

Polyglot markup maintains case consistency for values on the following attributes, which occur on
MIME types, language tags, charsets, booleans, media queries, and keywords.
Though not required, an easy way to maintain case-consistency is to use only lower case values for these attributes.
Polyglot markup maintains case consistency for these values
because, for the purpose of selector matching, attribute values in XML are all treated case sensitively;
however, HTML treats the values of these attributes as case insensitive
(See 4.14.1 Case-sensitivity, in the HTML5 specification). [HTML5]

accept

accept-charset

charset

checked

defer

dir

direction

disabled

enctype

hreflang

http-equiv

media

method

multiple

readonly

rel (for values that do not contain a colon)

scope

selected

shape

target (keywords only; browsing context names are case-sensitive)

type (on a, link, object, script, or style elements)

type (on input)

Note that other specifications, such as RDFa, may place additional restrictions on the allowed values of certain attributes.

Example: Given an empty instance of an element whose content model is not EMPTY (for example, an empty
title or paragraph) polyglot markupdoes not use the empty-element tag syntax.
That is, the document uses <p></p> and not <p/>.

Note

Elements in foreign content, such as MathML and SVG elements,
may either use the empty-element tag syntax or contain content.

In HTML, the content of the script and style elements is treated as if it were CDATA,
so that & and < are not special except when they occur as the end tag to close the element.
In XHTML, however, the same elements are treated as tags, character references, CDATA, etc.

Fig. 1Overview of the differences in how HTML and XML parse raw text elements

eitherlimiting the content to safe text content, that
is, text that gets interpreted the same way in HTML and in XML.

or trying to even out the constraints differences by
wrapping the contents in a CDATA section. The CDATA code is then seen as text
by the HTML parser (and can thus interfere with the scripting or styling language!), while the XML parser sees the
content as text without markup semantics.

Limiting the contents to safe text content requires more planning and control over the code, but can be said to be
more robust than the CDATA option as it requires no extra, potentially
breakable code to make the scripting or styling language work. The CDATA option on the
other hand, gives more freedom and robustness against various errors that can happen because the author isn’t
aware of the safe text content limitations or because the code is inserted by a tool that is unable to
guarantee that the content is safe.

4.6.2.1 Options for delivering safe text content

External safe text content.Polyglot markup can include scripts or stylesheets
by linking to external files rather than including the code in-line.
External files are parsed as the respective script or stylesheet and are thus not limited
by the same restrictions as safe text content.
Fig. 2Examples of linking to external scripts or stylesheets

Example 9

<!-- Ways to link to external scripts or stylesheets --><scriptsrc="external.js"></script><linkhref="external.css"rel="stylesheet"/><style>@import"external.css";</style>

Inline safe text content.Polyglot markup does not use characters or constructs
that are interpreted differently in HTML and XML.
This means not using the characters < and &
as well as the CDATA end mark string – ]]>.
Polyglot markup
is agnostic as to whether one uses character entities or a numeric character references,
so long as they are valid.
That is, for polyglot markup, there is no difference between &amp; and &#x3C;.
Fig. 3Examples of content that is not safe text content

Example 10

<!-- Unsafe content: < and & are not escaped This code is not XML well-formed. --><style>q::before{content:"<";}</style><script>var a ="&";</script><!-- Unsafe content: < and & are escaped at markup language level. This code means different things in HTML vs XML --><style>q::before{content:"&lt;";}</style><script>var a ="&amp;";</script><!-- Safe content: < and & escaped at scripting/stylesheet level --><style>q::before{content:"\00003c";}</style><script>var a ="\u0026";</script>

For CSS, the inline safe text content option would work very well most of the time, as < and
& are not key parts of CSS and not very often used. But when it comes to JavaScript,
the & and the < are key verbs (operators) of the
language, and thus one soon runs into trouble – it is better to use externalsafe text content.

Fig. 4Inline content containing no ambiguous strings

Example 11

<!-- The following example of inline script is polyglot markup because there are no ambiguous strings within the script element. --><script>document.body.appendChild(document.createElement("div"));</script>

Note

A workaround for using ambiguous strings is to include the properly escaped characters
inside the src attribute of style or script tags.

4.6.2.2 Safe CDATA content

Polyglot markup accepts raw text content wrapped in a CDATA section;
however instead of permitting any content (except the very CDATA end mark string – ]]>), only the
subset that corresponds to the particular raw text element’s HTML constraints is permitted. See the “HTML interpretation”
column in the parsing differences table above – all the cells with the text ”uninterpreted”
are also uninterpreted as CDATA and thus constitutes the safe subset of CDATA.

Wrapping raw text in a CDATA section introduces a new problem: when consumed as HTML, the start and end mark of the
CDATA section is seen by the script or stylesheet interpreter and can thus cause syntax errors or even halt the script
and stylesheet execution.
A solution is to comment out the CDATA start and end marks by using the comment methods of the script or stylesheet language.
Additionally, such as when script is used as a coding block container,
it may be necessary to even comment out the scripting/styling comments by hiding them inside an XML comment.

4.6.2.2.1 Safe rules for CDATA use

These rules assume that CDATA is of limited use for CSS.

General rules:

The CDATA section is subject to HTML’s restrictions on <script> and <style>.

There can be only one CDATA section per raw text element.

A CDATA section must appear at the start of its containing element, and hence be the first child of that element.

Before the CDATA section there can only be content that creates one node -
preferably only one line of code - which may consist of whitespace, an XML comment,
or a construct of the scripting/styling language
(usually a comment of the scripting/styling language).

After the CDATA section there can only be content that creates one node -
preferably only one line of code - which may consist of whitespace, an XML comment,
or a construct of the scripting/styling language
(usually a comment of the scripting/styling language).

Note

The statement that a "CDATA section must appear at the start of its containing element, and hence be the first child of that element,"
is due to how parsers may create DOM nodes based on characters and whitespace.
The following script element, because it contains no whitespace outside the CDATA node, has one node,
whether parsed as HTML or as XML:

<script><![CDATA[foo]]>/<script>

Because an author may need to comment out the CDATA "start tag" and "end tag,"
polyglot markup allows for one node before and after the CDATA section.
The following example has three nodes: one text node before the CDATA section,
one for the CDATA section, itself, and one after the CDATA section:

Fig. 5CDATA section that is commented out, resulting in a total of three DOM nodes.

Example 12

<script>/*<![CDATA[*/
foo
/*]]>*/</script>

The ]]> string:

is always commented out if <![CDATA[ is commented out.

is never commented out if <![CDATA[ is not commented out.

Example 13

<script>//<![CDATA[ Foo; //]]> </script>

The <![CDATA[ string can be handled in 3 ways:

<![CDATA[ - without commenting it out.

Example 14

<scripttype="not-CSS-and-not-JS"><![CDATA[foo]]></script>

Note

Using the <![CDATA[ block without commenting it out
is not conforming as type="text/css" or type="text/javascript" content when parsed as HTML.

//<![CDATA[ - using scripting language comments for the entire block.

Example 15

<script>//<![CDATA[ FOO; //]]></script>

Note that the comment starts in the node before the CDATA section.

<!--//--><![CDATA[ - Same as 2, but the scripting comment is hidden inside an XML comment.

Example 16

<script><!--//--><![CDATA[ FOO; //]]></script>

Note that the scripting language must accept <!-- as syntactically legal.
JavaScript does, but other scripting languages may not.

This approach is compatible with CSS; however, rule 2 above prevents validity.

4.6.2.2.2 Comment syntax in script

Polyglot markup does not place the opening <script> tag inside comments within a
script element.
When the HTML parser encounters an opening <script> tag inside comments within a script element,
it does not close the element on the next </script> end tag unless a closing comment string
(-->) occurs first, for compatibility-related reasons.
Alternatively, if the parser doesn’t see any comment end first, the element will be closed on the second</script> end tag.
If neither a comment end nor a second <script element end tag is found,
the rest of the document is commented out. Note that this behavior does not occur with the style element.

4.6.3 Escapable raw text elements

Escapable raw text elements are elements in which character references are permitted
but where the HTML parser treats elements as text rather than as markup. For polyglot markup, escapable raw text elements are:

title

textarea

Polyglot markup uses the same rules of safe text content for escapable raw text elements, except that character entities are permitted for escapable raw text elements.

4.6.4 Foreign elements

The exact rules of for foreign content elements are defined by the respective specifications.

4.6.5 Special elements

Unless otherwise specified, elements have no special restrictions other than those that apply to all polyglot markup.

4.7 Text

4.7.1 Newlines in textarea and pre elements

When polyglot markup uses either a textarea or pre element,
the text within the element should not begin with a newline.
This is because HTML and SGML-based systems delete the initial newline on parsing, while XML parsers do not.

4.8 Attributes

Polyglot markup does not use directly typed newline characters within an attribute.

Within an attribute's value, polyglot markup represents tabs, line feeds, and carriage returns
as numeric character references rather than by using literal characters.
For example, within an attribute's value, polyglot markup uses &#x9; for a tab
rather than the verbatim string literal, \t.
This is because of attribute normalization in XML [XML10].
Note, too, that JavaScript and CSS in attribute values are affected by attribute value normalization,
because a comment ends up commenting out not to the end of the source line but to the end of the entire
attribute value.

The following example uses numeric character references (escaped characters) for the line feed, tab, and less-than characters within a srcdoc attribute.

Because of attribute-value normalization in XML [XML10], polyglot markup does not use newline characters within an attribute.
Practically speaking, for source code with newlines within attributes, DOMs generated via XML and HTML will be different;
however, whitespace differences have no behavioral impact on the page unless:

explicitly examined by JavaScript, rendering the differences of small consequence.

used in attributes whose content is rendered visually, such as the content of @alt.

Note that directly typed newline characters are overtly not allowed in any attribute containing a URI.

4.8.1 Disallowed attributes

The following attributes are not allowed in HTML or XHTML within polyglot markup.
These attributes have effects in documents parsed as XML but do not have effects in documents parsed as text/html.
The HTML5 spec therefore defines them as invalid in text/html documents. [HTML5]

xml:space

xml:base

Note that the xml:space and xml:base attributes are allowed on SVG and MathML elements.
The attributes may therefore appear in polyglot markup when they appear within SVG or MathML as foreign content.

4.8.2 Language attributes

When specifying the language mapping of an element, polyglot markup uses both the lang and the xml:lang attributes.
Neither attribute is to be used without the other, and polyglot markup maintains identical values for both lang and xml:lang.

The root element SHOULD always specify the language, or else HTML’s fallback language effect may step in and
cause the language to vary depending on whether the document is consumed as XML (where the fallback language
is not required to work) or consumed via file URI (where fallback language via external HTTP
Content-Language would not work). Note that the internal http-equiv="Content-Languagemeta element is non-conforming in HTML5. For more, see e.g. HTML5’s
language determination rules.

4.8.3 Attributes with special considerations

The following attributes or their considerations require exceptions to the general rules for polyglot markup.

Polyglot markup always uses character references for the less than sign (<)
and ampersand (&) when they are used as characters,
however for CDATA inside foreign content, strings within comments, and for safe CDATA,
the following rules apply:

for script and style elements that contain safe CDATA, they may used as defined by the rules for safe CDATA;

4.10 Comments

When applying JavaScript and CSS to polyglot markup, the goal is to get the same result whether consumed
as HTML or as XML. It is therefore important to be aware of scripting and styling features that give different
results in HTML vs XML. These issues comes in addition to the polyglot usage rules for raw text elements.

4.11.1 JavaScript: innerHTML vs document.write()

Although document.write() and document.writeln() works in HTML,
neither function works in XHTML. The polyglot alternative is the innerHTML property,
which works for both HTML and XHTML.

Note

The innerHTML property takes a string. However, XML parsers will parse that string as XML in XHTML
while HTML parsers parse will parse that string as HTML in HTML. And because of this difference in parsing,
the code that innerHTML inserts must follow the guidelines for polyglot markup so that
the resulting DOM generated by the XML parser do not differ from the DOM generated by the HTML parser.

4.11.2 CSS: Attribute selectors that require a namespace prefix

CSS enables authors to select elements by referencing their attributes using attribute selectors:
[attr]{property:value}. Generally speaking, attribute selectors can be used freely
since polyglot markup relies on default namespaces, which do not affect attributes.

However, some of the attributes required by polyglot markup are namespaced.
Some are namespaced by default, such as the xmlns attribute.
Some attributes are namespaced by a prefix that is namespaced by default, such as xml:,
xmlns:, and xlink:.
In addition, extension specs may allow namespaced attributes other than those defined by the HTML specification.
As result, a selector such as [xmlns]{rule:foo} will not work in XHTML,
where the attribute has an associated namespace.
The same is true for prefixed attributes.
Even if one escapes the colon ([xml\:lang]{rule:foo}), such selectors
will only work in HTML
(except for the namespace declaration for the xlink: prefix.
This works in XML and in HTML and must thus be selected in a namespaced way in both syntaxes).

To be able to select namespaced attributes in XML, the attribute selector must include a namespace prefix. [SELECT]

For the unprefixed, namespaced attribute xmlns, a polyglot selector that works in both HTML
and XML can be created by using the asterisk (*) for the namespace prefix, indicating that the
selector is to match all attribute names without regard to the attribute's namespace:

Example 18

[*|xmlns]{color:lime}

For prefixed attributes, then, because the rules of polyglot markup as well as the HTML specification
itself dictates that the presence of a xml:lang="foo" must be accompanied with a corresponding
lang="foo" attribute, then, in a conforming polyglot document, one can use the same
approach as for the xmlns attribute.

Example 19

[*|lang]{color:lime}

Note

However, the requirement of polyglot markup to use both xml:lang="foo" and lang="foo"
means that even [lang]{color:lime} would work, in both XML parsers and HTML parsers.

When it comes to the xmlns:xlink attribute, which is required for polyglot svg elements,
then, because it, in contrast to xml:lang, belongs to a foreign content element in HTML/XHTML, it is
namespaced even in HTML. Hence, the only way – in HTML as well as in XML – to use this
attribute as a selector, is by declaring the namespace of the xmlns: prefix in CSS:

In cases where the user agent does not support namespaces in CSS and/or in markup, it is necessary to use
more than one selector. This could happen if the author declares prefixes – default or prefixed – which are
an extension specification permits or if the user agent does not support attribute selectors with CSS
namespace prefix.

Example 21

/*Selector for legacy user agents without support for namespace prefixed attribute selector:*/
[xmlns],
/*Selector for user agents with support for namespace prefixed attribute selector:*/
[*|xmlns]
{color:lime}

The example document is served as 'text/html'.
Some legacy user agents do not support SVG in when served up as 'text/html' as it is in this example.
The example page could also be served as 'application/xhtml+xml' instead, with the file extension .html,
maintaining adherence to polyglot markup and enabling the rendering of the SVG.