Re: [shadow-styling] Named parts, styling built-in form controls, and shadow styling (was Re: Goals for Shadow DOM review)

On Fri, Feb 21, 2014 at 11:34 AM, Edward O'Connor <eoconnor@apple.com> wrote:
> Hi Brian,
>
> You wrote:
>
>> We did have named parts at one time, i think that they turned out to
>> have the same "shadow-deep" problem with composibility.
>
> I think the current approach to the shadow-deep problem misses one of
> the scenarios that motivates the desire for type 2 encapsulation.
>
> Consider a page that has a component B. It also has a component A that
> itself contains a component B.
>
> Page
>  |
>  |-A
>  | |
>  | \-B1
>  |
>  \-B0
>
> There are a couple of different styling scenarios that I think any
> acceptable component model should support:
>
>  1. The author of component A has created a small, self-contained widget
>     that has its own look-and-feel. When embedded on different pages,
>     all A widgets should look the same. It should be really hard for
>     page authors embedding component A to screw this up. B1 shouldn't be
>     affected by CSS the page author intended to affect B0.
>
>  2. The author of component A has created a widget that should adapt to
>     the look-and-feel of the page embedding it. The page author wants to
>     style all of the Bs on the page in the same way. B1 should look the
>     same as B0.
>
> Now, the page also has a component C that contains a B:
>
> Page
>  |
>  |-A
>  | |
>  | \-B1
>  |
>  |-C
>  | |
>  | \-B2
>  |
>  \-B0
>
> Say component A is scenario 1 and component C is scenario 2. The page
> author should be able to straightforwardly author CSS that styles B0 and
> B2 but not B1.

That is relatively straightforward - style up ":matches(b0, c /shadow/
b2) /shadow/ ...".

If this is somewhat cumbersome (if you have to target multiple
elements, and thus repeat your selector multiple times), it's because
our tools for authoring CSS are bad.  Using any of (1) nested style
rules, (2) selector aliases, or (3) @extend from SASS, this is simple
to do.  This cumbersomeness is not a result of the scenario, it's a
general problem in CSS authoring.

This doesn't necessarily mean we shouldn't have some kind of "make me
even harder to style" flag, of course, just that the problem you're
describing can be solved in other ways.

Note that it's also possible that the page author might not *care*
what A's author wanted, and wants to style B1 anyway.  We shouldn't
make this impossible unless there are security-boundary reasons for
the restriction.  Thus, solving your scenario in a way that involves
the page author making the proactive choice might be best.

~TJ

Received on Friday, 21 February 2014 20:09:11 UTC