HTML and XML are markup languages based on plaintext files. This means that any given character could be part of a syntax form (a tag, a comment, a character reference, etc…) or it could be representing itself the way it reads in the file literally.
<tag>· Text nodetag>
Whenever a character might be ambiguous, both languages require explicit indication of the intent of the character. In HTML this occurs via escaping, while XML allows escaping or wrapping the content in a marked section, specifically a CDATA section.
<tag>· Text node]]>
These terms confuse me at times, especially since CDATA and CDATA sections are distinct forms of the same content, and it’s easy to conflate each term. This post is here to disambiguate the terms, their meanings, and why they exist.
The punchline comes at the end, but the story is hopefully worth the read.
Markup and mixed content
One of the first jobs of a parser for any plaintext-oriented format is to determine if the next input character represents real text or is part of a syntax form that carries special meaning. If it’s a syntax form we would call it markup, but if the characters are part of real text meant for display or rendering or reading then we call it data.
Anything that is not syntax is data.
The interpretation of the next character depends on the region of the document in which it’s parsed. While the rules for syntax forms are complicated1, this post will focus on the data forms.
PCDATA — “parsed character data”
May form: tags, comments, sections, character references, literal text.
Characters in this region could be data or could form the start of a new markup element. It’s “parsed” because it needs parsing before determining what it represents.
The HTML specification renames this to Data, which is simpler and a bit harder to search for. In XML, however, it’s used in a document-type definition (DTD). When an element may contain content — text — its data model must include #PCDATA. Otherwise the only characters allowable within that element are other elements, comments, and whitespace. XML documents are required to be valid SGML documents, so its own specification adopts the terminology from SGML’s.
Those who have worked with DTDs might note that elements in XML may contain #PCDATA while attributes contain CDATA instead. First of all, the # is there only to make it explicit that PCDATA is referring to the reserved keyword, rather than a element, for example, then the attribute value would need to be #PCDATA instead, but this is prevented by design.
PCDATA actually contains more than just literal text and elements. In addition to comments, processing instructions, and other node-like syntax, one important feature of PCDATA is the character reference. These make it possible to represent characters that would conflate with syntax (such as ‘<’ — <) or which might be cumbersome to enter on a keyboard (such as ‘§’ — §). When parsing, each character in these sequences neither creates an element nor displays as the text itself; rather, the entire sequence is parsed and translates into the character it refers to.
HTML pre-specifies a fixed set of named character references, but any Unicode code point may be referenced by its decimal or hexadecimal numeric index. While XML also allows referencing code points by their index2, it only pre-specifies the five named characters which correspond to its main markup introducers: <, >, &, ', and ". In XML, any additional named character references are created through the DTD by defining entities.
CDATA — “character data”
May form: [character references], literal text.
If a character isn’t markup, then it’s character data, which means that it’s representing its literal self or it’s part of a character reference. Once the parser has entered this region it will not create markup elements.
CDATA is the most confusable kind of character data; this is because there are many kinds of CDATA that share the same name:
- XML attributes may contain CDATA, where character references are decoded.
- XML CDATA sections only contain CDATA, but character references are not decoded.
- HTML kind of has the same CDATA sections, but only in foreign elements (inlined SVG and MathML elements).
- SGML elements may be declared to have a CDATA content model, in which case all content until the appropriate closing tag is to be parsed as character data, where character references are not decoded.
CDATA sections contain only literal text
Many people are familiar with CDATA sections, but it took me far longer to understand them than my intuition led on. They are the vestige of SGML “marked regions” which tell the parser to handle a specific range of bytes in a special way. The CDATA section is one of those, which tells the parser to completely turn off until it reaches ]]>.
It had other marked sections, however, which served different purposes.
<em>doem> exist as normal.]]>
The IGNORE and INCLUDE sections may seem strange, since SGML already has comments, and INCLUDE effectively does nothing, but the sections can be marked by replaced entities, making for conditional inclusion which can be overwritten via command-line arguments when invoking the SGML parser.
...<aside>Add `-Dreview-only=INCLUDE` when building drafts.This note won’t appear otherwise.aside>]]>
XML only retained CDATA sections from SGML, while HTML never included them. They are useful because they are so easy to parse. All characters inside of them are to be treated as literal text, up until the first occurrence of the terminating ]]>. Unlike elements, the marked sections do not nest.
There are no CDATA sections in HTML
The Internet is full of discussions about the use of CDATA sections in HTML, but there are no such things, mostly. HTML itself is an amalgam of pure HTML and embedded SVG and MathML. Content inside of those embedded SVG and MathML elements is parsed differently, and within this “foreign content” there are CDATA section nodes.
When something which look like a CDATA section appears in an HTML document, it’s transformed into a “bogus” HTML comment and considered a snippet of malformed markup. To make things more confusing, the parsing rules differ inside an HTML document for these regions depending on whether they are found within HTML elements or foreign elements.
- When a real CDATA section appears within SVG and MathML, it parses as in XML or SGML — everything is literal text until the nearest
]]>. - When a malformed CDATA look-alike appears in an HTML element, it gets special treatment — the parser only turns off until the nearest
>. This means that these sections end even without a closing]]>, and when they do, all of their contained content disappears from the page.
That small difference confuses naïve parsers and is a regular source of bugs.
<div>div><svg><text><none> here either.]]>text>svg><div><em>areem> tags in here]]>div> the section ends here ╯ ╰ start of a real end tagThe following is the equivalent markup to the third line.<div>areem> tags in here]]>div>
SGML contains CDATA regions outside of marked CDATA sections
SGML made it possible to define more kinds of content than XML does for a given element. For example, an element in SGML can be declared to have a CDATA content model, in which case the element itself behaves like a CDATA section. All characters after the opening tag are treated as literal text until the parser finds the nearest appropriate end tag3. XML rejected this ability because it increases the complexity of the parser and requires that every document also contains a full DTD when parsing. For example, if an element were declared to have CDATA content, then a would represent that literal string; on the other hand, if it were declared like any other normal element, it would have three children: “a ”, the b”.
...<verbatim>There are <no> tags in here, because this is CDATA,but you wouldn’t know without reading the DTD,overcomplicating the demands on the parser.verbatim>
These kinds of elements do exist in HTML, though a few were modified when HTML5 was standardized in 2008. Inside of the elements, the parser essentially turns off, which makes them easy to parse and can help avoid the need to extensively escape content. These elements are, of course,