Remove animationShorthandForParsing

I'm guessing it differed from the main longhand order at some point,
but currently it's identical to the shorthand that's generated.

R=ericwilligers@chromium.org

Change-Id: I388d3dd4d51ba18948246cb07083e1f48926f0a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2253740Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#781793}

third_party/blink/renderer/build/scripts/core/css/templates/style_property_shorthand.h.tmpl

@@ -59,7 +59,6 @@ class StylePropertyShorthand {
 const StylePropertyShorthand& {{property.name.to_lower_camel_case()}}Shorthand();
 {% endfor %}
 
-const StylePropertyShorthand& animationShorthandForParsing();
 const StylePropertyShorthand& transitionShorthandForParsing();
 
 // Returns an empty list if the property is not a shorthand.

third_party/blink/renderer/core/css/properties/shorthands/shorthands_custom.cc

@@ -78,7 +78,7 @@ bool Animation::ParseShorthand(
     const CSSParserContext& context,
     const CSSParserLocalContext& local_context,
     HeapVector<CSSPropertyValue, 256>& properties) const {
-  const StylePropertyShorthand shorthand = animationShorthandForParsing();
+  const StylePropertyShorthand shorthand = animationShorthand();
   const unsigned longhand_count = shorthand.length();
 
   HeapVector<Member<CSSValueList>, css_parsing_utils::kMaxNumAnimationLonghands>

third_party/blink/renderer/core/css/style_property_shorthand_custom.cc

@@ -25,34 +25,10 @@
 
 namespace blink {
 
-const StylePropertyShorthand& animationShorthandForParsing() {
-  // When we parse the animation shorthand we need to look for animation-name
-  // last because otherwise it might match against the keywords for fill mode,
-  // timing functions and infinite iteration. This means that animation names
-  // that are the same as keywords (e.g. 'forwards') won't always match in the
-  // shorthand. In that case the authors should be using longhands (or
-  // reconsidering their approach). This is covered by the animations spec
-  // bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=14790
-  // And in the spec (editor's draft) at:
-  // https://drafts.csswg.org/css-animations/#animation-shorthand-property
-  static const CSSProperty* kAnimationPropertiesForParsing[] = {
-      &GetCSSPropertyAnimationDuration(),
-      &GetCSSPropertyAnimationTimingFunction(),
-      &GetCSSPropertyAnimationDelay(),
-      &GetCSSPropertyAnimationIterationCount(),
-      &GetCSSPropertyAnimationDirection(),
-      &GetCSSPropertyAnimationFillMode(),
-      &GetCSSPropertyAnimationPlayState(),
-      &GetCSSPropertyAnimationName()};
-  static constexpr StylePropertyShorthand
-      webkit_animation_longhands_for_parsing(
-          CSSPropertyID::kAnimation, kAnimationPropertiesForParsing,
-          base::size(kAnimationPropertiesForParsing));
-  return webkit_animation_longhands_for_parsing;
-}
-
-// Similar to animations, we have property after timing-function and delay after
-// duration
+// The transition-property longhand appears last during parsing to prevent it
+// from matching against transition-timing-function keywords. Ideally we would
+// change the spec to use this order, see:
+// https://github.com/w3c/csswg-drafts/issues/4223
 const StylePropertyShorthand& transitionShorthandForParsing() {
   static const CSSProperty* kTransitionProperties[] = {
       &GetCSSPropertyTransitionDuration(),