- From: Brian Kardell <bkardell@gmail.com>
- Date: Tue, 3 Feb 2015 09:22:09 -0500
- To: Olli Pettay <olli@pettay.fi>
- Cc: Dimitri Glazkov <dglazkov@google.com>, "www-style@w3.org" <www-style@w3.org>, WebApps WG <public-webapps@w3.org>
- Message-ID: <CADC=+jdjitFZYiX8OU0XB_B103FrkEPZ7EmzXJjcKbimXN_eNg@mail.gmail.com>
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay <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/ >> >> 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
Received on Tuesday, 3 February 2015 14:22:41 UTC