openui / openui/open-ui

[selectmenu] How should writing-mode work with selectmenu

Open
#600 19 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

CSSWG i18n-tracker needs edits needs-triage select
Dominant language
MDX
Stars
4.5k
Forks
226
Avg merge
2d 22h
Merged PRs (30d)
4

Description

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:

Screen Shot 2022-08-29 at 8 37 31 PM

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:

Screen Shot 2022-08-29 at 8 52 10 PM

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked Scott Kellum and Greg Whitworth CodePens, compare the native selectmenu rendering with the custom button slot under vertical-lr, and read the cited CSS Writing Modes specification section. Done means reaching and documenting a decision about selectmenu writing-mode behavior and its default styles.

Written by the indexing model from the issue text.

Assessment

Tech stack
css, html
Domain
frontend, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.