716282 - CSSStyleDeclaration / Value parts of MozAnimation prop automatically reordered with false positions

Status: RESOLVED INVALID

(Core :: DOM: CSS Object Model, defect)

Description

[petabyte]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20100101 Firefox/9.0
Build ID: 20111216140209

Steps to reproduce:

I set MozAnimation to a valid (according to https://developer.mozilla.org/en/CSS/animation) value. 

Example: (whereas q-kfani-8 exists and is a valid @-moz-keyframes rule)
===

myElem.style.MozAnimation = "q-kfani-8 1000ms ease 700ms infinite alternate";




Actual results:

When I retrieve it afterwards the parts are automatically reordered -- but with false positions. Thus, the value of MozAnimation is useless for further processings. Yes, using the values of the sub properties, the shorthand notation property represents, would work around this problem, but it's more cumbersome (from a user's/webdeveloper's pov) and still a wrong behaviour.  



Expected results:

The value parts should stick to the order I've given to them (as long as it is the right one).

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This is normal for serialization of shorthands; implementations serialize them in a certain order, and do not store the order specified.

(Or are you saying that the order we serialize the declaration in is somehow incorrect, i.e., is a style that produces different results?  If so, could you attach a testcase?)

Comment 2

[petabyte]

Hi David, 

With 'serialize' you mean taking the string with the shorthand notated value and parsing/interpreting it, no? If so: it is serialized correctly. But after it was serialized, the original shorthand string gets intermixed. 

You say this is a normal behaviour ... okay ... is there a reason for this? And do you think that this behaviour will be "fixed" anytime?

Peter

Comment 3

[Boris Zbarsky [:bzbarsky]]

> With 'serialize' you mean taking the string with the shorthand notated value and
> parsing/interpreting it, no?

No, the other direction: taking an internal data structure that represents the animation styles and creating a string from it.

> is there a reason for this?

Yes.  The original string is not stored; what's stored are the values of the individual properties.  Note that in anything but the most trivial cases there isn't even a concept of "order" here, because the shorthand could be set several times, and the longhands can be set several times too, and then the result needs to be represented as a single shorthand string.

Note that the CSSOM spec is likely to define this behavior explicitly.  I doubt it'll be "fixed" anytime.

Again, why is this being a problem

Comment 4

[petabyte]

I guess that I got you wrong, sorry ... the order you serialize the declarations in is wrong. When I set MozAnimation to a valid shorthand notated value (as spec'd in latest CSS3 Animation working draft), the included "parts"/subproperty values are parsed and applied correctly, but the actual value that is generated (by serializing the subproperties I guess) for MozAnimation is wrong.

I attached a test case that demonstrates what I mean. It also works in WebKit where this is implemented correctly.

Test case is also available at http://pastebin.mozilla.org/1444827

Comment 5

[petabyte]

Attachment: Demonstrates the wrong behaviour

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could you describe what results you expect and what you get instead?  (In other words, describe the bug without using the word "wrong" or similar words, since those words only tell us that what you saw is different from what you expected without saying how.)

Comment 7

[petabyte]

When I set the MozAnimation property to a valid shorthand value (according to CSS3 Animation spec and the respective MDN page; schema: "<ani-name>, <ani-duration>, <ani-timing-function>, <ani-delay>, <ani-iteration-count>, <ani-direction>"), I expect it to keep exactly that value with all sub property values in exactly the same order. So when I'll retrieve it afterwards, I'd have the same shorthand value I've set it to.

Instead what I get is a shorthand value with the sub property parts being reordered onto positions that conform no longer to those defined in the spec. Due to this, the shorthand value isn't valid anymore and can't be reused (e.g. for the MozAnimation property of other elements).


What I assign to a MozAnimation property:
===
"<ani-name>, <ani-duration>, <ani-timing-function>, <ani-delay>, <ani-iteration-count>, <ani-direction>"

What I get when retrieving exactly the same MozAnimation property afterwards:
===
"<ani-duration>, <ani-timing-function>, <ani-delay>, <ani-direction>, <ani-fill-mode>, <ani-iteration-count>, <ani-name>"

Note the order of sub properties and that MozAnimationFillMode is now included in shorthand value (not part of CSS3 Animations spec and not mentioned on https://developer.mozilla.org/en/CSS/animation)

Comment 8

[petabyte]

P.s.: In WebKit this works as expected.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is your expectation that the order returned is the order you specified originally, or is your expectation that the order returned is the fixed order given in the spec whether or not that was the order you assigned?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

And in what way is the value returned not valid?  The spec allows the values in any order.  (And the fact that it does allow the values in any order imposes a bunch of contraints on the serialization, since all valid values for animation-fill-mode, animation-play-state, and animation-direction and some of the values for animation-iteration-count and animation-timing-function are *also* valid values for animation-name, which means animation-name must be serialized after the others mentioned if a fixed order is used.   Likewise animation-delay and animation-duration take the same value syntax, and duration takes the first time value.)

Comment 11

[petabyte]

My expected return order:
===
I expect the order returned to be the fixed one given in the spec. Ideally the one I assign is the "valid" one (according to spec) -- otherwise it'll be discarded, of course.

>>> ... The spec allows the values in any order. ...

Could you link to that section please? I've consulted the current working draft, the editor's draft and the according MDN page ... all of them dictate the same order and only mention six subproperties as allowed in shorthand syntax.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

http://dev.w3.org/csswg/css3-animations/#the-animation-shorthand-property- says:

Value: [<animation-name> || <animation-duration> || <animation-timing-function> || <animation-delay> || <animation-iteration-count> || <animation-direction> || <animation-fill-mode>] [, [<animation-name> || <animation-duration> || <animation-timing-function> || <animation-delay> || <animation-iteration-count> || <animation-direction> || <animation-fill-mode>] ]* 

http://www.w3.org/TR/CSS21/about.html#value-defs says:

A double bar (||) separates two or more options: one or more of them must occur, in any order.

Comment 13

[petabyte]

Okay, sorry for filing an invalid bug. But it makes no sense to me ... the positions have implied semantics (as written in one of your previous answers). So why does the spec allow an arbitrary order?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm really not sure -- the spec isn't particularly well-written.  I'd like to spend some time improving it, but I haven't had much time to do that yet.