On 02/03/2015 04:22 PM, Brian Kardell wrote:

On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay <o...@pettay.fi 
<mailto:o...@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:


        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.

    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.


    "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

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


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/>

Reply via email to