- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Thu, 12 Sep 2013 18:52:38 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>, Erik Arvidsson <arv@chromium.org>
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. > 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. 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. - R. Niwa
Received on Friday, 13 September 2013 01:53:04 UTC