Your support for our advertisers helps cover the cost of hosting, research, and maintenance of this FAQ
All white-space, including linebreaks (Mac CR, Win CR/LF, Unix LF), TAB characters, and normal spaces, even between ‘structural’ elements where no text can ever appear, is passed by the parser unchanged to the application (browser, formatter, viewer, converter, etc). The parser identifies the context in which the white-space was found (Element Content, Character Data Content, or Mixed Content), if this information is available, eg from a DTD or Schema. This means it is the application's responsibility to decide what to do with such space, not the parser's.
This is one of the few really radical changes from SGML, where all white-space in element content was discarded by the parser before it got anywhere near the application. See Why? below for why.
There are two different types of white-space:
insignificant white-space (discardable white-space) which occurs between structural elements in element content. This is space which occurs where only other elements are allowed, where text never occurs. It is usually inserted automatically by an editor or manually by an author to help with the visual clarity of the markup, and often has nothing to do with spacing you see when the document is processed or formatted. In XML, this space will get passed to the application (in SGML it got suppressed, which is why you can put all that extra space in old-style HTML documents and not worry about it);
significant white-space which occurs inside elements which can contain only text (Character Data Content, like a HTML title) or text and markup mixed together (Mixed Content, as in normal paragraphs). In XML, this space will still get passed to the application exactly as under SGML.
In both cases, it is the application's responsibility to handle the space correctly (XSLT2, for example, provides a strip-space instruction to specify how to handle it). The parser must therefore inform the application that white-space has occurred in element content, if it can detect it, so that it can be discarded. (Users of SGML will recognise that this information is not in the ESIS, but it is in the Grove.)
<chapter> <title> My title for Chapter 1. </title> <para> text </para> </chapter>
In the example above, the application will receive all the pretty-printing linebreaks, TABs, and spaces between the elements as well as those embedded in the chapter title. It is the function of the application, not the parser, to decide which type of white-space to discard and which to retain. Many XML applications have configurable options to allow programmers or users to control how such white-space is handled.
Peter Flynn writes:
In SGML, a DTD is compulsory, always. A parser therefore always knows in advance whether white-space has occurred in Element Content (and can therefore be discarded) or in Mixed Content or Character Data Content (where it must be preserved). XML allows processing without a DTD or Schema, where it may be impossible to tell whether space should be discarded or not, so the general rule was imposed that all white-space must be reported to the application.