Removing CssValue APIs

These APIs were introduced in the CSS DOM 2 spec and have been removed from the CSS DOM 3 spec. We should remove them as well.

http://dev.w3.org/csswg/cssom/#the-cssstyledeclaration-interface

BUG=

Committed: https://code.google.com/p/dart/source/detail?r=21121

[Jacob, 2013-03-21 23:11:51]

lgtm

A couple minor notes on the impl_Window changes that don't seem related to
removing CssValue but are part of this CL.

https://codereview.chromium.org/12857006/diff/2001/tools/dom/templates/html/i...
File tools/dom/templates/html/impl/impl_Window.darttemplate (right):

https://codereview.chromium.org/12857006/diff/2001/tools/dom/templates/html/i...
tools/dom/templates/html/impl/impl_Window.darttemplate:234: new
_DomPoint(point.x, point.y));
I think the JavaScript API for this was supposed to accept arbitrary objects of
the form {x: NUM, y: num}.  We might be able to use that to avoid performing
this conversion in the future.

https://codereview.chromium.org/12857006/diff/2001/tools/dom/templates/html/i...
tools/dom/templates/html/impl/impl_Window.darttemplate:235: return new
Point(result.x, result.y);
why not just make _DomPoint implement Point so this isn't required?

[blois, 2013-04-02 20:25:30]

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
File tools/dom/templates/html/impl/impl_Window.darttemplate (right):

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
tools/dom/templates/html/impl/impl_Window.darttemplate:234: new
_DomPoint(point.x, point.y));
On 2013/03/21 23:11:51, Jacob wrote:
> I think the JavaScript API for this was supposed to accept arbitrary objects
of
> the form {x: NUM, y: num}.  We might be able to use that to avoid performing
> this conversion in the future.

Can we guarantee that the fields x & y will not be renamed via minification?

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
tools/dom/templates/html/impl/impl_Window.darttemplate:235: return new
Point(result.x, result.y);
On 2013/03/21 23:11:51, Jacob wrote:
> why not just make _DomPoint implement Point so this isn't required?

That seems like a heavier solution than necessary here, this should be a fairly
lightweight conversion and I'd prefer to do the conversion (though went in the
opposite direction for ClientRect).

[Jacob, 2013-04-02 23:57:13]

lgtm

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
File tools/dom/templates/html/impl/impl_Window.darttemplate (right):

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
tools/dom/templates/html/impl/impl_Window.darttemplate:234: new
_DomPoint(point.x, point.y));
I doubt we can.  
On 2013/04/02 20:25:30, blois wrote:
> On 2013/03/21 23:11:51, Jacob wrote:
> > I think the JavaScript API for this was supposed to accept arbitrary objects
> of
> > the form {x: NUM, y: num}.  We might be able to use that to avoid performing
> > this conversion in the future.
> 
> Can we guarantee that the fields x & y will not be renamed via minification?

https://chromiumcodereview.appspot.com/12857006/diff/2001/tools/dom/templates...
tools/dom/templates/html/impl/impl_Window.darttemplate:235: return new
Point(result.x, result.y);
Why not make both cases consistent?
On 2013/04/02 20:25:30, blois wrote:
> On 2013/03/21 23:11:51, Jacob wrote:
> > why not just make _DomPoint implement Point so this isn't required?
> 
> That seems like a heavier solution than necessary here, this should be a
fairly
> lightweight conversion and I'd prefer to do the conversion (though went in the
> opposite direction for ClientRect).

[blois, 2013-04-05 18:03:07]

https://codereview.chromium.org/12857006/diff/2001/tools/dom/templates/html/i...
File tools/dom/templates/html/impl/impl_Window.darttemplate (right):

https://codereview.chromium.org/12857006/diff/2001/tools/dom/templates/html/i...
tools/dom/templates/html/impl/impl_Window.darttemplate:235: return new
Point(result.x, result.y);
On 2013/04/02 23:57:13, Jacob wrote:
> Why not make both cases consistent?
> On 2013/04/02 20:25:30, blois wrote:
> > On 2013/03/21 23:11:51, Jacob wrote:
> > > why not just make _DomPoint implement Point so this isn't required?
> > 
> > That seems like a heavier solution than necessary here, this should be a
> fairly
> > lightweight conversion and I'd prefer to do the conversion (though went in
the
> > opposite direction for ClientRect).
> 

Had a good discussion with Stephen on this, would be happy to discuss again,
there's not a real clear answer but:

1) There needs to be a conversion for points coming into these methods as they
are most likely not going to be _DomPoints.
2) There's probably no win by caching the converted _DomPoint
3) For conversion vs implements of the return value, the cost to conversion is
accessing each DOM property at conversion time, even if the properties are not
needed (2x higher conversion cost for ClientRect compared to DomPoint)
4) The cost to 'implements' is that the compiler may not know the actual
implementation type is and need to add get$x() methods. These adds quite a bit
of unwanted overhead, but whether or not this is added changes daily with the
dart2js compiler.

Result:
Conversion overhead for ClientRect is most likely too high, implements better
for that (2x as many fields).
Inclination that potential compiler misunderstanding of types for DomPoint
implementing Point outweighs conversion costs.

[Jacob, 2013-04-05 18:51:53]

lgtm

[blois, 2013-04-08 23:25:20]

Committed patchset #3 manually as r21121 (presubmit successful).