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.

"Its intuitive then to create a combinator in CSS which allows you to select the 
mount explicitly"
Yes, I agree with that assuming the mount actually wants to be selectable.
And even if all the mounts were selectable, we don't have atm a way to select 
some particular
mount explicitly. And I think we should have that explicitly-ness. >>> or 
/deep/ are like
select all and cross your fingers you selected what you wanted, and not 
anything more.
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(*)


"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.


Without the explicitly-ness we're back having the initial problems we're trying 
to solve, as the
blog says
"That is, preventing accidental violence against your allies is really hard – it’s simply too easy to accidentally select and operate on elements that aren’t “yours“. "
Same explicitly-ness should apply to things like Event.path etc.




(I still think shadow DOM needs proper encapsulation, even if components would 
all be 'allies'. A use case for encapsulation
would be rather similar to private: or protected: in many languages. But 
encapsulation is perhaps a bit different issue from
weaker isolation.)



-Olli

Reply via email to