[css-ui] Clarify scope of implementation-defined behavior for native appearance (and primitive appearance)

[annevk]

While discussing web-platform-tests/wpt#44138 via email with @zcorpan he raised this point:

I had a different understanding of the "may disregard some CSS properties" language in the spec. Changing computed styles of other properties based on native/primitive appearance seems like a fundamental change to how the CSS cascade normally works that I think it should be explicitly defined.

As an example, for the switch control the native appearance uses display:inline-grid (though display:block and the like will compute to display:grid). But when you change to the primitive appearance it'll always have display:initial. (When this was discussed during a WHATNOT call that was what the people attending preferred.)

Being able to change properties (as well as some other things) in this way will also be essential for the inevitable appearance:base-bikeshed.

cc @nt1m

[nt1m]

"may disregard some CSS properties"

To me this means engines need to be able to adjust both computed & used styles. @zcorpan interpretation I'm guessing was that the computed style would remain untouched but the used style may not match.

So it seems like we need to clarify the language computed vs. used style.

I think we should allow adjusting both computed & used styles, mainly because auto appearance may have different layout than none appearance (due to platform framework restrictions) and having that reflected in the computed style is helpful for web developers. min-height is adjusted for WebKit buttons for instance, it would be confusing if web developers didn't see it.

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Clarify scope of implementation-defined behavior for native appearance (and primitive appearance), and agreed to the following:

• RESOLVED: Disregarding CSS properties on widgets with native appearance must not affect computed values (unless required for Web-compat)

The full IRC log of that discussion

<fantasai> emilio: Seems like Webkit, but not Gecko, change the computed value of some CSS properties based on `appearance`, including `display`
<fantasai> emilio: Seems like the spec has language about disregarding some CSS properties, which is true
<fantasai> emilio: Gecko does that at used-value time
<fantasai> emilio: and don't do it much anymore
<fantasai> emilio: but we need to define whether `appearance` changes values at computed or used value tie
<fantasai> s/tie/time
<fantasai> florian: Part of the idea here is that if you're in native appearance mode, the way you're rendered might not be describable by CSS at all
<fantasai> florian: to the extent it does, it might be nice to hint at how
<fantasai> florian: but this was an allowance for not being describable by CSS
<fantasai> emilio: so it seems like it shouldn't affect computed values
<fantasai> florian: that makes sense to me
<fantasai> emilio: WebKit is forcing `display: grid` on <input switch> which doesn't seem great to me, especially since other form controls don't do that
<fantasai> iank_: That seems not great to me
<fantasai> iank_: We do this as part of final step in computation, and only for border-padding on checkbox/radio and one more small thing
<emilio> https://github.com//issues/3257
<fantasai> emilio: the other one I'm ware of is line-height: normal on select
<fantasai> emilio: and that sucks
<fantasai> emilio: so given everything else doesn't touch computed values, can we agree on not doign this at computed value time when possible?
<fantasai> emilio: and in the future? except for existing compat?
<fantasai> florian: Situation is, if I'm understnading correctly, in order not mess with native appearance ...
<fantasai> emilio: if effective appearance is not none, then for legacy reasons you need to disregard author-set border and padding
<fantasai> emilio: Gecko does it at used-value time, and Blink does it at used value-time
<fantasai> iank_: We'll go through creating computed style, then look at appearance, see that it's not none, and then force-reset the border, as if it as 'border: none !important'.
<fantasai> florian: I would agree that should be done at used-value time
<fantasai> florian: whether you fix the value by [...] then you shouldn't be able to tell the difference
<fantasai> iank_: how do you do it at used-value time?
<fantasai> emilio: when we are laying out, we override the border
<fantasai> emilio: [various things] are not great
<fantasai> florian: I would agree with used value, and don't expose in the OM
<fantasai> florian: the further we can go in that direction the better
<fantasai> iank_: In general, I would prefer if we didn't rely on this mechanism more
<fantasai> s/this/this computed-value-changing/
<fantasai> emilio: especially as more features rely on dependencies on properties, this will only cause more confusion and weird behavior
<fantasai> florian: Proposed that disregarding CSS properties when widgets have their native appearance must not change the computed value
<fantasai> iank_: Going forward
<dbaron> iank_: we might have a compat issue for checkboxes/radios
<fantasai> florian: would prefer to avoid making used values visible also, but can live with it for compat
<fantasai> iank_: It can be visible through used values
<fantasai> florian: shaded-wavy-border-style is not visible through OM, but 2px thickness is, ideally we don't expose either
<fantasai> iank_: changing the internals to grid will change how baselines are calculated, and that's observable
<fantasai> iank_: so these things are observable at used time
<fantasai> emilio: but shouldn't be observed at computed value time
<fantasai> iank_: would prefer if only going forward
<fantasai> fantasai: how about "unless required by Web-compat"
<fantasai> iank_: ok
<fantasai> Rossen_: any objections?
<fantasai> RESOLVED: Disregarding CSS properties on widgets with native appearance must not affect computed values (unless required for Web-compat)

