[css-shadow-parts] consider moving part-mapping to style rules

[fergald]

This came up in a meeting with Salesforce. It seems reasonable to consider this option.

The current spec provides the partmap attribute to allow a part inside a sub-component to be stylable from outside the containing component. This means that forwarding rules are spread across many elements, e.g.

<x-bar>
  # shadow
  <x-foo partmap="inner outer">...</x-foo>
  <x-foo partmap="inner outer">...</x-foo>
  <x-buz partmap="buz-part">...</x-foo>
</x-bar>

An possible alternative to that would be to include the part-mapping information in the style rules. There are several ways we could do this e.g.

<x-bar>
  # shadow
  <style>
    /* this causes x-bar::part(outer) to match elements inside x-foo */
    x-foo::part(inner) { @outer-name(outer) } 
    /* expose buz-part without renaming */
    x-buz::part(buz-part) { @outer-name() } 
  </style>
  <x-foo>...</x-foo>
  <x-foo>...</x-foo>
</x-bar>

Alternative ways of expressing this could be e.g.

@partmap myMap::x-foo {
	inner => outer; 
}

x-foo {
    @partmap(inner, outer);
}

x-foo::part(inner) { outer-name: outer } 

Good points:

• all mappings are centralized
  • although they may be spread through multiple style elements inside the shadow root, so not necessarily centralized
  • exposing the part name map via IDL is something we want, no matter how it expressed and anyone who wants to reason about the mapping should use that
• can compress many repetitive partmaps into a single CSS rule
• makes it even easier to emulate ::theme using ::part, each shadow tree can just do ::part(theme-name) { @outer-name()} to expose all the theme-name parts
• could also be used to add part names to elements, e.g. .some-class { @outer-name(some-part) } would be the same as adding part="some-part" to all of the elements of class "some-class"

Possible objections:

• all mappings are centralized
• these are not style rules, so should not be in the style sheet
• unclear if there are implementation problems with this

This is a fairly radical departure from the current spec and if people think this is a great/terrible idea, I'd like to hear that quickly. I think there's no difference in what can be expressed in either case, the main points are:

• the ability to expressing mappings for many elements in a compact form
• centralized vs distributed

[ Edited by @dbaron to change a file: URL to the https: URL for the spec. ]

[dbaron]

My initial (and not particularly carefully considered) reaction is that it feels rather complex; it's a good bit of additional syntax both for implementors to implement and for developers to learn. If the value it provides is worth the complexity, then it seems worth considering, but it's not clear to me whether it is.

[upsuper]

This seems like proposing to make selector matching depend on cascading result... It's unclear to me whether this setup is going to work.

[fergald]

@upsuper If you think of ::part(foo) { @outer-name() } as a style rule that sets a property on all matching elements as part of the cascade then yes. But there is no property being set. So you could just think of it as a way to specify the part mappings (that is clearer in some of the alternative versions where it's an @ rule) and it would not be implemented as anything like a normal style rule.

I can imagine that this idea could be quite objectionable itself. So maybe an @ rule that looks like

<style>
@partmap {
    /* this causes x-bar::part(outer) to match elements inside x-foo */
    x-foo::part(inner) => outer;
    /* expose buz-part without renaming */
    x-buz::part(buz-part);
}
</style>

[fergald]

@dbaron I think you actually have less custom syntax in some versions of this because it's just selectors and a pseudo-property "outer-name". You've gotten rid of the comma-separated partmap attribute entirely. However you do have some new and maybe unexpected semantics to deal with.

[idoros]

Hey, we are developing a pre-processor called Stylable, which extends the idea of scoping stylesheets with the ability to expose a "style API" for inner parts & states. Improving developer experience with a static language server that provides completions and warnings for this kind of style API.

This topic is interesting to me, because although Stylable currently implements scoping by namespacing the output CSS in build time, it could potentially provide the same developer experience for styling Web-Components. and hopefully output CSS that is more similar to the source CSS, moving the scoping to the browser engine.

So currently Stylable treats any CSS class as a potential custom pseudo-element (similar to ::part()):

/* btn.st.css */
.label { color:red; }

/* panel.st.css */
:import {
    -st-from: './btn.st.css';
    -st-default: Btn; /* import Btn definition */
}
.okBtn {
    -st-extends: Btn; /* give okBtn a Btn interface */
}
.okBtn::label { color:green; } /* access the label */

Notice: Stylable source file contain custom syntax that is transpiled away (like :import, -st-extends and the access to the custom pseudo-element ::label).

Which will be transpiled into:

.btn__label { color:red; }
.panel__okBtn .btn__label { color:green; }

If css shadow parts will allow defining parts through CSS definition, it would help tools such as Stylable to provide tooling to enhance web components authoring. For example we could output the previous CSS for web components (with the .some-class { @outer-name(some-part) } suggestion):

/* btn.st.css */
.label { 
    @outer-name(label);
    color:red;
}

/* panel.st.css */
.okBtn::part(label) { color:green; }

[caridy]

thanks @fergald for creating the issue. There are few more things from the meeting yesterday that I want to give more context on why we are proposing this:

• ergonomics: creating a new IDL for the remap attribute seems very limiting, and also suffered from some of the issues mentioned above, e.g.: users will have to learn that new syntax no matter what. The only prior art that I can think of is the style attribute.
• perf: it you move the remap info into a CSS, it is probably easier to cache the remapping (speculating here). At least you don't have to worry about the remap attribute reflection and mutation.
• extensibility: in the CSS we have more room for experimentation with the rules (we have quotes, line breaks, etc).
• equivalence: ultimately, users who want to have the remap in the place where they use the element can use the style attribute with the remap rules on it. (e.g.: <x-foo style="::part(inner) { @outer-name(outer) }">...</x-foo>

Yes, there are some cons:

• you need at least one style blob to do any remapping (I don't think this is a big deal).
• decentralization since the style blob might reference things that are not longer in use by the markup (counter argument is the usage of the style attribute)

[fergald]

@caridy I think your example in 'equivalence" is not correct, style= shouldn't be a selector-declaration pair, it should just be the inside of the declaration. So, it would have to be <x-foo style="@other-name(outer)"> which is not remapping, it's just naming, so equivalent to <x-foo part="outer">. To be able to do the remapping in-place you would need to go with the version where the inner and outer names are included inside the declaration, <x-foo style="@partmap(inner, outer)"> and when you use it in a stylesheet you select the host element without using ::part(inner).

[fergald]

If there is ever any future pure-HTML use case for and API like part, for exposing bits of shadow trees in a controlled way, then we should leave it as a purely HTML feature and not bring style sheets into it it.

[fergald]

@rniwa @domenic @tabatkins please take a look at this idea. I'm not a huge fan of it (having already implemented the existing spec). It seems a bit weird and is quite different to the existing proposal but it does seem to have some upsides and I don't see an immediate reason to dismiss it. It would be great to hear strong reasons one way or the other.

[sorvell]

This seems like a pretty powerful alternative to the current spec. It seems like it could be the exclusive way to describe parts. Consider:

// Defining Parts
// in x-foo
<style>
  .thumb.active {
    @part(thumb-active);
  }
</style>

// Forwarding Parts
// in x-host that contains an x-foo
<style>
  x-foo::part(thumb-active) {
    @part(x-foo-thumb-active);
  }
</style>

This would make it pretty easy to define parts that match complex selectors. For example, this would make it easier to expose parts for the "red" and "black" squares on a checkerboard.

If this is at all feasible to implement it seems worth exploring, at least briefly.

[rniwa]

I don't think we want to implement something this complicated. It would mean we'd need to go find these part-defining rules separately and run them at a completely different timing than when we actually apply styles. This would also make it very expensive to implement any IDL attribute for the mapping, which seems highly undesirable.

[fergald]

I'm not sure why this makes IDL expensive, the map is in the stylesheet, so you mutate it as you would any other rule in the stylesheet. There wouldn't be a partmap attribute or equivalent IDL. The implementation is the biggest concern for me. At least in blink it seems fairly implementable since Blink goes element by element. For each element it moves up the tree, so as we enter a new scope we would run these rules first to find out what the current element is named in this scope. It doesn't seem very hard but it definitely is special, that said you have have something doing roughly the same thing to apply the partmap as you move up through scopes. Whether you base it on an explicit map or on something like this.

[rniwa]

Manipulating rules is decidedly worse than exposing part or partmap IDL attribute for developer ergonomics.

This proposal is definitely a lot harder to implement in WebKit than the DOM-based alternative, and it would be quite a bit slower to run.