- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Wed, 04 Feb 2015 08:33:17 -0800
- To: Olli Pettay <olli@pettay.fi>
- Cc: Brian Kardell <bkardell@gmail.com>, Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
> On Feb 4, 2015, at 4:56 AM, Olli Pettay <olli@pettay.fi> wrote: > > On 02/03/2015 04:22 PM, Brian Kardell wrote: >> >> On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay <olli@pettay.fi <mailto:olli@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
Received on Wednesday, 4 February 2015 16:34:28 UTC