Intent to Deprecate and Remove: intrinsic & min-intrinsic keywords

[Christian Biesinger]

Primary eng (and PM) emails

cbies...@chromium.org


Summary

intrinsic and min-intrinsic are webkit/blink-specific keywords for the
standard max-content and min-content keywords, recently unprefixed.

Motivation

They are non-standard, and equivalent standardized keywords exist. Usage is low:

min-intrinsic at 0.0708%:
https://www.chromestatus.com/metrics/feature/popularity#LegacyCSSValueMinIntrinsic

intrinsic at 0.0150%:
https://www.chromestatus.com/metrics/feature/popularity#LegacyCSSValueIntrinsic

They are also not consistently implemented by our codebase, leading to
occasional asserts (e.g. https://codereview.chromium.org/1292163005/)

See also discussion at
https://groups.google.com/a/chromium.org/d/topic/blink-dev/Gmiodt2RZ7w/discussion

Thanks to davve and robhogan for starting the earlier discussion which
prompted this intent :)

Compatibility Risk

Has been supported for a long time in blink/webkit, but not
implemented by anyone else.

Alternative implementation suggestion for web developers

intrinsic -> max-content
min-intrinsic -> min-content

Usage information from UseCounter

see above

OWP launch tracking bug

not OWP, but crbug.com/475104

Entry on the feature dashboard

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

Requesting approval to remove too?
Ideally I'd like to deprecate now and remove after 46 branches
tomorrow, at least "intrinsic".

-christian

[Dimitri Glazkov]

LGTM.

[Christian Biesinger]

...actually, I just realized that I don't know how to show a
deprecation message from inside of CSSPropertyParser.cpp. I don't
think I have a LocalFrame available but I'd need one :/

[Christian Biesinger]

...actually, I just realized that I don't know how to show a
deprecation message from inside of CSSPropertyParser.cpp. I don't
think I have a LocalFrame available but I'd need one :/

On Thu, Aug 20, 2015 at 3:56 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:

[Elliott Sprehn]

I think you'd want to deprecate at apply not parse time.

[Philip Jägenstedt]

LGTM2

Given the low usage and that this has actually required recent maintenance, deprecating for just one deprecation cycle seems fine. If the removal will be in M47, please include the date of the removal in the message like for ElementOffsetHeight and some others.

There are some use counters in CSSPropertyParser.cpp already, does following that pattern not work in this case?

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

[Christian Biesinger]

Elliott: I basically just followed the existing use counters in the
parser, added a few months ago (I forget who added them). Which
function would you put them in?

Philip: Sadly I can't add deprecation messages from CSSPropertyParser
(that's what I tried), because I don't have a LocalFrame object
available. Neither the CSSParserContext nor the UseCounter keep a
reference to it, and without it I don't have a console object
available to show the deprecation message. Unless I'm missing another
way to do it.

-christian

[Elliott Sprehn]

On Fri, Aug 21, 2015 at 2:36 PM, Christian Biesinger <cbies...@chromium.org> wrote:

Elliott: I basically just followed the existing use counters in the
parser, added a few months ago (I forget who added them). Which
function would you put them in?

Philip: Sadly I can't add deprecation messages from CSSPropertyParser
(that's what I tried), because I don't have a LocalFrame object
available. Neither the CSSParserContext nor the UseCounter keep a
reference to it, and without it I don't have a console object
available to show the deprecation message. Unless I'm missing another
way to do it.

You'd need to plumb the Frame down with CSSParserContext just like we do the UseCounter.

- E

[Christian Biesinger]

OK - was assuming there was a reason why that wasn't done, since
CSSParserContext goes out of its way not to store the Document that
its constructor takes. I'll do this next week.

-christian

[Christian Biesinger]

On Fri, Aug 21, 2015 at 5:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:
>

[Yoav Weiss]

If you pass down a Frame, please make sure that it's optional - so that we would be able to use CSSParser off-main-thread, where we don't have access to a frame.

[TAMURA, Kent]

LGTM3.

--

TAMURA Kent
Software Engineer, Google

[Christian Biesinger]

This is now https://codereview.chromium.org/1314923005

The LocalFrame is indeed optional.

-christian

[Christian Biesinger]

The deprecation has shipped in beta now. Usage of min-intrinsic keeps
trending downward, now at 0.0551%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/752

intrinsic is already way below the threshold at 0.0157%:
https://www.chromestatus.com/metrics/feature/timeline/popularity/751

Note that before the deprecation (Chrome 46 and below), we would count
this keyword whenever we parse it, even in cases like "width:
min-intrinsic; width: -webkit-min-content;". So there is definitely
some amount of overcounting going on.

Therefore I'd like to go ahead and remove this from trunk and made a
patch to do so.
I assume the lgtms are still valid for that.
https://codereview.chromium.org/1420303002/

-Christian

[Philip Jägenstedt]

On Fri, Oct 23, 2015 at 11:12 PM, Christian Biesinger
<cbies...@chromium.org> wrote:
>
> The deprecation has shipped in beta now. Usage of min-intrinsic keeps
> trending downward, now at 0.0551%:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/752
>
> intrinsic is already way below the threshold at 0.0157%:
> https://www.chromestatus.com/metrics/feature/timeline/popularity/751
>
> Note that before the deprecation (Chrome 46 and below), we would count
> this keyword whenever we parse it, even in cases like "width:
> min-intrinsic; width: -webkit-min-content;". So there is definitely
> some amount of overcounting going on.
>
> Therefore I'd like to go ahead and remove this from trunk and made a
> patch to do so.
> I assume the lgtms are still valid for that.
> https://codereview.chromium.org/1420303002/

Right, assuming the deprecation will be in at least one release cycle,
everything seems to be in order.

[Christian Biesinger]

Yep - deprecation will ship in 47, removal in 48. Thanks!

-Christian