1553930 - Text cannot wrap in <select> because of white-space: nowrap !important in forms.css (was: multi-line support for selected option with longer text in select field)

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[kabaldesign]

Attachment: Screenshot_1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

• Create select field whose options have around 8 - 10 words
• Limit the width of the select field to a moderate size i.e. 300px
• select an option of that field
• You will see that a selected field is getting truncated

Actual results:

You will notice that the selected option that is longer than the select box is shown single-lined, even if word-break styles are being used.

In other browsers, as default this behavior is the same, but can be tweaked using word-break. It helps usability a lot

Expected results:

It could be a way to let us make a selected option multi-line by using css properties that do that job in similar situations.

Comment 1

[Emilio Cobos Álvarez (:emilio)]

Can you attach an HTML example that shows the difference?

I would've expected this to render in multiple lines in other browsers, per your comment: data:text/html,<select style="width: 10ch; height:100px; word-break: break-word;"><option style="word-break: break-word">Hello hello hello hello</option></select>, but it doesn't seem to be the case.

Comment 2

[kabaldesign]

Hi, here's a little demo. As you can see, with few addition in stylesheets, I can make this select box multiline in chrome and IE. But for some reason, Firefox ignores these word-breaking properties.

https://codepen.io/kabal/pen/ZNoZNV

Comment 3

[Emilio Cobos Álvarez (:emilio)]

I see, so this is because we have white-space: nowrap !important in the user-agent stylesheet.

It seems it was introduced long time ago, in bug 206937 and bug 363858. I suspect we could try to remove it and see if there's any extra fixes that the layout code would need. Probably other people have more context than I though :)

Comment 4

[Boris Zbarsky [:bzbarsky]]

In bug 363858 the issue was that we wanted the min width of options to equal the pref width, for auto sizing of the select.

That shouldn't affect this testcase per se, though, because the text being rendered is not in an <option>. The text in <option> is what you see when the popup is shown.

That said, if you add size="5" to the <select> in the testcase linked here (which I suggest getting into an attachment for when the site it's on goes away) you do see a rendering difference between Firefox and Chrome. Safari agrees with Firefox here. It sure would be nice if the behavior here were standardized or something... ;)

For the combobox case in the testcase, bug 206937 is a bigger issue: allowing wrapping there will likely reintroduce that crash unless something else is changed in the combobox code.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[firefox]

As it is 3 years later and with no apparent movement, I'd like to bump the importance of this bug by mentioning its relevance toward meeting WCAG 2.1, specifically Success Criterion 1.4.10 Reflow (https://www.w3.org/WAI/WCAG21/Understanding/reflow.html), which says that content should remain available and readable as the user zooms in. However, as a user zooms in on a select, the text becomes larger, while the element itself does not necessarily match in proportion, allowing less space for text to display. Because the white-space: nowrap definition is seemingly hard-coded into the definition of the element (adding select { white-space: normal !important; } to a stylesheet has no effect in Firefox), one cannot avoid losing some text in lengthy options.

I was able to override the behavior in Blink- and WebKit-based browsers by using appearance: none and white-space: normal, along with overflow-wrap: anywhere and an ::after pseudo element for the dropdown arrow. The same code had no effect in Firefox, however. Here is the CSS applied to a select that allows wrapping in Chromium and Safari, but not Firefox:

select {
  appearance: none;
  overflow-wrap: anywhere;
  white-space: normal;
  max-width: 100%;
  padding: 10px 20px 10px 10px;
}

Obviously, the padding values are to your liking. A full example follows:

HTML:

<div class="a-select">
  <select>
    <option selected>Very long text that will not wrap in Firefox, but will in Chrome, Edge, and Safari</option>
  </select>
</div>

CSS:

select {
  appearance: none;
  overflow-wrap: anywhere;
  white-space: normal;
  max-width: 100%;
  padding: 10px 20px 10px 10px;
}

.a-select {
  display: flex;
  max-width: 200px;
}

.a-select::after {
  content: "˅";
  display: block;
  width: 12px;
  height: 12px;
  font-size: 12px;
  font-weight: bold;
  margin-top: 10px;
  margin-left: -17px;
}

Also available at jsfiddle.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

This should be removable after bug 1744009. We now compute the pref size independently of the option styles.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: test-case

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: WIP: Bug 1553930 - Remove some !important declarations in forms.css.

These were added so that combobox intrinsic size didn't depend on
wrapping and so on. But that's the case now since bug 1744009, so we can
relax this.

Unfortunately to allow proper text wrapping we need to remove two things
that we need to find a replacement or alternative for:

• The min-inline-size: max-content. That regresses bug 1561794, not
  cool.

• The line-height: -moz-block-height. That regresses rendering in
  single-line comboboxes that aren't auto-sized, also not cool.

Comment 10

[Emilio Cobos Álvarez (:emilio)]

So I took a look, and it's a bit more complicated than that, see comment 9.