[selectmenu] How should writing-mode work with selectmenu

[gregwhitworth]

The amazing Scott Kellum dropped by our discord to inquire about the following:

I’m running into an issue with writing-mode and UI elements. It works as expected in Firefox but the UI elements in Chrome/Safari don’t respect the writing-mode applied to them.
https://codepen.io/scottkellum/pen/poLmmRB/4bbd0fd358fec6f42d8cf279679f7183
Is this issue documented anywhere or is it being worked on?

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

selectmenu {
	writing-mode: vertical-lr;
}

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:

<div slot="button">
    <div behavior="button" class="fake-input">
      Open
      <span class="arrow">&#9660;</span>
    </div>
    <div>
      <p>Selected Value: 
        <span behavior="selected-value" slot="selected-value"></span>
      </p>
    </div>
  </div>

We end up with the following rendering:

Here is what the spec says with regards to replaced elements respecting writing modes:

The content of replaced elements do not rotate due to the writing mode: images and external content such as from <iframe>s, for example, remain upright, and the default object size of 300px×150px does not re-orient. However embedded replaced content involving text (such as MathML content or form elements) should match the replaced element’s writing mode and line orientation if the UA supports such a vertical writing mode for the replaced content.

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 an input? 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.

[gregwhitworth]

@dandclark @mfreed7

[fantasai]

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.

[scottkellum]

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.

[gregwhitworth]

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

[css-meeting-bot]

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.

The full IRC log of that discussion

<gregwhitworth> Topic: How should writing-mode work with selectmenu
<gregwhitworth> github: https://github.com//issues/600
<hdv> gregwhitworth: there are interop issues between how browsers handle the current select menu… so I wanted to see if we can address this in selectmenu and figure out how we should handle writing modes
<hdv> gregwhitworth: I pinged @@@ from the CSSWG and there are some examples in the spec that are using select as an example of how it should work
<dbaron> s/@@@/fantasai and Florian/
<hdv> gregwhitworth: the spec says should rather thanmust, but I think we could probably say must
<hdv> gregwhitworth: I don't think when someone does the writing mode they wouldn't expect the selectmenu itself to be turned but not the options inside
<dandclark> q+
<hdv> gregwhitworth: I'm curious what people's thoughts are
<masonf> q+
<gregwhitworth> ack dbaron
<hdv> dbaron: when thinking about writing modes, there are a few languages to think about… a lot of examples are for Chinese or Japanese, which are languages that can be written horizontally or vertically… it can in many ways be a stylistic choice
<hdv> dbaron: there are however also languages where it is mandatory to use a specific writing mode
<gregwhitworth> ack dandclark
<hdv> dbaron: when we design things we have to make sure it can do vertical text, otherwise languages like Mongolian would not work
<hdv> dandclark: this came up because the selectmenu uses the native select for its button… so we end up with a popup that does respect vertical writing mode but a button that doesn't
<hdv> dandclark: so I think we at least should have a MUST that the selectmenu should follow the writing mode… if the button does not reflect it, like in current Chromium, then the popup should ignore it too , so that it is not werid
<bkardell_> dbaron: yeah, first appearance of "marker" in a spec is march 98 I think https://www.w3.org/TR/1998/PR-CSS2-19980324/generate.html#markers
<bkardell_> but the pseudo-element itself, is the one I mentioned above with the funny note
<hdv> dandclark: I'd like to see these buttons respect writing mode… not sure how realistic it is if we just say for a selectmenu you must
<gregwhitworth> ack masonf
<hdv> dandclark: there seems to be a contradiction to say it should work for selectmenu, but we don't fix it for button at the same time
<gregwhitworth> q+
<scottkellum> q+
<hdv> masonf: I think I agree with what dandclark said… not sure if there is already a bug for the button issue?
<sarah_h> this is a pretty good reference, and also recommends having the button follow writing mode: https://www.w3.org/International/articles/vertical-text/#forms_etc
<hdv> gregwhitworth: my only qualm with SHOULDs is that we finally get an opportunity to write MUST, all form element things have had SHOULD until now
<bkardell_> dbaron: sorry I got confused about where you replied :)
<hdv> gregwhitworth: and then browser makers can decide on if they'll implement it… but at least we decide what the right behavior is
<gregwhitworth> ack gregwhitworth
<hdv> scottkellum: to clarify… it's not just selectmenu, button and all of the various inputs, input type range and others. So this is also an interop thing, I'm not quite sure… it's very difficult from a design perspective, because writing mode is so important when it comes to design, it becomes very complicated to design UIs that some browsers support going in one direction, some in another, with various writing modes
<gregwhitworth> ack scottkellum
<gregwhitworth> ack dbaron
<hdv> gregwhitworth: I'm not opposed to having the discussion… just saying we're working on selectmenu now. It makes sense to add to Interop 2023
<masonf> +1 to adding writing modes for form controls to Interop2023...
<hdv> dbaron: one other place where it might make sense to write a requirement… maybe this is what you meant but not sure if you said it explicitly… if the button in the selectmenu visually shows you a direction or orientation, that that button should reflect the actual orientation you're going to get
<hdv> gregwhitworth: technically you don't know when you lay that glyph out, you don't know where it is going to be
<hdv> dbaron: in many cases it will go either up or down, not sideways
<hdv> gregwhitworth: would we know at style cascade time?
<hdv> masonf: when you put the button you don't know where it will go
<hdv> gregwhitworth: when you've done the cascade and it is sitting on computed style, you know, like I'll try to be anchored on the centre right
<hdv> dbaron: what I tried to say is… you shouldn't depend on lots of interesting anchoring styles… if the _language_ is such that you would expect a certain direction, that is followed
<dandclark> Not an expert on writing modes, but does this work? Proposed resoution: UAs must respect writing-mode for all of a selectmenu's default content.
<hdv> dbaron: seems reasonable to me
<dandclark> RESOLVED: UAs must respect writing-mode for all of a selectmenu's default content.
<dbaron> (might make sense to eventually have more concrete requirements in the spec, though)

