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).
Summary: CSSStyleDeclaration / Value parts of MozAnimation shorthand prop get automatically reordered but with false positions → CSSStyleDeclaration / Value parts of MozAnimation prop automatically reordered with false positions
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?)
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
> 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
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
Attachment #587671 - Attachment mime type: text/plain → text/html; charset=utf-8
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.)
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)
P.s.: In WebKit this works as expected.
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?
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.)
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
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?
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.
You need to log in before you can comment on or make changes to this bug.