W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2015

Re: Shadow tree style isolation primitive

From: Brian Kardell <bkardell@gmail.com>
Date: Tue, 3 Feb 2015 09:22:09 -0500
Message-ID: <CADC=+jdjitFZYiX8OU0XB_B103FrkEPZ7EmzXJjcKbimXN_eNg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:25 UTC