Intent to Ship: Unprefix intrinsic sizing keywords (min-content. max-content, fill, fit-content)

[Christian Biesinger]

Contact emails

cbies...@chromium.org

Spec

https://drafts.csswg.org/css-sizing/#width-height-keywords

(TAG review not applicable to CSS, afaik)

Summary

We have long supported prefixed versions of these keywords (though we
use -webkit-fill-available for fill). Based on in-person conversations
with Tab and Elika as well as an email to www-style
(https://lists.w3.org/Archives/Public/www-style/2015Aug/0039.html), it
is now safe to ship these new values even though css-sizing as a whole
is still a draft spec.

Tangentially related: The current discussion on removing old,
webkit-only but unprefixed versions of some of these properties
(min-intrinsic and intrinsic),
https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/min-intrinsic/blink-dev/Gmiodt2RZ7w/nwXYY0X-BwAJ

Of course I would keep around the prefixed versions as well.

Also thanks to alancutter for starting the previous version of this
discussion at https://groups.google.com/a/chromium.org/d/msgid/layout-dev/346e8a4e-ac08-4db4-8f45-ee31b8d05c68%40chromium.org?utm_medium=email&utm_source=footer

Link to “Intent to Implement” blink-dev discussion

n/a -- implementation long predates the fork


Is this feature supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, Android, and Android WebView)?

Yes


Demo link

http://jsbin.com/mabalawaba/edit?html,css,js,output

(this page will put each word on a separate line when this property works)

Debuggability

n/a?

Compatibility Risk

This feature is widely implemented, but prefixed:
http://caniuse.com/#feat=intrinsic-width

All browsers except IE implement a prefixed version of these keywords.

OWP launch tracking bug

No OWP bug. Let me know if I should file one.

Implementation bug: https://code.google.com/p/chromium/issues/detail?id=245157

Entry on the feature dashboard

https://www.chromestatus.com/feature/5901353784180736

-christian

[Rick Byers]

So the spec matches what we (and WebKit) already have had behind a prefix?  I.e. our new un-prefixed versions of these API should be interoperable with Safari and Mozilla's prefixed versions?

[Christian Biesinger]

Yes, that's correct.

(I am not sure that Safari supports the keywords for the height properties, btw, but we do)

-christian

[Rick Byers]

Ok, sounds good to me.  LGTM to ship.

[PhistucK]

While the rest of the gang have prefixed implementations, did you discuss with them whether they have any intention of unprefixing (or - worse - removing) their implementation?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Christian Biesinger]

I will contact them.

Meanwhile I also learned that Mozilla does not implement the keywords for heights, either: https://bugzilla.mozilla.org/show_bug.cgi?id=567039

-christian

[Christian Biesinger]

Got positive responses from Webkit and Gecko. It sounds like they both
want to unprefix but have no immediate plans to do so:

https://lists.webkit.org/pipermail/webkit-dev/2015-August/027604.html
http://logs.glob.uno/?c=mozilla%23layout&s=12+Aug+2015&e=12+Aug+2015#c6757

So, I think we should go ahead with this.

-christian

[Philip Jägenstedt]

LGTM2

[Christian Biesinger]

Thanks for the lgtms so far. FYI, I've also added use counters for the
prefixed keywords so we can see which of the prefixes we will
eventually be able to remove
(https://codereview.chromium.org/1285263005/).

Anyone up for a third lgtm? :)

-christian

[Chris Harrelson]

LGTM3

[Christian Biesinger]

Thanks for the LGTMs. This is now unprefixed:
https://chromium.googlesource.com/chromium/blink.git/+/bf119cdfece210e69c9a99af06f1b9981e2a1bc2

-christian

[Manuel Rego Casasnovas]

On 06/08/15 05:38, Christian Biesinger wrote:
> (I am not sure that Safari supports the keywords for the height
> properties, btw, but we do)

JFTR, WebKit supports the keywords for height since this summer:
http://trac.webkit.org/changeset/185908

Bye,
Rego