Re: [css3-transforms] Extending CSSOM interface

On Thursday 2012-02-16 16:05 -0800, Dirk Schulze wrote:
> Hi Aryeh,
> 
> Even if CSSOM is in development, there is a W3C recommendation that specifies getPropertyCSSValue():
> 
> http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration
> 
> Like you said, browsers don't need to pass the test. But tests can use the already specified behavior of getPropertyCSSValue(). Therefore the argument that it is not possible to access CSS objects (and their interfaces) and write tests is not valid.
> 
> This can be used for instance for CSSPrimitiveValue: http://www.w3.org/TR/DOM-Level-2-Style/css#CSS-CSSPrimitiveValue
> 
> Even if future versions of CSSOM or CSSOM Value might replaced getPropertyCSSValue() and CSSValue or modify it, it does't affect the current specification process for CSS Transform.

There should be an open issue on removing this material from the
transforms spec.  Either that, or it's possible (since I have a
vague memory of a discussion) that we already resolved to remove
this material from the spec.  We shouldn't be specifying anything
new that depends on the CSSValue interface.

-David

> On Feb 16, 2012, at 2:37 PM, Dirk Schulze wrote:
> 
> > Hi Aryeh,
> > 
> > On Feb 16, 2012, at 12:38 PM, Aryeh Gregor wrote:
> > 
> >> 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():
> > I said that Gecko has a way to access CSSOM and get objects. I did not said, that gecko implemented the CSS Transform interfaces, because it doesn't yet.
> > 
> >> 
> >> 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.
> > Oh, it would be a big surprise for me to see [object WebKitCSSTransformValue] on other engines.
> > 
> >> 
> >> 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.)
> > Dropping CSSTransformValue and CSSMatrix? Or just the first one?
> > 
> >> 
> >>> 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.
> > That is a good point. Actually you just test parts without getPropertyCSSValue() javascript:alert(window.WebKitCSSTransformValue.CSS_MATRIX) works. It doesn't mean that we can't write test based on the current status of getPropertyCSSValue(). Like Glenn wrote, it is open if it will be in the CSSOM spec or in a future CSSOM Values spec.
> > 
> >> 
> >>> 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.
> > But if you just add a parser, you still can't order the list to your needs, or do I misunderstand you? Everytime you pass a string, the current items of the list would get replaced. I have nothing agains a constructor, I just say that it is not enough.
> > 
> >> 
> >> 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.
> > Sure, just add SVG elements (root SVGElements, inner SVGelements, ...) into your test, than you don't even need transform to get strange results across platforms. But if you add CSS Transforms to SVGElements (say <rect>), you will see that the results on the screen don't match the results of CSSRect.
> > 
> >> 
> >>> 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.
> > Sounds reasonable.
> > 
> > -Dirk
> > 
> > 
> 
> 

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Friday, 17 February 2012 00:28:19 UTC