Mail list Etiquette [Was: Re: Shadow tree style isolation primitive]
[ Apologies for cross-posting ] On 2/4/15 6:56 PM, Ryosuke Niwa wrote: That sounds rather demeaning and insulting [1]. public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant. Given this thread resulted in some heated replies, I'd like to remind everyone of WebApps' e-mail list etiquette policy: [[ https://www.w3.org/2008/webapps/wiki/WorkMode#Mail_List_Policy.2C_Usage.2C_Etiquette.2C_etc. *WebApps' members appreciate and encourage frank technical discussions on our mail lists but all discussions must be done in a respectful manner. Please note this respect requirement is codified in the Process Document via the following participation criteria Social competence in one's role http://www.w3.org/2005/10/Process-20051014/policies.html#ParticipationCriteria. Additionally, seeCode of Ethics and Professional Conduct http://www.w3.org/Consortium/cepc/and if you did not attend/Kindergarten/, we expect our list participants to adhere to the basic principles inAll I Really Need To Know I Learned In Kindergarten http://www.peace.ca/kindergarten.htm. *]] Please focus on technical comments and always be respectful. -Thanks, ArtB [1] http://www.w3.org/Consortium/cepc/ - R. Niwa
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 10:11 AM, Dimitri Glazkov dglaz...@google.com wrote: ... Hanging but?! Oh lordy. Oooh, let me turn this into a contemplative sidebar opportunity. Shadow DOM and Web Components seem to have what I call the Unicorn Syndrome. There's a set of specs that works, proven by at least one browser implementation and the use in the wild. It's got warts (compromises) and some of those warts are quite ugly. Those warts weren't there in the beginning -- they are a result of a hard, multi-year slog of trying to make a complete system that doesn't fall over in edge cases, and compromising. A lot. So there's a temptation to make new proposals (unicorns) that are wart-free, but incomplete or not well-thought-out. Don't get me wrong. I like new ideas. What I would like to avoid is judging a workhorse against a unicorn. Armed with your imagination, unicorn will always win. I shouldn't have sent this. It was uncool of me. My bad. Please accept my apologies. :DG
Re: Shadow tree style isolation primitive
On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM has changed over time from do everything possible, make things awesome to explain the platform to the current enable easier composition. So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :) Personally I think composition piece itself doesn't legitimate the complexity of shadow DOM. Though, it is not clear what composition means to different people. Is the need for insertion points part of composition? In my mind it might not be. It is part of the stronger encapsulation where one has hidden DOM between a parent node and a child node. Is event retargeting part of composition? It might not, if composition was to deal with nodes which are all in document (and if nodes part of the composition were in document, we wouldn't have all the is-in-document issues). And so on. That said, I think we should aim for something stronger than just enabling easier composition. The end goal could go as far as let pages to implement their own form controls. And to make that all less error prone for the users of such components requires encapsulation. So, start with composition but keep the requirements for the proper encapsulation in mind by not introducing syntaxes or APIs which might make implementing encapsulation harder. Are there cases where encapsulation and composition contradicts? I guess that depends on the definition of those both. -Olli
Re: Shadow tree style isolation primitive
On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM has changed over time from do everything possible, make things awesome to explain the platform to the current enable easier composition. So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :) I appreciate the affirmation, the kindness, and the smiley. Though since this is public forum, I have to add a few things: 1) The original Component Model (as it was known back then) charter from 2011 clearly includes easier composition as one of its main goals, as illustrated by https://wiki.whatwg.org/wiki/Component_Model https://wiki.whatwg.org/wiki/Component_Model and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we definitively solved at huge chunk of these problems. For example, Polymer is a clear illustration that https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager is nearly 100% solved and there are now examples in the wild of most of these use cases solved with Web Components. There's still lots of work to do, of course. But 2) Refining terminology and the way to describe problem space is a natural part of working on solutions for that problem space. Calling it marketing is just not helpful. I agree his wording was a bit harsh. But let me try to explain where Olli is coming from because I do sympathize with what he's saying here. For example, at the WebApps F2F meeting last spring, you mentioned that explaining builtin element is a goal of web components. Yet, the web components as spec'ed today doesn't explain any builtin elements due to its lack of strong encapsulation. And insertion points, which is a huge source of complexity, is only needed to explain details and summary elements. The ability to attach multiple generations of shadow DOM to a single host element, which is another source of an enormous complexity, is not required to explain any builtin HTML elements at all as far as I know. So it appears that there is a precedence in adding features to Web components that are not needed for builtin elements but desirable for other use cases. Yet, you (Google representatives as the collective) in the past argued that you didn't want to add support for imperative API for selecting distributed elements because that can't explain builtin elements even though we've listed a few use cases that can't be adequately addressed unless we have an imperative API. So I have a hard time understanding that exactly which use cases and problems you're trying to solve (and have solved) in web components because it seems to drift left and right every time we discuss different issues. Let us not discuss goals and objectives, etc… because they're too abstract at this point. Personally I think composition piece itself doesn't legitimate the complexity of shadow DOM. I accept this as a personal opinion, not a fact. Like I mentioned earlier in the thread, I fully agree with Olli's position here. I don't think I'll be interested in implementing shadow DOM in WebKit at all if the only use case we're solving at first is the layout manager use case. I've done a fair amount of web programming myself, and most recently I've been using Ember.js to write a new UI for our performance dashboard. Granted, I only have ~5000 lines of JS code so it's not nearly as big as Gmail or many other modern Web apps but I've encountered a lot more pressing issues that need to be addressed in the platform than having to soft-ecapsulate DOM and CSS rules. Though, it is not clear what composition means to different people. Is the need for insertion points part of composition? In my mind it might not be. It is part of the stronger encapsulation where one has hidden DOM between a parent node and a child node. For example, this is clearly where you haven't thought through the problem space. Sure, you don't need insertion points for simple hierarchical composition. But as soon as you get to the Layout Manager use case (not to belabor a 4-year old doc), you run into the need for insertion points. Take https://www.polymer-project.org/docs/elements/layout-elements.html https://www.polymer-project.org/docs/elements/layout-elements.html, as examples in the wild. Yet, the web components as currently spec'ed doesn't address other use cases listed. So again, I'd like to remind us all that different participants of the working group care about
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 10:52 AM, Marc Fawzi marc.fa...@gmail.com wrote:
Following this thread because there is real need for what is being
discussed.
However, until that need is satisfied, here is what we're thinking to
achieve style encapsulation, using current-world technologies, and I'm
hoping you would point out any problems you see with doing it this way.
1. We build components that render DOM elements, e.g. via React or
something like that.
2. We write or generate a stylesheet per component and name the .css file
same as component name, and convert it from CSS to a named subtree (e.g.
CSS.componentName.styles: { ... }) in a global JSON structure (build time)
3. The components consume style rules from that data structure at run time
and convert them to inline styles on the elements they render. The inline
styles are injected and rewritten based on component state. We use CSS3
transitions rather than style tweening.
4. For @keyframes, we create a style element in the document and namespace
them like component-name-keyframe-name.
Not using this list as a Stackoverflow substitute. My purpose here is to
show one way of achieving style isolation without Web Components, Shadow
DOM, etc, and figure out whether the web needs anything more than we
already have.
This sounds pretty neat and similar to thing that Christopher Chedeau
presented in his CSS in your JS talk (http://vimeo.com/116209150). I
can't think of a better example of the Web Platform (and CSS in particular)
completely failing the developer. I admire your and Christopher's
desperation and persistence to stay successful within the constraints of
the existing system.
FWIW, with Shadow DOM, you simply don't need any of these build steps or
factorings. Just write your styles in your component.
:DG
Re: Shadow tree style isolation primitive
* Dimitri Glazkov wrote: Shadow DOM and Web Components seem to have what I call the Unicorn Syndrome. There's a set of specs that works, proven by at least one browser implementation and the use in the wild. It's got warts (compromises) and some of those warts are quite ugly. Those warts weren't there in the beginning -- they are a result of a hard, multi-year slog of trying to make a complete system that doesn't fall over in edge cases, and compromising. A lot. So there's a temptation to make new proposals (unicorns) that are wart-free, but incomplete or not well-thought-out. Don't get me wrong. I like new ideas. What I would like to avoid is judging a workhorse against a unicorn. Armed with your imagination, unicorn will always win. There has never been much of a consensus on the problems that need to be solved, so it is not really surprising that a consensus-solution is not forthcoming; instead we have continous scope creep and eternal delays. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/
Re: Shadow tree style isolation primitive
... Hanging but?! Oh lordy. Oooh, let me turn this into a contemplative sidebar opportunity. Shadow DOM and Web Components seem to have what I call the Unicorn Syndrome. There's a set of specs that works, proven by at least one browser implementation and the use in the wild. It's got warts (compromises) and some of those warts are quite ugly. Those warts weren't there in the beginning -- they are a result of a hard, multi-year slog of trying to make a complete system that doesn't fall over in edge cases, and compromising. A lot. Compromise 1. a. A settlement of differences in which each side makes concessions. I don’t remember any of that happening. I guess you mean a different definition of “compromising”? Regards, Maciej
Re: Shadow tree style isolation primitive
On Feb 5, 2015, at 3:51 PM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Feb 5, 2015 at 2:53 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Feb 5, 2015, at 9:41 AM, Dimitri Glazkov dglaz...@google.com mailto:dglaz...@google.com wrote: On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM has changed over time from do everything possible, make things awesome to explain the platform to the current enable easier composition. So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :) I appreciate the affirmation, the kindness, and the smiley. Though since this is public forum, I have to add a few things: 1) The original Component Model (as it was known back then) charter from 2011 clearly includes easier composition as one of its main goals, as illustrated by https://wiki.whatwg.org/wiki/Component_Model https://wiki.whatwg.org/wiki/Component_Model and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we definitively solved at huge chunk of these problems. For example, Polymer is a clear illustration that https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager is nearly 100% solved and there are now examples in the wild of most of these use cases solved with Web Components. There's still lots of work to do, of course. But 2) Refining terminology and the way to describe problem space is a natural part of working on solutions for that problem space. Calling it marketing is just not helpful. I agree his wording was a bit harsh. But let me try to explain where Olli is coming from because I do sympathize with what he's saying here. Let's do it. For example, at the WebApps F2F meeting last spring, you mentioned that explaining builtin element is a goal of web components. Yep. I would like to emphasize that explaining the platform is not a self-goal. It's a constraint, which helps guiding the thinking about new primitives and behaviors. Relying on builtin elements to inform discovery of Shadow DOM was a real thing. I hope you remember me going through that huge refactoring in WebKit. Okay. Yet, the web components as spec'ed today doesn't explain any builtin elements due to its lack of strong encapsulation. There are two distinct concepts mixed in here: 1) the type 2 encapsulation. There's no barrier for this to happen. There's broad agreement that we should do it, and even recent work by hayato on outlining specific places where the open and closed modes differ. The research he provided shows that it's a fixed set of changes (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775 https://www.w3.org/Bugs/Public/show_bug.cgi?id=27775), enabled by a flag as we discussed at the spring session. Like we've argued many times in the past, type II encapsulation should be default and components should opt-in to open up its internals. In that regard, our position perfectly aligns with what Olli says. That is, representatives of two major browser vendors agree on this matter. 2) the actual, honest-to-goodness security boundary (isolation) that builtins enjoy thanks to the C++/JS bindings layer. This is a much more difficult problem, but something we definitely want to tackle at some point in the future. Maybe Realms are the answer. Like I've mentioned in the past, we did a through case study of this model and we've discovered a number of problems with existing web components features that we believe are not fixable in the future. If you're asking us to go study layout manager use case, which we did do, please go study our use case as well. And insertion points, which is a huge source of complexity, is only needed to explain details and summary elements. For builtins, yes. For general composition problem, they are essential. Sorry, maybe I was short on words. What I meant is that they're not needed for builtin elements. During our study of layout manager use case, we did come to consolation that something akin to insertion points and node distributions are necessary. The ability to attach multiple generations of shadow DOM to a single host element, which is another source of an enormous complexity, is not required to explain any builtin HTML elements at all as far as I know. This is true. Multiple roots per element is an extension that enables reasoning about subclassing in terms of DOM. You are definitely overstating the complexity. It's not that difficult -- just a list of pointers
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM has changed over time from do everything possible, make things awesome to explain the platform to the current enable easier composition. So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :) I appreciate the affirmation, the kindness, and the smiley. Though since this is public forum, I have to add a few things: 1) The original Component Model (as it was known back then) charter from 2011 clearly includes easier composition as one of its main goals, as illustrated by https://wiki.whatwg.org/wiki/Component_Model and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we definitively solved at huge chunk of these problems. For example, Polymer is a clear illustration that https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager is nearly 100% solved and there are now examples in the wild of most of these use cases solved with Web Components. There's still lots of work to do, of course. But 2) Refining terminology and the way to describe problem space is a natural part of working on solutions for that problem space. Calling it marketing is just not helpful. Personally I think composition piece itself doesn't legitimate the complexity of shadow DOM. I accept this as a personal opinion, not a fact. Though, it is not clear what composition means to different people. Is the need for insertion points part of composition? In my mind it might not be. It is part of the stronger encapsulation where one has hidden DOM between a parent node and a child node. For example, this is clearly where you haven't thought through the problem space. Sure, you don't need insertion points for simple hierarchical composition. But as soon as you get to the Layout Manager use case (not to belabor a 4-year old doc), you run into the need for insertion points. Take https://www.polymer-project.org/docs/elements/layout-elements.html, as examples in the wild. Is event retargeting part of composition? This one is something I am eager to explore. Event retargeting came directly from trying to address the goal of explaining the native controls, and it might be something we could separate from the pure composition primitive. That said, I think we should aim for something stronger than just enabling easier composition. The end goal could go as far as let pages to implement their own form controls. And to make that all less error prone for the users of such components requires encapsulation. Again, I accept this as a personal opinion, but I would like to push back on this. Stronger encapsulation comes with its own host of problems for developers. Before taking this as a fact, I encourage first exploring the trade-offs and trying to prototype/build/tool/test components. I've done it. I've learned the lesson. So, start with composition but keep the requirements for the proper encapsulation in mind by not introducing syntaxes or APIs which might make implementing encapsulation harder. Agreed. Are there cases where encapsulation and composition contradicts? I guess that depends on the definition of those both. Yes. :DG
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 9:41 AM, Dimitri Glazkov dglaz...@google.com wrote: On Thu, Feb 5, 2015 at 5:46 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 02:24 AM, Dimitri Glazkov wrote: However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. Yes. The marketing speech for shadow DOM has changed over time from do everything possible, make things awesome to explain the platform to the current enable easier composition. So it is not very clear to me what even the authors of the spec always want, this said with all the kindness :) I appreciate the affirmation, the kindness, and the smiley. Though since this is public forum, I have to add a few things: 1) The original Component Model (as it was known back then) charter from 2011 clearly includes easier composition as one of its main goals, as illustrated by https://wiki.whatwg.org/wiki/Component_Model and https://wiki.whatwg.org/wiki/Component_Model_Use_Cases. In fact, we definitively solved at huge chunk of these problems. For example, Polymer is a clear illustration that https://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Layout_Manager is nearly 100% solved and there are now examples in the wild of most of these use cases solved with Web Components. There's still lots of work to do, of course. But ... Hanging but?! Oh lordy. Oooh, let me turn this into a contemplative sidebar opportunity. Shadow DOM and Web Components seem to have what I call the Unicorn Syndrome. There's a set of specs that works, proven by at least one browser implementation and the use in the wild. It's got warts (compromises) and some of those warts are quite ugly. Those warts weren't there in the beginning -- they are a result of a hard, multi-year slog of trying to make a complete system that doesn't fall over in edge cases, and compromising. A lot. So there's a temptation to make new proposals (unicorns) that are wart-free, but incomplete or not well-thought-out. Don't get me wrong. I like new ideas. What I would like to avoid is judging a workhorse against a unicorn. Armed with your imagination, unicorn will always win. :DG
Re: Shadow tree style isolation primitive
On Feb 4, 2015, at 4:56 AM, Olli Pettay o...@pettay.fi wrote: On 02/03/2015 04:22 PM, Brian Kardell wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/ https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. [snip] We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) Is there a reason you couldn't do that with normal CSS techniques, no additional combinator? something like /mount/[id=foo] ? That leaves all the isolation up to the outside world. If ShadowRoot had something like attribute DOMString name?; which defaults to null and null means deep(name) or deep(*) wouldn't be able to find the mount, that would let the component itself to say whether it can deal with outside world poking it CSS. [snip] It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. By the previous comment though it seems you are saying it's ok to reach into the mounts, If mount explicitly wants that in which case you could do exactly this... Perhaps the shortness of the sentence makes it seem like I am saying something I am not, basically I'm saying it should be possible to explicitly write rules which do apply inside a mount. I agree with it should be possible to explicitly write rules which do apply inside a mount assuming the mount itself has been flagged to allow that. Otherwise it wouldn't be really explicitlyness, since can just easily select randomly any mount. CSS already gives you all sorts of tools for someone developing a bit in isolation to say how important it is that this particular rule holds up - you can increase specificity with id-based nots or use !important or even the style attribute itself if it is that fundamental - what you can't do is protect yourself on either end from accidental error. I feel like one could easily over-engineer a solution here and kill its actual chances of success, whereas a smaller change could not only have a good chance of getting done, but have very outsized impact and provide some of the data on how to improve it further. Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. [Perhaps a bit off topic to the style isolation] In other words, I'm not very happy to add super complicated Shadow DOM to the platform if it doesn't really provide anything new which couldn't be implemented easily with script libraries and a bit stricter coding styles and conventions. I concur. I don't think introducing something as complex as shadow DOM is worth our effort if the only problem we're solving is multiple teams at a large company stepping on each other. They could simply use their own framework or library, or even create their own convention, to solve that problem for themselves. - R. Niwa
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. Aa;erlhas;dlgpasodifapsldikjf; I keep hearing this kind of sentiment pop up, and I'm like, have you ever done serious webdev? I know a lot of browser devs haven't, and I don't know if you have or not, but this is the sort of thing that is plain as day if you have. You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to friendly fire (as Brian puts it). Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, because they're the only problems related to explaining the current DOM, shows a serious lack of insight into the types of problems experienced by webdevs today, when developing complex webapps. There is no naming scheme that accomplishes this. There is no amount of discipline that will help. Devs are humans, and webpages are very complicated multi-party computer programs, and helping people organize and manage that complexity is an enormous win. Existing Shadow DOM composition is a tailored solution to that. If it looks complex, it's because the platform is complex, and so there's a lot of interface to deal with. Its core, though, is just what if this piece of the document was hidden from the rest of the document by default, and you can't cut away much of Shadow DOM without losing that entirely. - Separate-but-related rant: And like, the sort of mindset that can just throw out Sure, it would require :not(.component) usage too. like it was just some simple thing, easy to implement and do, is amazing. You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors, and need to do it for EVERY COMPONENT. Heck, to do it correctly, you have to do in on EVERY COMPOUND SELECTOR *within* each selector. It's optimizing in the exact wrong direction; you have to explicitly say every time that you don't want to match against a finite set of components; missing it once, or adding a new component that you haven't expressed in your giant-list-of-exclusions-on-every-selector-in-your-page, means you've got a potential styling bug. I, just, man. What. I'm unclear how to have a productive discussion when this is entertained as a serious suggestion. ~TJ
Re: Shadow tree style isolation primitive
On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. Aa;erlhas;dlgpasodifapsldikjf; I keep hearing this kind of sentiment pop up, and I'm like, have you ever done serious webdev? I know a lot of browser devs haven't, and I don't know if you have or not, but this is the sort of thing that is plain as day if you have. That sounds rather demeaning and insulting [1]. public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant. You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to friendly fire (as Brian puts it). Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, because they're the only problems related to explaining the current DOM, shows a serious lack of insight into the types of problems experienced by webdevs today, when developing complex webapps. While I agree those are problems worth solving, let us recognize and respect that different participates of the working group care about different use cases and are interested in solving different set of problems. There is no naming scheme that accomplishes this. There is no amount of discipline that will help. Devs are humans, and webpages are very complicated multi-party computer programs, and helping people organize and manage that complexity is an enormous win. Existing Shadow DOM composition is a tailored solution to that. If it looks complex, it's because the platform is complex, and so there's a lot of interface to deal with. Its core, though, is just what if this piece of the document was hidden from the rest of the document by default, and you can't cut away much of Shadow DOM without losing that entirely. ... Separate-but-related rant: And like, the sort of mindset that can just throw out Sure, it would require :not(.component) usage too. like it was just some simple thing, easy to implement and do, is amazing. You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors, and need to do it for EVERY COMPONENT. Heck, to do it correctly, you have to do in on EVERY COMPOUND SELECTOR *within* each selector. It's optimizing in the exact wrong direction; you have to explicitly say every time that you don't want to match against a finite set of components; missing it once, or adding a new component that you haven't expressed in your giant-list-of-exclusions-on-every-selector-in-your-page, means you've got a potential styling bug. However, the use case we're talking here is multiple teams working on a single website potentially stepping on each other's toes; implying the enormous size of the entity working on the website. I have a hard time imagining that any organization of that scale to not have a sever-side or pre-deployment build step for the website at which point they can add a preprocessing step to modify all selectors. e.g. even a website I worked on with only four other people had a build step before we could deploy it. [1] http://www.w3.org/Consortium/cepc/ - R. Niwa
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 10:56 AM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. Aa;erlhas;dlgpasodifapsldikjf; I keep hearing this kind of sentiment pop up, and I'm like, have you ever done serious webdev? I know a lot of browser devs haven't, and I don't know if you have or not, but this is the sort of thing that is plain as day if you have. That sounds rather demeaning and insulting [1]. public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant. Most browser devs are not webdevs. This is not an insult nor is it demeaning. I've been a member of the W3C for many years, and problems with browser devs not understanding the issues of real webdevs on the ground have always been rampant. It's a large part of the reason I joined the W3C in the first place, so I could help develop CSS specs that were important for webdevs but being ignored by the browser devs in the group. If you find that demeaning, I'm sorry? It's not something you can ignore; it's always an elephant in the room when trying to solve problems that frustrate webdevs. It really is important to ensure that browser devs sit down and listen to people with real webdev experience (such as, for example, Brian Kardell). You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to friendly fire (as Brian puts it). Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, because they're the only problems related to explaining the current DOM, shows a serious lack of insight into the types of problems experienced by webdevs today, when developing complex webapps. While I agree those are problems worth solving, let us recognize and respect that different participates of the working group care about different use cases and are interested in solving different set of problems. That's precisely what I'm getting frustrated with - when people make suggestions that composition isn't important, and people can just use better selectors and some discipline to solve those problems, it makes it difficult to have productive conversations. Composition is a massive problem with today's webapps. Isolation is a minor problem that is important for some valuable use-cases, so it shouldn't be ignored, but neither should it be elevated to the sole important thing to be discussed here. There is no naming scheme that accomplishes this. There is no amount of discipline that will help. Devs are humans, and webpages are very complicated multi-party computer programs, and helping people organize and manage that complexity is an enormous win. Existing Shadow DOM composition is a tailored solution to that. If it looks complex, it's because the platform is complex, and so there's a lot of interface to deal with. Its core, though, is just what if this piece of the document was hidden from the rest of the document by default, and you can't cut away much of Shadow DOM without losing that entirely. ... Separate-but-related rant: And like, the sort of mindset that can just throw out Sure, it would require :not(.component) usage too. like it was just some simple thing, easy to implement and do, is amazing. You'd need to spam that EVERYWHERE, on NEARLY ALL of your selectors, and need to do it for EVERY COMPONENT. Heck, to do it correctly, you have to do in on EVERY COMPOUND SELECTOR *within* each selector. It's optimizing in the exact wrong direction; you have to explicitly say every time that you don't want to match against a finite set of components; missing it once, or adding a new component that you haven't expressed in your giant-list-of-exclusions-on-every-selector-in-your-page, means you've got a potential styling bug. However, the use case we're talking here is multiple teams working on a single website potentially stepping on each other's toes; implying the enormous size of the entity working on the website. I have a hard time imagining that any organization of that scale to not have a sever-side or pre-deployment build step for the website at which point
Re: Shadow tree style isolation primitive
On Thu, Feb 5, 2015 at 11:03 AM, Olli Pettay o...@pettay.fi wrote: On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote: You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to friendly fire (as Brian puts it). If we want to just help with composition, then we can find simpler model than shadow DOM with its multiple shadow root per host and event handling oddities and what not. (and all the mess with is-in-doc is still something to be sorted out etc.) Try to. ^_^ Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, No one has tried to imply that. I don't know where you got that. By your statements implying that composition issues can just be handled by better discipline and some selector modification, in the message I responded to earlier. I'm not sure how to interpret those statement if you didn't mean that composition wasn't worth solving. ~TJ
Re: Shadow tree style isolation primitive
On 02/05/2015 01:20 AM, Tab Atkins Jr. wrote: You don't need strong isolation primitives to do a lot of good. Simple composition helpers lift an *enormous* weight off the shoulders of web devs, and make whole classes of bugs obsolete. Shadow DOM is precisely that composition helper right now. In most contexts, you can't ever touch something inside of shadow DOM unless you're doing it on purpose, so there's no way to friendly fire (as Brian puts it). If we want to just help with composition, then we can find simpler model than shadow DOM with its multiple shadow root per host and event handling oddities and what not. (and all the mess with is-in-doc is still something to be sorted out etc.) Stronger isolation does solve some problems, sure. But trying to imply that those are the only problems we need to solve, No one has tried to imply that. I don't know where you got that.
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 3:56 PM, Ryosuke Niwa rn...@apple.com wrote: On Feb 4, 2015, at 3:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Feb 4, 2015 at 11:56 PM, Olli Pettay o...@pettay.fi wrote: Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. Aa;erlhas;dlgpasodifapsldikjf; I keep hearing this kind of sentiment pop up, and I'm like, have you ever done serious webdev? I know a lot of browser devs haven't, and I don't know if you have or not, but this is the sort of thing that is plain as day if you have. That sounds rather demeaning and insulting [1]. public-webapps, or a mailing list of any W3C working group, isn't an appropriate forum to rant. +1. However, the use case we're talking here is multiple teams working on a single website potentially stepping on each other's toes; implying the enormous size of the entity working on the website. I have a hard time imagining that any organization of that scale to not have a sever-side or pre-deployment build step for the website at which point they can add a preprocessing step to modify all selectors. e.g. even a website I worked on with only four other people had a build step before we could deploy it. The need to modify selectors on the server side is highly symptomatic of the composition problem remaining unsolved. This processing is not due to the burning desire of the developers to munge their selectors, but rather due to their inability to reason about the composition of styles, and having to rely on out-of-band composition. For all the criticism Shadow DOM receives, it is currently the only solution that solves this problem. As I mentioned before, I am very open to using Shadow DOM to extract a simpler primitive that is more focused on solving the style composition problem in-band. However, I would like to first understand if that is the problem that the group wants to solve. It is unclear from this conversation. :DG
Re: Shadow tree style isolation primitive
On 02/03/2015 07:24 PM, Dimitri Glazkov wrote: Not trying to barge in, just sprinkling data... On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/ https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. [snip] We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) Is there a reason you couldn't do that with normal CSS techniques, no additional combinator? something like /mount/[id=foo] ? That's ::shadow in the scoping spec: http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement [snip] It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. This is still possible, and works in a predictable way with today's styling machinery. Use inline styles on the button that you want to be green/red inside of the scope, and no /deep/ or /mount/ or will be able to affect it: http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the war progressed to the stage where !important is used as hammer. Why should even !important work if the component wants to use its own colors? :DG
Re: Shadow tree style isolation primitive
On 02/03/2015 04:22 PM, Brian Kardell wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto:o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.__wordpress.com/2015/01/14/__friendly-fire-the-fog-of-dom/ https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. [snip] We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) Is there a reason you couldn't do that with normal CSS techniques, no additional combinator? something like /mount/[id=foo] ? That leaves all the isolation up to the outside world. If ShadowRoot had something like attribute DOMString name?; which defaults to null and null means deep(name) or deep(*) wouldn't be able to find the mount, that would let the component itself to say whether it can deal with outside world poking it CSS. [snip] It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. By the previous comment though it seems you are saying it's ok to reach into the mounts, If mount explicitly wants that in which case you could do exactly this... Perhaps the shortness of the sentence makes it seem like I am saying something I am not, basically I'm saying it should be possible to explicitly write rules which do apply inside a mount. I agree with it should be possible to explicitly write rules which do apply inside a mount assuming the mount itself has been flagged to allow that. Otherwise it wouldn't be really explicitlyness, since can just easily select randomly any mount. CSS already gives you all sorts of tools for someone developing a bit in isolation to say how important it is that this particular rule holds up - you can increase specificity with id-based nots or use !important or even the style attribute itself if it is that fundamental - what you can't do is protect yourself on either end from accidental error. I feel like one could easily over-engineer a solution here and kill its actual chances of success, whereas a smaller change could not only have a good chance of getting done, but have very outsized impact and provide some of the data on how to improve it further. Why do we need shadow DOM (or something similar) at all if we expose it easily to the outside world. One could even now just require that elements in components in a web page have class=component, and then .component could be used as . Sure, it would require :not(.component) usage too. And from DOM APIs side one could easily implement filtering for the contents of components using small script libraries. [Perhaps a bit off topic to the style isolation] In other words, I'm not very happy to add super complicated Shadow DOM to the platform if it doesn't really provide anything new which couldn't be implemented easily with script libraries and a bit stricter coding styles and conventions. -Olli If this doesn't seem -hostile- to decent further improvements, finding something minimal but still very useful might be good. -- Brian Kardell :: @briankardell :: hitchjs.com http://hitchjs.com/
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 7:56 AM, Olli Pettay o...@pettay.fi wrote: On 02/03/2015 04:22 PM, Brian Kardell wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi mailto: o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.__wordpress.com/2015/01/14/__friendly- fire-the-fog-of-dom/ https://briankardell.wordpress.com/2015/01/14/ friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. [snip] If ShadowRoot had something like attribute DOMString name?; which defaults to null and null means deep(name) or deep(*) wouldn't be able to find the mount, that would let the component itself to say whether it can deal with outside world poking it CSS. That actually doesn't sound crazy to me. I mean, it actually fits pretty nicely into the conceptual model I think and it would add a whole additional layer of possible protection which is explainable in sort of todays terms with minimal new 'stuff'... the combinator is new anyway and you're dealing with mount in what seems like a good way there. I think I like it. [snip] [Perhaps a bit off topic to the style isolation] In other words, I'm not very happy to add super complicated Shadow DOM to the platform if it doesn't really provide anything new which couldn't be implemented easily with script libraries and a bit stricter coding styles and conventions. I'd suggest that you're radically over-stating - you really can't easily solve this problem, even with much stricter coding style, as I explained in that post. This is a problem and even without named mount protection above, this would be a giant leap forward because the -default- thing is to not match. Doing 'right' by default is a giant win. That said, as I say above, I kinda like the named mount idea... -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Wed, Feb 4, 2015 at 11:36 PM, Olli Pettay o...@pettay.fi wrote: Why should even !important work if the component wants to use its own colors? Because that's how !important usually works. If the author has progressed to the point of doing !important, we should assume that they know what they're doing and let it work. At the end of the day, it should be possible for the outer page to have some way of styling any part of a non-sealed (a la inputs, etc) shadow DOM. Anyone claiming this isn't necessary should be sentenced to a year of doing web dev with jQuery components and hostile clients. ~TJ
Re: Shadow tree style isolation primitive
On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. Its intuitive then to create a combinator in CSS which allows you to select the mount explicitly Yes, I agree with that assuming the mount actually wants to be selectable. And even if all the mounts were selectable, we don't have atm a way to select some particular mount explicitly. And I think we should have that explicitly-ness. or /deep/ are like select all and cross your fingers you selected what you wanted, and not anything more. We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. Without the explicitly-ness we're back having the initial problems we're trying to solve, as the blog says That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that aren’t “yours“. Same explicitly-ness should apply to things like Event.path etc. (I still think shadow DOM needs proper encapsulation, even if components would all be 'allies'. A use case for encapsulation would be rather similar to private: or protected: in many languages. But encapsulation is perhaps a bit different issue from weaker isolation.) -Olli
Re: Shadow tree style isolation primitive
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.wordpress.com/2015/01/14/ friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. [snip] We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) Is there a reason you couldn't do that with normal CSS techniques, no additional combinator? something like /mount/[id=foo] ? [snip] It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. By the previous comment though it seems you are saying it's ok to reach into the mounts, in which case you could do exactly this... Perhaps the shortness of the sentence makes it seem like I am saying something I am not, basically I'm saying it should be possible to explicitly write rules which do apply inside a mount. CSS already gives you all sorts of tools for someone developing a bit in isolation to say how important it is that this particular rule holds up - you can increase specificity with id-based nots or use !important or even the style attribute itself if it is that fundamental - what you can't do is protect yourself on either end from accidental error. I feel like one could easily over-engineer a solution here and kill its actual chances of success, whereas a smaller change could not only have a good chance of getting done, but have very outsized impact and provide some of the data on how to improve it further. If this doesn't seem -hostile- to decent further improvements, finding something minimal but still very useful might be good. -Olli -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
Not trying to barge in, just sprinkling data... On Tue, Feb 3, 2015 at 6:22 AM, Brian Kardell bkard...@gmail.com wrote: On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay o...@pettay.fi wrote: On 02/02/2015 09:22 PM, Dimitri Glazkov wrote: Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.wordpress.com/2015/01/14/ friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. random comments about that blog post. [snip] We need to be able to select mount nodes explicitly, and perhaps explicitly say that all such nodes should be selected. So, maybe, deep(mountName) and deep(*) Is there a reason you couldn't do that with normal CSS techniques, no additional combinator? something like /mount/[id=foo] ? That's ::shadow in the scoping spec: http://dev.w3.org/csswg/css-scoping/#shadow-pseudoelement [snip] It still needs to be possible from the hosting page to say “Yes, I mean all buttons should be blue” I disagree with that. It can very well be possible that some component really must control the colors itself. Say, it uses buttons to indicate if traffic light is red or green. Making both those buttons suddenly blue would break the whole concept of the component. This is still possible, and works in a predictable way with today's styling machinery. Use inline styles on the button that you want to be green/red inside of the scope, and no /deep/ or /mount/ or will be able to affect it: http://jsbin.com/juyeziwaqo/1/edit?html,css,js,output ... unless the war progressed to the stage where !important is used as hammer. :DG
Re: Shadow tree style isolation primitive
Brian recently posted what looks like an excellent framing of the composition problem: https://briankardell.wordpress.com/2015/01/14/friendly-fire-the-fog-of-dom/ This is the problem we solved with Shadow DOM and the problem I would like to see solved with the primitive being discussed on this thread. :DG
Re: Shadow tree style isolation primitive
On Wed, Jan 14, 2015 at 2:11 AM, Brian Kardell bkard...@gmail.com wrote: So if that is a given, why can we not start there and explain how it would work and use it to fashion increasingly high abstractions - hopefully with the ability to do some experimentation outside of native implementations? Because you don't want CSS to influence markup or DOM. So putting the primitive in markup or DOM is the wrong way around. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
On Jan 13, 2015, at 4:15 AM, cha...@yandex-team.ru wrote: 13.01.2015, 00:57, Ryosuke Niwa rn...@apple.com: On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote: 09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? The benefit of this approach is that all the styling information will be in one place. CSS cascading rules is already complicated, and having to consult the markup to know where the selector boundary is will be yet another cognitive stress. Sorry, I'm dense this morning for sure. Why would all the styling information be in one place? I'm still thinking from the model of BEM, where the benefit is that for a particular block you can collect everything (styling, scripts, whatever magic you want - or just a couple of plain tags and 4 words) in one place, and the different pieces get stitched together without having to worry about how they will impact each other because ordinarily they won't. To separate presentational information (CSS) from the semantics (HTML). Defining both style isolation boundaries and the associated CSS rules in an external CSS file will allow authors to change both of them without having to modify every HTML documents that includes the CSS file. Of course, this is a non-starter for Web apps that require a lot of scripting, but style isolation is a very useful feature for a lot of static pages as well. - R. Niwa
Re: Shadow tree style isolation primitive
On Jan 13, 2015, at 3:46 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com
mailto:rn...@apple.com wrote:
To separate presentational information (CSS) from the semantics (HTML).
Defining both style isolation boundaries and the associated CSS rules in an
external CSS file will allow authors to change both of them without having to
modify every HTML documents that includes the CSS file. Of course, this is a
non-starter for Web apps that require a lot of scripting, but style isolation
is a very useful feature for a lot of static pages as well.
- R. Niwa
Ryosuke,
Should you also be able to do this from JavaScript/DOM in your opinion?
Like, forget shadow dom as it is today in chrome or proposed -- should you be
able to do something like
```
element.isolateTree = true;
```
and achieve a similar effect? If not, why specifically?
Or element.setAttribute('isolatetree', true); I can't think of a reason not to
do this.
- R. Niwa
Re: Shadow tree style isolation primitive
On Tue, Jan 13, 2015 at 8:09 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 13, 2015, at 3:46 PM, Brian Kardell bkard...@gmail.com wrote:
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com wrote:
To separate presentational information (CSS) from the semantics (HTML).
Defining both style isolation boundaries and the associated CSS rules in an
external CSS file will allow authors to change both of them without having
to modify every HTML documents that includes the CSS file. Of course, this
is a non-starter for Web apps that require a lot of scripting, but style
isolation is a very useful feature for a lot of static pages as well.
- R. Niwa
Ryosuke,
Should you also be able to do this from JavaScript/DOM in your opinion?
Like, forget shadow dom as it is today in chrome or proposed -- should you
be able to do something like
```
element.isolateTree = true;
```
and achieve a similar effect? If not, why specifically?
Or element.setAttribute('isolatetree', true); I can't think of a reason
not to do this.
- R. Niwa
So if that is a given, why can we not start there and explain how it would
work and use it to fashion increasingly high abstractions - hopefully with
the ability to do some experimentation outside of native implementations?
--
Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
13.01.2015, 00:57, Ryosuke Niwa rn...@apple.com: On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote: 09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? The benefit of this approach is that all the styling information will be in one place. CSS cascading rules is already complicated, and having to consult the markup to know where the selector boundary is will be yet another cognitive stress. Sorry, I'm dense this morning for sure. Why would all the styling information be in one place? I'm still thinking from the model of BEM, where the benefit is that for a particular block you can collect everything (styling, scripts, whatever magic you want - or just a couple of plain tags and 4 words) in one place, and the different pieces get stitched together without having to worry about how they will impact each other because ordinarily they wont. (The corresponding cognitive price is that if you *want* to do things page-wide across a bunch of different blocks, you need to think more). Could you provide a slightly longer-form answer for dummies (i.e. me) please? cheers -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: Shadow tree style isolation primitive
On Tue, Jan 13, 2015 at 2:07 PM, Ryosuke Niwa rn...@apple.com wrote: To separate presentational information (CSS) from the semantics (HTML). Defining both style isolation boundaries and the associated CSS rules in an external CSS file will allow authors to change both of them without having to modify every HTML documents that includes the CSS file. Of course, this is a non-starter for Web apps that require a lot of scripting, but style isolation is a very useful feature for a lot of static pages as well. - R. Niwa Ryosuke, Should you also be able to do this from JavaScript/DOM in your opinion? Like, forget shadow dom as it is today in chrome or proposed -- should you be able to do something like ``` element.isolateTree = true; ``` and achieve a similar effect? If not, why specifically? -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 10:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: tl;dr: Cramming a subtree into a TreeScope container and then hanging that off the DOM would do the job for free (because it bakes all that functionality in). Sure, or we could expose a property that when set isolates a tree. Both a lot simpler than requiring ShadowRoot. However, it seems to me that ideally you can control all of this through CSS. The ability to isolate parts of a tree and have them managed by some other stylesheet or selector mechanism. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? cheers Chaals This is a bit different from the `all` property as that just changes the values of all properties, it does not make a selector such as div no longer match. So to be clear, the idea is that if you have a tree such as section class=example h1Example/h1 div ... /div /section Then a simple div selector would not match the innermost div if we isolated the section. Instead you would have to use section div or some such. Or perhaps associate a set of selectors and style declarations with that subtree in some manner. -- https://annevankesteren.nl/ -- Charles McCathie Nevile - web standards - CTO Office, Yandex cha...@yandex-team.ru - - - Find more at http://yandex.com
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren ann...@annevk.nl wrote:
I'm wondering if it's feasible to provide developers with the
primitive that the combination of Shadow DOM and CSS Scoping provides.
Namely a way to isolate a subtree from selector matching (of document
stylesheets, not necessarily user and user agent stylesheets) and
requiring a special selector, such as , to pierce through the
boundary.
This is a bit different from the `all` property as that just changes
the values of all properties, it does not make a selector such as
div no longer match.
So to be clear, the idea is that if you have a tree such as
section class=example
h1Example/h1
div ... /div
/section
Then a simple div selector would not match the innermost div if we
isolated the section. Instead you would have to use section div or
some such. Or perhaps associate a set of selectors and style
declarations with that subtree in some manner.
It's probably feasible, sure. But I'm not sure that it's necessary,
or that browsers will go for it. Using a shadow root as the isolation
boundary is *really convenient*, because it's a separate tree
entirely; the fact that outside rules don't apply within it, and
inside rules don't apply outside, falls out for free.
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Basically, trying to smuggle private state into a global declarative
language is a bitch.
So, CSS is out. We can't reasonably do this within the confines of
CSS application. It needs to be handled at a different layer. We
could do it in HTML, potentially - some new global attribute that
creates a styling boundary that prevents outside styling from
targeting anything inside. Then you can just use standard style
scoped to apply your own styles within the boundary - as long as the
scoping root is inside the boundary, styling is allowed.
But that means you have to add an attribute to every element that uses
this styling boundary, and move your style info into inline scoped
blocks. That's annoying. :/
Let's check out JS. If you can mark some elements as always being
styling boundaries, then whenever they're constructed, whether
manually or via the parser, they'll get the right mechanics
automatically. And since this is JS, it shouldn't be too hard to say
always attach this stylesheet to the element whenever it gets
created, or perhaps introduce some explicit ability to do this in the
platform.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
So, do you still think it's worth it to try to subdivide the
functionality further? I think it's packaged in a reasonable way at
the moment.
~TJ
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote: 09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? The benefit of this approach is that all the styling information will be in one place. CSS cascading rules is already complicated, and having to consult the markup to know where the selector boundary is will be yet another cognitive stress. - R. Niwa
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 4:57 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru wrote: 09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? The benefit of this approach is that all the styling information will be in one place. CSS cascading rules is already complicated, and having to consult the markup to know where the selector boundary is will be yet another cognitive stress. - R. Niwa If it it necessary to reflect similar at the imperative end of things with qsa/find/closest (at minimum) - and I think it is the least surprising thing to do - then you've merely moved where the cognitive stress is, and in a really new way... Suddenly your CSS is affecting your understanding of the actual tree! That seems bad. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren ann...@annevk.nl wrote:
I'm wondering if it's feasible to provide developers with the
primitive that the combination of Shadow DOM and CSS Scoping provides.
Namely a way to isolate a subtree from selector matching (of document
stylesheets, not necessarily user and user agent stylesheets) and
requiring a special selector, such as , to pierce through the
boundary.
This is a bit different from the `all` property as that just changes
the values of all properties, it does not make a selector such as
div no longer match.
So to be clear, the idea is that if you have a tree such as
section class=example
h1Example/h1
div ... /div
/section
Then a simple div selector would not match the innermost div if we
isolated the section. Instead you would have to use section div or
some such. Or perhaps associate a set of selectors and style
declarations with that subtree in some manner.
It's probably feasible, sure. But I'm not sure that it's necessary,
or that browsers will go for it. Using a shadow root as the isolation
boundary is *really convenient*, because it's a separate tree
entirely; the fact that outside rules don't apply within it, and
inside rules don't apply outside, falls out for free.
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such as an
element or an attribute to end the current isolation, just like insertion
points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Let's check out JS. If you can mark some elements as always being
styling boundaries, then whenever they're constructed, whether
manually or via the parser, they'll get the right mechanics
automatically. And since this is JS, it shouldn't be too hard to say
always attach this stylesheet to the element whenever it gets
created, or perhaps introduce some explicit ability to do this in the
platform.
There is a huge benefit in providing declarative alternative. There are many
use cases in which style/selector isolations are desirable on an existing
element such as section and article elements.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees. They're two
distinct features. Even though I do agree it might be desirable to have both
in many important use cases, there are use cases in which we don't
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 2:07 PM, Brian Kardell bkard...@gmail.com wrote: On Mon, Jan 12, 2015 at 4:57 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Jan 12, 2015, at 4:13 AM, cha...@yandex-team.ru mailto:cha...@yandex-team.ru wrote: 09.01.2015, 16:42, Anne van Kesteren ann...@annevk.nl mailto:ann...@annevk.nl: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. Sounds like a reasonable, and perhaps feasible thing to do, but the obvious question is why? The use cases I can think of are to provide the sort of thing we do with BEM today. Is the effort worth it, or are there other things I didn't think of (quite likely, given I spent multiple seconds on the question)? The benefit of this approach is that all the styling information will be in one place. CSS cascading rules is already complicated, and having to consult the markup to know where the selector boundary is will be yet another cognitive stress. - R. Niwa If it it necessary to reflect similar at the imperative end of things with qsa/find/closest (at minimum) - and I think it is the least surprising thing to do - then you've merely moved where the cognitive stress is, and in a really new way... Suddenly your CSS is affecting your understanding of the actual tree! That seems bad. I agree that having both style isolation and subtree isolation is desirable in some use cases such as Web app widgets. However, there are other use cases for which style isolation without subtree isolation is desirable in non-App Web documents. - R. Niwa
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such as
an element or an attribute to end the current isolation, just like
insertion points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Yeah, something like that would work, but it also means you need to
account for all the things that might want to be isolated in your
component. That's relatively clumsy.
Let's check out JS. If you can mark some elements as always being
styling boundaries, then whenever they're constructed, whether
manually or via the parser, they'll get the right mechanics
automatically. And since this is JS, it shouldn't be too hard to say
always attach this stylesheet to the element whenever it gets
created, or perhaps introduce some explicit ability to do this in the
platform.
There is a huge benefit in providing declarative alternative. There are many
use cases in which style/selector isolations are desirable on an existing
element such as section and article elements.
Sure, I agree. I'm just pointing out that trying to implement it with
our existing declarative mechanisms is going to be at least somewhat
clumsy and ugly. Having an explicit tree that delineates the
isolation context makes things a little clearer, imo.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees. They're
two distinct features. Even though I do agree it might be desirable to have
both in many important use cases, there are use cases in which we don't need
subtree isolations.
I'm not trying to, I'm pointing out that style isolation, as a
concept, seamlessly blends into DOM isolation as you move across API
surfaces. I don't think there's a clear and obvious point where you
can draw the line and say it only applies up to here, no further,
except by going all the way to subtree isolation.
~TJ
RE: Shadow tree style isolation primitive
± On Fri, Jan 9, 2015 at 5:40 AM, Anne van Kesteren ann...@annevk.nl
± wrote:
± I'm wondering if it's feasible to provide developers with the
± primitive that the combination of Shadow DOM and CSS Scoping provides.
± Namely a way to isolate a subtree from selector matching (of document
± stylesheets, not necessarily user and user agent stylesheets) and
± requiring a special selector, such as , to pierce through the
± boundary.
±
± This is a bit different from the `all` property as that just changes
± the values of all properties, it does not make a selector such as
± div no longer match.
±
± So to be clear, the idea is that if you have a tree such as
±
±section class=example
± h1Example/h1
± div ... /div
±/section
±
± Then a simple div selector would not match the innermost div if we
± isolated the section. Instead you would have to use section div or
± some such. Or perhaps associate a set of selectors and style
± declarations with that subtree in some manner.
±
± It's probably feasible, sure. But I'm not sure that it's necessary, or that
± browsers will go for it. Using a shadow root as the isolation boundary is
± *really convenient*, because it's a separate tree entirely; the fact that
± outside rules don't apply within it, and inside rules don't apply outside,
falls
± out for free.
±
± Let's assume we did it, though. We'd have to have some mechanism for
± defining an isolation boundary, and denoting whether rules were inside or
± outside the boundary. This sounds like an at-rule,
± like:
±
± @isolate .example {
± h1 { ... }
± div { ... }
± }
±
± Now, a problem here is that you have a conflict between nesting isolated
± things and specifying isolation. Say you have foo and bar elements,
± both of which need to be isolated. You'd think you could just write:
±
± @isolate foo {
± ...
± }
± @isolate bar {
± ...
± }
±
± But this won't work! If you have markup like foobar.../bar/foo, the
± bar there is inside the foo's isolation boundary, so the @isolate rule
± can't find it. You'd need to
± *also* nest the @isolate bar rule (and all its styling rules) within the foo
± one, and vice versa. The effect of this on *three* mutually isolated
± components is, obviously, terrible; let's not even mention trying to use
± multiple modules together that weren't explicitly designed together.
±
± Alternately, say that it does work - the @isolate selector pierces through
± isolation boundaries. Then you're still screwed, because if the outer page
± wants to isolate .example blocks, but within your component you use
± .example normally, without any isolation, whoops!
± Suddenly your .example blocks are isolated, too, and getting weird styles
± applied to them, while your own styles break since they can't cross the
± unexpected boundary.
±
± Basically, trying to smuggle private state into a global declarative language
is a
± bitch.
±
± So, CSS is out. We can't reasonably do this within the confines of CSS
± application. It needs to be handled at a different layer. We could do it in
± HTML, potentially - some new global attribute that creates a styling boundary
± that prevents outside styling from targeting anything inside. Then you can
± just use standard style
± scoped to apply your own styles within the boundary - as long as the
± scoping root is inside the boundary, styling is allowed.
±
± But that means you have to add an attribute to every element that uses this
± styling boundary, and move your style info into inline scoped blocks. That's
± annoying. :/
±
± Let's check out JS. If you can mark some elements as always being styling
± boundaries, then whenever they're constructed, whether manually or via
± the parser, they'll get the right mechanics automatically. And since this is
JS,
± it shouldn't be too hard to say always attach this stylesheet to the element
± whenever it gets created, or perhaps introduce some explicit ability to do
± this in the platform.
±
± This last one, though, is pretty much exactly Custom Elements, just with the
± children staying in the light tree rather than being moved into a shadow tree.
± But keeping them in the light tree has complications; it means that
± everything in the platform needs to be made aware of the isolation
± boundary. Should qSA respect the isolation boundaries or not? Depends on
± what you're using it for.
± What about things that aren't CSS at all, like getElementsByTagName()?
± That's equivalent to a qSA with the same argument, but it's not a selector,
± per se. Manual tree-walking would also need to be made aware of this, or
± else you might accidentally descend into something that wants isolation.
± Shadow DOM at least gives an answer to all of these, by putting the
± elements in a separate tree. You don't need to think of every one
± individually, or deal with inconsistent design when someone forgets to spec
± their new tree-searching thing to respect the boundary.
±
± So, do you still
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 2:37 PM, Brian Kardell bkard...@gmail.com wrote: On Mon, Jan 12, 2015 at 5:18 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: [snip] I agree that having both style isolation and subtree isolation is desirable in some use cases such as Web app widgets. However, there are other use cases for which style isolation without subtree isolation is desirable in non-App Web documents. - R. Niwa Can you share such a case? If you're worried about CSS selectors 'bleeding through' how do functional selectors not have precisely the same concerns? I'm not saying it doesn't exist, I'm saying that I am having trouble envisioning it and would like some more information. It does seem to me that both sorts of isolation naturally 'fall out' of simply having a connector of trees that isn't using parent/child pointers and that most things would just work and be easy to explain (as a thing on its own and to use to build up higher features) which is an aspect I am having trouble seeing in nearly all other proposals. Once again, I'm not saying it's not there, I'm just asking for someone to explain/show me. Sure, here are some use cases I can think off the top of my head: Styling a navigation bar which is implemented as a list of hyperlinks Styling an article in a blog Styling the comment section in a blog article Styling a code snippet in a blog article None of these scenarios require authors to write scripts. - R. Niwa
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 3:51 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such
as an element or an attribute to end the current isolation, just like
insertion points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Yeah, something like that would work, but it also means you need to
account for all the things that might want to be isolated in your
component. That's relatively clumsy.
Examples? Are you talking about DOM APIs such as querySelectorAll and alike?
Then, please refer to my other reply [1] in which I listed use cases that
involve no author scripts.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees. They're
two distinct features. Even though I do agree it might be desirable to
have both in many important use cases, there are use cases in which we
don't need subtree isolations.
I'm not trying to, I'm pointing out that style isolation, as a
concept, seamlessly blends into DOM isolation as you move across API
surfaces.
I don't see any connection between the two. Many of the use cases I listed
[1] require us to have DOM isolations.
doesn't require us to have DOM isolations.
Now, I agree there are use cases in which such DOM isolation mechanisms are
desirable. If we didn't want to add two separate mechanisms to address both
use cases, we could use a host language dependent mechanism such as a
dedicated HTML attribute to define a boundary.
[1] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0112.html
- R. Niwa
Re: Shadow tree style isolation primitive
Sure, here are some use cases I can think off the top of my head: 1. Styling a navigation bar which is implemented as a list of hyperlinks 2. Styling an article in a blog 3. Styling the comment section in a blog article 4. Styling a code snippet in a blog article None of these scenarios require authors to write scripts. - R. Niwa I'm sorry, this might be dense but as use cases go those seem incomplete I believe you intend to illustrate something here, but I'm not getting it... Is the idea that the nav bar wants to deliver this is how I am styled without interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like this is actually really hard to manage with CSS and here's potentially a way to make it 'scope' easier? -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 4:28 PM, Brian Kardell bkard...@gmail.com wrote: On Mon, Jan 12, 2015 at 7:23 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: On Jan 12, 2015, at 4:16 PM, Brian Kardell bkard...@gmail.com mailto:bkard...@gmail.com wrote: Sure, here are some use cases I can think off the top of my head: Styling a navigation bar which is implemented as a list of hyperlinks Styling an article in a blog Styling the comment section in a blog article Styling a code snippet in a blog article None of these scenarios require authors to write scripts. - R. Niwa I'm sorry, this might be dense but as use cases go those seem incomplete I believe you intend to illustrate something here, but I'm not getting it... Is the idea that the nav bar wants to deliver this is how I am styled without interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like this is actually really hard to manage with CSS and here's potentially a way to make it 'scope' easier? It's both that the navigation bar wants to have its own set of CSS rules and doesn't want to get affected by other CSS rules; and it's hard to manage a large number of CSS rules manually without an encapsulation mechanism like a style isolation boundary [1]. [1] http://stackoverflow.com/questions/2253110/managing-css-explosion http://stackoverflow.com/questions/2253110/managing-css-explosion - R. Niwa Yeah, ok, that's what I thought you meant. Professionally, I come up with this case all the time and the number of cases where I want JavaScript ops to inadvertently poke into me is 0. Let's use your menu case, lets say that I have a class=title on some menu elements and use id=main - because, hey, that's one reason we like style isolation, we don't need to invent complex strategies. Fairly high odds that someone else in the page will qsa those and do something bad to me inadvertently. Having those respect the same boundary for the same seems very, very natural to me. I understand your use case but please also understand that some authors don't want to write a few dozen lines of JavaScript to create a shadow DOM, and hundreds of lines of code or load a framework to decoratively isolate CSS rules in their pages. Quick note based on some of your other responses - I actually didn't see any proposal in the suggestions about TreeScope or a non-parent/child link connector or something that talked about insertion points... I think that is a secondary question, as is event retargeting? My comments are literally limited to the bare minimum stuff above without discussion of those. What questions do you have with regards with insertion points and event retargeting? Are you asking whether they should happen as a side effect of having a style isolation? I would just say that we feel event retargeting should be treated as a separate concern from style isolation. I'm denying that a style isolation with event retargeting is a valid use case but there are use cases in which style isolation without event retargeting is desirable or retargeting needs to be implemented by frameworks. - R. Niwa
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such as
an element or an attribute to end the current isolation, just like
insertion points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Yeah, something like that would work, but it also means you need to
account for all the things that might want to be isolated in your
component. That's relatively clumsy.
Examples? Are you talking about DOM APIs such as querySelectorAll and alike?
Then, please refer to my other reply [1] in which I listed use cases that
involve no author scripts.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees. They're
two distinct features. Even though I do agree it might be desirable to have
both in many important use cases, there are use cases in which we don't need
subtree isolations.
I'm not trying to, I'm pointing out that style isolation, as a
concept, seamlessly blends into DOM isolation as you move across API
surfaces.
I don't see any connection between the two. Many of the use cases I listed [1]
require us to have DOM isolations.
Now, I agree there are use cases in which such DOM isolation mechanisms are
desirable. If we didn't want to add two separate mechanisms to address both
use cases, we could use a host language dependent mechanism such as a dedicated
HTML attribute to define a boundary.
[1] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0112.html
- R. Niwa
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. If that's the behavior we want, then we should simply make @isolate pierce through isolates. You previously mentioned that: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Alternately, say that it does work - the @isolate selector pierces through isolation boundaries. Then you're still screwed, because if the outer page wants to isolate .example blocks, but within your component you use .example normally, without any isolation, whoops! Suddenly your .example blocks are isolated, too, and getting weird styles applied to them, while your own styles break since they can't cross the unexpected boundary. But this same problem seems to exist in shadow DOM as well. We can't have a bar inside a foo behave differently from ones outside foo since all bar elements share the same implementation. I agree - R. Niwa
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such
as an element or an attribute to end the current isolation, just like
insertion points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Yeah, something like that would work, but it also means you need to
account for all the things that might want to be isolated in your
component. That's relatively clumsy.
Examples? Are you talking about DOM APIs such as querySelectorAll and
alike? Then, please refer to my other reply [1] in which I listed use cases
that involve no author scripts.
? I didn't mention DOM APIs. I'm referring back to the example you're
replying to - if you use a bar element inside your foo component,
and you know that bar has isolation styles, you have to specifically
call that out inside your foo styling so that it (a) is shielded
from your foo styles, and (b) is able to pick up the global definition
for bar styles. This is relatively clumsy. Some of the other
solutions attach the I want to be isolated information to the
element itself more directly, so you don't have to worry about what
you put inside of yourself.
This is no more clumsy than defining an insertion points in shadow DOM. Or am
I misunderstanding you?
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees.
They're two distinct features. Even though I do agree it might be
desirable to have both in many important use cases, there are use cases in
which we don't need subtree isolations.
I'm not trying to, I'm pointing out that style isolation, as a
concept, seamlessly blends into DOM isolation as you move across API
surfaces.
I don't see any connection between the two. Many of the use cases I listed
[1] require us to have DOM isolations.
I listed a number of APIs in the text you're responding to, all of
which may or may not want to pay attention to style isolation,
depending on the use-case. I'm not saying you necessarily need DOM
isolation for any given use-case. I'm saying that there are a lot of
Re: Shadow tree style isolation primitive
[oof, somehow your latest response flattened all of the quotes] On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ? I didn't mention DOM APIs. I'm referring back to the example you're replying to - if you use a bar element inside your foo component, and you know that bar has isolation styles, you have to specifically call that out inside your foo styling so that it (a) is shielded from your foo styles, and (b) is able to pick up the global definition for bar styles. This is relatively clumsy. Some of the other solutions attach the I want to be isolated information to the element itself more directly, so you don't have to worry about what you put inside of yourself. This is no more clumsy than defining an insertion points in shadow DOM. Or am I misunderstanding you? Yeah. In Shadow DOM, you can just *use* the bar element, without having to think about it. If it happens to also use shadows to isolate its contents, that's irrelevant to you; you dont' have to make a single change to your foo component in order to recognize that. That's nice composition, which isn't *strictly* necessary in any solution, but it's a really good thing. I listed a number of APIs in the text you're responding to, all of which may or may not want to pay attention to style isolation, depending on the use-case. I'm not saying you necessarily need DOM isolation for any given use-case. I'm saying that there are a lot of APIs that query or walk the DOM, and whether they should pay attention to a style isolation boundary is a question without clear answers. I don't understand what you mean here. As far as I know, there are only two sensible options here: Style isolation implies DOM subtree isolation in all DOM APIs Style isolation doesn't affect DOM APIs at all Shadow DOM does 1. I'm suggesting that we need a mechanism to do 2. It's not terrible if we introduced @isolate to do 1 and also provided shadow DOM to do 1. In that world, shadow DOM is a syntax sugar around @isolate in the CSS land with DOM API implications. I mean, those are two possible options. They're not the only ones. For example, you could say that all selectors pay attention to the isolation boundary, so qSA is affected. That's *a* consistent answer, and could be very reasonable - people often use qSA to do styling-related things, and having it respect the style boundaries makes sense there. I'm saying there are multiple places you can draw the line. I think there's a nice defensible spot at the point you end up with when you do DOM isolation - everything that cares about the DOM tree (which includes CSS selectors, defined in terms of the DOM tree) gets locked out by default. Anywhere else has arguments for it, but I don't think any of them are particularly more compelling than any other. ~TJ
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 7:45 PM, Ryosuke Niwa rn...@apple.com wrote: I understand your use case but please also understand that some authors don't want to write a few dozen lines of JavaScript to create a shadow DOM, and hundreds of lines of code or load a framework to decoratively isolate CSS rules in their pages. As far as I can tell, I am not talking about shadow dom or specifically what authors would have to write... If I did, I didn't intend to do so. I am talking about how it is explained and where. It could literally be as simple as a single line of JavaScript for purposes of what I am discussing - As anne mentioned earlier, it could just be a property of an element potentially... Maybe you could even do with markup attribute. I thought that what we were discussing was how to isolate the simpler/potentially less controversial bits of this. Conceptually then, my point then is about when you isolate to prevent accidental style leakage, it seems you nearly always want to prevent qsa and traversal kinds of leakage too, and that it wouldn't hurt you in some very rare case where you didn't explicitly *want* it, as long as you can explicitly traverse the boundary with a combinator. Quick note based on some of your other responses - I actually didn't see any proposal in the suggestions about TreeScope or a non-parent/child link connector or something that talked about insertion points... I think that is a secondary question, as is event retargeting? My comments are literally limited to the bare minimum stuff above without discussion of those. What questions do you have with regards with insertion points and event retargeting? Are you asking whether they should happen as a side effect of having a style isolation? I'm saying that you can talk about isolation without insertion points or event retargeting, which is what I got out of the thread topic. Maybe I'm wrong? I would just say that we feel event retargeting should be treated as a separate concern from style isolation. I'm denying that a style isolation with event retargeting is a valid use case but there are use cases in which style isolation without event retargeting is desirable or retargeting needs to be implemented by frameworks. Now I'm quite confused. IIRC you are the one that brought up insertion points earlier - was someone else talking about them? In any case, I agree with you, it's possible to have this conversation without those two as a start and I'd suggest we do that. - R. Niwa -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 3:51 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 2:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Jan 12, 2015 at 2:14 PM, Ryosuke Niwa rn...@apple.com wrote:
On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Let's assume we did it, though. We'd have to have some mechanism for
defining an isolation boundary, and denoting whether rules were
inside or outside the boundary. This sounds like an at-rule,
like:
@isolate .example {
h1 { ... }
div { ... }
}
Now, a problem here is that you have a conflict between nesting
isolated things and specifying isolation. Say you have foo and
bar elements, both of which need to be isolated. You'd think you
could just write:
@isolate foo {
...
}
@isolate bar {
...
}
But this won't work! If you have markup like
foobar.../bar/foo, the bar there is inside the foo's
isolation boundary, so the @isolate rule can't find it. You'd need to
*also* nest the @isolate bar rule (and all its styling rules) within
the foo one, and vice versa. The effect of this on *three* mutually
isolated components is, obviously, terrible; let's not even mention
trying to use multiple modules together that weren't explicitly
designed together.
Alternately, say that it does work - the @isolate selector pierces
through isolation boundaries. Then you're still screwed, because if
the outer page wants to isolate .example blocks, but within your
component you use .example normally, without any isolation, whoops!
Suddenly your .example blocks are isolated, too, and getting weird
styles applied to them, while your own styles break since they can't
cross the unexpected boundary.
Another alternative. We can add a host language dependent mechanism such
as an element or an attribute to end the current isolation, just like
insertion points in a shadow DOM would.
Better yet, we can provide this mechanism in CSS. e.g.
@isolate foo integrates(bar) {
...
}
@isolate bar {
...
}
(I'm not proposing this exact syntax. We can certainly do better.)
Yeah, something like that would work, but it also means you need to
account for all the things that might want to be isolated in your
component. That's relatively clumsy.
Examples? Are you talking about DOM APIs such as querySelectorAll and alike?
Then, please refer to my other reply [1] in which I listed use cases that
involve no author scripts.
? I didn't mention DOM APIs. I'm referring back to the example you're
replying to - if you use a bar element inside your foo component,
and you know that bar has isolation styles, you have to specifically
call that out inside your foo styling so that it (a) is shielded
from your foo styles, and (b) is able to pick up the global definition
for bar styles. This is relatively clumsy. Some of the other
solutions attach the I want to be isolated information to the
element itself more directly, so you don't have to worry about what
you put inside of yourself.
This last one, though, is pretty much exactly Custom Elements, just
with the children staying in the light tree rather than being moved
into a shadow tree. But keeping them in the light tree has
complications; it means that everything in the platform needs to be
made aware of the isolation boundary. Should qSA respect the
isolation boundaries or not? Depends on what you're using it for.
What about things that aren't CSS at all, like getElementsByTagName()?
That's equivalent to a qSA with the same argument, but it's not a
selector, per se. Manual tree-walking would also need to be made
aware of this, or else you might accidentally descend into something
that wants isolation. Shadow DOM at least gives an answer to all of
these, by putting the elements in a separate tree. You don't need to
think of every one individually, or deal with inconsistent design when
someone forgets to spec their new tree-searching thing to respect the
boundary.
Let's not conflate style isolation with isolation of DOM subtrees. They're
two distinct features. Even though I do agree it might be desirable to
have both in many important use cases, there are use cases in which we
don't need subtree isolations.
I'm not trying to, I'm pointing out that style isolation, as a
concept, seamlessly blends into DOM isolation as you move across API
surfaces.
I don't see any connection between the two. Many of the use cases I listed
[1] require us to have DOM isolations.
I listed a number of APIs in the text you're responding to, all of
which may or may not want to pay attention to style isolation,
depending on the use-case. I'm not saying you necessarily need DOM
isolation for any given use-case. I'm saying that there are a lot of
APIs that query or walk the DOM, and whether they should pay attention
to a style isolation boundary is a question without clear answers.
~TJ
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 4:16 PM, Brian Kardell bkard...@gmail.com wrote: Sure, here are some use cases I can think off the top of my head: Styling a navigation bar which is implemented as a list of hyperlinks Styling an article in a blog Styling the comment section in a blog article Styling a code snippet in a blog article None of these scenarios require authors to write scripts. - R. Niwa I'm sorry, this might be dense but as use cases go those seem incomplete I believe you intend to illustrate something here, but I'm not getting it... Is the idea that the nav bar wants to deliver this is how I am styled without interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like this is actually really hard to manage with CSS and here's potentially a way to make it 'scope' easier? It's both that the navigation bar wants to have its own set of CSS rules and doesn't want to get affected by other CSS rules; and it's hard to manage a large number of CSS rules manually without an encapsulation mechanism like a style isolation boundary [1]. [1] http://stackoverflow.com/questions/2253110/managing-css-explosion - R. Niwa
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 7:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:16 PM, Brian Kardell bkard...@gmail.com wrote: Sure, here are some use cases I can think off the top of my head: 1. Styling a navigation bar which is implemented as a list of hyperlinks 2. Styling an article in a blog 3. Styling the comment section in a blog article 4. Styling a code snippet in a blog article None of these scenarios require authors to write scripts. - R. Niwa I'm sorry, this might be dense but as use cases go those seem incomplete I believe you intend to illustrate something here, but I'm not getting it... Is the idea that the nav bar wants to deliver this is how I am styled without interference from the page, potentially through some assembly on the server or preprocess or something? Or it is just like this is actually really hard to manage with CSS and here's potentially a way to make it 'scope' easier? It's both that the navigation bar wants to have its own set of CSS rules and doesn't want to get affected by other CSS rules; and it's hard to manage a large number of CSS rules manually without an encapsulation mechanism like a style isolation boundary [1]. [1] http://stackoverflow.com/questions/2253110/managing-css-explosion - R. Niwa Yeah, ok, that's what I thought you meant. Professionally, I come up with this case all the time and the number of cases where I want JavaScript ops to inadvertently poke into me is 0. Let's use your menu case, lets say that I have a class=title on some menu elements and use id=main - because, hey, that's one reason we like style isolation, we don't need to invent complex strategies. Fairly high odds that someone else in the page will qsa those and do something bad to me inadvertently. Having those respect the same boundary for the same seems very, very natural to me. Quick note based on some of your other responses - I actually didn't see any proposal in the suggestions about TreeScope or a non-parent/child link connector or something that talked about insertion points... I think that is a secondary question, as is event retargeting? My comments are literally limited to the bare minimum stuff above without discussion of those. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
[ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] On Mon, Jan 12, 2015 at 5:23 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:59 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 4:18 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 4:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: ? I didn't mention DOM APIs. I'm referring back to the example you're replying to - if you use a bar element inside your foo component, and you know that bar has isolation styles, you have to specifically call that out inside your foo styling so that it (a) is shielded from your foo styles, and (b) is able to pick up the global definition for bar styles. This is relatively clumsy. Some of the other solutions attach the I want to be isolated information to the element itself more directly, so you don't have to worry about what you put inside of yourself. This is no more clumsy than defining an insertion points in shadow DOM. Or am I misunderstanding you? Yeah. In Shadow DOM, you can just *use* the bar element, without having to think about it. I don't know what you mean by one doesn't have to think about it. The style applied on bar won't propagate into the shadow DOM by default [1] unless we use /deep/ or [2] The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. In the previous examples, we weren't talking about defining styling for bars that are specifically inside of foos, just how to style bar generically, regardless of its context. Current shadow DOM makes that easy to do without requiring the different components to know about each other in any way; the declarative CSS mechanisms we were previously discussing did not. I mean, those are two possible options. They're not the only ones. For example, you could say that all selectors pay attention to the isolation boundary, so qSA is affected. That's *a* consistent answer, and could be very reasonable - people often use qSA to do styling-related things, and having it respect the style boundaries makes sense there. I'm saying there are multiple places you can draw the line. I think there's a nice defensible spot at the point you end up with when you do DOM isolation - everything that cares about the DOM tree (which includes CSS selectors, defined in terms of the DOM tree) gets locked out by default. Anywhere else has arguments for it, but I don't think any of them are particularly more compelling than any other. What are other sensible alternatives? I agree there are other options but they aren't sensible as far as I'm concerned. [1] http://jsfiddle.net/seyL1vqn/ [2] http://jsfiddle.net/seyL1vqn/1/ I listed several in the text you're responding to, and previous replies. ~TJ
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. It's sending HTML-quoted stuff, which doesn't survive the flattening to plain-text that I and a lot of others do. Plain-text is more interoperable. The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. If that's the behavior we want, then we should simply make @isolate pierce through isolates. You previously mentioned that: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Alternately, say that it does work - the @isolate selector pierces through isolation boundaries. Then you're still screwed, because if the outer page wants to isolate .example blocks, but within your component you use .example normally, without any isolation, whoops! Suddenly your .example blocks are isolated, too, and getting weird styles applied to them, while your own styles break since they can't cross the unexpected boundary. But this same problem seems to exist in shadow DOM as well. We can't have a bar inside a foo behave differently from ones outside foo since all bar elements share the same implementation. I agree Yes! But pay attention to precisely what I said: it's problematic to, for example, have a command to isolate all class=example elements pierce through isolation boundaries, because classes aren't expected to be unique in a page between components - it's very likely that you'll accidentally hit elements that aren't supposed to be isolated. It's okay to have *element name* isolations pierce, though, because we expect all elements with a given tagname to be the same kind of thing (and Web Components in general is built on this assumption; we don't scope the tagnames in any way). But then we're not actually providing selectors to the isolate mechanism, we're just providing tagnames, and having that affect the global registry of tagnames. That's fine, it's just a different type of solution, with different contours, and it's much closer to normal web components stuff. (And thus it makes more sense to stick as close to web components as reasonable, to reduce the number of slightly-different concepts authors have to think about.) ~TJ
Re: Shadow tree style isolation primitive
On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. It's sending HTML-quoted stuff, which doesn't survive the flattening to plain-text that I and a lot of others do. Plain-text is more interoperable. The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. If that's the behavior we want, then we should simply make @isolate pierce through isolates. You previously mentioned that: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Alternately, say that it does work - the @isolate selector pierces through isolation boundaries. Then you're still screwed, because if the outer page wants to isolate .example blocks, but within your component you use .example normally, without any isolation, whoops! Suddenly your .example blocks are isolated, too, and getting weird styles applied to them, while your own styles break since they can't cross the unexpected boundary. But this same problem seems to exist in shadow DOM as well. We can't have a bar inside a foo behave differently from ones outside foo since all bar elements share the same implementation. I agree Yes! But pay attention to precisely what I said: it's problematic to, for example, have a command to isolate all class=example elements pierce through isolation boundaries, because classes aren't expected to be unique in a page between components - it's very likely that you'll accidentally hit elements that aren't supposed to be isolated. It's okay to have *element name* isolations pierce, though, because we expect all elements with a given tagname to be the same kind of thing (and Web Components in general is built on this assumption; we don't scope the tagnames in any way). I don't want to go too much on a tangent but it seems like this is a dangerous assumption to make once components start depending on different versions (e.g. v1 versus v2) of other components. Also, it's not hard to imagine authors may end up defining custom elements of the same name to be used in their own components. If someone else then pulls in those two components, one of them will be broken. To solve a dependency problem like this, we need a real dependency resolution mechanism for components. But then we're not actually providing selectors to the isolate mechanism, we're just providing tagnames, and having that affect the global registry of tagnames. I don't think having a global registry of tag names is a sufficient nor a necessary mechanism to address the issue at hand. As such, I'm not suggesting or supporting that. - R. Niwa
Re: Shadow tree style isolation primitive
Intent to remove style scoped in blink-dev is here: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R1x18ZLS5qQ On Tue Jan 13 2015 at 1:26:52 PM Marc Fawzi marc.fa...@gmail.com wrote: Can someone shed light at why Scoped Style Element was removed from Chrome experimental features? http://caniuse.com/#feat=style-scoped In suggesting @isolate declaration, I meant it would go inside a scoped style element. If there are nested scope style elements and each have @isolate then it means that the styles don't bleed from parent with scoped style to child with scoped style if child has @isolate The big question is why was scoped style element removed from Chrome 37's experimental flags? Just curious. On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. It's sending HTML-quoted stuff, which doesn't survive the flattening to plain-text that I and a lot of others do. Plain-text is more interoperable. The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. If that's the behavior we want, then we should simply make @isolate pierce through isolates. You previously mentioned that: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Alternately, say that it does work - the @isolate selector pierces through isolation boundaries. Then you're still screwed, because if the outer page wants to isolate .example blocks, but within your component you use .example normally, without any isolation, whoops! Suddenly your .example blocks are isolated, too, and getting weird styles applied to them, while your own styles break since they can't cross the unexpected boundary. But this same problem seems to exist in shadow DOM as well. We can't have a bar inside a foo behave differently from ones outside foo since all bar elements share the same implementation. I agree Yes! But pay attention to precisely what I said: it's problematic to, for example, have a command to isolate all class=example elements pierce through isolation boundaries, because classes aren't expected to be unique in a page between components - it's very likely that you'll accidentally hit elements that aren't supposed to be isolated. It's okay to have *element name* isolations pierce, though, because we expect all elements with a given tagname to be the same kind of thing (and Web Components in general is built on this assumption; we don't scope the tagnames in any way). I don't want to go too much on a tangent but it seems like this is a dangerous assumption to make once components start depending on different versions (e.g. v1 versus v2) of other components. Also, it's not hard to imagine authors may end up defining custom elements of the same name to be used in their own components. If someone else then pulls in those two components, one of them will be broken. To solve a dependency problem like this, we need a real dependency resolution mechanism for components. But then we're not actually providing selectors to the isolate mechanism, we're just providing tagnames, and having that affect the global registry of tagnames. I don't think having a global registry of tag names is a sufficient nor a necessary mechanism to address the issue at hand. As such, I'm not suggesting or supporting that. - R. Niwa
Re: Shadow tree style isolation primitive
Can someone shed light at why Scoped Style Element was removed from Chrome experimental features? http://caniuse.com/#feat=style-scoped In suggesting @isolate declaration, I meant it would go inside a scoped style element. If there are nested scope style elements and each have @isolate then it means that the styles don't bleed from parent with scoped style to child with scoped style if child has @isolate The big question is why was scoped style element removed from Chrome 37's experimental flags? Just curious. On Mon, Jan 12, 2015 at 6:27 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 6:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jan 12, 2015 at 5:59 PM, Ryosuke Niwa rn...@apple.com wrote: On Jan 12, 2015, at 5:41 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: [ryosuke, your mail client keeps producing flattened replies. maybe send as plain-text, not HTML?] Weird. I'm not seeing that at all on my end. It's sending HTML-quoted stuff, which doesn't survive the flattening to plain-text that I and a lot of others do. Plain-text is more interoperable. The style defined for bar *in bar's setup code* (that is, in a style contained inside bar's shadow tree) works automatically without you having to care about what bar is doing. bar is like a replaced element - it has its own rendering, and you can generally just leave it alone to do its thing. If that's the behavior we want, then we should simply make @isolate pierce through isolates. You previously mentioned that: On Jan 12, 2015, at 1:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Alternately, say that it does work - the @isolate selector pierces through isolation boundaries. Then you're still screwed, because if the outer page wants to isolate .example blocks, but within your component you use .example normally, without any isolation, whoops! Suddenly your .example blocks are isolated, too, and getting weird styles applied to them, while your own styles break since they can't cross the unexpected boundary. But this same problem seems to exist in shadow DOM as well. We can't have a bar inside a foo behave differently from ones outside foo since all bar elements share the same implementation. I agree Yes! But pay attention to precisely what I said: it's problematic to, for example, have a command to isolate all class=example elements pierce through isolation boundaries, because classes aren't expected to be unique in a page between components - it's very likely that you'll accidentally hit elements that aren't supposed to be isolated. It's okay to have *element name* isolations pierce, though, because we expect all elements with a given tagname to be the same kind of thing (and Web Components in general is built on this assumption; we don't scope the tagnames in any way). I don't want to go too much on a tangent but it seems like this is a dangerous assumption to make once components start depending on different versions (e.g. v1 versus v2) of other components. Also, it's not hard to imagine authors may end up defining custom elements of the same name to be used in their own components. If someone else then pulls in those two components, one of them will be broken. To solve a dependency problem like this, we need a real dependency resolution mechanism for components. But then we're not actually providing selectors to the isolate mechanism, we're just providing tagnames, and having that affect the global registry of tagnames. I don't think having a global registry of tag names is a sufficient nor a necessary mechanism to address the issue at hand. As such, I'm not suggesting or supporting that. - R. Niwa
Re: Shadow tree style isolation primitive
If the goal is to isolate a style sheet or several per a DOM sub tree then why not just use scoped style element that has imports that apply the stylesheet(s) only to the sub tree in scope? Obviously, you are talking about preventing stylesheets applied at a higher level from leaking in. So maybe then in the scoped style element there can be some @ declaration like @isolate that would tell the browser not to apply any styles defined at a higher level. Not sure how browsers would implement that but it seems that since we (developers) already have a way to define scoped style that it ought to be possible to isolate the elements that we're applying the scoped style to from styles defined by the user at a higher level while still applying user agent styles. Just a thought... Sent from my iPhone On Jan 12, 2015, at 8:47 AM, Brian Kardell bkard...@gmail.com wrote: On Mon, Jan 12, 2015 at 7:04 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 10:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: tl;dr: Cramming a subtree into a TreeScope container and then hanging that off the DOM would do the job for free (because it bakes all that functionality in). Sure, or we could expose a property that when set isolates a tree. Both a lot simpler than requiring ShadowRoot. However, it seems to me that ideally you can control all of this through CSS. The ability to isolate parts of a tree and have them managed by some other stylesheet or selector mechanism. Controlling it through CSS definitely seems to be very high-level. To me at least it feels like it requires a lot more answering of how since it deals with identifying elements by way of rules/selection in order to differentially identify other elements by way of rules/selection. At the end of the day you have to identify particular elements as different somehow and explain how that would work. It seems better to start there at a reasonably low level and just keep in mind that it might be a future aim to move control of this sort of thing fully to CSS. Since CSS matching kind of conceptually happens on 'not exactly the DOM tree' (pseudo elements, for example) it seems kind of similar to me and it might be worth figuring that out before attempting another high-level feature which could make answering 'what's the path up' all that much harder. -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 11:51 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 12, 2015 at 5:47 PM, Brian Kardell bkard...@gmail.com wrote: Controlling it through CSS definitely seems to be very high-level. To me at least it feels like it requires a lot more answering of how since it deals with identifying elements by way of rules/selection in order to differentially identify other elements by way of rules/selection. At the end of the day you have to identify particular elements as different somehow and explain how that would work. It seems better to start there at a reasonably low level and just keep in mind that it might be a future aim to move control of this sort of thing fully to CSS. I'm not sure I agree. Unless you make all of CSS imperative it seems really hard to judge what belongs where. It's important that at least qsa/find/closest style things defined in Selectors match the same in script as in CSS matching. Whatever solution likely needs to include this consideration. I've heard some worries about async/sync requirements regarding rendering here but I'd say it's further than that if it's rule based too from my perspective - this seems like something we're going to have to deal with anyway in a larger sense of extensibility. I wouldn't (personally) let that dictate that we can't do this in script - there are lots of places where that seems practical/controllable enough even now and we could make globally better with some effort. Basing this off something in CSS matching, as opposed to DOM means that new roots can come into play (or leave) in a document-wide sense based on the addition or removal or rules. This seems confusing and problematic to me and the combination of these was relevant to my comment about what's matching what. It seems to me that identifying a shadow root is concrete to an instance and once it's there, it's there. You can consciously choose to combinator select through it or not, but it's there unless the physical DOM changes. -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 7:04 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 10:11 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: tl;dr: Cramming a subtree into a TreeScope container and then hanging that off the DOM would do the job for free (because it bakes all that functionality in). Sure, or we could expose a property that when set isolates a tree. Both a lot simpler than requiring ShadowRoot. However, it seems to me that ideally you can control all of this through CSS. The ability to isolate parts of a tree and have them managed by some other stylesheet or selector mechanism. Controlling it through CSS definitely seems to be very high-level. To me at least it feels like it requires a lot more answering of how since it deals with identifying elements by way of rules/selection in order to differentially identify other elements by way of rules/selection. At the end of the day you have to identify particular elements as different somehow and explain how that would work. It seems better to start there at a reasonably low level and just keep in mind that it might be a future aim to move control of this sort of thing fully to CSS. Since CSS matching kind of conceptually happens on 'not exactly the DOM tree' (pseudo elements, for example) it seems kind of similar to me and it might be worth figuring that out before attempting another high-level feature which could make answering 'what's the path up' all that much harder. -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Mon, Jan 12, 2015 at 5:47 PM, Brian Kardell bkard...@gmail.com wrote: Controlling it through CSS definitely seems to be very high-level. To me at least it feels like it requires a lot more answering of how since it deals with identifying elements by way of rules/selection in order to differentially identify other elements by way of rules/selection. At the end of the day you have to identify particular elements as different somehow and explain how that would work. It seems better to start there at a reasonably low level and just keep in mind that it might be a future aim to move control of this sort of thing fully to CSS. I'm not sure I agree. Unless you make all of CSS imperative it seems really hard to judge what belongs where. Since CSS matching kind of conceptually happens on 'not exactly the DOM tree' (pseudo elements, for example) it seems kind of similar to me and it might be worth figuring that out before attempting another high-level feature which could make answering 'what's the path up' all that much harder. This is false. Selector matching happens against the DOM tree. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
On Jan 9, 2015 8:43 AM, Anne van Kesteren ann...@annevk.nl wrote: I'm wondering if it's feasible to provide developers with the primitive that the combination of Shadow DOM and CSS Scoping provides. Namely a way to isolate a subtree from selector matching (of document stylesheets, not necessarily user and user agent stylesheets) and requiring a special selector, such as , to pierce through the boundary. This is a bit different from the `all` property as that just changes the values of all properties, it does not make a selector such as div no longer match. So to be clear, the idea is that if you have a tree such as section class=example h1Example/h1 div ... /div /section Then a simple div selector would not match the innermost div if we isolated the section. Instead you would have to use section div or some such. Or perhaps associate a set of selectors and style declarations with that subtree in some manner. -- https://annevankesteren.nl/ For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)?
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. Yeah, these are the reasons I ask - shadowRoot IMO kind of solves these parts of the problem in really the only sensible way I can imagine, but I think what you're saying is it's too much - and - is there a lesser thing, something maybe underneath that proposal which just offers this part. That's why I say, kind of a fragment root of which maybe if we get to shadow dom it could be a special type of? I guess you're not proposing that but I am saying what about a proposal like that would it answer your concerns? -- https://annevankesteren.nl/ -- Brian Kardell :: @briankardell :: hitchjs.com
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting this effort, so this is timely. :DG On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
Here's an attempt from 2012. This approach doesn't work (the trivial plumbing mentioned in the doc is actually highly non-trivial), but maybe it will give some insights to find the right a proper solution: https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing :DG On Fri, Jan 9, 2015 at 7:54 AM, Dimitri Glazkov dglaz...@google.com wrote: For the record, I am a huge fan of exploring this. I tried a couple of times, but was unable to extract this primitive from Shadow DOM in a clean way. I talked with Tab late last year about restarting this effort, so this is timely. :DG On Fri, Jan 9, 2015 at 7:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 9, 2015 at 4:35 PM, Brian Kardell bkard...@gmail.com wrote: For clarity, are you suggesting you'd control the matching boundary via CSS somehow or you'd need an indicator in the tree? A new element/attribute or something like a fragment root (sort of a shadowroot-lite)? I wasn't suggesting anything since I'm not sure what the best way would be. It has to be some flag that eventually ends up on an element so when you do selector matching you know what subtrees to ignore. If you set that flag through a CSS property you'd get circular dependencies, but perhaps that can be avoided somehow. Setting it through an element or attribute would violate separation of style and markup. -- https://annevankesteren.nl/
Re: Shadow tree style isolation primitive
On Fri, Jan 9, 2015 at 8:08 AM, Dimitri Glazkov dglaz...@google.com wrote: Here's an attempt from 2012. This approach doesn't work (the trivial plumbing mentioned in the doc is actually highly non-trivial), but maybe it will give some insights to find the right a proper solution: https://docs.google.com/document/d/1x2CBgvlXOtCde-Ui-A7K63X1v1rPPuIcN2tCZcipBzk/edit?usp=sharing tl;dr: Cramming a subtree into a TreeScope container and then hanging that off the DOM would do the job for free (because it bakes all that functionality in).
