Re: [css3-transforms] Extending CSSOM interface

On Thu, Feb 16, 2012 at 1:43 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> At least for WebKit and Mozilla there is a way to get them: getPropertyCSSValue().

Gecko does not appear to return anything like a CSSTransformValue from
getPropertyCSSValue():

data:text/html,<!doctype html>
<body style="-moz-transform:rotate(45deg)">
<script>
document.documentElement.textContent =
getComputedStyle(document.querySelector("body"))
.getPropertyCSSValue('-moz-transform')[0];
</script>

This outputs "undefined".  In WebKit, with the prefixes changed, it
outputs "[object WebKitCSSTransformValue]".  In Opera and IE it throws
an exception.  So as I said: this is implemented only by WebKit.

If we do want to spec support for this, the spec has to say what
returns the value.  Even if it said that calling
getPropertyCSSValue("transform") on the result of getComputedStyle()
had to return an appropriate CSSTransformValue, that would be
something.  Right now there's absolutely no clue given as to how to
get one of these objects.

But really, I think that getPropertyCSSValue() and CSSValueList need
to be properly specced for this to make sense.  It's impossible to
actually test conformance for the interface if the interface it
extends isn't defined anywhere, for example.  I'd favor just dropping
it entirely, unless other browsers than WebKit want to implement it.
(Note that IE and Opera seem not to implement getPropertyCSSValue() at
all.)

> It should be the biggest concern of CSSOM to address that! In the meantime we can specify the interfaces and make sure that they work when all browsers support either getPropertyCSSValue or another way to access it from CSSOM.

Until that time, the specification doesn't specify anything.  In
particular, it's not testable, so it can't progress to PR.

> I believe that this is one of the biggest outstanding issues on CSSOM. But it shouldn't block us to specify the interfaces right now. This is really important, since authors don't want to parse strings on their own to script transforms and an interface like that also avoids parsing on the browser and makes performance better!

If this is the goal, you could give CSSTransformList a constructor
that parses a transform string for you.  Then you can avoid the
getPropertyCSSValue() issues.

On Thu, Feb 16, 2012 at 2:07 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> Oh, then you should write more tests if you think getBoundingClientRect is implemented interoperable :) Our team is working on it right now, and it definitely isn't for some cases.

In Chrome 18 dev, getBoundingClientRect() passes all my 2D transform
tests, and all 3D transform tests except a few that involve display:
inline-block.  Gecko passes all of the 2D and 3D tests except for a
few rounding errors and a few that involve display: table.  I'm
curious to know what cases aren't interoperable -- I'd like to update
my tests.

> And stop with moving the web forward? I really don't understand you point. You don't want to improve existing interfaces or add new interfaces?

I do.  But only if a) their behavior is defined, to the point of all
features being testable; and b) multiple independent browsers
implement them or are interested in implementing them.  I don't think
we should put things in the spec if they're not fully defined, or if
only one browsers implements them and other browsers aren't interested
in implementing them.

Received on Thursday, 16 February 2012 20:39:00 UTC