Open gregwhitworth opened 2 years ago
@dandclark @mfreed7
The Writing Modes spec actually has an example of both an input and a select drop-down in vertical writing mode to illustrate the expectations: https://www.w3.org/TR/css-writing-modes-4/#example-fb72ee40
The requirement to do it right is only a SHOULD rather than a MUST because there's a wide variety of replaced elements, and a UA might not be able to handle all of them appropriately.
But for form controls, they are under the UA's control, so it should be trying. My expectation would be that every bit of text that's horizontal in a horizontal writing mode should be vertical in a vertical writing mode, and the layouts should be adjusted analogously. Remember that some writing systems are vertical-only, the same way that English is horizontal-only, and while sometimes “sideways” text (wrt native orientation) is appropriate in a design, that's not going to be normal or particularly readable.
Thanks @fantasai that’s some really helpful/interesting context.
The requirement to do it right is only a SHOULD rather than a MUST
I can understand this. Is there any way we might be able to increase the pressure here? Writing modes have significant impact on layout and I can’t think of an easy way to test for this with @supports
.
The Writing Modes spec actually has an example of both an input and a select drop-down in vertical writing mode to illustrate the expectations: https://www.w3.org/TR/css-writing-modes-4/#example-fb72ee40
LOL, that's what I get for simply searching for replaced elements rather than reading the whole spec :P
Thanks as always @fantasai
The Open UI Community Group just discussed How should writing-mode work with selectmenu
, and agreed to the following:
RESOLVED: UAs must respect writing-mode for all of a selectmenu's default content.
I only just now noticed this thread. Fwiw, the i18n WG has an open gap report on this topic at https://github.com/w3c/clreq/issues/247. That points to some tests that may be useful, and to bug reports we raised against browsers.
One thing that is not made clear there, nor here, nor did i mention it at https://www.w3.org/International/articles/vertical-text/#forms_etc, is the cascade direction for a select list. In vertical Chinese & Japanese (& Korean) you'd expect the items to select should extend to the left of the line, since that's the direction in which lines flow for those languages (ie. vertical-rl).
For Mongolian, however, vertical lines flow from left to right, so the select options, should probably appear on the right. And any little angled pointer should also point to the right.
In case it helps, i posted pictures of what i'd expect to see in vertical text for input.text, textarea, and select.
Japanese https://r12a.github.io/scripts/jpan/ja.html#interaction Chinese https://r12a.github.io/scripts/hani/zh.html#interaction Mongolian https://r12a.github.io/scripts/mong/mn.html#interaction
This issue has been accepted to be addressed in interop 2023 and from an implementation side this should get resolved this year.
However this doesn’t resolve the resolution this group came up with to change the wording in the spec from “should” to “must”.
The Open UI Community Group just discussed [selectmenu] How should writing-mode work with selectmenu
.
Thanks @r12a, I will use your examples as a guide to implement this behavior.
Given that we have these examples as a goal and the resolution to make selectmenu respect writing-mode, is there anything else to discuss here? I'm going to tentatively close this because I think we're all on the same page - I just need to find a way to implement this in chromium and then add it to the explainer with some screenshots
@josepharhar the one thing that we were holding off closing this for was that we recommended the spec language change from "should" to "must" and that hasn't happened yet. But yes, from an implementation standpoint this is closed 👍🏻
That "should" or "must" is in the CSS spec so that should be opened as a CSSWG issue, right? Has an issue been opened?
@josepharhar I am unsure how this group raises recommendations to the CSSWG exactly, but my understanding is that the recommendation was made after we discussed it in the meeting.
I filed a csswg issue: https://github.com/w3c/csswg-drafts/issues/8633
@scottkellum @josepharhar @mfreed7 In my opinion, in order for us to have a meaningful discussion in the CSSWG we'll need to get the <selectmenu>
PR in WHATWG because I think that will enable the discussion to move in a different direction. While <selectmenu>
isn't itself novel in that it still is a replace element; I think we may want to give these replaced elements a different name OR make it a must for specific elements. This also becomes related to #689 as that would make it so that the text should remain as should in that case.
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
Now that we are going to reuse the select element instead of creating a new selectmenu/selectlist element in response to apple feedback, my plan is still the same: support writing-mode etc. for the new thing. I'm not sure if there needs to be any special considerations in the CSS or WHATWG specs.
The Open UI Community Group just discussed [selectmenu] How should writing-mode work with selectmenu
, and agreed to the following:
RESOLVED: <select> MUST support writing-modes but it will be defined in another issue that covers the user-agent stylesheet default styles when appearance: base-select is set
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.
The amazing Scott Kellum dropped by our discord to inquire about the following:
While I do think there should be some general discussion around how writing-modes function with respect to replaced elements I think it's worth looking at the
<selectmenu>
in its current form and determine if this is the expected behavior. Here is a forked version of Scott's pen including the new<selectmenu>
.Just in case you don't have experimental flags enabled on a Chromium browser; here is how it renders:
Note that the CSS is very basic in that it simply applies the writing mode to all of HTML
So basically what is happening is that the replaced element is not adhering to this writing mode. If I replace the default content with my own:
We end up with the following rendering:
Here is what the spec says with regards to replaced elements respecting writing modes:
Based on what the spec says I think this comes down to whether we want the
selectmenu
shadow DOM to use other replaced elements or not, in this case aninput
? And I'm primarily curious what users that consume content in this writing mode; what do they prefer? No matter what we decide on the prior topic of using replaced elements; we'll want to have the default styles be something that users will want.