Hi Sam, On Thu, Jun 30, 2011 at 3:50 AM, Sam Weinig <wei...@apple.com> wrote:
> 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. XBL2 introduces complexities we didn't see the need to accommodate as the use cases differ (see below). Instead of saying "lets just do XBL2", it would help to understand what properties it has that you think are valuable -- other than being "out there" for a long time, since that's not actually of any value to web developers. In trying to come up with a model that satisfies the needs of web developers who are trying to build components, we've found that many of the concepts XBL2 embodies can be handled orthogonally. For instance, data binding can happen independently of the XBL concept of "bindings" (see the MDV experiments), as can the templating language. These systems have power to handle expanded, important use cases when decouples from XBL, and at a minimum are more easily and clearly understood when presented in a way that composes them instead of bundling them. > 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? We observe that web developers are attempting to use DOM in both structural ("semantic" or "component-oriented") and visual ways inside the same document. 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. - 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. The lack of a view-DOM axis for components means that implementation and interface must always bleed into each other. - CSS rules have over-broad application as a result of specificity, and having some mechanism for targeting CSS to "just my component" would enable developers to write more terse, less unintentionally over-specific rules that are easier to maintain and integrate. - Building custom components without platform support leads to a duplication of infrastructure between toolkits, slowing apps unnecessarily. - Decoration is the exceptional case, not the base-case, and is currently handled in script with utilities like querySelectorAll(). This appears to be workable and explicit system support isn't justified at this point. That's not exhaustive, and I can elaborate with examples if you prefer. I look forward to understanding your perspective better. > > - 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 mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev