On Mon, Jul 1, 2013 at 1:20 AM, Alexandre Morgaut <[email protected]> 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
