1556554 - text-transform is inherited by `<button>` and `<select>`

Status: RESOLVED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[Mike Pennisi [:jugglinmike]]

Attachment: form-control-no-inherit-text-transform.patch

Other user agents have long disabled text-transform inheritance for these elements, and web developers have signaled their preference by implementing that styling in various "CSS normalizer" projects.

• Implementation in normalize.css https://github.com/necolas/normalize.css
• Implementation in sanitize.css https://github.com/csstools/sanitize.css
• Implementation in marx https://github.com/mblode/marx
• Implementation in WebKit
  https://github.com/WebKit/webkit/blob/89c28d471fae35f1788a0f857067896a10af8974/Source/WebCore/css/html.css#L360
• Implementation in Chromium
  https://chromium.googlesource.com/chromium/src/+/9b0f9c1/third_party/blink/renderer/core/html/resources/html.css#406

A patch to the specification is under review here:

https://github.com/whatwg/html/pull/4672

Comment 1

[Emilio Cobos Álvarez (:emilio)]

So Blink and WebKit also do this for all of input, textarea, select, button... Should we also do that?

Also, are there tests for that patch?

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We already have it for input and textarea:
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/layout/style/res/forms.css#101,141
from bug 150341.

Comment 3

[Simon Pieters [:zcorpan]]

Test at https://github.com/web-platform-tests/wpt/pull/17152

Comment 4

[Mats Palmgren (inactive)]

Doing this for input, textarea, select seems reasonable given that they are replaced elements.
I disagree with <button> though - it creates CSS boxes for its children and flows them
according to CSS rules, so properties should inherit without surprises there IMO.

Comment 5

[Cameron McCormack (:heycam)]

Thanks for the patch Mike. It looks like in the GitHub issue people agree with not having the button rule. Could you update the patch? Thanks!

Comment 6

[Mike Pennisi [:jugglinmike]]

Thanks for taking a look at this, Cameron! We're still waiting on support from
WebKit in that discussion thread. Given that the goal is interoperability, I'd
rather not commit to a change that we don't yet expect to be implemented
consistently. It may be that we forgo technical purity in the interest of
interoperability.

If you don't mind, I'd like a little more time to get buy-in from WebKit.

Comment 7

[Simon Pieters [:zcorpan]]

I have made a new proposal in the spec issue, though this needs buy-in from Gecko.

https://github.com/whatwg/html/issues/1310#issuecomment-520795729

Comment 8

[Mats Palmgren (inactive)]

Replied on the spec issue.

Comment 9

[Simon Pieters [:zcorpan]]

The spec change and wpt tests have landed: https://github.com/whatwg/html/issues/1310#issuecomment-524088613

Comment 10

[Cameron McCormack (:heycam)]

This eventually got done in bug 1481112. Thanks for writing that initial patch, Mike.

Comment 11

[Mike Pennisi [:jugglinmike]]

Ah, too bad!

This and bug 1567323 make two patches in two months that have been superseded by work from Mozilla employees. I can only imagine how complicated it is to manage this project, so it's understandable. Also, I was fortunate enough to write the patches as part of my day job. I'm just a little concerned for other external contributors who can't say the same.

:heycam is there anyone on the triage team(s) who would be interested in hearing about this?

Comment 12

[Cameron McCormack (:heycam)]

Sorry about that! I would put it down to it being difficult to keep track of all the bugs we have on file and their current status. I know that I am guilty of filing a bug to fix an issue, not having found a previously filed bug because I didn't use the same set of keywords in the bug title. And for the number of bugs within the components I'm interested in, I basically can't keep up with regular bug comment mails. Using needinfo to get someone's attention is probably more likely to be successful.

Looking at bug 1567323 specifically, attaching a patch without flagging a specific reviewer will likely result in the patch not being noticed. If you have a complete patch that you'd like to get landed, please do use Phabricator and request review from someone. If you don't know who might be a good reviewer, start off by choosing someone who's an owner or peer of the module of the code you're changing: https://wiki.mozilla.org/Modules/All

But your point about dropping contributors' patches is a good one, and points like the above should be documented somewhere if they're not already. I'm not sure how up to date the documentation at https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide is but it looks like it does talk about how to submit patches, use of Phabricator, etc.

Comment 13

[mike]

Thanks very much, Cameron. That's helpful feedback, and I appreciate your taking the time to share it :)