Re: Fwd: @srcdoc content parsing in XHTML documents

I missed the point about "proper" rules for parsing. Thank you! Now it's
clear and I understand why HTML "completion" is enabled.

2015-03-13 17:53 GMT+01:00 Boris Zbarsky <bzbarsky@mit.edu>:

> 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
>
>