Re: Support getElementById and other methods of ShadowRoot on DocumentFragment

On Fri, Jun 29, 2012 at 2:06 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 6/29/12 4:53 PM, Ryosuke Niwa wrote:
>
>> The last time I checked, WebKit had some architectural constraint that
>> prevented us from executing CSS queries on a detached frame.
>>
>
> Detached frame, or detached DOM tree?  That is, is the problem that a
> DocumentFragment is not in a document (and would you have the same problem
> with an Element not in a document), or is this only a problem in cases when
> the ownerDocument has a null defaultView?


Any detached DOM tree as I understand it.

On Fri, Jun 29, 2012 at 2:13 PM, Olli Pettay <Olli.Pettay@helsinki.fi>
 wrote:

> On 06/29/2012 09:47 PM, Ryosuke Niwa wrote:
>
>> On Fri, Jun 29, 2012 at 11:22 AM, Elliott Sprehn <esprehn@gmail.com
>>  <mailto:esprehn@gmail.com>> wrote:
>>     On Fri, Jun 29, 2012 at 11:18 AM, Ryosuke Niwa <rniwa@webkit.org
>>  <mailto:rniwa@webkit.org>> wrote:
>>
>>         Are you suggesting that getElementsBy* on ShadowRoot will return
>> a static node list? If so, that's inconsistent with the existing ones. If
>>         not, then getElementsBy* return HTMLCollection, and I'm strongly
>> opposed to adding any new method that returns live node list or
>>         HTMLCollection. They impose significant performance burdens and
>> design constraints on all DOM mutations
>>
>>     That's not what the spec says:
>>
>>         *Must* behave exactly like document.getElementsByTagName <
>> http://www.w3.org/TR/domcore/**#dom-document-**getelementsbytagname<http://www.w3.org/TR/domcore/#dom-document-getelementsbytagname>>,
>> except scoped
>>         <https://dvcs.w3.org/hg/**webcomponents/raw-file/tip/**
>> spec/shadow/index.html#dfn-**scoping-constraints<https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-scoping-constraints>>
>> to the shadow DOM subtree.
>>
>>     So it should already return a non-static NodeList. It doesn't make
>> sense to have methods with the exact same names and different behaviors on
>>     Document vs ShadowRoot.
>>
>>
>> Then I'm opposed to adding this on DocumentFragment. Like mutation
>> events, live node lists and HTMLCollection are two of the worst APIs.
>>
> Don't compare mutation events and live node lists please ;)
>
> I don't know what is so bad with live node lists (well, making the
> implementation fast can be a bit tricky).


They impose a lot of cost on DOM mutation code, and behave pathologically
bad if the live-ness is used. Any iteration over a live node list that
modifies the subtree in a relevant way (i.e. adds/removes a node) will have
Θ(n^2) behavior in WebKit.

We've got rid of mutation events in shadow DOM in the favor of mutation
>> observers. We should do the same so that we don't expose any live node
>> lists or HTMLCollection inside the shadow DOM. Over time, authors will
>> learn to use methods that return static node lists.
>>
>
> AFAIK, we're not going to remove live node lists from normal DOM, so
> methods which return live node lists in normal DOM,
> should return similar thing also on shadow DOM.


It is relevant because we're talking about whether to expose these methods
on shadow DOM or not. Surely, we have lots of APIs that return
HTMLCollections and live node lists but it's for historical reasons. We
shouldn't be adding more methods that return a live node list or a
HTMLCollection.

- Ryosuke