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

[Dimitri Glazkov]

On Wed, Jun 29, 2011 at 6:49 AM, Dominic Cooney <dominicc at chromium.org> wrote:
>
>
> 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.

Right -- we discussed this on public-webapps a while back:
http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html.

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

XBL2 is an awesome spec, and we borrow from it as much as can (in
fact, most of style/event plumbing follows the spec pretty precisely),
but in trying to tackle an immense problem space, it's gotten to the
point where it's got too many knobs. We are trying to build this from
ground up, starting with our own plumbing, and arrive at the proper
API set by iteratively exposing small, carefully selected surfaces and
keeping a tight feedback loop with Web developers.

Through this process, we will write with the next iteration of the XBL2 spec.

Hope this helps,

:DG<

>
>
> Dominic
>>
>> Regards,
>> Maciej
>>
>>
>>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>