Csswg-drafts: [css-ui] Auto-disable native appearance when cascaded value has author origin

[andruud]

Browsers currently automatically disable the native appearance of widgets in some cases, even if
appearance is e.g. auto (see issue 11). This can happen when the author styles the border, background, or in Firefox's case padding (I believe).

This issue is not about _which_ properties disable the native appearance, but _how_ they disable appearance, which is quite different in Firefox (which has reasonable behavior) vs Chrome/Safari (which has ... less reasonable behavior):

In Chrome (and as far as I can see in Safari), the native appearance is disabled when the author styles the background/border in such a way that it differs from the _would-be_ background/border had only UA-origin declarations existed. This approach isn't great, because:

• Tweaking the UA-style due to e.g. a redesign of widgets can toggle native behavior on or off in the wild. (This exact thing happened in Chrome recently).
• You can get different results in multiple dimensions: for each type of widget, each OS, each browser, depending on what's specified in the UA sheets. This also makes it entirely incomprehensible for authors.
• It adds annoying technical complexity, since we must somehow know the computed values of an alternate cascade-reality that shouldn't need to exist.

Instead, we should specify that border/background/etc applied by the author origin disables the native appearance _regardless of their value_. This is (to the best of my knowledge) what Firefox does currently.

See also related Intent to Ship on blink-dev.

[zcorpan]

https://github.com/whatwg/html/pull/4857 has a start for defining this. See https://whatpr.org/html/4857/rendering.html#appropriate-widget

https://github.com/whatwg/html/pull/4857#issuecomment-525261650 is not yet fixed, though.

[smfr]

whatwg/html#4857 has a start for defining this. See https://whatpr.org/html/4857/rendering.html#appropriate-widget

Shouldn't CSS define this, rather than HTML?

[smfr]

A downside of the Gecko behavior is that an author can't "get back" to the UA rendering by setting the property value to one that matches the UA stylesheet.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Auto-disable native appearance when cascaded value has author origin.

The full IRC log of that discussion

<dael> Topic: [css-ui] Auto-disable native appearance when cascaded value has author origin

<dael> github: https://github.com/w3c/csswg-drafts/issues/4777

<dael> florian: We have appearance property with atuo look native. WHen in native there's a number of properties where if you set to a value it disables native-ness. Example is border-bottom

<dael> florian: 2 things undefined. What's the set of properties that have this effect and on which elements. Other thing, this issue, is how do these properties disable. One is FF which if author sets to any value it disables nativeness. Chrome is the values is set different then UA it disables nativeness. Chrome plans to switch to FF behavior

<dael> florian: Not spec anywhere, but an attempt in HTML and a placeholdder in CSS UI 4. Mostly a heads up from Chrome they are trying this. BUt if people think it's a bad idea it's good to say so before they try

<dael> smfr: I think Chrome inherited from WK. WOuld be interested in seeing experiment. If successful WK probably willing to follow

<dael> florian: Since appearance are sensistive to compat I'm interested to wait out experiment before changing spec

<dael> Rossen_: We're at top of hour. Anyone from Chrome that could have feedback on success now? If not we push back to GH and discuss next week

<dael> florian: No experiement yet. Pinging us before hand in case it sounds like a terrible idea. Doesn't sound like it is so we should let them run and report back.

<dael> Rossen_: I see.

<dael> Rossen_: Let's end here and then hopefully we'll get data back from Chrome experiementation

[Loirooriol]

an author can't "get back" to the UA rendering

Maybe revert could do this?

[ExE-Boss]

Firefox already supports revert since version 67 (bug 1215878).

[Loirooriol]

@ExE-Boss But <button style="border: revert">Button</button> disables the native appearance in Firefox.

[emilio]

Yeah, I think we could support revert switching back to the native appearance pretty easily though.

[emilio]

@andruud looking at the blink implementation, it seems you account for border-image properties too, which is something that we don't do: Is that intentional?

I'm not quite sure if we do that intentionally or not (would need to dig the history a bit). Both ignoring them and not ignoring them makes some amount of sense, we probably just need to agree on which one makes more sense or is more useful to authors.

[andruud]

@emilio It's intentional in the sense that I (for now) didn't intend to change _which_ properties disable appearance, just _how_ it happens.

I guess if other visual aspects of the border (color, width, etc) are grounds for disabling, then border-image* is as well? (I don't have a strong opinion). I'm in general not a very big fan of this auto-disabling feature, but since we have it, we should probably always auto-disable when an author declaration would effectively be ignored by maintaining the appearance.

* And maybe border-radius?

[zcorpan]

@andruud commented in https://github.com/whatwg/html/pull/4857#discussion_r435044451 that we might want to include animation origin and transition origin as well, not only author origin.

[zcorpan]

@smfr

whatwg/html#4857 has a start for defining this. See https://whatpr.org/html/4857/rendering.html#appropriate-widget

Shouldn't CSS define this, rather than HTML?

Yes, probably some things should be moved to CSS UI. Also see https://github.com/w3c/csswg-drafts/issues/3526