[annevk]

What does this resolution mean for width and height?

cc @emilio @bfgeek @frivoal

[frivoal]

@annevk The point of this resolution is that "disregarding" a property means that the user agent is free to render the widget in a way that possibly disagrees with the value of the property.

The main motivation is that the widget may be rendered in a way that isn't even possible to represent in CSS. It's not about being allowed to override the value specified by the author with some other value, but being allowed to ignore the property entirely. So even if the value would be representable in css (and just happen to disagree with the author styles), that's considered an implementation detail: if the UA is doing something else, it's doing something else, and that's not observable via the computed value.

width and height are not special here, and the result is that they're (allowed to be) the handled same as what would happen on a <span> or some other non-replaced inline: they don't apply, don't have an effect, and the UA figures out the size of the widget some other way. But just because it does so doesn't mean that all of sudden the computed value is changed. So for instance, if some child element of the the widget has height: inherit that'll get the original value.

[nt1m]

I think @fantasai mentioned that width and height are always defined to be the used value in CSSOM, which is what makes it special in this case. Firefox / Chrome don't have to think about this given those match regardless of the appearance, but it's not unreasonable for system frameworks to force a different layout and reflect that in the computed style?

It would be misleading if the size wasn't reflected in this case in the computed style, especially if that size is bigger.

[frivoal]

I think @fantasai mentioned that width and height are always defined to be the used value in CSSOM, which is what makes it special in this case.

The resolution is about the computed value, not about the used value, nor about the result of the getComputedStyle() method, which, confusingly, doesn't always return computed values.

Conceptually, the same arguments could apply to the used value as well, but the discussion didn't explore that too much, and there was a sense that this may be more challenging from an implementation point of view, so that is currently left undefined.

It would be misleading if the size wasn't reflected in this case in the computed style

<style>span { width: 3px; }</style>
<span id=test>supercallifragilisticexpialidocious</span>
<script>console.log(getComputedStyle(test).width);</script>

This will yield "3px", even thought the span is bigger then 3px, because width and height don't apply to non-replaced inlines. Same thing here.

(I used getComputedStyle() for simplicity here, and in does in this case return the computed value. You could observe the computed value some other way, it would still be 3px.)

it's not unreasonable for system frameworks to force a different layout and reflect that in the computed style?

The idea is that it's not always doable when you're choosing to have a non-css based appearance, so we should not try to reflect the value even if we could do it some of the time. Let's say that the border property has been set to 3px solid black, but your widget looks like this:

Or maybe it has a border that looks like that:

There's no value you can put in the border property that will do this. So you leave the property's value be 3px solid black, you ignore it, and you paint the lovely eye candy. If instead if your native appearance happens to have a 5px solid purple border, you don't pipe that back into the property just because this one could be represented in CSS. If you're doing something custom that's different from what the author asked, you're doing something different, and it's not reflected back.