- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 13 Sep 2013 04:15:05 +0000 (UTC)
- To: Ryosuke Niwa <rniwa@apple.com>
- Cc: whatwg <whatwg@whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Erik Arvidsson <arv@chromium.org>
On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > On Sep 12, 2013, at 2:00 PM, Ian Hickson <ian@hixie.ch> wrote: > > On Thu, 12 Sep 2013, Ryosuke Niwa wrote: > >> On Sep 12, 2013, at 11:43 AM, Ian Hickson <ian@hixie.ch> wrote: > >>> > >>> So you also support having a Document descendant that is used for > >>> Documents that have global scopes / browsing contexts / the works, > >>> and one that is used for Documents that don't (e.g. > >>> createDocument(), XHR), where the former has the named getter and > >>> the latter doesn't? > >> > >> I think that's what I'm suggesting except that I'm suggesting to keep > >> calling the former HTMLDocument. > >> > >> As far as I checked, SVGDocument and alike don't have named getter > >> either so I'd rather not introduce it any non-HTML document. > > > > What's an "HTML document" in this world? Something served using > > text/html? Something with a browsing context? Some combination > > thereof? > > I'm not trying to invent anything new here. HTMLDocument as existed > before the merge. Ok, I guess I'm confused then, because earlier you said you agreed with the idea of removing this feature from non-browsing-context Documents, which is a different criteria. > > SVGDocument is supposed to be merged into Document as well. The idea > > is to not have any descendants of Document. The reason is that you can > > have compound documents that need both the SVG and HTML (and MathML > > and FooML) methods. There's no such thing as "non-HTML documents" now. > > Documents can have SVG and HTML and mix it at will. > > That's okay but there's no point in bringing in legacy features like > named property in that new world. What we did is bring SVG into the "old world", so that there's no distinction between these new kinds of documents and HTMLDocuments. So on the contrary, I don't see how else we could do it if we want it to be possible to have HTML and SVG in text/html. > Named properties impos a significant runtime cost, and we'd like to get > rid of them as much as possible. As such, I'm strongly opposed to > supporting it in more places. What are the places you see us as adding this in? Just XML documents? Those are so rare that it doesn't seem to me that it makes much difference one way or the other. (That's not saying I don't want to remove them there either. We could definitely say something like "the set of named properties is empty if the document is not marked as being an "HTML document" (in the DOM Core sense) "or if the document has no browsing context" -- but that seems orthogonal to the original issue of Document vs HTMLDocument vs SVGDocument.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 13 September 2013 04:15:30 UTC