Re: Shadow tree style isolation primitive

> 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