Intent to Remove: getPropertyCSSValue, CSSValue and friends

387 views
Skip to first unread message

Timothy Loh

unread,
Oct 30, 2014, 12:12:41 AM10/30/14
to blin...@chromium.org, taba...@chromium.org, ese...@chromium.org

Primary eng (and PM) emails

tim...@chromium.org


Link to “Intent to Deprecate” thread

https://groups.google.com/a/chromium.org/d/msg/blink-dev/eBu466IGmMw/ddqqlGBG2xkJ


Summary

Remove CSSValue (and all subclasses, including CSSPrimitiveValue, CSSValueList, Rect, RGBColor, WebKitCSSTransformValue, WebKitCSSFilterValue, etc.)

Remove CSSStyleDeclaration.getPropertyCSSValue

https://code.google.com/p/chromium/codesearch#search/&q=CSSValue%20file:.idl&sq=package:chromium&type=cs


https://code.google.com/p/chromium/issues/detail?id=331608


Motivation

CSSValue and friends were deprecated by the W3C waaay back in 2003 (probably before WebKit even added many of them):

http://lists.w3.org/Archives/Public/www-style/2003Oct/0347.html


We are the only engine (besides WebKit) to fully implement these.  Firefox exposes a limited set of CSSValues and only when accessed via getComputedStyle:

https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/225

Usage of getPropertyCSSValue is at 0.0076%, lower than the threshold of 0.03% we commonly use.


Entry on chromestatus.com

None.


Compatibility Risk

This removal has low compatibility risk. getPropertyCSSValue is not implemented by IE, and the usage is quite low. We don’t have UseCounter data for usage of CSSValue/etc., but it is unlikely that these will be depended on separately from getPropertyCSSValue.

Dimitri Glazkov

unread,
Oct 30, 2014, 12:19:42 AM10/30/14
to Timothy Loh, blin...@chromium.org, taba...@chromium.org, Eric Seidel
LGTM.

Chris Harrelson

unread,
Oct 30, 2014, 12:21:23 AM10/30/14
to Timothy Loh, blin...@chromium.org, taba...@chromium.org, Eric Seidel
LGTM

On Wed, Oct 29, 2014 at 9:12 PM, Timothy Loh <tim...@chromium.org> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Kentaro Hara

unread,
Oct 30, 2014, 12:23:40 AM10/30/14
to Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
 Does this mean that we can completely remove the CSSValue hierarchy from Blink?

yukishiino@ is planning to split CSSValue into CSSValueForDOM and CSSValueForJS (used for CSSOM) in order to make all JS-exposed objects ScriptWrappable. For that goal, he is now adding UseCounters for CSSOM.

If we can just remove the hierarchy completely, that sounds the best :)

--
Kentaro Hara, Tokyo, Japan

Timothy Loh

