Support Custom Pseudo-elements

[hayatoito]

See the proposal from @philipwalton.
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Custom-Pseudo-Elements.md

Let me file an issue here to discuss and keep track of the proposal.

[hayatoito]

At the first glance, the proposal sounds good to me.
I think we would have more questions and answers for detail, however, before proceeding, I'd like to hear more opinions from other people.

@tabatkins, WDYT if you have a chance to take a look?

[rniwa]

We would prefer using part syntax as follows so that future pseudo element names we introduce in CSS wouldn't interfere with author defined parts components expose:

<date-range-selector>
  <!-- #shadow-root -->
    <div id="container">
      <input part="start-date" id="start-date" type="date">
      <input part="end-date" id="end-date" type="date">
    </div>
  <!-- /shadow-root -->
</date-range-selector>

date-range-selector:part(start-date),
date-range-selector:part(end-date) {
  /* normal styles */
}

@hober @othermaciej

[tabatkins]

Yeah, if we do add custom pseudo-elements, we need to do it namespaced, like ::part.

That said, the CSSWG provisionally accepted my @apply rule draft, which makes pseudo-elements unnecessary for WC.

That is, CSS variables handle most of the styling needs of WC already. They only fall down when you want to offer the ability to arbitrarily style an element; there are too many properties to make it reasonable to offer enough variables for styling. Pseudo-elements expose an element for arbitrary styling, so that's useful. The @apply rule also does that, tho, and via the existing mechanism of CSS custom properties, so there's probably no need to add custom pseudo-elements.

[philipwalton]

@tabatkins I'm aware of the @apply rule (it was discussed in the issue that prompted this proposal), and I think in general using @apply with custom properties is the best way to style third-party elements.

However, I brought up several use-cases in the proposal that I think are legitimate and that I don't think the @apply rule can handle (unless I'm misunderstanding part of its functionality).

You said:

Pseudo-elements expose an element for arbitrary styling, so that's useful. The @apply rule also does that [...]

Can you go into more detail here? How would the @apply rule handle the styling of an input element only in the :focus, :enabled, and :out-of-range state? As far as I can tell, the only way is for the element author to hard-code that selector in the element's shadow styles. Something like:

input {
  /* normal input styles */
  @apply --date-range-selector-inputs;
}
input:focus:enabled:out-of-range {
  /* input styles for the focus, enabled, and out-of-range states */
  @apply --date-range-selector-inputs-focused-enabled-out-of-range;
}

It seems unreasonable for component authors to have to anticipate and hard-code every element state their users may ever want to style. Exposing the element itself is much simpler and still maintains the privacy of other element in the component (unlike ::shadow/>>>).

[tabatkins]

You're right, this doesn't handle pseudo-classes well. I'll have to give that some thought.

[morewry]

I'm just a user, but, in my opinion, there is a need for pseudo-element functionality from a perspective of allowing a component author to provide a stable public interface for styling a component. As a component author, I should be able to change the internal implementation details of my web component without any disruption to a component user. The only way I can feasibly do that is to have an explicit mechanism for defining my publicly style-able surface. Custom pseudo elements do this. While @apply appears to actually do so as well, custom pseudo elements have benefits beyond lack of difficulty with pseudo classes.

Vendor elements that utilize obscured internals have long allowed styling of certain portions via pseudo elements. And, correct me if I'm wrong, isn't there some work on standardizing these for common replaced elements, like form controls? Therefore, with custom pseudo elements, a user authored component would be style-able like a vendor component. Having user authored elements feel like native elements is a good thing--and not only because having the standard explain the existing platform is nice.

A component user does not have to learn any new language constructs to style a custom pseudo element, and yet can still enhance their use of a custom pseudo element with new CSS features as they develop. While I am enthusiastic about bringing popular pre-processor features (and implied enhancements, like @apply) to CSS, I am also of the opinion that, in respect to web component styles, we should lean toward allowing CSS authors to simply...write familiar CSS. Since several of the CSS standards are brand spanking new, surely they would have kinks needing to be worked out? As a result, it seems to me that it would be putting the cart before the horse to hang the style story for Shadow DOM on them.

[tabatkins]

