[webkit-dev] Shadow DOM API (first iteration) ready for landing
dominicc at chromium.org
Tue Jun 28 23:33:03 PDT 2011
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:
>>> 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.
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
> Element.webkitPseudo // not sure what this is -- showing my ignorance
"…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
> window.WebKitShadowTreeConstructor // all trees begin at a root, right?
> window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree
For uniformity we were going to also make documents tree scopes. This
makes things simpler for script because every element, text node, etc.
will be in a tree scope (a document or a shadow root.)
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev