Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-writing-modes] writing-mode on form control elements #8633

Open
josepharhar opened this issue Mar 22, 2023 · 6 comments
Open

[css-writing-modes] writing-mode on form control elements #8633

josepharhar opened this issue Mar 22, 2023 · 6 comments
Labels
css-writing-modes-3 css-writing-modes-4 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.

Comments

@josepharhar
Copy link
Contributor

The spec says that user agents "should" instead of "must" respect writing mode in replaced elements. I suppose this makes sense for native form control picker popups that don't support being rotated for writing mode on some native platforms.

However, there are parts of the controls that the user agent can control because they are actually rendered inside the page and don't use native platform code to render, such as the button to open a picker for various input types, the <button> element, the <textarea> element, etc.

There are also several WPTs which have been included in interop2023 to test this behavior (for the part rendered inside the page), but they all have optional in their name (which seems like a contradiction to me), and I'm guessing it's because the spec says "should" instead of "must": https://wpt.fyi/results/css/css-writing-modes/forms?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2022-forms%20or%20label%3Ainterop-2023-forms
cc @nt1m who has worked on these tests

I don't know about the other browsers, but in chromium we even have a user agent stylesheet rule to disable writing-mode for certain form control elements and I don't know why we have it: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/resources/html.css;l=410-413;drc=5fa2480334f68dbe19ee6591cba86dde6bb25603

In discussions for the new <selectmenu> element, this was also raised as an issue with interest in changing the "should" to a "must": openui/open-ui#600 (comment)

Should the spec say "must" instead of "should"?
Should user-agent stylesheets disable writing-mode on form control elements like chromium is doing or not?

@tabatkins
Copy link
Member

The "should" is indeed because replaced elements might be out of the UA's direct control, yeah. Still, "should" means "do it unless there's a good reason not to", so if we can support writing-mode, we, uh, "should".

@nt1m
Copy link
Member

nt1m commented Mar 24, 2023

The reason I marked them as optional is because each platform may choose to different things in terms of form controls, e.g. iOS uses a button for <select multiple> instead of a listbox, so some of the tests don't necessarily apply.

@fantasai
Copy link
Collaborator

fantasai commented Mar 29, 2023

SHOULD is an RFC2119 keyword defined thus:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

I agree with Tab that the spec is correct as-is.

Should user-agent stylesheets disable writing-mode on form control elements like chromium is doing or not?

The answer to this is clearly no. The UA should support writing-mode on any form control elements that it can.

@josepharhar Do you have enough information here to close the issue, or do you still think something needs to change?

@nt1m
Copy link
Member

nt1m commented Mar 29, 2023

I don't know about the other browsers, but in chromium we even have a user agent stylesheet rule to disable writing-mode for certain form control elements and I don't know why we have it:

This is historical and inherits from WebKit, WebKit has the same CSS rule because no one at the time had time to make form controls writing mode compatible.

@josepharhar
Copy link
Contributor Author

I agree with Tab that the spec is correct as-is.

Sounds good

Do you have enough information here to close the issue, or do you still think something needs to change?

Sounds like we don't need anything in css to change.
I just wonder if we can remove that user agent style in chromium, and if we can enforce writing-mode for <selectmenu> when I try to get it specced and tested since it will not be rendering any native OS stuff, despite it technically being a form control element.

This is historical and inherits from WebKit, WebKit has the same CSS rule because no one at the time had time to make form controls writing mode compatible.

Do you think we should remove that rule?

@nt1m
Copy link
Member

nt1m commented Mar 29, 2023

Do you think we should remove that rule?

Yeah, I think this rule shouldn't have been added and form controls should have been made writing mode compatible (and the folks who wrote this rule at the time seem to agree this was temporary)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-writing-modes-3 css-writing-modes-4 Current Work i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response.
Projects
None yet
Development

No branches or pull requests

6 participants