I forgot that old Presto 12.x also support XMLDocument interface and XMLDocument.load() method.

On the XMLDocument issue--the idea is not so much which constructor is manifest by the returned document, but what the "internal" document nature is (and this is not super-obvious)--whether it (and it's many relevant APIs contingent on this behavior--not just in this spec) act like an XML document or an HTML document.

Historically, there was only a "uni-document"--the same document interface used for all kinds of documents. This simplified things. That is largely how it works in browsers today, though they will expose an HTMLDocument and XMLDocument interface for web compat.

I'll need to do a bit of research to see what instance mapping the parseFromString's document should be associated with.

== 

Regarding text.serializeAsCDATA, this new feature was dropped from this spec in order to move it along to REC faster. It could be included, but would be marked 'at risk' and removed eventually anyway if two implementations did not support it.

It may be a candidate for the next edition of this spec if there is still implementation interest (for it or for a second edition of DOM P&S), and I'd be happy to re-add it.

Ok, thx for the clarification.

Regarding parseFromString() something else interested me:

"text/html" 
[The scripting flag must be set to "disabled".]

This apply only for this type or should be apply to more?


And origin, don't see any info about it for new document. 
In DOM we have some step:
http://dom.spec.whatwg.org/#dom-domimplementation-createdocument
http://dom.spec.whatwg.org/#dom-domimplementation-createhtmldocument

This bug exist in WHATWG section:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15916

> Regarding parseFromString() something else interested me:
> 
> "text/html" 
> [The scripting flag must be set to "disabled".]
> 
> This apply only for this type or should be apply to more?

The "scripting flag" is a concept that only makes sense for the HTML Parser. Thus, I think this is correct. The XML namespace-aware parser processing XHTML will presumably also not execute the script--but here I am less sure, and will need to check. (Most browsers route the elements created by the XML Parser that are in the HTML namespace through the same underlying processing code that handles HTML elements, so this wouldn't surprise me.) If this turns out to be true I may need to invent something to indicate that this same flag should be set for XHTML script elements...


> And origin, don't see any info about it for new document. 
> In DOM we have some step:
> http://dom.spec.whatwg.org/#dom-domimplementation-createdocument
> http://dom.spec.whatwg.org/#dom-domimplementation-createhtmldocument
> 
> This bug exist in WHATWG section:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15916

The spec mentions that:
   "Additionally, the document must have a URL value equal to the URL of the active document, a location value of null."

So its "origin" as I think I understand it, is the same as the main document. I may need to clarify this though??

> The "scripting flag" is a concept that only makes sense for the HTML Parser.
> Thus, I think this is correct. The XML namespace-aware parser processing
> XHTML will presumably also not execute the script--but here I am less sure,
> and will need to check. (Most browsers route the elements created by the XML
> Parser that are in the HTML namespace through the same underlying processing
> code that handles HTML elements, so this wouldn't surprise me.) If this
> turns out to be true I may need to invent something to indicate that this
> same flag should be set for XHTML script elements...

In other cases (variety of XML) this flag (or behaviour) fit for XHTML script elements (when use correct namespace).

>The spec mentions that:
>   "Additionally, the document must have a URL value equal to the URL of the >active document, a location value of null."

> So its "origin" as I think I understand it, is the same as the main
> document. I may need to clarify this though??
 
Yuuup, in fact it should be enough, my mistake.

(In reply to Travis Leithead [MSFT] from comment #2)
> I'll need to do a bit of research to see what instance mapping the
> parseFromString's document should be associated with.

Oh, I just noticed that you did the research for me in Comment 0. Oh well, I confirmed it :-)

I did some digging and found this IRC log on WHATWG that seemed related:
http://krijnhoetmer.nl/irc-logs/whatwg/20140313#l-293

Which led me to: https://bugzilla.mozilla.org/show_bug.cgi?id=983090

From what I can piece together, the change to use a vanilla Document object is to avoid having to support the .load API for the documents created by parseFromString. This may be an interim requirement if Mozilla pulls support for .load, after which it won't matter quite so much if the XMLDocument constructor is used. Regardless, there's no harm in the current text, and I think it was considered the best option going forward, so I prefer to stick with it.

(In reply to spiritRKS1910 from comment #5)
> > The "scripting flag" is a concept that only makes sense for the HTML Parser.
> > Thus, I think this is correct. The XML namespace-aware parser processing
> > XHTML will presumably also not execute the script--but here I am less sure,
> > and will need to check. (Most browsers route the elements created by the XML
> > Parser that are in the HTML namespace through the same underlying processing
> > code that handles HTML elements, so this wouldn't surprise me.) If this
> > turns out to be true I may need to invent something to indicate that this
> > same flag should be set for XHTML script elements...
> 
> In other cases (variety of XML) this flag (or behaviour) fit for XHTML
> script elements (when use correct namespace).

I will add a note to the spec to clarify this point.

Note added.

https://dvcs.w3.org/hg/innerhtml/rev/8dbd8dbdefdc

Now everything is clear. I have nothing to add.