- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Fri, 13 Mar 2015 12:53:14 -0400
- To: public-html@w3.org
On 3/13/15 12:01 PM, Andrea Rendine wrote:
> From the W3 spec (all versions, for what I remember), the rules for
> parsing documents in <iframe@srcdoc> are as follows:
Those aren't the rules for parsing it. Those are the author conformance
requirements to have a document considered to be valid (X)HTML.
The rules for parsing in http://www.w3.org/TR/2014/REC-html5-20141028/
are defined at
http://www.w3.org/TR/2014/REC-html5-20141028/embedded-content-0.html#process-the-iframe-attributes
and say the following:
If the srcdoc attribute is specified
Navigate the element's child browsing context to a resource
whose Content-Type is text/html, whose URL is about:srcdoc,
and whose data consists of the value of the attribute. The
resulting Document must be considered an iframe srcdoc document.
The content-type is text/html, so the HTML parser is used, period.
> 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
...
> It's also a valid XML document
Yep.
> 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, as Chrome
> currently does, thus ignoring self-closing elements and adding implied
> ones.
I assume you meant "parsing", not "serialization"? If so, then this is
what the spec says to do, yes.
-Boris
Received on Friday, 13 March 2015 16:53:45 UTC