Unprefix min-content and max-content keywords

RESOLVED FIXED in Firefox 66

Status

()

defect
P3
normal
RESOLVED FIXED
3 years ago
4 months ago

People

(Reporter: dbaron, Assigned: boris)

Tracking

(Blocks 5 bugs, {dev-doc-complete, DevAdvocacy, site-compat})

Trunk
mozilla66
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox66 fixed)

Details

(Whiteboard: [DevRel:P1][wptsync upstream], )

Attachments

(9 attachments)

We should unprefix the keywords at https://drafts.csswg.org/css-sizing/#width-height-keywords .  This includes renaming -moz-available to fill (different name).

See also bug 1312588.
Posted file image fill test
It seems our -moz-available isn't compatible with Chrome's -webkit-fill-available.
(Firefox overflows in the vertical dimension when the window is wide,
Chrome does not.
Firefox preserves the image ratio when the window is narrow, Chrome does not.)
(In reply to Mats Palmgren (:mats) from comment #1)
> It seems our -moz-available isn't compatible with Chrome's
> -webkit-fill-available.
> (Firefox overflows in the vertical dimension when the window is wide,
> Chrome does not.
> Firefox preserves the image ratio when the window is narrow, Chrome does
> not.)

Maybe the difference in this test is that they support the keyword for the block-size dimension and we only support it for inline-size?
It looks like Chrome support it in both dimensions, but the ratio-preservation
is wrong in some cases and they also overflow in some cases.  But, they do
preserve the ratio here when it's only specified in one axis, unlike
the first testcase that has 'fill' in both axes. 

It seems Gecko only support 'fill' in the inline-direction though.
We should probably not unprefix this before we support it in both.
Priority: -- → P3
The current Level 3 draft defers `fill` and `fit-content` to Level 4. Is it possible to unprefix `-moz-min-content` and `-moz-max-content`?
Assignee

Comment 6

9 months ago
>> fill keyword now renamed stretch

>> The current Level 3 draft defers `fill` and `fit-content` to Level 4. Is it possible to unprefix `-moz-min-content` and `-moz-max-content`?

I'm looking at bug 1312588, and happy to fix this as well. In other words, we can unprefix min-content, max-content, and rename "-moz-available" as "-moz-stretch" [1]. (This update may help me go through the code for better understanding our sizing calculation)

[1] https://www.w3.org/TR/css-sizing-3/#valdef-width-stretch
Assignee

Updated

9 months ago
Assignee: nobody → boris.chiou
Unprefixing -moz-min-content and -moz-max-content seems fine to me,
but I think we should leave the other as is.  I don't see any
benefit in breaking content that use -moz-available until we can
ship the real unprefixed 'stretch' value (and we probably need to
be a little careful there in case Chrome/WebKit don't support
the unprefixed 'stretch' yet at that time).
https://caniuse.com/#feat=intrinsic-width
Assignee

Comment 8

9 months ago
(In reply to Mats Palmgren (:mats) from comment #7)
> Unprefixing -moz-min-content and -moz-max-content seems fine to me,
> but I think we should leave the other as is.  I don't see any
> benefit in breaking content that use -moz-available until we can
> ship the real unprefixed 'stretch' value (and we probably need to
> be a little careful there in case Chrome/WebKit don't support
> the unprefixed 'stretch' yet at that time).
> https://caniuse.com/#feat=intrinsic-width

I see. We can unprefix only "-moz-min-content" and "-moz-max-content" for now, and file another bug for tracking -moz-available and -moz-fit-content. Thanks for this suggestion.

Comment 9

9 months ago
Should we fix this problem first? https://bugzilla.mozilla.org/show_bug.cgi?id=567039
I don't think we need to block this on bug 567039.
Assignee

Updated

9 months ago
Summary: unprefix min-content, max-content, fit-content, and fill keywords → Unprefix min-content and max-content keywords
Assignee

Comment 11

9 months ago
Filed bug 1495868 for unprefixing -moz-fit-content and -moz-available.
Assignee

Updated

9 months ago
See Also: → 1495868
Assignee

Comment 12

9 months ago
ExtremumLength is the keyword type for css sizing properties, so we
could use cbindgen.

In Gecko, we use nsStyleCoord to store the sizing properties, and use
integer values to check the enum values, so I keep the macros in nsStyleConsts.
Even though we need to convert the enum type into integer, we still have
benefits to reduce the complexity of converting Rust into C++, and leave
the simplified mappings in C++ for better readability.
Assignee

Comment 13

9 months ago
Remove "-moz-" for width, min-width, max-width, height, min-height, max-height,
inline-size, min-inline-size, max-inline-size, and flex-basis.

Depends on D7535
It might be worth considering if we should:
1. keep supporting the -moz- prefixed values for some time in parallel?
2. put this change behind a pref so that we can undo it in the field
   if there are unexpected regressions?

Personally, I think it's probably fine to ship it with neither of
those, but others might have thoughts on that?
The safest way is to do both of them and in addition put prefixed values behind another pref.

We may want to run bigquery for whether there are lots of pages using the prefixed ones, if so we may want to have two prefs for them then.
Assignee

Comment 16

9 months ago
Thanks for the feedback.

Adding one pref for prefixed keywords and one pref for unprefixed keywords may need a lot of update on the test files (because we have to make sure all tests passed if we disable one of the prefs).

I'd like to just add a pref for unprefixed version, and keep the test files which use "-moz-" keywords unchanged, and add some css property value tests in property_database.js to test the syntax for the unprefixed keywords. After deciding to remove the pref, we update all the tests to use the unprefixed version. This way could do both:
> 1. keep supporting the -moz- prefixed values for some time in parallel
> 2. put this change behind a pref so that we can undo it in the field if there are unexpected regressions

I will update the part 2 by adding a pref for the standard/unprefixed keywords.
Ugh, I just made the same remark in Phabricator :(

I think it'd be ok to avoid prefs and just land the change as is with an alias for the -moz- prefixed version. It's trivial to remove the unprefixed one if needed (modulo tests and such unfortunately, but that's a problem you have with the prefs anyway).
There's a case where we don't match the spec as written, which is what happens when you specify block-size: min-content.

We compute to auto (instead of 'behaves as', which is what the spec says). This is observable in getComputedStyle:

<div style="display: none; height: min-content"></div>


Per spec, getComputedStyle should return min-content, and in Gecko it returns auto if I'm reading the code correctly (I cannot test because I'm on my phone until tomorrow morning).

What do other engines do?
Isn't height a property which gCS should return used value for? If so, it probably doesn't matter too much.
My example had display: none very intentionally. For that we return the computed value.
I agree that it probably doesn't matter _much_ in the wild. But it'd be nice to be interoperable here before shipping rather than after, and / or get the spec fixed should it be needed.
Assignee

Comment 22

9 months ago
(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)
> Per spec, getComputedStyle should return min-content, and in Gecko it
> returns auto if I'm reading the code correctly (I cannot test because I'm on
> my phone until tomorrow morning).
> 
> What do other engines do?

I tried this on Chrome and Firefox:
1. with |display:none|:
  * Firefox, by setting width, height, min-width, min-height, max-width, max-height with -moz-min-content:
    width: -moz-min-content
    height: auto
    min-width: -moz-min-content
    min-height: 0px
    max-width: -moz-min-content
    max-height: none

  * Chrome, by setting width, height, min-width, min-height, max-width, max-height with min-content:
    width: min-content
    height: min-content
    min-width: min-content
    min-height: min-content
    max-width: min-content
    max-height: min-content

2. without |display:none|:
  * Firefox, by setting width, height, min-width, min-height, max-width, max-height with -moz-min-content:
    width: ...px
    height: ...px
    min-width: -moz-min-content
    min-height: 0px
    max-width: -moz-min-content
    max-height: none

  * Chrome, by setting width, height, min-width, min-height, max-width, max-height with min-content:
    width: ...px
    height: ...px
    min-width: min-content
    min-height: min-content
    max-width: min-content
    max-height: min-content

I think the differences are caused by Bug 567039. i.e. We don't implement keywords for block-size dimension, so return the initial values. And Bug 567039 shouldn't block this.
Attachment #9013820 - Attachment description: Bug 1322780 - Part 2: Unprefix -moz-min-content and -moz-max-content → Bug 1322780 - Part 2: Support unprefixed min-content and max-content
Assignee

Updated

9 months ago
Blocks: 1495939
(In reply to Boris Chiou [:boris] from comment #22)
I don't think bug 567039 is related to this, right?

Per spec it should behave as auto, but compute to min-content. We _almost_ agree with the spec, we just compute to auto. If we disagree with the spec for any funded reason, I think we should raise it in the CSSWG, but otherwise this doesn't look too hard to fix I'd think.
Assignee

Comment 24

9 months ago
(In reply to Emilio Cobos Álvarez (:emilio) from comment #23)
> (In reply to Boris Chiou [:boris] from comment #22)
> I don't think bug 567039 is related to this, right?
> 
> Per spec it should behave as auto, but compute to min-content. We _almost_
> agree with the spec, we just compute to auto. If we disagree with the spec
> for any funded reason, I think we should raise it in the CSSWG, but
> otherwise this doesn't look too hard to fix I'd think.

So looks like only properties in block-size dimension have this problem. I don't know why we have this kind of behavior. Hi mats, do we intentionally return "auto" in this case? Or this is just a bug.
Flags: needinfo?(mats)
I suspect it's just a bug.
I think Chrome has the correct gCS results in all cases.
width/height returns the used values when there is a box
but min/max-width/height don't, according to:
https://drafts.csswg.org/cssom/#resolved-values

I don't think we need to block this bug on correcting the gCS
results for min/max-width/height.  It's probably better to do
all of that in bug 567039.

It would be nice if you could fix the computed value for 'height'
though, since we are expected to support these keywords correctly
there.
Flags: needinfo?(mats)
Assignee

Comment 26

9 months ago
Thanks for this feedback. I would like to land this after emilio accepts the alias way for -moz- prefixed. (i.e. We accept both prefixed and unprefixed keywords without a pref, and gCS always returns the unprefixed version if |display:none|.)

About the bug of gCS, we could fix it in a separate bug or in Bug 567039.
On the dev.platform thread https://groups.google.com/d/topic/mozilla.dev.platform/vyCAurCC2DI/discussion I wrote:

So I'm a little bit concerned about doing this partially,
particularly if the subset we choose is different from the subset
other browsers choose, but also because it appears to be shipping a
feature part of which is ready and part of which isn't ready.

I'm curious what the state of implementations is between browsers
for:
 * support for these keywords on 'width'
 * support for these keywords on 'height'
 * whether support is prefixed, unprefixed, or both
 * whether the effect of these keywords on intrinsic sizes is
   interoperable
 * whether the support for all of 'min-content', 'max-content',
   'fit-content', 'fit-content()', and 'fill'/'stretch'/'available'
   is at equivalent stages

I think it may make more sense to do this work behind a pref until
the effect on intrinsic sizes is both good and interoperable (or at
least interoperable if we decide we're stuck with the bad behavior).

I'm also particularly concerned about shipping these for 'height'
when our our implementation in the block-size dimension isn't  
correct.  I suspect having a correct implementation depends on first
solving major spec issues like
https://github.com/w3c/csswg-drafts/issues/2890 .  And I suspect
there are also likely style system issues with supporting values for
'height' and 'width' and 'inline-size' but not on 'block-size'.

I think it may be better to continue further discussion in the bug.
Assignee

Comment 28

9 months ago
Thanks for this feedback.

(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #27)
> I'm curious what the state of implementations is between browsers for:
>  * support for these keywords on 'width'
Firefox, Chrome, and Safari supports these keywords on 'width'.

>  * support for these keywords on 'height'
Chrome and Safari supports these keywords on 'height'. Firefox doesn't.

>  * whether support is prefixed, unprefixed, or both
Chrome and Safari support both except -webkit-fill-available.
i.e. max-content, min-content, fit-content,
-webkit-min-content, -webkit-max-content, -webkit-fill-available, -webkit-fit-content.

>  * whether the effect of these keywords on intrinsic sizes is
>    interoperable
I use some tests which calculating the intrinsic size. e.g.
1) https://jsfiddle.net/borischiou/fqvd0twx/ (copied from layout/reftests/box-properties/box-sizing-2.html)
2) https://jsfiddle.net/borischiou/ejac9yz2/ (copied from chrome LayoutTests/fast/css-intrinsic-dimensions)
3) https://jsfiddle.net/borischiou/ymf3q5e6/ (copied from chrome LayoutTests/fast/css-intrinsic-dimensions)
(If they cannot show the effect of intrinsic size, please let me know.)

Tried these on Firefox, Chrome, and Safari, and they look the same. (And more tests below.)
Therefore, I think these keywords on intrinsic size should be interoperable.

>  * whether the support for all of 'min-content', 'max-content',
>    'fit-content', 'fit-content()', and 'fill'/'stretch'/'available'
>    is at equivalent stages

Looks like Chrome doesn't support 'fit-content()' if I read the code correctly, and neither of Firefox.
It seems we don't have enough tests in wpt, and most tests related to css-sizing are in project repos.
(e.g. [gecko]/layout/reftests/box-properties/ or [chromium]/src/third_party/WebKit/LayoutTests/fast/css-intrinsic-dimensions/)

All I can do is to test them from a subset of our reftests (in layout/reftests/box-properties/):
1) box-sizing-1.html (https://jsfiddle.net/borischiou/u27wyez0/)
2) box-sizing-2.html (https://jsfiddle.net/borischiou/fqvd0twx/)
3) box-sizing-3.html (https://jsfiddle.net/borischiou/d9eqwLch/)
4) box-sizing-4.html (https://jsfiddle.net/borischiou/49ztae7y/)
5) minmax-width-special-values-block-intrinsic.html (https://jsfiddle.net/borischiou/h8em1597/)
  * Chrome has bugs on this test file.
6) width-special-values-block-intrinsic.html (https://jsfiddle.net/borischiou/wa7dv6x4/)
7) width-special-values-block.html (https://jsfiddle.net/borischiou/r23wcte7/)
8) width-special-values-float-intrinsic.html (https://jsfiddle.net/borischiou/t9aro04s/)
9) width-special-values-float.html (https://jsfiddle.net/borischiou/3fp851ms/)
10) width-special-values-cell-auto.html (https://jsfiddle.net/borischiou/wv5tLfb3/)
  * Chrome has bugs on this test file.
11) width-special-values-cell-fixed.html (https://jsfiddle.net/borischiou/4oLqh3te/)
  * Chrome has bugs on this test file.

If our test coverage is enough and correct, for the inline-size dimension, we should be
at equivalent stages except Chrome has some bugs on table layout with these keywords.

> I think it may make more sense to do this work behind a pref until
> the effect on intrinsic sizes is both good and interoperable (or at
> least interoperable if we decide we're stuck with the bad behavior).

It is ok to add a pref to protect the unprefixed keywords. However, this may add some complexity
on our parser and serialization because we have to support two different version of keywords.
Anyway, this is doable.

> I'm also particularly concerned about shipping these for 'height'
> when our our implementation in the block-size dimension isn't  
> correct.  I suspect having a correct implementation depends on first
> solving major spec issues like
> https://github.com/w3c/csswg-drafts/issues/2890.

OK. We could make the pref off, and only enable it on nightly and for testing.

Thanks.
I'm also not really sure what we do today for these keywords when they're used in the block dimension, nor what Chrome does.  Maybe it's not as bad as I suspect it is, but it would need to be tested before we unprefix.
Assignee

Comment 30

9 months ago
I checked our implementation today, and we just treat the keywords on block size as default values. In other words, for block dimension, the computed values of keywords are always `auto` or `none`. (e.g. height/min-height => auto, max-heigth => none). Therefore, their rendering results are always the same as `auto`/`none` on block dimension.

Not sure how many things Chrome does for the keywords. Probably need to check their implementation.
Assignee

Updated

9 months ago
Depends on: 1496558
(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #27)
> I'm also particularly concerned about shipping these for 'height'
> when our our implementation in the block-size dimension isn't  
> correct.  I suspect having a correct implementation depends on first
> solving major spec issues like
> https://github.com/w3c/csswg-drafts/issues/2890 .  And I suspect
> there are also likely style system issues with supporting values for
> 'height' and 'width' and 'inline-size' but not on 'block-size'.

Actually, I think much of this paragraph that I wrote earlier was wrong, since the definition of these values when they're used in the block-size dimension is actually quite straightforward (from https://drafts.csswg.org/css-sizing-3/#valdef-width-min-content):

  otherwise behaves as the property’s initial value

We'd still need to write a small amount of code and probably a slightly larger amount of tests to make sure this is done correctly, but it's actually a relatively straightforward project for somebody new to the area.

(Making sure we have correct intrinsic sizing behavior when they're used in the inline dimension, as mentioned in bug 1312588, might be harder... or it might actually be reasonably fine today.)
Assignee

Comment 32

9 months ago
(In reply to David Baron :dbaron: 🏴󠁵󠁳󠁣󠁡󠁿 ⌚UTC-7 from comment #31)
> 
>   otherwise behaves as the property’s initial value
>

While working on Bug 1496558, I tried to make sure we treat the keywords on block size dimension as initial values, and store the correct computed values.

> We'd still need to write a small amount of code and probably a slightly
> larger amount of tests to make sure this is done correctly, but it's
> actually a relatively straightforward project for somebody new to the area.

Yes. We have some tests for this, especial in grid. However, those tests are not enough. Therefore, we should add more in layout/reftests/box-properties/. (Looks like our current tests in this folder only cover inline size.)


In conclusion, I should add some tests in this bug to make sure we treat the keywords on block size dimension as initial values. And then we can unprefix max-content and min-content.
Keywords: DevAdvocacy
Whiteboard: [DevRel:P1]
Assignee

Comment 33

7 months ago
After landing bug 1496558 and its regression bug, it seems there is no other regression for now,
so I'm plan to continue the work:
1. Add test cases. For grid and flexbox, we have some already, so I intent to add tests
   for only basic cases without grid and flexbox.
2. Some reviewers suggest it's fine without the pref, and the others suggest add one. For now,
   we fixed some bugs to match the spec, so I think it should be fine to unprefix them
   without the pref. However, I will still keep the alias keywords.
   (i.e. -moz-max-conent/max-content, and -moz-min-content/min-content)
Attachment #9013819 - Attachment description: Bug 1322780 - Part 1: Use cbindgen for ExtremumLength → Bug 1322780 - Part 1: Use cbindgen for ExtremumLength.
Attachment #9013820 - Attachment description: Bug 1322780 - Part 2: Support unprefixed min-content and max-content → Bug 1322780 - Part 2: Support unprefixed min-content and max-content.
Assignee

Comment 34

7 months ago
Depends on D7536
Attachment #9028813 - Attachment description: Bug 1322780 - Part 3: Add tests. → Bug 1322780 - Part 4: Add tests.
Assignee

Comment 35

7 months ago
We should let block-size accept keywords as the initial value, just like width
in vertical writing mode or height in horizontal writing mode.

Depends on D7536
Attachment #9030894 - Attachment description: Bug 1322780 - Part 3: Let logical height accept keywords. → Bug 1322780 - Part 3: Let logical height, block-size, apply to keywords.
Assignee

Updated

7 months ago
Status: NEW → ASSIGNED
Attachment #9030894 - Attachment description: Bug 1322780 - Part 3: Let logical height, block-size, apply to keywords. → Bug 1322780 - Part 3: Let logical height, block-size, accept keywords.
Assignee

Updated

6 months ago
Blocks: 1514264

Comment 37

6 months ago
Pushed by boris.chiou@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/1edf365b731a
Part 1: Use cbindgen for ExtremumLength. r=emilio
https://hg.mozilla.org/integration/autoland/rev/3511904f12cf
Part 2: Support unprefixed min-content and max-content. r=mats,emilio
https://hg.mozilla.org/integration/autoland/rev/ecf13af1b421
Part 3: Let logical height, block-size, accept keywords. r=emilio
https://hg.mozilla.org/integration/autoland/rev/1ecaff8ff57d
Part 4: Add tests. r=dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/14597 for changes under testing/web-platform/tests
Whiteboard: [DevRel:P1] → [DevRel:P1][wptsync upstream]

Comment 39

6 months ago
I think -webkit-flex or -webkit-flex-basis does not support min-content and max-content.

https://img.alicdn.com/tfs/TB1yqVIwY2pK1RjSZFsXXaNlXXa-1382-808.png (It seems that I have no right to submit comments.)
You need to press submit at the bottom, but in any case that's wrong.

https://drafts.csswg.org/css-flexbox/#propdef-flex-basis says that the grammar takes a <'width'>, so it should parse anything that the width property parses.

Comment 41

6 months ago
I mean, Chrome and Safari don't support using min-content in -webkit-flex or -webkit-flex-basis https://img.alicdn.com/tfs/TB1ZaSbwZbpK1RjSZFyXXX_qFXa-714-286.png
Upstream PR merged
WPT pull for the changes in part 4 in https://github.com/web-platform-tests/wpt/pull/14607.  (The previous comment was about part 2.)
The tests that gate the merge to WPT are unhappy because some of the tests produced unstable results in Firefox:


### /css/vendor-imports/mozilla/mozilla-central-reftests/sizing/hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html ###
| Subtest |          Results           | Messages |
|---------|----------------------------|----------|
|         | **FAIL: 3/10, PASS: 7/10** |          |

### /css/vendor-imports/mozilla/mozilla-central-reftests/sizing/vert-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html ###
| Subtest |          Results           | Messages |
|---------|----------------------------|----------|
|         | **FAIL: 1/10, PASS: 9/10** |          |


I'd also note that one of them failed every time in Firefox:

### /css/vendor-imports/mozilla/mozilla-central-reftests/sizing/vert-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html ###
| Subtest | Results | Messages |
|---------|---------|----------|
|         | FAIL    |          |
Flags: needinfo?(boris.chiou)
Assignee

Comment 46

6 months ago
Thanks for this notification. I saw two problems in the tests:

1. My reftests are still too large, so the test cannot see the oversized part.
   (The size of screenshot is about 600px by 600px, I think.)
2. The color of scrollbar between test and reference are different. (I don't know why...)

The only way to fix this is: split these 4 failures into more tests, and make sure the size could be fitted into a small viewport (~400px by ~400px)
Flags: needinfo?(boris.chiou) → needinfo?(dbaron)
Assignee

Updated

6 months ago
Flags: needinfo?(dbaron)
Assignee

Comment 47

6 months ago
screenshot of hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
Assignee

Comment 48

6 months ago
screenshot of reference: hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
Assignee

Comment 49

6 months ago
So I will add one more patch to split the following files (and their reference):

hori-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
hori-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
vert-block-size-small-or-larger-than-container-with-min-or-max-content-2a.html
vert-block-size-small-or-larger-than-container-with-min-or-max-content-2b.html
(In reply to Boris Chiou [:boris] from comment #46)
> 2. The color of scrollbar between test and reference are different. (I don't
> know why...)

This might be https://github.com/web-platform-tests/wpt/issues/13563.
I think it's 600x600 so no need to make it smaller than that.
Also, I typically reset the margin like so:
html,body {
  color:black; background-color:white; font:16px/1 monospace; padding:0; margin:0;
}
to avoid wasting space to that.
Assignee

Comment 52

6 months ago
If the size is larger than 600x600, we cannot test all the rendering
results, and it seems there is a bug related the inactive windows,
https://github.com/web-platform-tests/wpt/issues/13563, which may causes
that the scroll bar has different color.
Assignee

Comment 53

6 months ago
(In reply to Mats Palmgren (:mats) from comment #51)
> I think it's 600x600 so no need to make it smaller than that.
> Also, I typically reset the margin like so:
> html,body {
>   color:black; background-color:white; font:16px/1 monospace; padding:0;
> margin:0;
> }
> to avoid wasting space to that.

Good idea. I will apply this rule in the future. :)

Comment 54

6 months ago
Pushed by boris.chiou@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/28ed7729ca2d
Part 5: Adjust reftests to be fitted into 600x600. r=dholbert
Thanks; successfully merged this time.
Assignee

Comment 58

6 months ago
(In reply to Kohei Yoshino [:kohei] (Bugzilla UX) (FxSiteCompat) from comment #57)
> Posted site compatibility note:
> https://www.fxsitecompat.com/en-CA/docs/2018/min-max-content-keywords-for-
> css-sizing-properties-have-been-unprefixed/

Nice! Thank you. :)

Hi Boris,

I'm working on updating the MDN compat data in light of this change. Can you help me out with a list of the properties that support the min-content and max-content keywords?

So far I've got

width
height
min-width
max-width
min-height
max-height
flex-basis

what others are there?

Thanks!

Flags: needinfo?(boris.chiou)
Assignee

Comment 60

4 months ago

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #59)

So far I've got

width
height
min-width
max-width
min-height
max-height
flex-basis

what others are there?

The following properties:

width, height, min-width, min-height, max-width, max-height, flex-basis,

And

block-size, inline-size,
min-block-size, min-inline-size,
max-block-size, max-inline-size,

Thanks for updating mdn. :)

Flags: needinfo?(boris.chiou)

(In reply to Boris Chiou [:boris] from comment #60)

(In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #59)

So far I've got

width
height
min-width
max-width
min-height
max-height
flex-basis

what others are there?

The following properties:

width, height, min-width, min-height, max-width, max-height, flex-basis,

And

block-size, inline-size,
min-block-size, min-inline-size,
max-block-size, max-inline-size,

Thanks for updating mdn. :)

Great, thanks a lot for the help Boris.

I've updated the compat data for all of the properties: https://github.com/mdn/browser-compat-data/pull/3573

I've also added a note to the Fx66 rel notes: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/66#CSS

Let me know if that looks OK. Thanks!

You need to log in before you can comment on or make changes to this bug.