Intent to Remove: getPropertyCSSValue, CSSValue and friends

[Timothy Loh]

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]

LGTM.

[Chris Harrelson]

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]

 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]

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]

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]

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]

LGTM!

[Yuki Shiino]

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]

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]

Thanks a lot!

[Philip Rogers]

LGTM

[PhistucK]

Can this be coordinated with WebKit somehow?

Are they opposed of such removal?

☆PhistucK

LGTM

[Tab Atkins Jr.]

LGTM

And, on a personal note, yesssssssssss

~TJ

[Dimitri Glazkov]

+rniwa

Ryosuke,

Would you WebKit folks be interested in something like this?

:DG<

[Jelte Liebrand]

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]

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]

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]

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]

FWIW this has now been removed from Blink (M41). Thanks to alancutter@ for reviewing heaps of test changes :)

[Chris Harrelson]

Nice!