Re: [whatwg] Why are we merging Document and HTMLDocument again?

On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
> On Sep 13, 2013, at 1:53 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> > 
> > It's not entirely clear to me what the suggestion from Ryosuke is. Is 
> > it to keep getters on HTMLDocument only and expose HTMLDocument only 
> > in browsing contexts created from text/html resources? And use 
> > Document everywhere else and have Document contain all the other 
> > members including (former) SVGDocument members? That setup would make 
> > sense to me anyway.
> 
> My proposal something along that line.

Could you be more precise?


On Fri, 13 Sep 2013, Simon Pieters wrote:
>
> Let's list concrete cases and see what we want to do with each one.
> 
> In a browsing context:
> 
> * text/html document (uses interface "Document" and is an "HTML document")
> * XML document (uses interface "Document" and is an "XML document")
> 
> Not in a browsing context:
> 
> * document.implementation.createDocument() (uses interface "XMLDocument" and
>   is an "XML document")
> * document.implementation.createHTMLDocument() (uses interface "Document" and
>   is an "HTML document")
> * new Document() (uses interface "Document" and is an "XML document")
> * XHR response (uses interface "Document" and is an "XML document", even for
>   text/html if I read the spec correctly)
>
> For instance the createHTMLDocument() case currently supports named 
> getter in Gecko but not in Blink. 
> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2519

The list above would be a good one to start from. What features would you 
want in which cases?


On Fri, 13 Sep 2013, Ryosuke Niwa wrote:
>
> But HTMLDocument also has a bunch of other junk properties like embeds, 
> plugins, scripts, compatMode, bgColor, fgColor, alinkColor, linkColor, 
> vlinkColor, etc… We even have write() and writeln() there!
> 
> I don’t want to start adding all these legacy methods elsewhere.

These aren't all junk. "scripts" for example is a perfectly valid and 
useful API, which it would definitely make sense to use from within an 
HTML fragment inside an SVG document.

write() and open() are only useful in an HTML context, since it bails if 
the Document is an XML one.

Also, the vast majority of the time, a document is the kind of document 
that needs these APIs. There's not really much of an "elsewhere" for them 
to be found in. It's not like having them in XML documents actually 
affects many people, so not having them doesn't actually help any 
appreciable number of people either.

But, I'm certainly open to having a more elaborate scheme where some APIs 
aren't available everywhere if that's what it takes for us to make SVG-in- 
text/html-HTML and HTML-in-XML-SVG be able to generally use the same APIs.


I think the way to move forward with this would be to describe:

 (a) The different categories that you think should behave differently,
 (b) How each category should behave,
 (c) Within each category, what APIs you think should be available (or,
     possibly better, a general rule to decide what API is available and a 
     brief example of how this is applied to a subset of the total API 
     surface -- we can extrapolate from there)

Currently, the spec has an almost trivial answer to this; there's 
basically just the one category except for XMLDocument which is used in 
some edge cases needed for compat.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'