On Wed, Jun 29, 2011 at 3:35 AM, Maciej Stachowiak <m...@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 <gga...@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 <gga...@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< _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
