Support unknown property strings in transition-property

Support unknown property strings in transition-property

The spec mandates that transition-property (and thus the transition
shorthand) are able to support arbitrary unknown properties, for
backwards and forwards compatibility. This patch adds support for such
unknown properties.

Note that this makes the shorthand strings like "ease" or "ease ease-in"
ambiguous. In this patch we take the first case to refer to a timing
function, and in the second case the first token as a timing function
and the second token as the property name.

This change progresses the w3c transitions test transition-property-002,
although the first two cases of the test are incorrect.

BUG=304020, 375098
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=176489

[Timothy Loh, 2014-05-27 05:44:52]

The css-transitions spec isn't clear on what to do for cases like "transition:
ease linear". I don't think we should put much effort into getting these cases
working nicely since these shouldn't occur in practice (I'm ok with leaving this
as described below and in the patch notes).

This handles some silly edge cases somewhat badly at the moment (afaict firefox
has the same handling). In particular:
- "transition: ease steps(2, start)" fails to parse
- "transition: ease 1s linear 2s" gets serialized in getComputedStyle as "linear
1s ease 2s"

Note that without the transitionShorthandForParsing cases I've added we'd parse
"transition: ease" as a property and "transition: ease width" wouldn't parse at
all, while the transition-001[1] test suggests these should register the "ease"
in both cases as a timing function.

Tab - It probably makes sense for completeness to explain how to handle e.g.
"ease linear" in the css-transitions spec. Maybe we could take the option of
disallowing valid timing functions in <single-transition-property>, since this
is probably the simplest option implementation-wise and avoids all the edge
cases described here?

[1]
test.csswg.org/suites/css-transitions-1_dev/nightly-unstable/html/transition-001.htm

[Tab Atkins, 2014-05-27 21:15:30]

On 2014/05/27 05:44:52, Timothy Loh wrote:
> The css-transitions spec isn't clear on what to do for cases like "transition:
> ease linear". I don't think we should put much effort into getting these cases
> working nicely since these shouldn't occur in practice (I'm ok with leaving
this
> as described below and in the patch notes).
> 
> This handles some silly edge cases somewhat badly at the moment (afaict
firefox
> has the same handling). In particular:
> - "transition: ease steps(2, start)" fails to parse
> - "transition: ease 1s linear 2s" gets serialized in getComputedStyle as
"linear
> 1s ease 2s"
> 
> Note that without the transitionShorthandForParsing cases I've added we'd
parse
> "transition: ease" as a property and "transition: ease width" wouldn't parse
at
> all, while the transition-001[1] test suggests these should register the
"ease"
> in both cases as a timing function.
> 
> Tab - It probably makes sense for completeness to explain how to handle e.g.
> "ease linear" in the css-transitions spec. Maybe we could take the option of
> disallowing valid timing functions in <single-transition-property>, since this
> is probably the simplest option implementation-wise and avoids all the edge
> cases described here?

The CSSWG just discussed this at the recent F2F, and we settled on some simple
rules for how to disambiguate a <custom-ident> that can't be positionally
disambiguated.

Basically, greedily assign values to properties that they might belong to,
treating the <custom-ident> properties as low-priority.  So a <custom-ident>
prop doesn't get a value assigned unless it's a keyword that would be invalid in
any other property, or is a keyword for a property that has already been
assigned earlier in the property value.

In particulary, this means that "ease linear" gets parsed into a timing-function
of "ease" and a name of "linear".  It also means that we should always serialize
the name last, preferably while also serializing the entire rest of the property
for future-friendliness.

There's an open question on how to treat things when the second value isn't an
ident, like in "ease steps(2)".  Following the above rule would make it
syntactically invalid (after timing-function gets set to "ease", there's nothing
that can absorb the "steps(2)").  However, allowing timing-function to switch to
the "steps(2)" gives us behavior similar to the list-style shorthand, where you
can't tell whether a "none" should be assigned to list-style-type or
list-style-image until you parse the rest of the property.  The CSSWG expressed
reluctance to spread this kind of behavior further.  I've started a thread on
www-style to resolve this question.

[dstockwell, 2014-05-29 22:00:59]

lgtm

https://codereview.chromium.org/298043007/diff/1/LayoutTests/transitions/tran...
File LayoutTests/transitions/transitions-parsing-expected.txt (right):

https://codereview.chromium.org/298043007/diff/1/LayoutTests/transitions/tran...
LayoutTests/transitions/transitions-parsing-expected.txt:467: FAIL
style.transitionProperty should be all. Was initial.
is there a bug for this?

[Timothy Loh, 2014-06-19 03:21:05]

The CQ bit was checked by timloh@chromium.org

[Timothy Loh, 2014-06-19 03:21:09]

https://codereview.chromium.org/298043007/diff/1/LayoutTests/transitions/tran...
File LayoutTests/transitions/transitions-parsing-expected.txt (right):

https://codereview.chromium.org/298043007/diff/1/LayoutTests/transitions/tran...
LayoutTests/transitions/transitions-parsing-expected.txt:467: FAIL
style.transitionProperty should be all. Was initial.
On 2014/05/29 22:01:00, dstockwell wrote:
> is there a bug for this?

Made a bug: crbug.com/386459

[commit-bot: I haz the power, 2014-06-19 03:22:04]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/timloh@chromium.org/298043007/20001

[commit-bot: I haz the power, 2014-06-19 05:08:53]

Change committed as 176489