Intent to Deprecate and Remove: support for position values with 3 parts (excluding background)

瀏覽次數:164 次
跳到第一則未讀訊息

Eric Willigers

未讀,
2018年1月21日 晚上11:09:152018/1/21
收件者:blink-dev

Primary eng (and PM) emails

ericwi...@chromium.org


Summary

In 2017 the spec syntax changed so that <position> values, excluding background-position, no longer accept 3-value syntax like "left 20% top" or "right bottom 20%".


Blink will follow the spec and, after a deprecation period, no longer support values excluded by the spec.


Motivation

  • Consistency with spec

  • This will make it easier to parse future shorthands that may have a length or percentage adjacent to a <position>.

  • New properties accepting <position> will use the spec syntax, and we should be consistent.


Interoperability and Compatibility Risk

The risk is low as usage is less than 0.002% in total. The spec change to remove support for position values with 3 parts occurred early last year, and was recently reaffirmed in an  CSS WG discussion.


Edge: Supported, positive to removal

Firefox: Supported, positive to removal

Safari: Supported, positive to removal


Alternative implementation suggestion for web developers

Web developers can easily use 2 (or 1 or 4) value syntax instead of 3 value.

e.g. "80% 100%" or "top 0% right 20%" instead of "top right 20%"


Usage information from UseCounter


3 part position values appear in the following contexts:

basic-shape

0.00003%


gradient

0.0008%


object-position

0.0007%


perspective-origin

0.000001%


They also appear in background-position, with much higher usage, but that is supported by spec and isn't affected by this Intent.


OWP launch tracking bug

crbug.com/804187


Entry on the feature dashboard

https://www.chromestatus.com/features/5116559680864256



Requesting approval to remove too?

Yes, in M68.


TAMURA, Kent

未讀,
2018年1月23日 晚上8:42:212018/1/23
收件者:Eric Willigers、blink-dev
LGTM1 to remove.


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cac08cfb-8ded-4be7-a9dd-47186ea30975%40chromium.org.



--
TAMURA Kent
Software Engineer, Google


Rick Byers

未讀,
2018年1月23日 晚上9:55:262018/1/23
收件者:TAMURA, Kent、Eric Willigers、blink-dev
LGTM2

The usage in some cases like gradient isn't tiny, and the fact that all engines currently support this increases the risk.  But my intuition is that the severity of breakage (and ease of update) will be quite low in this case, so I support attempting a removal after at least a one milestone deprecation period.  As always if we discover significant breakage (eg. during beta) we should be prepared to re-enable and re-evaluate the tradeoff.  Since background-position will need to continue to support 3-value, it doesn't seem worth causing much pain to avoid the need for a couple other exceptions.

Also I'm somewhat skeptical that all other engines will actually remove - we've seen several cases in the past where removal lingers for years as a low-priority bug on every engine other than Chrome (and so we ultimately gain nothing by being willing to go first and take the risk).  So I'd like to go on record and say that if after a year of being removed in Chrome, it's still supported in at least two other engines then I'd argue for adding it back to Chrome (and the spec) to get back to a place of interop.  I.e. we're willing to take the risk of going first, but not to be the only one over a period of a year :-).

Rick

Philip Jägenstedt

未讀,
2018年1月25日 上午8:04:062018/1/25
收件者:Rick Byers、TAMURA, Kent、Eric Willigers、blink-dev
LGTM3

Please make sure there are negative tests for the non-support of this in web-platform-tests. This will make it easy to figure out if anyone else is following, and if we regularly triage tests that only we have been passing for a year, then this would come up. Similar to Rick, I think we should reopen the spec discussion if nobody else removes in a year, and put it back even if the spec doesn't change unless anyone else moves even then.

Daniel Bratell

未讀,
2018年1月29日 中午12:09:502018/1/29
收件者:blink-dev、Eric Willigers

In general it would be good to know these numbers in relation to a relevant feature usage so that we don't accidentally that larger features. I checked object-position and perspective-origin and about 0.03% of the sites using object-position triggered the counter while perspective-origin was much lower (0.00001%). The two others, basic-shape and gradient, I had no reference for.


/Daniel

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



--
/* Opera Software, Linköping, Sweden: CET (UTC+1) */

Eric Willigers

未讀,
2019年10月28日 晚上7:08:112019/10/28
收件者:blink-dev、tk...@chromium.org、ericwi...@chromium.org


On Wednesday, January 24, 2018 at 1:55:26 PM UTC+11, Rick Byers wrote:
Also I'm somewhat skeptical that all other engines will actually remove - we've seen several cases in the past where removal lingers for years as a low-priority bug on every engine other than Chrome (and so we ultimately gain nothing by being willing to go first and take the risk).  So I'd like to go on record and say that if after a year of being removed in Chrome, it's still supported in at least two other engines then I'd argue for adding it back to Chrome (and the spec) to get back to a place of interop.  I.e. we're willing to take the risk of going first, but not to be the only one over a period of a year :-).

Rick

回覆所有人
回覆作者
轉寄
0 則新訊息