Intent to Implement and Ship: CSS min(), max() and clamp()

[Xiaocheng Hu]

Contact emails xiaoc...@chromium.org Explainer https://developer.mozilla.org/en-US/docs/Web/CSS/min#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/max#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/clamp#Examples Design docs/spec Specification: https://drafts.csswg.org/css-values-4/#comp-func http://bit.ly/31Yfkm6 TAG review

TAG review doesn't seem necessary.

There is no change to existing specs, and the feature seems pretty small with pretty straightforward behaviors introduced. Summary Allow comparison functions min(), max() and clamp() in math expressions for numeric CSS values. Motivation https://crbug.com/825895 The feature has been requested for over a year with many stars, and has been shipped in Safari. We should also make it available in Chromium. Risks

Interoperability and Compatibility Not expected. Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1519519) Edge: No public signals Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=167000) Web developers: No signals Ergonomics Not expected. Activation Not expected. Security Not expected.

Debuggability Not expected. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No https://crbug.com/978682 Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=825895 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5714277878988800

This intent message was generated by Chrome Platform Status.

[Xiaocheng Hu]

API owners: is a TAG review necessary for this one?

Thanks!

[Emilio Cobos Álvarez]

On 6/26/19 9:15 PM, Xiaocheng Hu wrote:

Contact emails xiaoc...@chromium.org Explainer https://developer.mozilla.org/en-US/docs/Web/CSS/min#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/max#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/clamp#Examples Design docs/spec Specification: https://drafts.csswg.org/css-values-4/#comp-func http://bit.ly/31Yfkm6 TAG review

TAG review doesn't seem necessary.

There is no change to existing specs, and the feature seems pretty small with pretty straightforward behaviors introduced. Summary Allow comparison functions min(), max() and clamp() in math expressions for numeric CSS values. Motivation https://crbug.com/825895 The feature has been requested for over a year with many stars, and has been shipped in Safari. We should also make it available in Chromium. Risks

Interoperability and Compatibility Not expected.

There are various bits here that are tricky and for which a naive implementation on Blink would make stuff not be correct and interoperable. For example all the callers to Length::IsPercentOrCalc are wrong if you start treating min() and max() the same way calc() is treated (which is the obvious way to implement it). But I assume you're aware of those so :)

Also, related-ish question, does this intent include the multi-unit math that values-4 specifies? Or just the new functions? Those bits are not shipped by Safari and are probably a lot trickier.

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1519519)

I wouldn't consider having a bug on file for this "Public support".

I've been working on things that happen to block that bug for unrelated reasons, mostly performance and code cleanup.

Though I personally think these are nice, I don't speak for Mozilla as a whole :)

  -- Emilio

Edge: No public signals Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=167000) Web developers: No signals Ergonomics Not expected. Activation Not expected. Security Not expected.

Debuggability Not expected. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No https://crbug.com/978682 Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=825895 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5714277878988800

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhYKuuij5h7pmmoSGqPd_0BOpE_9fxpeHv1zpMVLSFz2HA%40mail.gmail.com.

[Xiaocheng Hu]

Thanks for the comments!

On Wed, Jun 26, 2019 at 2:38 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

On 6/26/19 9:15 PM, Xiaocheng Hu wrote:

Contact emails xiaoc...@chromium.org Explainer https://developer.mozilla.org/en-US/docs/Web/CSS/min#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/max#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/clamp#Examples Design docs/spec Specification: https://drafts.csswg.org/css-values-4/#comp-func http://bit.ly/31Yfkm6 TAG review

TAG review doesn't seem necessary.

There is no change to existing specs, and the feature seems pretty small with pretty straightforward behaviors introduced. Summary Allow comparison functions min(), max() and clamp() in math expressions for numeric CSS values. Motivation https://crbug.com/825895 The feature has been requested for over a year with many stars, and has been shipped in Safari. We should also make it available in Chromium. Risks

Interoperability and Compatibility Not expected.

There are various bits here that are tricky and for which a naive implementation on Blink would make stuff not be correct and interoperable. For example all the callers to Length::IsPercentOrCalc are wrong if you start treating min() and max() the same way calc() is treated (which is the obvious way to implement it). But I assume you're aware of those so :)

I think IsPercentOrCalc() should return true if min() and max() are involved, and the function should better be renamed as IsPercentOrMath().

Besides, all clients of Length (or similar structures like CalculationValue) will be changed to stop assuming a (px+%) result format on math functions. They currently do.

Anyway, shouldn't these be considered as bugs and be fixed right away? I thought this part means what interop/compat risks are expected if the feature is implemented properly.

Also, related-ish question, does this intent include the multi-unit math that values-4 specifies? Or just the new functions? Those bits are not shipped by Safari and are probably a lot trickier.

No. Since the implementation plan is to extend calc(), the supported unit types are exactly the same as what we currently do for calc().

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1519519)

I wouldn't consider having a bug on file for this "Public support".

I've been working on things that happen to block that bug for unrelated reasons, mostly performance and code cleanup.

Though I personally think these are nice, I don't speak for Mozilla as a whole :)

Sorry, I'm pretty new to this launch process.

I'll switch this field back

  -- Emilio

Edge: No public signals Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=167000) Web developers: No signals Ergonomics Not expected. Activation Not expected. Security Not expected.

Debuggability Not expected. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No https://crbug.com/978682 Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=825895 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5714277878988800

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhYKuuij5h7pmmoSGqPd_0BOpE_9fxpeHv1zpMVLSFz2HA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e22ecdf-67f0-b650-9d81-bfea60f1fc99%40mozilla.com.

[Emilio Cobos Álvarez]

On 6/27/19 12:39 AM, Xiaocheng Hu wrote:
>
> Thanks for the comments!
>
> On Wed, Jun 26, 2019 at 2:38 PM Emilio Cobos Álvarez <emi...@mozilla.com
> <mailto:emi...@mozilla.com>> wrote:
>
> On 6/26/19 9:15 PM, Xiaocheng Hu wrote:

>> Contact emailsxi...@chromium.org
>> <mailto:xiaoc...@chromium.org>Explainerhttps://developer.mozilla.org/en-US/docs/Web/CSS/min#Exampleshttps://developer.mozilla.org/en-US/docs/Web/CSS/max#Exampleshttps://developer.mozilla.org/en-US/docs/Web/CSS/clamp#ExamplesDesign
>> docs/specSpecification:
>> https://drafts.csswg.org/css-values-4/#comp-funchttp://bit.ly/31Yfkm6TAG

>> review
>> TAG review doesn't seem necessary.
>> There is no change to existing specs, and the feature seems pretty
>> small with pretty straightforward behaviors introduced.

>> SummaryAllow comparison functions min(), max() and clamp() in math

>> expressions for numeric CSS values.

>> Motivationhttps://crbug.com/825895The feature has been requested

>> for over a year with many stars, and has been shipped in Safari.
>> We should also make it available in Chromium. Risks
>> Interoperability and Compatibility Not expected.
>
> There are various bits here that are tricky and for which a naive
> implementation on Blink would make stuff not be correct and
> interoperable. For example all the callers to
> Length::IsPercentOrCalc are wrong if you start treating min() and
> max() the same way calc() is treated (which is the obvious way to
> implement it). But I assume you're aware of those so :)
>
> I think IsPercentOrCalc() should return true if min() and max() are
> involved, and the function should better be renamed as IsPercentOrMath().
>
> Besides, all clients of Length (or similar structures like
> CalculationValue) will be changed to stop assuming a (px+%) result
> format on math functions. They currently do.
>
> Anyway, shouldn't these be considered as bugs and be fixed right away? I
> thought this part means what interop/compat risks are expected if the
> feature is implemented properly.

Yeah I guess that's right, sorry for the confusion :)

> Also, related-ish question, does this intent include the multi-unit
> math that values-4 specifies? Or just the new functions? Those bits
> are not shipped by Safari and are probably a lot trickier.
>
> No. Since the implementation plan is to extend calc(), the supported
> unit types are exactly the same as what we currently do for calc().

Cool, thanks for confirming :)

>> /Firefox/: Public support

>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1519519)
>
> I wouldn't consider having a bug on file for this "Public support".
>
> I've been working on things that happen to block that bug for
> unrelated reasons, mostly performance and code cleanup.
>
> Though I personally think these are nice, I don't speak for Mozilla
> as a whole :)
>
> Sorry, I'm pretty new to this launch process.
> I'll switch this field back
>
>   -- Emilio
>

>> /Edge/: No public signals /Safari/: Shipped
>> (https://bugs.webkit.org/show_bug.cgi?id=167000) /Web developers/:

>> No signals Ergonomics Not expected. Activation Not expected.
>> Security Not expected.

>> DebuggabilityNot expected. Will this feature be supported on all

>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and

>> Android WebView)?Yes Is this feature fully tested by
>> web-platform-tests
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?No
>> https://crbug.com/978682Tracking
>> bughttps://bugs.chromium.org/p/chromium/issues/detail?id=825895Link to