[r12a]

I only just now noticed this thread. Fwiw, the i18n WG has an open gap report on this topic at w3c/clreq#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.

[r12a]

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

[scottkellum]

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”.

[css-meeting-bot]

The Open UI Community Group just discussed [selectmenu] How should writing-mode work with selectmenu.

The full IRC log of that discussion

<gregwhitworth> Topic: [selectmenu] How should writing-mode work with selectmenu
<gregwhitworth> github: https://github.com//issues/600
<gregwhitworth> q?
<hdv> ScottKellum: we had a proposed resolution that we agreed upon before: writing mode is inconsistent with selectmenu, as they have a different writing mode depending on the context they are in
<gregwhitworth> ack gregwhitworth
<hdv> ScottKellum: the proposal is to change 'should' to 'must' in the spec… but this is now part of Interop 2023. Is there anything more that we need to do here?
<gregwhitworth> q+
<masonf> q?
<hdv> ScottKellum: is this maybe an opportunity to push a bit more to get it changed in the spec? or do we mark it as resolved as it is (hopefully) going to be implemented in browsers?
<masonf> q+
<hdv> ack greg
<hdv> gregwhitworth: clarifying question: it isn't in the spec today, right?
<hdv> ScottKellum: correct
<gregwhitworth> ack masonf
<hdv> gregwhitworth: so you're asking if we should uplevel it as the spec doesn't have as' must' today?
<hdv> ScottKellum: various ways: (1) we could leave it as is, as Interop is already addressing this so we don't need to change the spec
<hdv> ScottKellum: (2) or we could have the spec changed as it is now part of Interop that might make things easier
<hdv> ScottKellum: (3) as this is now part of Interop, there is not as much of a pressing need for this, so we could mark this issue as resolved
<hdv> masonf: I'm in favour of keeping this unresolved, with the understanding that when selectmenu ships that it has all of writing mode working correctly. We should make sure to add a testcase in Interop to make sure this is tested for selectmenu
<hdv> gregwhitworth: the only qualm for me against closing is would be that closing it before it has changed in the spec wouldnt be great
<hdv> masonf: for the popover things I prefer the issues to close so it goes off my to do list, for me closing an issue means we're in agreement about it and done with it
<hdv> gregwhitworth: when thinking about code, you wouldn't close the issue until the code has landed. So for this, what was in my mind is that it wouldn't close until landed in the spec
<hdv> masonf: for popover I had a label for popover-spec or something we could have something like that for selectmenu
<hdv> gregwhitworth: so sounds like we will leave it open and leave it for the next owners of selectmenu to deal with it

