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

[Dimitri Glazkov]

On Wed, Jun 29, 2011 at 3:35 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> 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?

Also, I'll post on public-webapps as a follow-up to our earlier
discussions and present this API-let as the first step forward.

:DG<