W3C

HTML templates and XML

There’s been some discussion recently about a new HTMl facility that provides reusable content: stuff that can appear in a Web page multiple times. It’s a facility similar to XInclude in some ways, except more limited in scope.

The template element is treated specially by the parser in a Web browser when it creates a DOM tree: it’s hidden and not part of the regular DOM. This means that normal DOM JavaScript methods won’t find the content if they traverse the tree, getElementsByID won’t find elements in templates, and so on.

Similarly, if you use XPath or XSLT in the browser, the template element’s contents will be invisible.

The question was asked, is this OK for XML?

The answer, of course, is yes, it’s perfectly fine. The application can construct a data model from XML in any way it likes. XPath and XSLT in the browser operate on the DOM tree, so if something isn’t in the DOm they won’t see it.

Outside of a Web browser, template is just a normal element and XML systems have no reason to treat it specially. This is actually what you need, so that you can search for templates on your Web server.

5 thoughts on “HTML templates and XML

  1. Could you please give an example? I cannot see why XSLT should not manage every element in the XML source when invoked with a processing-instruction.

    XSLT is indeed useful for changing potentially anything, such as, why not, adding/deleting/modifying templates?

    For me, it is more problematic for the resulting tree because the XSLT engines within browsers seem to directly construct the DOM tree (for debuggers, the execution time for the XSLT stylesheet is included in the HTML loading time!).

    1. Alain,

      Currently the XSLT engine in the Web browser does not get to see the XML source at all, but instead operates on the DOM directly; it also does not write out XML but instead returns DOM nodes. This is why, for example, disable-output-escaping is not available.

      If the template is not part of the DOM tree then XPath and XSLT can’t access it.

      I agree that this sounds inconvenient. An approach worth investigating might be to enable calling a JavaScript function from XSLT that returned an HTML template. I don’t think this part of the design is yet written in stone. The purpose of the blog entry was to say it’s not inherently breaking XML, XPath or XSLT.

      A similar issue is that you can’t access computed CSS properties or other parts of the DOM in a Web browser that are not part of the the document tree. There have been proposals to change this (e.g. see Mike Kay’s work at Saxonica on Saxon Client Edition) but today such proposals do not have the attention of Web browser programmers. But we can add access later without breaking anything.

      I do agree that it should be possible to create templates in the result of XSLT; I don’t know whether that has been addressed.

      Thanks for commenting!

  2. Peter, the template element is being introduced in HTML 5. Earlier versions of HTML did not have a template element.

Comments are closed.