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

[Dominic Cooney]

On Wed, Jun 29, 2011 at 7:35 PM, 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.
>

I think webkitShadowRoot makes sense—it is precise, the parallelism with the
constructor name makes sense, and the reflexive shadowHost/shadowRoot is
nice.


> 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
> >
>

These are good questions; Dimitri is a better person to answer them than me.
On the security and isolation use case:

I take the point about exposing shadowRoot running counter to using shadow
DOM as a security boundary. I’m skeptical about that particular use case. I
think isolation should be supported by something that puts less emphasis on
presentation and is more closely related to the isolation boundary web pages
have today (ie iframes.) Easier isolation is appealing, but feels like a
pork-barrel amendment to XBL use cases. I have been and am going to keep
arguing against it in other venues.


> 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.
>

Dominic

Regards,
> Maciej
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110629/22facfa6/attachment.html>