1317206 - [css-grid] Empty <select> elements doesn't stretch in the inline-axis

Status: NEW

(Core :: Layout: Grid, defect)

Description

[Mats Palmgren (inactive)]

data:text/html,<div style="display:grid; grid:100px/100px"><select></select></div>

Comment 1

[yisibl]

Similar problems:

data:text/html,<div style="display:grid; grid:100px/200px"><progress></progress></div>

Comment 2

[Mats Palmgren (inactive)]

Stretching <progress> grid items seems to work fine for me in the latest Nightly.

Comment 3

[Mats Palmgren (inactive)]

Attachment: fix

There is a small web-compat risk with this patch, since if an author have
specified a 'width' that is smaller than 2.5em this new 'min-inline-size'
will force it to 2.5em.  It's easy to workaround though (add min-width:0),
and empty <select>s are likely very rarely used.

Comment 4

[Mats Palmgren (inactive)]

Attachment: reftests

Comment 5

[Mats Palmgren (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=19459a60bc9170578a4dcf253fbe87692442633d&exclusion_profile=false

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren (:mats) from comment #3)
> There is a small web-compat risk with this patch, since if an author have
> specified a 'width' that is smaller than 2.5em this new 'min-inline-size'
> will force it to 2.5em.  It's easy to workaround though (add min-width:0),
> and empty <select>s are likely very rarely used.

Sorry for not replying sooner here. The patch is trivial, but this risk troubles me a bit.

What if we simply removed this min-width instead? That seems strictly lower-risk to me, because:
 * On my system at least, *native-themed* empty <select> elements (i.e. those with default styling) seem to render at the same size, regardless of whether this style is present of not.  So they're not actually relying on this "inline-size" styling.

 * If I remove this line entirely, then unthemed empty <select> elements do indeed collapse away to nothing. However, that seems fine to me from a compat perspective, because that's what happens in Chrome as well (for both themed + unthemed <selects> actually).

If we're making a somewhat-arbitrary behavior change here, it seems like we should be changing in a direction that's closer to being compatible with other browsers. What do you think?

Comment 7

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (for a variety of <select> behaviors)

Here's the testcase I'm using locally to probe our & Chrome's behavior on these elements, BTW.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: screenshot of testcase 1 in various browsers

Here's a screenshot comparing testcase 1 in these browsers:

 Nightly | Nightly w/ 'fix' | Nightly w/ alternative patch | Chrome

("alternative patch" = simply dropping the rule that you're touching here)

I've circled every case that I noticed where one Nightly configuration differs from the other two Nightly configuration.  In each of these cases where possible-Nightly-versions disagree with each other, "alternative patch" consistently agrees with Chrome's rendering, meaning it's probably more likely to be web-compatible now & into the future.  (Unless there's a reason we should disagree with its/Chrome's rendering.)

Comment 9

[Daniel Holbert [:dholbert]]

Comment on attachment 8810689 [details] [diff] [review]
fix

(r- for now, per comment 6)

Comment 10

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 11

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 12

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.