unread,
Oct 30, 2014, 12:28:08 AM10/30/14
to Kentaro Hara, Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
I assume you're referring to crbug.com/390065? We'll still keep CSSValues for representing values internally, although these will no longer be web-exposed (perhaps eventually they'll be replaced by something else).

Kentaro Hara

unread,
Oct 30, 2014, 12:31:54 AM10/30/14
to Timothy Loh, Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
I assume you're referring to crbug.com/390065? We'll still keep CSSValues for representing values internally, although these will no longer be web-exposed (perhaps eventually they'll be replaced by something else).

Yes.

Then we need to keep CSSValue in Blink implementation, but we no longer need to make CSSValue derive ScriptWrappable because CSSValue is no longer exposed to JS. In other words, we can mark crbug.com/390065 as WONTFIX. Am I understanding correctly?

Timothy Loh

unread,
Oct 30, 2014, 12:33:50 AM10/30/14
to Kentaro Hara, Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
On Thu, Oct 30, 2014 at 3:31 PM, Kentaro Hara <har...@chromium.org> wrote:
I assume you're referring to crbug.com/390065? We'll still keep CSSValues for representing values internally, although these will no longer be web-exposed (perhaps eventually they'll be replaced by something else).

Yes.

Then we need to keep CSSValue in Blink implementation, but we no longer need to make CSSValue derive ScriptWrappable because CSSValue is no longer exposed to JS. In other words, we can mark crbug.com/390065 as WONTFIX. Am I understanding correctly?

That's correct, CSSValue won't need to be ScriptWrappable. 

Kentaro Hara

unread,
Oct 30, 2014, 12:35:58 AM10/30/14
to Timothy Loh, Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
LGTM!

Yuki Shiino

unread,
Oct 30, 2014, 12:47:03 AM10/30/14
to Kentaro Hara, Timothy Loh, Timothy Loh, Yuki Shiino, blin...@chromium.org, taba...@chromium.org, Eric Seidel
Hi Timothy,

Are you going to remove CSSValue.idl, etc. as well?  As we will no longer expose CSSValue to web, I think they will be gone, too.  We're especially interested in
- core/css/CSSValue.idl
- core/css/CSSRule.idl
- core/css/RGBColor.idl
- core/css/Rect.idl
(implicitly including their subclasses.  If you remove above 4 IDLs, then their subclasses should be gone, too.)

These 4 IDLs (and their subclasses) were our targets to make ScriptWrappable.
Will you remove them?

Cheers,
Yuki Shiino

Timothy Loh

unread,
Oct 30, 2014, 12:58:09 AM10/30/14
to Yuki Shiino, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel
On Thu, Oct 30, 2014 at 3:46 PM, Yuki Shiino <yukis...@chromium.org> wrote:
Hi Timothy,

Are you going to remove CSSValue.idl, etc. as well?  As we will no longer expose CSSValue to web, I think they will be gone, too.  We're especially interested in
- core/css/CSSValue.idl
- core/css/CSSRule.idl
- core/css/RGBColor.idl
- core/css/Rect.idl
(implicitly including their subclasses.  If you remove above 4 IDLs, then their subclasses should be gone, too.)

These 4 IDLs (and their subclasses) were our targets to make ScriptWrappable.
Will you remove them?

Cheers,
Yuki Shiino


CSSRule is not going to be removed, as it is still part of the CSSOM, http://dev.w3.org/csswg/cssom/#the-cssrule-interface. The other idl files you've listed will go away.

Yuki Shiino

unread,
Oct 30, 2014, 1:36:59 AM10/30/14
to Timothy Loh, Yuki Shiino, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel
Thanks a lot!

Philip Rogers

unread,
Oct 30, 2014, 1:51:30 AM10/30/14
to Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
LGTM

PhistucK

unread,
Oct 30, 2014, 3:14:44 AM10/30/14
to Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
Can this be coordinated with WebKit somehow?
Are they opposed of such removal?


PhistucK

LGTM

Tab Atkins Jr.

unread,
Oct 30, 2014, 1:02:43 PM10/30/14
to Timothy Loh, blin...@chromium.org, taba...@chromium.org, Eric Seidel
LGTM

And, on a personal note, yesssssssssss

~TJ

Dimitri Glazkov

unread,
Oct 30, 2014, 1:07:26 PM10/30/14
to PhistucK, Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand, Ryosuke Niwa
+rniwa

Ryosuke,

Would you WebKit folks be interested in something like this?

:DG<

Jelte Liebrand

unread,
Oct 30, 2014, 2:31:13 PM10/30/14
to blin...@chromium.org, taba...@chromium.org, ese...@chromium.org, tim...@chromium.org
These APIs have always bugged me, they are a mess, so removing them makes sense.

But we (Quickoffice on Chrome) do use them, in particular for things like converting size values from PX to PT and getting actual number/float values rather than a bunch of cssText strings that we'd have to parse... Without these APIs, what would the recommended approach be to doing this? Roll our own conversion and parsing modules?

/Cheers,
Jelte

Tab Atkins

unread,
Oct 30, 2014, 2:40:12 PM10/30/14
to Jelte Liebrand, blink-dev, taba...@chromium.org, Eric Seidel, tim...@chromium.org
On Thu, Oct 30, 2014 at 11:31 AM, Jelte Liebrand <jlie...@google.com> wrote:
> These APIs have always bugged me, they are a mess, so removing them makes
> sense.
>
> But we (Quickoffice on Chrome) do use them, in particular for things like
> converting size values from PX to PT and getting actual number/float values
> rather than a bunch of cssText strings that we'd have to parse... Without
> these APIs, what would the recommended approach be to doing this? Roll our
> own conversion and parsing modules?

You don't need these to do px to pt conversions - you just multiple by 3/4.

For the rest, these APIs are super-shitty and we shouldn't try to
preserve them just for the purpose of doing a bit of conversions; we
should instead have non-shitty APIs in CSSOM.

I have a long-term proposal for much better APIs in this vein that the
CSSWG plans to adopt, but it requires JavaScript to finish up its
Value Objects proposal. It's possible that we can do conversion APIs
beforehand somehow, but that could use some discussion on the
www-style list.

I don't think we should hold up killing these terrible APIs, though.
Most authors just roll their own parsing/converting, which isn't
great, but generally works.

~TJ

Ryosuke Niwa

unread,
Nov 17, 2014, 11:19:35 PM11/17/14
to Dimitri Glazkov, PhistucK, Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
There appears to be a mild interest in removing these API among WebKit contributors I've talked to.  However, it really depends on the usage of these APIs in wild, I haven't met anyone motivated enough to do the work in WebKit yet.

Mike Lawther

unread,
Nov 20, 2014, 1:02:00 AM11/20/14
to Ryosuke Niwa, Dimitri Glazkov, PhistucK, Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
Hi Ryosuke,

When you say it really depends on the usage in the wild - do you mean lower usage would be more motivating? The OP mentioned that "getPropertyCSSValue is at 0.0076%".

At any rate, it sounds safe to say that you don't know of anyone in WebKit opposed to the removal of these APIs?

Timothy Loh

unread,
Nov 20, 2014, 1:32:38 PM11/20/14
to Mike Lawther, Ryosuke Niwa, Dimitri Glazkov, PhistucK, Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
FWIW this has now been removed from Blink (M41). Thanks to alancutter@ for reviewing heaps of test changes :)

Chris Harrelson

unread,
Nov 20, 2014, 1:36:07 PM11/20/14
to Timothy Loh, Mike Lawther, Ryosuke Niwa, Dimitri Glazkov, PhistucK, Philip Rogers, Yuki Shiino, Timothy Loh, Kentaro Hara, blin...@chromium.org, taba...@chromium.org, Eric Seidel, Jelte Liebrand
Nice!
Reply all
Reply to author
Forward
0 new messages