[css-ui] Changing UA styles based on the computed value of the appearance property

[josepharhar]

I'm working on improvements to the <select> element (whatwg thread here), and I came across an issue while implementing a prototype of the Apple-supported behavior of switching to a new rendering mode based on the value of the appearance property.

The select element has several UA style rules which we don't want in the new rendering mode, such as white-space:pre, which makes all of the options in the popup have a bunch of line breaks rendered in my examples.

I tried adding an internal pseudo-selector which matches when the element has the new appearance value, but I found that it took two style updates to get the final style, which @andruud described as a "non-starter".

@annevk suggested that I should ask here to see if there is a way that we can make this work.

Also, if there are any previous discussions about the appearance property that are related to this, I would appreciate links to them.

cc @nt1m

[annevk]

#5998 is the other thread.

In particular what we're looking for here is a way whereby a new value of the appearance property impacts the backing style sheet of the element. It's acceptable if this mechanism only works for HTML form controls.

@nt1m conceptualized this idea as a user agent at-rule, e.g.,

select {
  @appearance-base {
    border: thin solid ButtonBorder;
    ...
  }
}

(Conceptually this needs to be something like an at-rule as you might need to style various states as well.)

[josepharhar]

I’ve tried implementing a few solutions to this and here are my thoughts:

solution 1: internal pseudo-class for child content

We could have an internal pseudo-class which matches the select when it has a child in the new content model, which would be a button or datalist. This way we can adjust the UA styles based on the new DOM to get the new UA styles. I currently have this implemented in the chromium prototype here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css;l=918-929;drc=df34b11bbe7a46c53c782a6d4a24145a4af05e10

Issues:

• In the case that you put appearance:bikeshed on a select which doesn’t have the new <button> or <datalist> content, you won’t get updated UA styles.

solution 2: adjust style after style calculation to remove old appearance:auto UA styles

After style recalc, chromium and webkit have a style adjuster which changes the computed style. We could look for appearance:bikeshed on a select element here and remove a few styles we don’t want, like border and background-color. I started a patch to implement this in chromium here: https://chromium-review.googlesource.com/c/chromium/src/+/5348242/2/third_party/blink/renderer/core/css/resolver/style_adjuster.cc

Issues:

• If the author uses appearance:bikeshed and then wants to apply the exact same border, background-color, etc that we removed from the UA stylesheet, it will be removed by the style adjuster and the author won’t even know why.

solution 3: leave the UA styles in there

We could just leave the problematic UA styles in there and make the developer revert all of them when they apply appearance:bikeshed.

Issues:

• This has poor ergonomics, would get negative feedback from developers, and may hurt adoption of this feature.

solution 4: put an attribute on select to opt-in

We could use an HTML attribute instead of appearance:bikeshed to opt in to the new behavior and content model (similar to to the proposed switch attribute?). This attribute could be used in the UA stylesheet to change the styles as desired.

solution 5: add an internal pseudo-class or @ rule which matches when style is computed to appearance:bikeshed

We could add an internal @ rule or internal pseudo-class to gate the UA styles based on appearance as desired.

Issues:

• As I explained in the issue description, this would require two style recalcs to get a final style.

@emilio do you have any thoughts?

[annevk]

I'm not sure solution 5 would require two style passes. I think that depends on how it's implemented. If it's implemented in terms of solution 2 for instance, maybe not? Also, for solution 2 you can read out author styles and account for them. It's just a lot of work which is why some kind of novel mechanism is needed that abstract that so you don't have to implement "base style sheets" from scratch for each control.

[emilio]

I agree with @andruud that requiring two styling passes is a no-go. It's also cyclic, even though if you restrict the pseudo-class / at-rule to the UA sheet you can kinda cheat and assume that there's no cycle...

What styles do you plan to apply to <select> on this case? <select> already has default styles that are somewhat reasonable (borders etc) for appearance: none.

We discussed this with @annevk and @mfreed7 in the context of <input type=checkbox switch> too. My preference would be to not do this. Have the default styles be sane and either:

• Make appearance: none be the "stylable, uses a non-replaced box and thus has pseudo-elements and other goodies" behavior (we can do this for switch, but likely not for <select>).
• Make appearance: base create a non-replaced box, and thus render child elements, have pseudo-elements etc. appearance: none would still create a replaced box that wouldn't create renderers / layout objects for the pseudo-elements and thus would remain behaving as it is.

This has no cycles and is trivialish to implement, but whether this is possible depends on the kind of styling differences that you want to have between base and none / auto.

[emilio]

cc @chrishtr and @zcorpan who were also in that conversation.

[emilio]

For the white-space: pre issue that can probably be removed? Gecko at least doesn't have it unless I'm missing something.

[emilio]

Ah, I guess gecko has white-space: nowrap !important. But we could make that part of the internal box styles for the none / auto case.

[nt1m]

@emilio While your suggestion does remove magic from style system, it does introduce a burden to the web developer to specify input::decoration (or however the anonymous box will be targeted by the web dev), which I think is undesirable.

[emilio]

@nt1m you mean select::decoration (or something)? And how so? You can use styles for the internal anonymous box when appearance isn't base, and make base give you a regular box.

[nt1m]

Would the base styles for the input move to the anonymous box? Or would the anonymous box have a pseudo-element to target them (e.g. ::decoration) with the UA sheet styling that?

[emilio]

What kinds of differences do we want between none and base? Most controls with none look reasonable (checkbox / radio being the exception).

My preference would be to keep the styles the same, and the difference would be which kind of box none creates vs. base (so that e.g. display: flex works with appearance: base and so on).

[josepharhar]

I reviewed all of the UA styles for <select> as well as the ones desired for a stylable <select>. It turns out that we don't need to change style on the <select> element; we only need to style its child elements like the options, button or datalist. We can do that with new interoperable UA styles that always apply, even for existing usages of <select>, since existing <select> usage has no children that render via CSS.

Therefore "solution 3: leave the UA styles in there" will work fine and turns out to have no significant problem of poor ergonomics. And we can go with what Emilio suggested and all is well.

When the time comes to add stylability to other form controls, we can follow this pattern and just leave existing interoperable UA styles in place, and expect developers to add in their own customizations.

[annevk]

But that means we cannot for instance have consistent sizing and theming for appearance:base controls, can we? Because whenever any of that would clash with none it would not be okay? I thought the idea with base was that we'd have a "web native" consistent look & feel across form controls.