- From: François REMY <francois.remy.dev@outlook.com>
- Date: Sat, 8 Feb 2014 11:48:16 +0100
- To: "'Tab Atkins Jr.'" <jackalmage@gmail.com>, "'www-style list'" <www-style@w3.org>
I had a quick look at it. A few things there did not match your latest update on Shadow DOM [1] and I would like to understand why. Firstly, I never saw any discussion about the ":ancestor(...)" pseudo-class in the past, which allow selectors inside a shadow DOM to select elements outside the shadow DOM. Wow, I think we are breaking yet another level of encapsulation here in a way I don't like at all. A Shadow DOM should never have an impact on an another element in the visible DOM than the element it's applied on, otherwise I don't need a crystal ball to tell you the "mobile performance" will see a dramatic decrease in bowsers implementing your spec. In all seriousness, can you provide a single "responsible" use case for this? A parent may need to break into the privacy of its children for some good purposes, like providing things that the children cannot or should not provide themselves (after all, a parent own its children in the web model so nothing could really be kept private anyway). The reverse, however, should not be true because, otherwise, "siblings" shadow DOMs may break into each-other privacy and totally make nut the purpose of the Shadow DOM specification. Secondly, why do we need three shadow selectors? Three combinators were currently being discussed: - #a /shadow-descendants combinator (aka the ^hat) which selects all elements in the shadow tree of #a - #a /recursive-shadow-descendants combinator (aka the ^^cat) which selects all elements in a shadow tree contained in #a - #a /content combinator (aka ::content) which selects the elements of the document fragment rendered in lieu of the <content#a> element being selected. The current draft added a /shadow-children selector. I've no problem with that but I note you can already achieve it using "#a /shadow-descendants :top". I think that the names being chosen are not clear at all given we now have four combinators. As a beginner, I would have no clue what "shadow-all" and "shadow-deep" would do differently. [1] http://lists.w3.org/Archives/Public/www-style/2013Nov/0313.html ± -----Message d'origine----- ± De : Tab Atkins Jr. [mailto:jackalmage@gmail.com] ± Envoyé : samedi 8 février 2014 04:24 ± À : www-style list ± Objet : [shadow-styling] First Draft of Shadow DOM Styling uploaded ± ± I've uploaded the first draft of Shadow DOM Styling, the spec I intended to ± write a few weeks ago, to <http://dev.w3.org/csswg/shadow-styling/>. ± ± There are a few bits I haven't filled in yet, because it's late and I don't want to ± work anymore, and I'm sure there are a few holes that aren't even ± mentioned yet. If you notice any, please let me know. ± ± ~TJ
Received on Saturday, 8 February 2014 10:48:45 UTC