On 02/03/2015 04:22 PM, Brian Kardell wrote:
On Tue, Feb 3, 2015 at 8:06 AM, Olli Pettay <[email protected]
<mailto:[email protected]>> 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.
-Olli
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/>
