Intent to ship: unprefixed max-content and min-content for css sizing properties

[Boris Chiou]

Summary:
`max-content` and `min-content` are sizing values for width, min-width,
max-width, height, min-height, max-height, inline-size, min-inline-size,
max-inline-size, and flex-basis. We support these two keywords with -moz-
prefix for many years, and Google Chrome has shipped them for 3 years. Our
implementation on inline-size dimension are stable, and it'd be nicer to
unprefix the keywords so people don't have to write both versions (i.e.
prefixed and unprefixed) on their websites. Therefore, I think it's worth
to unprefix them.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322780
<https://bugzilla.mozilla.org/show_bug.cgi?id=1141895>

Link to standard: https://drafts.csswg.org/css-sizing/#sizing-values

Platform coverage: all platforms

Estimated or target release: Firefox 64

Do other browser engines implement this?
Chrome has shipped unprefixed max-content and min-content values from 46
[1]. Safari still uses -webkit- prefixed.

Preference behind which this will be implemented: n/a
DevTools bug: n/a

[1] https://caniuse.com/#feat=intrinsic-width

--
Regards,
Boris

[L. David Baron]

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.

-David

On Tuesday 2018-10-02 12:48 -0700, Boris Chiou wrote:
> Summary:
> `max-content` and `min-content` are sizing values for width, min-width,
> max-width, height, min-height, max-height, inline-size, min-inline-size,
> max-inline-size, and flex-basis. We support these two keywords with -moz-
> prefix for many years, and Google Chrome has shipped them for 3 years. Our
> implementation on inline-size dimension are stable, and it'd be nicer to
> unprefix the keywords so people don't have to write both versions (i.e.
> prefixed and unprefixed) on their websites. Therefore, I think it's worth
> to unprefix them.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322780
>

> Link to standard: https://drafts.csswg.org/css-sizing/#sizing-values
>
> Platform coverage: all platforms
>
> Estimated or target release: Firefox 64
>
> Do other browser engines implement this?
> Chrome has shipped unprefixed max-content and min-content values from 46
> [1]. Safari still uses -webkit- prefixed.
>
> Preference behind which this will be implemented: n/a
> DevTools bug: n/a
>
> [1] https://caniuse.com/#feat=intrinsic-width

--

𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[David Burns]

Are there any web platform tests for this feature?

David

On Tue, 2 Oct 2018 at 20:49, Boris Chiou <bch...@mozilla.com> wrote:

> Summary:
> `max-content` and `min-content` are sizing values for width, min-width,
> max-width, height, min-height, max-height, inline-size, min-inline-size,
> max-inline-size, and flex-basis. We support these two keywords with -moz-
> prefix for many years, and Google Chrome has shipped them for 3 years. Our
> implementation on inline-size dimension are stable, and it'd be nicer to
> unprefix the keywords so people don't have to write both versions (i.e.
> prefixed and unprefixed) on their websites. Therefore, I think it's worth
> to unprefix them.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1322780

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1141895>

>
> Link to standard: https://drafts.csswg.org/css-sizing/#sizing-values
>
> Platform coverage: all platforms
>
> Estimated or target release: Firefox 64
>
> Do other browser engines implement this?
> Chrome has shipped unprefixed max-content and min-content values from 46
> [1]. Safari still uses -webkit- prefixed.
>
> Preference behind which this will be implemented: n/a
> DevTools bug: n/a
>
> [1] https://caniuse.com/#feat=intrinsic-width
>
> --

> Regards,
> Boris
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Boris Chiou]

The web platform tests only check if the parser could accept the keywords
in css/css-sizing/parsing. About the rendering results of keywords, I
cannot find any reftest in css-sizing or in css-boxing in wpt. Both Gecko
and Blink put the reftests in their repos, instead of wpt. This is another
problem for now. If we could make all keywords match the spec, it would be
easier to move all of our tests into wpt.

For now, it seem there are some concerns about shipping this keywords, so
I'd like to add a pref for them. At least we could support both unprefixed
and prefixed versions.

Regards,
Boris


On Fri, Oct 5, 2018 at 10:36 AM Boris Chiou <bo...@mozilla.com> wrote:

> The web platform tests only check if the parser could accept the keywords
> in css/css-sizing/parsing. About the rendering results of keywords, I
> cannot find any reftest in css-sizing or in css-boxing in wpt. Both Gecko
> and Blink put the reftests in their repos, instead of wpt. This is another
> problem for now. If we could make all keywords match the spec, it would be
> easier to move all of our tests into wpt.
>
> For now, it seem there are some concerns about shipping this keywords, so
> I'd like to add a pref for them. At least we could support both unprefixed
> and prefixed versions.
>
>
> Regards,
> Boris