>> entry on the Chrome Platform

>> Statushttps://chromestatus.com/feature/5714277878988800

>> This intent message was generated by Chrome Platform Status

>> <https://www.chromestatus.com/>.

>> --
>> You received this message because you are subscribed to the Google
>> Groups "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to blink-dev+...@chromium.org

>> <mailto:blink-dev+...@chromium.org>.

>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhYKuuij5h7pmmoSGqPd_0BOpE_9fxpeHv1zpMVLSFz2HA%40mail.gmail.com

>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhYKuuij5h7pmmoSGqPd_0BOpE_9fxpeHv1zpMVLSFz2HA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e22ecdf-67f0-b650-9d81-bfea60f1fc99%40mozilla.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5e22ecdf-67f0-b650-9d81-bfea60f1fc99%40mozilla.com?utm_medium=email&utm_source=footer>.
>

[Yoav Weiss]

On Wed, Jun 26, 2019 at 9:16 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

API owners: is a TAG review necessary for this one?

Was this discussed as part of the CSSWG? If so, and since this is already shipped in Safari, I don't feel it's necessary to wait for a TAG review here.

Thanks!

On Wed, Jun 26, 2019 at 12:15 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

Contact emails xiaoc...@chromium.org Explainer https://developer.mozilla.org/en-US/docs/Web/CSS/min#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/max#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/clamp#Examples Design docs/spec Specification: https://drafts.csswg.org/css-values-4/#comp-func http://bit.ly/31Yfkm6 TAG review

TAG review doesn't seem necessary.

There is no change to existing specs, and the feature seems pretty small with pretty straightforward behaviors introduced. Summary Allow comparison functions min(), max() and clamp() in math expressions for numeric CSS values. Motivation https://crbug.com/825895 The feature has been requested for over a year with many stars, and has been shipped in Safari. We should also make it available in Chromium. Risks

Interoperability and Compatibility Not expected.

As far as developer advice goes, what would be the recommendation for using these new functions while they are supported by some browsers but not all?

To use `@supports`? Something else?

 

