Intent To Deprecate: CSSValue and friends

[Eric Seidel]

Primary eng (and PM) emails
ese...@chromium.org

Summary
Deprecate CSSValue (and all subclasses, including CSSPrimativeValue, CSSValueList, Rect, RGBColor, WebKitCSSTransformValue, WebKitCSSFilterValue, etc.)
https://code.google.com/p/chromium/codesearch#search/&q=CSSValue%20file:.idl&sq=package:chromium&type=cs

Motivation
Turns out 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

I also learned today that 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

I had assumed the inspector was a big consumer of these, but that doesn't even seem to be true anymore:
https://code.google.com/p/chromium/codesearch#search/&q=getPropertyCSSValue%20file:.js&sq=package:chromium&type=cs

A new CSSOM spec is in the works:

http://dev.w3.org/csswg/cssom/

Usage information from UseCounter
I've uploaded a patch to add deprecation logging and usecounters:

https://codereview.chromium.org/101143005

Compatibility Risk
Since IE never implemented these this should be removable.  Unclear yet how bad the compatibility risk is.

Row on feature dashboard?
Not yet.

Tracking as http://crbug.com/331608

Requesting approval to remove too?
Not yet.

[Tab Atkins Jr.]

On Fri, Jan 3, 2014 at 4:18 PM, Eric Seidel <ese...@chromium.org> wrote:
> A new CSSOM spec is in the works:
> http://dev.w3.org/csswg/cssom/

To be clear, this spec is not intending to provide a replacement for
the CSSValue & friends API. It's just an improved spec for the
existing OM stuff.

Anne van Kesteren partially completed a new proposal for a CSSOM
Values API before he left the CSSWG and stopped working on it. I
intend to work on that, but was waiting for either implementor
interest or a glut of free time, neither of which have shown up in the
last two years. Since Eric seems potentially interested in this,
though, I can start actively working on it.

(The existing CSSValue API, as defined by DOM Level 2 Style, is
*horrible*. It's a complete disaster for future compatibility, and
would freeze a number of design choices which we *regularly* make in
CSS without incident. For example, the getPropertyCSSValue function,
at least as implemented by Firefox and specced in MDN, returns null
for shorthand properties. CSS *regularly* converts normal properties
into shorthands, as the property gains complexity and becomes
worthwhile to subdivide. The old API we have currently would break
all pages trying to work with the property's value when we changed
over, as it suddenly switches from an object to null. There are good
ways to handle the kinds of changes that CSS tends to make, which I'll
address in my API proposal.)

~TJ

[Alexis Menard]

Hi,

On Fri, Jan 3, 2014 at 9:18 PM, Eric Seidel <ese...@chromium.org> wrote:

Primary eng (and PM) emails
ese...@chromium.org

Summary
Deprecate CSSValue (and all subclasses, including CSSPrimativeValue, CSSValueList, Rect, RGBColor, WebKitCSSTransformValue, WebKitCSSFilterValue, etc.)
https://code.google.com/p/chromium/codesearch#search/&q=CSSValue%20file:.idl&sq=package:chromium&type=cs

Motivation
Turns out 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

I also learned today that 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

I think it's good to remember what we're talking about here for people not so familiar with the subject. We have two main cases where CSSValues derived objects are returned to the public.

- window.getComputedStyle(myElement, null).getPropertyValue/getCSSPropertyValue("prop")

- myElement.style.getPropertyValue/getCSSPropertyValue("prop")

You can use the return value in that way for example :

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").toString()", "'[object CSSValueList]'");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").cssText", "'320px solid rgb(0, 0, 255)'")

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").length", "3");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").item(0).getFloatValue(CSSPrimitiveValue.CSS_PX)", "320");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").item(1).getStringValue()", "'solid'");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").item(2).getRGBColorValue().red.getFloatValue(CSSPrimitiveValue.CSS_NUMBER)", "0");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").item(2).getRGBColorValue().green.getFloatValue(CSSPrimitiveValue.CSS_NUMBER)", "0");

shouldBe("computedStyle.getPropertyCSSValue("border-bottom").item(2).getRGBColorValue().blue.getFloatValue(CSSPrimitiveValue.CSS_NUMBER)", "255");

Above is an example of the CSSOM we "leak".

Realistically speaking I think from the two uses cases the former is almost impossible to deprecate (I don't even think we have a replacement for that). While *I* think most of the people use the cssText or getPropertyValue() to check the computed value of the property I've seen few lines of code using the CSSOM on the return value after using typeof().

From the later we could potentially deprecate style.getCSSPropertyValue as Blink (and then WebKit) is the only browser supporting it (as long as my testing at that time). See : https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleDeclaration

What Eric has not highlighted here but I believe is the idea he has behind this deprecation. Today in Blink after parsing the CSS, we construct a bunch of CSSValues holding the representation of the values for each properties for a given declaration. These CSSValues are used (and converted) on the fly for use in the rendering and layouting code. These CSSValues are also the same ones we return in the use cases I highlighted above. This is working well but it's not very efficient : CSSValues (and derived) hold a lot of information that the layout/rendering code doesn't really need (some type infos, some bits related to how we construct the string representation, ...). Ideally long term Blink should use a given internal representation of the CSSValues with all the infos needed by the clients inside the engine and when queried, it returns the CSSOM built from these internal object. This is a long term plan and probably a good chunk of work but I think it's worth it. Plus if we have this system to create a CSSOM representation of an internal CSSValue then it's easy to return one CSSOM representation or another (provided a spec arrives at some point).

Note that the CSSOM is a wonderful place of unspecified behaviour. It's very inconsistent from one vendor to another.

I had assumed the inspector was a big consumer of these, but that doesn't even seem to be true anymore:
https://code.google.com/p/chromium/codesearch#search/&q=getPropertyCSSValue%20file:.js&sq=package:chromium&type=cs

A new CSSOM spec is in the works:

http://dev.w3.org/csswg/cssom/

Usage information from UseCounter
I've uploaded a patch to add deprecation logging and usecounters:

https://codereview.chromium.org/101143005

Compatibility Risk
Since IE never implemented these this should be removable.  Unclear yet how bad the compatibility risk is.

Row on feature dashboard?
Not yet.

Tracking as http://crbug.com/331608

Requesting approval to remove too?
Not yet.

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

--
Alexis Menard

[Tab Atkins Jr.]

I'm pretty sure we can kill both of them. As noted in MDN, we and
Firefox are the only browsers that support the method on gCS, and
we're the only ones who support it on style. IE and Opera have never
supported this, and FF's "support" is very haphazard. I suspect that
the biggest user of this API is our own layout tests, which use them
to a ridiculous degree. (And completely unnecessarily, too - many
tests call gCS(el).gPCV('foo').cssText rather than just using
gCS(el)['foo'].)

Because they've never been supported in IE, they work in only some
circumstances and only partially in Firefox, and they don't work for
any shorthands (which means that code depending on a property
returning a useful value will break as soon as we turn that property
into a shorthand, which CSS does regularly), I suspect usage in the
wild to be absolutely minimal, and eagerly await the UseCounter data
hopefully supporting this.

We plan on replacing this with a *good* values-based API that works
well with the ways the language naturally evolves, and is less
ridiculously verbose.

~TJ

[Alex Russell]

+1. Please kill these ASAP.

[rosa maria palacios juncosa]