Unprefix fit-content keyword.
Categories
(Core :: Layout, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox94 | --- | fixed |
People
(Reporter: emilio, Assigned: emilio)
References
(Blocks 4 open bugs)
Details
Attachments
(2 files)
Assignee | ||
Comment 1•3 years ago
|
||
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Try is running, probably a bunch of other new tests are passing.
Assignee | ||
Comment 2•3 years ago
|
||
Mostly progressions, as expected, but there are two bits that deserve
some attention:
-
First there are two table tests that regress (because we were
treating fit-content like auto). However Chromium fails the
non-tentative one also, just in a different way, so I think it's
worth punting on changing table layout and go to the CSSWG to figure
out if "auto" is the desired behavior here. -
Second, there's another test that regresses
(position-absolute-replaced-minmax.html) for the same reason, we used
to treat the size as "auto".The test that regresses comes from a Chromium crash
(https://bugs.chromium.org/p/chromium/issues/detail?id=1010798) and
the relevant behavior different also affects other intrinsic
keywords, so I don't think we should address it here, and is unlikely
to be a common case in the wild if we hadn't hit this before with
other unprefixed keywords IMO.In any case I filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1732780 for this
behavior difference to investigate later. -
Third, I removed fit-content from min-{width,height}-invalid. They
are valid sizing keywords in css-sizing-5, and they apply to these
properties. Other browsers also parse it.
Depends on D126718
Comment 4•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7905b23762e5
https://hg.mozilla.org/mozilla-central/rev/4d3c7ac994c7
Comment 5•3 years ago
|
||
\o/
:)
Updated•2 years ago
|
Description
•