Efforts to standardize the internal pseudo-elements aren't very successful, unfortunately. I keep trying to get something done with that, but it's very difficult to do in a reasonable way. I'm not confident that it will ever be achieved.

Mixins and Nesting are battle-tested concepts with long histories from CSS preprocessors; their mixture, especially, has a long history of use in Sass (and maybe more?). These aren't new concepts, they're just new to vanilla CSS. And they lean on existing useful and well-tested concepts from CSS, like inheritance and properties.

Custom pseudo-elements, on the other hand, don't. We've had pseudo-elements for a long time, but only a small number, and they don't nest. We still need to figure out how to solve a number of issues before it's usable:

1. Are shadow-pseudos more like classes or IDs? That is, do they need to be unique, or is it ok to have multiple selected by the same name? If you can have multiple, how do we select a single one to style? Does the component author have to allow this? Can a single element expose multiple pseudo names for itself?
2. How do we handle both a parent and child exposing themselves as pseudo-elements? Is the nesting visible or not? If yes, can you write ::foo::bar?
3. (This one's important and hard.) If a component contains other components, and wants to expose some of its sub-components parts as pseudo-elements, how does it surface them? Are they selectable by default somehow (if so, how do you handle namespacing)? If not, how do you expose them? Is it apparent that they come from a sub-component, or can the parent component make them look "native"?

All of these questions apply to vars/@apply/nesting too, but they all have definite, simple answers there, and those answers are imo reasonable behavior. We have no idea what the answers would be for pseudo-elements, tho.

This is why it's backwards to characterize vars/@apply/nesting as "new and untested" and pseudo-elements as "old and well-known". It's almost exactly the opposite when you dig into details.

[philipwalton]

Are shadow-pseudos more like classes or IDs? That is, do they need to be unique, or is it ok to have multiple selected by the same name? If you can have multiple, how do we select a single one to style? Does the component author have to allow this? Can a single element expose multiple pseudo names for itself?

I imagined them as being non-unique, like classes. It's extremely likely that component authors will create elements with many children of the same type, like a <ul> element does today.

Though that raises the question (at least in my mind) of whether or not to allow a single HTML element to have more than one pseudo element name. To continue with the <date-range-selector> element example, the start and end date inputs are both inputs, and will probably want to be styled similarly, but they also might want to be styled individually. Should it be possible to select the start date field via both ::start-date and ::field (or whatever). Perhaps by allowing space-separated pseudo attribute name definitions: e.g. <input pseudo="field start-date">.

How do we handle both a parent and child exposing themselves as pseudo-elements? Is the nesting visible or not? If yes, can you write ::foo::bar?

(This one's important and hard.) If a component contains other components, and wants to expose some of its sub-components parts as pseudo-elements, how does it surface them? Are they selectable by default somehow (if so, how do you handle namespacing)? If not, how do you expose them? Is it apparent that they come from a sub-component, or can the parent component make them look "native"?

I think this paradigm can be simplified to just components and their sub-components, rather than thinking of it in terms of a possibly infinitely nested tree of shadow components (ala /deep/). As long as the component author exposes the sub-component via a custom pseudo-element, it shouldn't matter how many levels deep it's nested. For example:

<x-foo>
  <!-- #shadow-root -->
    <x-bar pseudo="x-bar-item">
  <!-- /shadow-root -->
</x-foo>

If <x-bar> exposes its own ::x-baz-item pseudo-element, then consumers of <x-foo> could theoretically style ::x-baz-item pseudo-elements from a main document stylesheet via something like:

x-foo::x-bar-item::x-baz-item {
  color: red;
}

This paradigm allows for /deep/-like styling without the performance implications or the exposing of component internals.

[philipwalton]

As I was writing that last post, I thought of a possible solution to the pseudo-class/@apply issue. Borrowing from Sass, again, pseudo-element states could be defined in the custom property definition via the &:pseudo-class nesting syntax.

Here's what it could look like:

:root {
  --x-foo-styles: {
    color: blue;

    &:hover {
      background-color: yellow;
    }
    &:active {
      outline: 1px dotted;
    }
  }
}

This, if @apply-ed in a shadow <style> declaration, would only be applied when the pseudo-class states matched.

There are definitely some specificity/cascade issues to iron out, but if this could work, then I believe all my concerns about custom property shortcomings would be alleviated.

[rniwa]

Like we agreed during the last F2F, custom properties, @apply, and custom pseudo elements aren't conflicting ideas. They address slightly different use cases and both can be supported.

In particular, in an isolated web component case where neither component nor its container document trusts each other, we can't expose all mixins defined in the container document into the shadow tree.

Also, there is an added benefit of developer familiarity with custom pseudo elements. While the technical problems faced by nested rules and @apply might be similar (or even simpler as you claim) to those faced by custom pseudo elements, relying solely on three brand new CSS syntax seems like a lot of cognitive load.

[rniwa]

Also, where is the proposal for nesting syntax? Is it https://lists.w3.org/Archives/Public/www-style/2011Jun/0022.html ?

[othermaciej]

I think custom pseudos are a good direction. Comments on some specific issues:

(1) It's critical for component authors to be able to whitelist the set of style properties that can be applied to an exposed named part.
(2) I'm somewhat partial to :part syntax because then we never have to worry about namespace collisions with future CSS built-in pseudos.
(3) I don't think prefixing is necessary. If pseudo names are reused between different custom elements, that's not a problem, because you can specify the element and part.
(4) I don't think @apply plus the increasing series of other features that need to come along with it is a replacement. The syntax is pretty inscrutable. I immediately understand what Philip's named part examples are doing, but I don't understand what his @apply + nesting proposal does.
(5) Having a nice and easy to understand syntax for consumers of a component is important. Unlike many other aspects of web components, this syntax will be used by many garden-variety web developers, not just authors of JavaScript frameworks.

[tabatkins]

@philipwalton (re: nesting) Yes, that's precisely what I was getting at when I was talking about @apply/nesting. ^_^ There's no specificity issues to iron out - It Just Works™.

@rniwa

Like we agreed during the last F2F, custom properties, @apply, and custom pseudo elements aren't conflicting ideas. They address slightly different use cases and both can be supported.

No, they don't address slightly different use-cases. They address the exact same use-cases.

In particular, in an isolated web component case where neither component nor its container document trusts each other, we can't expose all mixins defined in the container document into the shadow tree.

Sure we can. And when you do want to block, that's what all: initial is for. (Alternately, an equivalent of all for just custom properties has been proposed; it would be called --, as in --: initial.) You can then let particular custom properties thru with --foo: inherit.

Also, there is an added benefit of developer familiarity with custom pseudo elements. While the technical problems faced by nested rules and @apply might be similar (or even simpler as you claim) to those faced by custom pseudo elements, relying solely on three brand new CSS syntax seems like a lot of cognitive load.

I already addressed this in my earlier reply to Rachel.

@othermaciej

(1) It's critical for component authors to be able to whitelist the set of style properties that can be applied to an exposed named part.

Why? CSS doesn't do this today. ::before/after take all properties. ::first-line and friends don't, but that's because they're not actually elements, they're bizarre collections of fragments (to use CSS terms), and that limits what you can reasonably do with them. That's not relevant to this topic, tho; we're only planning to expose actual elements here.

If you want to whitelist properties, that's best done with simple CSS variables - expose variables for each property you want to allow. If you want to expose arbitrary styling but blacklist some properties for sanity, that's trivially done with @apply - just list the blacklist properties with their desired values after the @apply rule. With custom pseudos, this is yet another new thing you'll have to define and introduce, presumably in JS.

(2) I'm somewhat partial to :part syntax because then we never have to worry about namespace collisions with future CSS built-in pseudos.

Yes, ::part() is definitely a preferable syntax for pseudo-elements here.

(4) I don't think @apply plus the increasing series of other features that need to come along with it is a replacement. The syntax is pretty inscrutable. I immediately understand what Philip's named part examples are doing, but I don't understand what his @apply + nesting proposal does.

It's not "increasing", it's complete. Variables/@apply/nesting are a complete styling feature.

The syntax is relatively new, but a lack of immediately familiarity doesn't automatically imply "inscrutable". It's a declaration block stuffed into a custom property. Nesting is familiar to users of every single CSS preprocessor in existence, and is consistently one of the most popular and highly used features. The learning curve here is miniscule based on practical evidence.