Firefox: Public support (https://bugzilla.mozilla.org/show_bug.cgi?id=1519519) Edge: No public signals Safari: Shipped (https://bugs.webkit.org/show_bug.cgi?id=167000) Web developers: No signals Ergonomics Not expected. Activation Not expected. Security Not expected.

Debuggability Not expected. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? No https://crbug.com/978682

Adding those tests seems imperative indeed. Thanks for filing that.

 

Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=825895 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5714277878988800

This intent message was generated by Chrome Platform Status.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhaiSv4MxWeh6S0fAdg%2BLrUJy26KHKk%3DNjv81GrPW9NUFw%40mail.gmail.com.

[Stephen Mcgruer]

Xiaocheng and I have already spoken about this, but I would like to see the interpolation story (https://github.com/w3c/csswg-drafts/issues/4082) answered before we ship this. It may be that interpolation is already well defined, but this wasn't clear to me when Xiaocheng and I chatted about it. It would be well worth investigating how Safari handles interpolation of min(), max(), and clamp() today if they have already shipped, and check whether they have landed any WPT tests relating to interpolation (the Safari bug mentions WPT tests once - most likely in the non-interpolation context - but it's not clear to me if they actually landed any).

That said, not an API owner, can't block anything formally :p

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEishn5LnKOUeKLm1vcDDM5e%2BNd6tDiqtXJpLXBhv9k0SQ%40mail.gmail.com.

[Xiaocheng Hu]

Sorry for the delay.

On Thu, Jul 4, 2019 at 5:28 AM Stephen Mcgruer <smcg...@chromium.org> wrote:

Xiaocheng and I have already spoken about this, but I would like to see the interpolation story (https://github.com/w3c/csswg-drafts/issues/4082) answered before we ship this. It may be that interpolation is already well defined, but this wasn't clear to me when Xiaocheng and I chatted about it. It would be well worth investigating how Safari handles interpolation of min(), max(), and clamp() today if they have already shipped, and check whether they have landed any WPT tests relating to interpolation (the Safari bug mentions WPT tests once - most likely in the non-interpolation context - but it's not clear to me if they actually landed any).

That said, not an API owner, can't block anything formally :p

The interpolation spec issue is already resolved:

• RESOLVED: For interpolation math functions are treated as atomic algebraic terms. You interpolate a calc expression that is the weighted sum of all the terms

So there's no blocking issue here.

 

On Thu, 4 Jul 2019 at 03:48, Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jun 26, 2019 at 9:16 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

API owners: is a TAG review necessary for this one?

Was this discussed as part of the CSSWG? If so, and since this is already shipped in Safari, I don't feel it's necessary to wait for a TAG review here.

Sorry I'm not familiar with this process. How do I check?

 

Thanks!

On Wed, Jun 26, 2019 at 12:15 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

Contact emails xiaoc...@chromium.org Explainer https://developer.mozilla.org/en-US/docs/Web/CSS/min#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/max#Examples https://developer.mozilla.org/en-US/docs/Web/CSS/clamp#Examples Design docs/spec Specification: https://drafts.csswg.org/css-values-4/#comp-func http://bit.ly/31Yfkm6 TAG review

TAG review doesn't seem necessary.

There is no change to existing specs, and the feature seems pretty small with pretty straightforward behaviors introduced. Summary Allow comparison functions min(), max() and clamp() in math expressions for numeric CSS values. Motivation https://crbug.com/825895 The feature has been requested for over a year with many stars, and has been shipped in Safari. We should also make it available in Chromium. Risks

Interoperability and Compatibility Not expected.

As far as developer advice goes, what would be the recommendation for using these new functions while they are supported by some browsers but not all?

To use `@supports`? Something else?

Yes, we should follow the standard approach and use @supports.

[Chris Harrelson]

LGTM1

https://github.com/w3c/csswg-drafts/issues/544

https://github.com/w3c/csswg-drafts/issues/2519

On Thu, Jul 18, 2019 at 12:40 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

Sorry for the delay.

On Thu, Jul 4, 2019 at 5:28 AM Stephen Mcgruer <smcg...@chromium.org> wrote:

Xiaocheng and I have already spoken about this, but I would like to see the interpolation story (https://github.com/w3c/csswg-drafts/issues/4082) answered before we ship this. It may be that interpolation is already well defined, but this wasn't clear to me when Xiaocheng and I chatted about it. It would be well worth investigating how Safari handles interpolation of min(), max(), and clamp() today if they have already shipped, and check whether they have landed any WPT tests relating to interpolation (the Safari bug mentions WPT tests once - most likely in the non-interpolation context - but it's not clear to me if they actually landed any).

That said, not an API owner, can't block anything formally :p

The interpolation spec issue is already resolved:

• RESOLVED: For interpolation math functions are treated as atomic algebraic terms. You interpolate a calc expression that is the weighted sum of all the terms

So there's no blocking issue here.

 

On Thu, 4 Jul 2019 at 03:48, Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Jun 26, 2019 at 9:16 PM Xiaocheng Hu <xiaoc...@chromium.org> wrote:

API owners: is a TAG review necessary for this one?

Was this discussed as part of the CSSWG? If so, and since this is already shipped in Safari, I don't feel it's necessary to wait for a TAG review here.

Sorry I'm not familiar with this process. How do I check?

They are in the editor's draft, and there are CSSWG resolutions regarding that as part of the standard process.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhZ40yvh4U6iUa2svr9amakio%3Dq6bPH%3D92KjoavtTyB9dQ%40mail.gmail.com.

[Yoav Weiss]

LGTM2

[Rick Byers]

LGTM3 assuming the WPT tests will be landed and passing consistently between Chrome and Safari prior to the feature being enabled. If there are some known failures or differences in behavior between Chrome and Safari then please ping this thread to let us know.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhF0M%3DjsKmjZitxZ0Wy2c_BMM2mnmLMHS46yFxc2F%2BnZw%40mail.gmail.com.

[Boris Zbarsky]

On 7/20/19 6:33 PM, Rick Byers wrote:
> LGTM3 assuming the WPT tests will be landed

> <https://bugs.chromium.org/p/chromium/issues/detail?id=978682> and

> passing consistently between Chrome and Safari prior to the feature
> being enabled.

Just to check, do the tests test the situations I recall David Baron
bringing up the last time min() and max() in calc() were being
discussed, where there were multiple layouts possible that would fit the
constraints, with no obvious way to decide which one should actually be
used? Does the calc() spec handle that now?

-Boris

[Xiaocheng Hu]

(back from vacation...)

Thanks for the reviews!

I'm pretty new to style and might have missed that discussion.

Could you provide some context? Thanks!

-Boris

[j.j.]

Am Freitag, 2. August 2019 21:42:13 UTC+2 schrieb Xiaocheng Hu:

(back from vacation...)

Probably this:

https://github.com/w3c/csswg-drafts/issues/544#issuecomment-272501187

[Xiaocheng Hu]

That's about clamp() and is already resolved:

https://github.com/w3c/csswg-drafts/issues/2519#issuecomment-387803089

[Boris Zbarsky]

On 8/2/19 3:41 PM, Xiaocheng Hu wrote:
> I'm pretty new to style and might have missed that discussion.
>
> Could you provide some context?

I don't have links off the top of my head; I haven't been following CSS
specs that closely recently. As I recall the issue was something like this:

Given the combination of calc(), min(), and max(), it's possible to
produce values for `width`, say, that are arbitrary piecewise linear
functions of the width of the parent. In particular, you can set things
up so that multiple values of the parent width all map to the same child
width.

Now in situations in which the parent is shrink-wrapping, how do you
decide which of those valid parent widths it should have?

Again, this is my vague memory of the problem and you would do best to
contact David Baron directly about the issue instead of relying on my
memory of a long-ago complicated technical point he raised...

-Boris

[Boris Zbarsky]

On 8/2/19 4:15 PM, j.j. wrote:
> Probably this:
> https://github.com/w3c/csswg-drafts/issues/544#issuecomment-272501187

No, that is very much not what I am talking about.

-Boris

[Xiaocheng Hu]

This part seems already spec-ed?

https://drafts.csswg.org/css-sizing-3/#percentage-sizing gave a bunch of rules to resolve cyclic percentages, which basically says "use initial value", "treat it as auto" or "treat it as zero".

Blink seems to be doing that already (haven't checked thoroughly though), so it doesn't seem to be a new issue for min/max/clamp.

[Boris Zbarsky]

On 8/5/19 6:19 PM, Xiaocheng Hu wrote:
> https://drafts.csswg.org/css-sizing-3/#percentage-sizing gave a bunch of
> rules to resolve cyclic percentages, which basically says "use initial
> value", "treat it as auto" or "treat it as zero".

Yes, those percentage rules have been there for a while. Again, I seem
to recall that there were additional issues with min/max, but again you
should just check with David Baron about this.

-Boris

[Xiaocheng Hu]

Routing in David Baron...

[L. David Baron]

The reasons I dropped min() and max() when I was originally
implementing calc() in Gecko are described in these two posts:
https://lists.w3.org/Archives/Public/www-style/2010Sep/0233.html
https://lists.w3.org/Archives/Public/www-style/2011Oct/0735.html

The first issue (that it makes division by zero harder to detect)
has been fixed in css-values-4 by defining the behavior of division
by zero rather than making it an error. (And probably also in
css-values-3 by limiting the feature, actually, rather than fixing
the issue.)

I believe the second issue (which is the only issue in the second of
those posts) still largely remains. It's not clear how min() and
max() should be handled in cases where layout algorithms try to
produce the correct intrinsic width for things with percentage
widths. The only interoperable case of this is likely widths on
table cells and columns, and maybe column groups. It may also
affect heights on certain table parts as well (cells, rows, row
groups).

The spec sort of works around this by explicitly avoiding the issue
in https://drafts.csswg.org/css-values-4/#calc-computed-value :

Given the complexities of width and height calculations on table
cells and table elements, math expressions mixing both
percentages and lengths for widths and heights on table columns,
table column groups, table rows, table row groups, and table
cells in both auto and fixed layout tables MAY be treated as if
auto had been specified.

but it doesn't say what behavior results if the implementation
chooses not to follow the "MAY".

It's possible there's also related material in one of:
https://drafts.csswg.org/css-sizing-3/
https://drafts.csswg.org/css-sizing-4/
https://drafts.csswg.org/css-tables-3/

-David

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

[Xiaocheng Hu]

Routing in Tab for a better spec discussion...

Blink follows the "MAY" part IIRC, so at least it still seems spec-compliant to implement min() and max() in Blink.

Spec-wise, I don't have a good idea.

Tab, could you shed some light on this interop issue? Thank you!

[Xiaocheng Hu]

Update: Shipped in M79 already. A comprehensive WPT test suite has also been added.

Related issues:

- The previous issue dbaron@ raised has been resolved for table at https://github.com/w3c/csswg-drafts/issues/94. We'll create a spec change PR and add relevant WPT soon.

- There's a newly raised serialization issue. This doesn't seem to be severe enough to block the launch, though.