Re: [csswg-drafts] [css-forms-1] Should `appearance: base` inherit more text-related properties? (#11486)

The CSS Working Group just discussed ``[css-forms-1] Should `appearance: base` inherit more text-related properties?``, and agreed to the following:

* `RESOLVED: text-shadow, text-rendering, letter-spacing, word-spacing, text-autospace all inherit, and text-transform, text-align, text-indent are reset`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> ntim: so this is about inheriting more text-related properties in apperance:base<br>
&lt;TabAtkins> ntim: a few months ago i was playing with custom select in chrome, a few text properties weren't inherited<br>
&lt;TabAtkins> ntim: think wa sfixed in chrome, but no formal resolution<br>
&lt;TabAtkins> ntim: elika and i also discussed taht transform, align, and indent should not be inherited and should probably reset<br>
&lt;TabAtkins> ntim: any other thoughts on this?<br>
&lt;TabAtkins> TabAtkins: what are the properties we're adding?<br>
&lt;TabAtkins> ntim: there's a list in the issue<br>
&lt;TabAtkins> ntim: text-shadow, text-rendering, letter-sapcing, word-spacing, text-auto-space<br>
&lt;TabAtkins> ntim: and resetting text-transform, text-align, text-indent<br>
&lt;emilio> q+<br>
&lt;TabAtkins> TabAtkins: those all make sense to me<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: do other form controls inherit any of these?<br>
&lt;TabAtkins> ntim: this is just for appearance:base, font and color already inherit<br>
&lt;TabAtkins> emilio: seems okay, a bit concerned about adding more dependencies from appearnce to random properties, in terms of causing confusion<br>
&lt;TabAtkins> emilio: but not objecting, if you think it's better that's okay<br>
&lt;TabAtkins> emilio: i'd just prefer to not do it if possible<br>
&lt;TabAtkins> ntim: the reason i filed this issue is i was doing a website and i wanted to put some inputs in a table, and wanted them to be transparent in the table, and table styles to inherit into them<br>
&lt;TabAtkins> ntim: just like  a div<br>
&lt;TabAtkins> emilio: right. i don't know if introducing such strong differneces between base and auto will be a positive or negative in practice<br>
&lt;TabAtkins> emilio: like, this *is* something you can do today and it's already confusing for authors, adding more could be unfortuante<br>
&lt;TabAtkins> ntim: appearnce:base is kinda a chance to reset things and give authors a better behavior. basically the same behavior you get from a div on the page<br>
&lt;TabAtkins> emilio: but we're not *really* restarting, right, this value already exists<br>
&lt;astearns> ack dbaron<br>
&lt;TabAtkins> emilio: so i'm just not convinced it's much of a net benefit, but i don't want to block. just concerned it'll be more confusing than not<br>
&lt;TabAtkins> dbaron: almost a side comment, in support of text-indent and text-aling<br>
&lt;TabAtkins> dbaron: in some sense the logic of text-indent and text-align might have been better if they applied to a BFC rather than being inherited<br>
&lt;TabAtkins> dbaron: so it kinda makes sense to inherit those onto things that are likely to be blocks but reset on things likely to be inline-blcoks<br>
&lt;emilio> q+<br>
&lt;TabAtkins> dbaron: becuase you usually don't want them to inherit into inline blocks<br>
&lt;emilio> q-<br>
&lt;TabAtkins> dbaron: you probably don't want these to leak into the inline-block<br>
&lt;TabAtkins> dbaron: so given standard form styling, i think this makes sense<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: +1 to what dbaron just said, that's a core part of the logic<br>
&lt;emilio> q+<br>
&lt;TabAtkins> fantasai: and the reason for blocking text-transform, unless the author specifically wants tex-ttransform to take affect, it's confusing to the user if what they see and what they type aren't the same. so authors should be explicit about this<br>
&lt;TabAtkins> fantasai: for the rest, i agree with Tim that the conceptual model for appearance:base is blending with the rest of the page<br>
&lt;TabAtkins> fantasai: and inheriting anything that affects text styles - not just font, but spacing and such as well - makes sense<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: jsut clarifying, resetting those isn't really a behavior change<br>
&lt;TabAtkins> emilio: so we're in agreement there, and i generally agree with dbaron's points too<br>
&lt;TabAtkins> emilio: the behavior change is inheriting a bunch of new stuff (not resetting them, as we do today)<br>
&lt;TabAtkins> emilio: but i don't object<br>
&lt;TabAtkins> emilio: if we could explain it just via CSS it woudl be nicer<br>
&lt;TabAtkins> emilio: but this feels very cosmetic, easy to do if you need/want<br>
&lt;TabAtkins> emilio: i'd rather avoid the UA magic to get there<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: if you think about appearance:normal, we're taking the OS appearnce and pulling it into the page. for appearance:base, we're blending it into the page.<br>
&lt;TabAtkins> fantasai: the styles we've set up - using currentcolor, a transparent bg, etc - achieves this<br>
&lt;TabAtkins> fantasai: having some things not apply is confusing for that mental model, and might not always be immediately noticeable<br>
&lt;TabAtkins> fantasai: as for style changing, we alreayd have to apply different props based on base or auto anyway, this is just another on the list<br>
&lt;fantasai> emilio, it's more magic from your point of view, but less magic from the author's point of view :)<br>
&lt;TabAtkins> ntim: so proposed resolution is we should inherit [the properties listed in the issue] and reset [the other properties listed in the issue]<br>
&lt;emilio> q+<br>
&lt;TabAtkins> fantasai: in other words we inherit text-tasnform, text-aling, and text-indent, and inherit everything else as normal<br>
&lt;astearns> ack emilio<br>
&lt;TabAtkins> emilio: do we mention cursor? unsure that should be inherited.<br>
&lt;TabAtkins> emilio: would rather go with an explicit list<br>
&lt;TabAtkins> fantasai: for white-space we should set it to 'pre', spaces should be visible since it's in the value<br>
&lt;TabAtkins> fantasai: for cursor, not sure what it normally does for text inputs, if it's different form the rest of the page we should set it accordingly<br>
&lt;TabAtkins> astearns: dont' think emilio was saying we should make a decision on those two properties, just because there are more complexities with styles, we should resolve on just this finite list of properties<br>
&lt;TabAtkins> emilio: yeah, i agree on those properties. in practice we only need to inherit some things that are reset by the UA stylesheet.<br>
&lt;astearns> ack dbaron<br>
&lt;fantasai> PROPOSED: Reset text-indent, text-align, and text-transform to initial values; set white-space to pre; and inherit all other text properties mentioned in the issue<br>
&lt;dbaron> I think the proposal is to inherit text-shadow text-rendering letter-spacing word-spacing text-autospace and to reset text-transform text-align text-indent<br>
&lt;TabAtkins> PROPOSED: text-shadow, text-rendering, letter-spacing, word-spacing, text-autospace all inherit, and text-transform, text-align, text-indent are reset<br>
&lt;TabAtkins> astearns: objections to these 8 properties?<br>
&lt;TabAtkins> RESOLVED: text-shadow, text-rendering, letter-spacing, word-spacing, text-autospace all inherit, and text-transform, text-align, text-indent are reset<br>
&lt;TabAtkins> astearns: a follow-on reoslution would be to have appearance:base set white-space:pre<br>
&lt;TabAtkins> ntim: that might be no change from current state?<br>
&lt;TabAtkins> dbaron: think it differs on control<br>
&lt;TabAtkins> astearns: another issue, then<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11486#issuecomment-2770347743 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 April 2025 18:29:55 UTC