-
Notifications
You must be signed in to change notification settings - Fork 681
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
Comments
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". |
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 |
SHOULD is an RFC2119 keyword defined thus:
I agree with Tab that the spec is correct as-is.
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? |
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. |
Sounds good
Sounds like we don't need anything in css to change.
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) |
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?
The text was updated successfully, but these errors were encountered: