W3C home > Mailing lists > Public > public-html@w3.org > March 2015

Re: Fwd: @srcdoc content parsing in XHTML documents

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Fri, 13 Mar 2015 12:53:14 -0400
Message-ID: <550315FA.50400@mit.edu>
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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:46:12 UTC