[webkit-dev] Shadow DOM API (first iteration) ready for landing

[Maciej Stachowiak]

On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:

> On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>> 
>> On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
>> 
>>> On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen <ggaren at apple.com> wrote:
>>>> Hi Dmitri.
>>>> 
>>>>> Since this is an experimental API, here are the actual API names we want to use:
>>>>> 
>>>>> Element.webkitShadow
>>>>> Element.webkitPseudo
>>>>> document.webkitCreateShadow()
>>>>> window.WebKitShadowRootConstructor
>>>>> window.WebKitTreeScopeConstructor
>>>> 
>> 
>>>> Even though we've been using "shadow" as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of "shadow" on the web, which is a color radiating around a visual element.
>>> 
>>> I sympathize and agree that there's a naming collision, but I think
>>> the train has left the station on this one. "Shadow tree" and "shadow
>>> content" are terms that have been used pretty much universally to
>>> describe this construct, from XBL/XUL and XBL2 to SVG. I don't think
>>> we need to invent a new name for it.
>> 
>> Fair enough.
>> 
>> How about using "shadow tree" or "shadow content" consistently instead of just "shadow"? I can imagine "webkitShadow" meaning a lot of different things. "webkitShadowTree" or "webkitShadowContent" seems clearer.
>> 
>> Element.webkitShadowTree
> 
> I agree that just "shadow" could be confused with CSS shadows,
> although those are boxShadow and textShadow, so maybe just shadow is
> OK from a grepping point of view.
> 
> shadow*Tree* doesn’t feel quite right to me; consider
> shadowTree.firstChild? An element has a firstChild; a tree has lots of
> nodes.
> 
>> Element.webkitPseudo // not sure what this is -- showing my ignorance
>> document.webkitCreateShadowTree()
> 
> "…Tree" could be confusing because the object being created is just
> the container; it starts out empty. To me, "tree" and "content" refer
> to the whole shadow subtree, and the thing being created here is more
> specific.

Calling it "shadow tree" or "shadow content" may be imprecise, but surely calling it "shadow" is outright inaccurate. Consider how you'd complete this sentence:

I'd use the Element.webkitShadow API to get the ______ for that element.

I think I'd fill in that blank with "shadow tree" or "shadow DOM". I certainly wouldn't fill it in with "shadow". It sounds like your discussion leans in the direction of "shadow container" or maybe "shadow root". In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense.

Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html

In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. 

Is there a record of the rationale for this rather different direction?  Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document (<http://dglazkov.github.com/component-model/dom.html>) doesn't really explain the reasons . I also found a list of use cases: <http://wiki.whatwg.org/wiki/Component_Model_Use_Cases>. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: <http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation>

I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so.

Regards,
Maciej





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110629/4cf1587e/attachment.html>