[josepharhar]

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

[scottkellum]

@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 👍🏻

[josepharhar]

That "should" or "must" is in the CSS spec so that should be opened as a CSSWG issue, right? Has an issue been opened?

[scottkellum]

@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.

[josepharhar]

I filed a csswg issue: w3c/csswg-drafts#8633

[gregwhitworth]

@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.

[github-actions]

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.

[josepharhar]

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.

[css-meeting-bot]

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

The full IRC log of that discussion

<una> q+
<masonf> q+
<brecht_dr> jarhar I think we should make the new select support other writing modes, maybe it's just that
<gregwhitworth> ack una
<gregwhitworth> q+
<brecht_dr> una question: regarding button and writing mode. It looks that the button is not respecting the writing mode, but the selected option do. There seems to be a few funky things going on there
<dbaron> I just wrote a review comment on Joey's most recent patch that he sent me for review... where he didn't get writing mode handling correct in the default styles :-) But it is easily fixable.
<brecht_dr> una +1 on the writing mode though. Is this also going to be specced in the design is another question I have
<brecht_dr> jarhar We want to let this up to the browsers for a part, it's not clarified in detail
<gregwhitworth> https://github.com//issues/600#issuecomment-1231181295
<gregwhitworth> fantasai comment ^
<brecht_dr> masonf Ofcourse we should suppor the writing modes, the tricky bit is how it should behave in different writing modes
<brecht_dr> masonf In terms on this issue we should just resolve on supporting it. We could take it further about the actual design for this later on
<brecht_dr> gregwhitworth Are we going to define and spec this? I think we should. It's relatively clearly defined in an internationalization
<dandclark> q+
<gregwhitworth> ack gregwhitworth
<brecht_dr> gregwhitworth I think we should resolve that it MUST (not should) and this should be defined in the UA stylesheet to be determined
<dandclark> https://github.com/w3c/csswg-drafts/issues/8633
<gregwhitworth> ack dbaron
<Luke> q+
<brecht_dr> dbaron I think a lot of the interesting stuff is going to be when we specify the default styles for this
<brecht_dr> dbaron there will be details, but i'm sure we'll get it right
<gregwhitworth> ack dandclark
<gregwhitworth> ack Luke
<brecht_dr> Luke Is there a way to style based on the writing mode?
<gregwhitworth> q+
<brecht_dr> dbaron A lot of it will be based on using logical properties in the base styles
<gregwhitworth> ack gregwhitworth
<dbaron> https://drafts.csswg.org/css-logical-1/
<una> that also solves the spec piece, if its specced with logical properties
<dbaron> s/in the base styles/in the styles authors write/
<gregwhitworth> Proposed Resolution: <select> MUST support writing-modes but it will be defined in another issue that covers the user-agent stylesheet default styles when appearance: select-base is set
<masonf> base-select
<masonf> +1
<gregwhitworth> Proposed Resolution: <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
<Luke> +1
<brecht_dr> +1
<keithamus> +1
<dandclark> +1
<gregwhitworth> 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
<dbaron> +1