Anne van Kesteren

The case for XML5

My XML5 idea is over twelve years old now. I still like it as web developers keep running into problems with text/html:

• Cannot arbitrarily nest elements. E.g., there is no way to create a custom element that takes the place of the td element. There is also no way to create a custom element that contains certain HTML elements, such as the tr element. (See webcomponents #113 for more.)
• Cannot have custom elements start tags that are marked as self-closing. I.e., custom elements always require an explicit end tag. (See webcomponents #624 for more.)
• Cannot introduce a serialization of ShadowRoot nodes to enable server-side rendering. (See dom #510 for more.)
• Any change made to the parser can and is likely to impact the parsing of existing documents as every byte stream is converted to a tree. This has severe compatibility and security implications that cannot be underestimated.

XML in browsers has much less of a compatibility footprint. Coupled with XML not always returning a tree for a given byte stream making backwards compatible (in the sense that old well-formed documents parse the same way) extensions to it is possible. There is a chance for it to ossify like text/html though, so perhaps XML5 ought to be amended somewhat to leave room for future changes.

(Another alternative is a new kind of format to express node trees, but then we have at least three problems.)