- From: Andrea Rendine <master.skywalker.88@gmail.com>
- Date: Tue, 10 Mar 2015 20:32:22 +0100
- To: public-html-comments@w3.org
- Message-ID: <CAGxST9kTumYAFFiUR+xhSBPrmfO0P9pZd6aEEPAn2M2e+Ozp1Q@mail.gmail.com>
>From the W3 spec (all versions, for what I remember), the rules for parsing documents in <iframe@srcdoc> are as follows: "For iframe elements in HTML documents, the srcdoc attribute, if present, must have a value using the HTML syntax that consists of the following syntactic components, in the given order: ..." followed by a list comprehensive of HTML elements, some of which can be omitted when implied. Then: "For iframe elements in XML documents, the srcdoc attribute, if present, must have a value that matches the production labeled document in the XML specification." Which, in short terms, means that (once unescaped) it must consist of XML elements properly nested, with one element accomplishing the role of "root" element (i.e. with no parents and no siblings). Now, this is my question: consider a document represented by the following markup (properly escaped): <p>This is an <abbr>HTML</abbr> paragraph with <b>nested <i>elements</i></b></p> This is very simple, of course. It matches the requirements for srcdoc-based documents in HTML, as it represents a whole page (<html>,<head>,<title> and <body> have all implied start and end tags). It's also a valid XML document because its elements are properly nested and it has a root <p> element. However, of course it isn't an XHTML document, as in XHTML no tags can be implied. It's not even expected to be rendered as an (X)HTML document, as nothing says that it has to be treated as such. How are UAs supposed to treat a value like the one proposed above? Apart from current interpretations (FF a couple of versions ago implemented HTML serialisation on iframe elements in XHTML documents), should (or must) the document be implicitly completed? If not, is the expected rendering the same of HTML elements? Thanks in advance. Andrea
Received on Tuesday, 10 March 2015 19:32:48 UTC