- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 1 Jul 2013 17:41:58 -0700
- To: Alexandre Morgaut <Alexandre.Morgaut@4d.com>
- Cc: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>
On Mon, Jul 1, 2013 at 1:20 AM, Alexandre Morgaut <Alexandre.Morgaut@4d.com> wrote: > First, Beside the already mentioned good arguments, I'd says that even for consistency purpose those DOM "get" methods should be available on DocumentFragment. > > I mean, that's easy to think about libs / frameworks / devtools, public or internal, providing methods expecting a Document as parameter coming from different frames, iframes, tabs, windows. Probability is very high that such method expect methods as getElementById() or getElementsByTagName(). It would be sad to have a new DocumentFragment Interface and not being able to use them with such existing tools. > > > > Actually all this make me bring back a previous discussion about IDs as property names > > I've been horrified in the past (an I'm still) to discover more and more User Agents binding a references to elements with an "id" or a "name" directly to the global object: > http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0000.html > > This turned out, as Kyle Huey mentioned it, to even be defined in HTML5: > http://www.whatwg.org/specs/web-apps/current-work/#dom-window-nameditem Yup. We in mozilla tried to get it removed. But Ian wouldn't remove it until all other vendors comitted to removing it from their implementation. And other vendors didn't respond until we gave up due to too much page breakage. I would say mozilla is still ok with removing this support from non-quirks pages, if you can get enough other vendors to commit to doing it too. It's a battle we lost fighting it on our own. / Jonas
Received on Tuesday, 2 July 2013 00:42:51 UTC