- From: Olli Pettay <olli@pettay.fi>
- Date: Wed, 04 Feb 2015 14:56:29 +0200
- To: Brian Kardell <bkardell@gmail.com>
- CC: Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
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. -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/>
Received on Wednesday, 4 February 2015 12:56:56 UTC