On Fri, Mar 27, 2015 at 2:53 AM, Travis Leithead < travis.leithead@microsoft.com> wrote: > Hi folks, > > > > Today’s ShadowDOM model is designed around only adding shadow roots to > element in the ‘light side’. I assume this is intentional, but was hoping > someone could describe why this design was chosen? Or said another way, if > there was an imperative API to _*remove*_ a shadow DOM, would that > symmetry be bad? > > > > In full transparency, I’m thinking about potential solutions for a > simplified shadow dom, > Could you share some background on how we should gauge simplicity? What you have sketched here is less expressive than Shadow DOM (for example, it can't do what the <content> element does.) That's not necessarily good or bad, but it depends on what you're aiming for. > and it occurs to me that it can’t get much simpler than the following: > > · Elements only [ever] have one “shadow side” which is essentially > a secondary child node list. Whenever anything’s in this list the Element > renders that content instead of its “light” children. (Or maybe there’s a > switch to tell the element which side to render: light or dark?) > > · Elements expose this “shadow node list” via APIs that are very > similar to existing node list management, e.g., appendShadowChild(), > insertShadowBefore(), removeShadowChild(), replaceShadowChild(), > shadowChildren[], shadowChildNodes[]. > > · No special Event swizzling, no security boundary, no alternate > script engine, no intermediate shadow root object, etc. This minimalist > approach only provides node ‘hiding’ and potentially an alternate rendering > path. > Along these lines, an ancient debate was whether the boundary of the component was just "inside" the host element or just outside it (so, imagine a 1:1 swap of element for its shadow twin element.) But whether this is simplified or not is a very complex question. > · Another feature could then provide the stronger “component” > boundary, specifically the javascript global scope isolation. This > delineation may more closely match the division we are seeing between the > “React-like” scenarios and more robust component-kitchen-style custom > element deployments. > > > > >
Received on Friday, 27 March 2015 05:42:32 UTC