Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Thu, Jun 30, 2011 at 1:21 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Hi Sam! On Wed, Jun 29, 2011 at 7:50 PM, Sam Weinig wei...@apple.com wrote: Hi Dimitri, First of all, nice work on getting to this point! Thanks, it's been a nice, long slog :) It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? I think you're right, more work is needed in getting more consensus on the first step. I am glad this thread generated so much excitement, even if mixed with confusion. As a result, we've taken this thread to public-webapps. Maciej is asking exactly the same questions here: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1387.html Please follow along :) I posted a follow-up on public-webapps: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0975.html Please chime in with your observations, concerns, critiques and cheers. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
From: Alex Russell slightly...@chromium.org We observe that web developers are attempting to use DOM in both structural (semantic or component-oriented) and visual ways inside the same document. I would like to understand what you mean here: can you suggest an example or other place to read? In particular I imagine the DOM as a tree of visual components which can be interpreted in multiple ways, some of which cause the tree to become a graph. I don't understand the split between visual and components. This creates tension and requires unnatural levels of discipline. Notably: - Understanding your DOM as a retained-mode component tree is confounded by the presence of visual nodes in the document. - It's currently impossible to build new components which can be added to the tree in a native way. Instead, systems like Closure, Dojo, YUI, etc. build parallel trees of components in script which manage chunks of visual DOM. Anyone who attempts to script this visual DOM risks blowing up the entire world as ownership becomes confused. By parallel trees of components do you mean logical or conceptual components managed by Closure/Dojo et al rather than DOM? - The parallel trees that these toolkits create are non-interoperable. The low-level bits of these toolkits are generally interoperable to the extent that they agree on DOM, therefore, allowing components to be expressed with a DOM interface would bolster interoperability. - Working with DOM as a visual representation for components is made difficult because of tension between the desire to add structure to enable visual controls and the markup is semantic ideal. This last phrase is the one that really caught my interest, but I don't understand the sentence. How can one work with the DOM as a visual representation without adding structure? How can this be in tension with markup is semantic? By markup is semantic ideal do you mean gee it would be awesome if markup exactly expressed my full-formed, universally understood, perfect Web page which can't possibly exist? It just seems odd to juxtapose a practical thing with something that is impossible. Sorry if my questions are naive. I've worked quite a lot with XBL and now we are planning to get rid of it in our code so I'm puzzled by arguments between two groups who want to improve it (or so that is how I interpret this thread). jjb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton johnjbar...@johnjbarton.com wrote: From: Alex Russell slightly...@chromium.org We observe that web developers are attempting to use DOM in both structural (semantic or component-oriented) and visual ways inside the same document. I would like to understand what you mean here: can you suggest an example or other place to read? In particular I imagine the DOM as a tree of visual components which can be interpreted in multiple ways, some of which cause the tree to become a graph. I don't understand the split between visual and components. This creates tension and requires unnatural levels of discipline. Notably: - Understanding your DOM as a retained-mode component tree is confounded by the presence of visual nodes in the document. - It's currently impossible to build new components which can be added to the tree in a native way. Instead, systems like Closure, Dojo, YUI, etc. build parallel trees of components in script which manage chunks of visual DOM. Anyone who attempts to script this visual DOM risks blowing up the entire world as ownership becomes confused. By parallel trees of components do you mean logical or conceptual components managed by Closure/Dojo et al rather than DOM? Yes. The DOM is semantic instinct leads this reality for large apps to create serious cognitive overhead. In using a new component, you must be aware of (and know the rules for) this parallel tree as well as its relationship to other DOM which, for all intents and purposes, might be just fine for *some* bits of your app. Forms are a great example of this, wherein you want a regular input type=text in one place and a constrained date picker in the next. Mixing and matching these today requires feats of discipline that custom, real DOM components could help alleviate. - The parallel trees that these toolkits create are non-interoperable. The low-level bits of these toolkits are generally interoperable to the extent that they agree on DOM, therefore, allowing components to be expressed with a DOM interface would bolster interoperability. - Working with DOM as a visual representation for components is made difficult because of tension between the desire to add structure to enable visual controls and the markup is semantic ideal. This last phrase is the one that really caught my interest, but I don't understand the sentence. How can one work with the DOM as a visual representation without adding structure? That's exactly the problem. Re-arranging elements visually often requires re-parenting them with respect to ne structure. That structure isn't there to convey meaning in terms of the tree of components, only their layout. Having to wade through this sea of formatting nodes makes working with DOM-as-component-tree less than satisfying. How can this be in tension with markup is semantic? By markup is semantic ideal do you mean gee it would be awesome if markup exactly expressed my full-formed, universally understood, perfect Web page which can't possibly exist? No. It just seems odd to juxtapose a practical thing with something that is impossible. I'm not trying to. I used lower-case s and quotes around semantic to (unsuccessfully) avoid that. Custom components will only ever have local or probabilistic non-local meaning, but my view is that's the best you'll do in any casethe Meta Crap argument, if you will. DOM is confused on many levels, and I'm only trying to explain how the desire to express the relationships between components is currently in tension with the desire to use HTML/CSS/DOM for rapid creation of component view and layout. A shadow or view axis for components can alleviate this tension. Sorry if my questions are naive. I've worked quite a lot with XBL and now we are planning to get rid of it in our code so I'm puzzled by arguments between two groups who want to improve it (or so that is how I interpret this thread). Assume that my position from here on out is this: - XBL and XBL2 contain many good ideas - These ideas may have more leverage as small additions to HTML/CSS/DOM than as a large, coordinated and interdependent spec - Many of the use-cases that XBL and XBL2 handle are not primary in the toolkits that are being used widely on the web today. As far as suitability for inclusion in the web platform goes, I argue that we should pay more attention to common practice than to un-implemented standards. One of the two has a test function for utility, and it isn't the one without users. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On 6/30/2011 8:52 AM, Alex Russell wrote: On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton johnjbar...@johnjbarton.com mailto:johnjbar...@johnjbarton.com wrote: From: Alex Russell slightly...@chromium.org mailto:slightly...@chromium.org How can one work with the DOM as a visual representation without adding structure? That's exactly the problem. Re-arranging elements visually often requires re-parenting them with respect to ne structure. That structure isn't there to convey meaning in terms of the tree of components, only their layout. Having to wade through this sea of formatting nodes makes working with DOM-as-component-tree less than satisfying. Is this a problem of dev-tools, JavaScript language/infrastructure, or DOM? If we up our game in dev-tools can key part of this problem be solved? Here I am thinking about tools like the firebug-dojo-extension which takes a step towards giving the dojo developer a dojo view of the Web app. This does not solve toolkit interop to be sure. But isn't that a JS problem? jQuery and dojo are hard to mix but I'm having an hard time imagining how any DOM work solves that. It could make jQuery and dojo obsolete and that would solve interop. * Many of the use-cases that XBL and XBL2 handle are not primary in the toolkits that are being used widely on the web today. As far as suitability for inclusion in the web platform goes, I argue that we should pay more attention to common practice than to un-implemented standards. One of the two has a test function for utility, and it isn't the one without users. This seems like a reasonable approach, but I would imagine that these points would lead you towards meta-element constructions like XBL, ie to allow dojo widgets to be expressed in markup. But you seem to be arguing against that approach. The info at: http://dglazkov.github.com/component-model/dom.html is pretty puzzling to me at least. Perhaps there is another explanation that shows how the secondary tree created by the shadow DOM works to solve the problems you outline? I appreciate your patience, jjb ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
Hi Sam! On Wed, Jun 29, 2011 at 7:50 PM, Sam Weinig wei...@apple.com wrote: Hi Dimitri, First of all, nice work on getting to this point! Thanks, it's been a nice, long slog :) It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? I think you're right, more work is needed in getting more consensus on the first step. I am glad this thread generated so much excitement, even if mixed with confusion. As a result, we've taken this thread to public-webapps. Maciej is asking exactly the same questions here: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1387.html Please follow along :) :DG - Sam On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote: Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html 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 We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
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. 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.) Dominic Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
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? 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 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 7:35 PM, 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. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 6:49 AM, Dominic Cooney domin...@chromium.org wrote: On Wed, Jun 29, 2011 at 7:35 PM, 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. 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
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 5:01 AM, 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. This falls into the broad bucket of things that webdevs are exposed to that tend to be unnecessarily long (querySelectorAll vs. query) for no good reason. Meaning comes with use. My bias as a webdev is to want the shortest thing that means something close. In particular, since you'll be scripting through this property a LOT, having it be short is a serious win. With those preferences, is there something we can do that's better *and* shorter than shadow? Element.webkitShadowTree Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
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
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
Hi Dimitri, First of all, nice work on getting to this point! It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? - Sam On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote: Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html 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 We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Shadow DOM API (first iteration) ready for landing
Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html 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 We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
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. Perhaps component or subtree or disconnectedTree would be a better API name. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
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 Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
