1322780 - Unprefix min-content and max-content keywords

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 1

[Mats Palmgren (inactive)]

Attachment: 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.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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?

Comment 3

[Mats Palmgren (inactive)]

Attachment: image fill test, one axis only

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.

Comment 4

[yisibl]

fill keyword now renamed stretch

https://drafts.csswg.org/css-sizing-3/#valdef-width-stretch
https://drafts.csswg.org/css-sizing-3/#changes

Comment 5

[Masataka Yakura]

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`?

Comment 6

[Boris Chiou [:boris]]

>> 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

Comment 7

[Mats Palmgren (inactive)]

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

Comment 8

[Boris Chiou [:boris]]

(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

[yisibl]

Should we fix this problem first? https://bugzilla.mozilla.org/show_bug.cgi?id=567039

Comment 10

[Mats Palmgren (inactive)]

I don't think we need to block this on bug 567039.

Comment 11

[Boris Chiou [:boris]]

Filed bug 1495868 for unprefixing -moz-fit-content and -moz-available.

Comment 12

[Boris Chiou [:boris]]

Attachment: Bug 1322780 - Part 1: Use cbindgen for ExtremumLength.

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.

Comment 13

[Boris Chiou [:boris]]

Attachment: Bug 1322780 - Part 2: Support unprefixed min-content and max-content.

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

Comment 14

[Mats Palmgren (inactive)]

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?

Comment 15

[Xidorn Quan [:xidorn] UTC+11]

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.

Comment 16

[Boris Chiou [:boris]]

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.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

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).

Comment 18

[Emilio Cobos Álvarez (:emilio)]

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?

Comment 19

[Xidorn Quan [:xidorn] UTC+11]

Isn't height a property which gCS should return used value for? If so, it probably doesn't matter too much.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

My example had display: none very intentionally. For that we return the computed value.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 22

[Boris Chiou [:boris]]

(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.

Comment 23

[Emilio Cobos Álvarez (:emilio)]

(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.

Comment 24

[Boris Chiou [:boris]]

(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.

Comment 25

[Mats Palmgren (inactive)]

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.

Comment 26

[Boris Chiou [:boris]]

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.

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 28

[Boris Chiou [:boris]]

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.

Comment 29

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 30

[Boris Chiou [:boris]]

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.

Comment 31

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.)

Comment 32

[Boris Chiou [:boris]]

(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.

Comment 33

[Boris Chiou [:boris]]

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)

Comment 34

[Boris Chiou [:boris]]

Attachment: Bug 1322780 - Part 4: Add tests.

Depends on D7536

Comment 35

[Boris Chiou [:boris]]

Attachment: Bug 1322780 - Part 3: Let logical height, block-size, accept keywords.

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

Comment 36

[Boris Chiou [:boris]]

try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=e68fd0c4369996f09c3ef644fe08c06522cc2ea5

Comment 37

[Pulsebot]

Pushed by [e-mail]:
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

Comment 38

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/14597 for changes under testing/web-platform/tests

Comment 39

[yisibl]

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.)

Comment 40

[Emilio Cobos Álvarez (:emilio)]

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

[yisibl]

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

Comment 42

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/1edf365b731a
https://hg.mozilla.org/mozilla-central/rev/3511904f12cf
https://hg.mozilla.org/mozilla-central/rev/ecf13af1b421
https://hg.mozilla.org/mozilla-central/rev/1ecaff8ff57d

Comment 43

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged

Comment 44

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.)

Comment 45

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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    |          |

Comment 46

[Boris Chiou [:boris]]

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)

Comment 47

[Boris Chiou [:boris]]

Attachment: screenshot of hori-2a.html

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

Comment 48

[Boris Chiou [:boris]]

Attachment: screenshot of hori-2-ref.html

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

Comment 49

[Boris Chiou [:boris]]

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

Comment 50

[Emilio Cobos Álvarez (:emilio)]

(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.

Comment 51

[Mats Palmgren (inactive)]

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.

Comment 52

[Boris Chiou [:boris]]

Attachment: Bug 1322780 - Part 5: Adjust reftests to be fitted into 600x600.

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.

Comment 53

[Boris Chiou [:boris]]

(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

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/28ed7729ca2d
Part 5: Adjust reftests to be fitted into 600x600. r=dholbert

Comment 55

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/28ed7729ca2d

Comment 56

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Thanks; successfully merged this time.

Comment 57

[Kohei Yoshino [:kohei]]

Posted site compatibility note: https://www.fxsitecompat.com/en-CA/docs/2018/min-max-content-keywords-for-css-sizing-properties-have-been-unprefixed/

Comment 58

[Boris Chiou [:boris]]

(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. :)

Comment 59

[Chris Mills [:cmills]]

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!

Comment 60

[Boris Chiou [:boris]]

(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. :)

Comment 61

[Chris Mills [:cmills]]

(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!