As you can see in the testcase, there is no smooth transition because the transition shorthand does not seem to override the first transition-property, even though it should, and it does in every other engine and older versions of WebKit. Chrome 19 and Safari 6.0 do not have this issue. It can be reproduced in Chrome > 19 and WebKit nightlies. I can also reproduce it in my Safari 6.0, but not BrowserStack’s Safari 6.0, so I'm not sure whether it occurs there. Steps to reproduce: - Go to testcase - Hover over the gold paragraph - Observe how there is no smooth transition Things that fix the issue: - Explicitly adding the transition-property value in the shorthand. i.e. converting transition: 2s; to transition: 2s all; or transition 2s background; - Merging the two rules Things that don't fix the issue: - Increasing the specificity of the second rule - Adding a separate transition-property declaration in the second rule WITHOUT removing the first one Other observations: - Other transition-* properties like transition-duration or transition-delay don't seem to exhibit this issue.
That does seem like a bug.
Interesting. In debug, we hit: ASSERTION FAILED: prop >= firstCSSProperty && prop < (firstCSSProperty + numCSSProperties)
When parsing the shorthand, CSSParser::parseTransitionShorthand() fills in unsupplied values with the "initial" value: // Fill in any remaining properties with the initial value. for (i = 0; i < numProperties; ++i) { if (!parsedProperty[i]) addAnimationValue(values[i], cssValuePool().createImplicitInitialValue()); } and later on we take this to imply that we should use Animation::initialAnimationProperty() which is CSSPropertyInvalid. Maybe that should be All?
Regressed with http://trac.webkit.org/changeset/113225 when Alexis changed initialAnimationProperty() to return CSSPropertyInvalid rather than cAnimateAll. Also, the use of CSSPropertyID in platform/animation code is a layering violation.
Possibly seeing this (the assertion at least) on http://davidcelis.com/blog/2012/09/06/stop-validating-email-addresses-with-regex/?utm_source=rubyweekly&utm_medium=email
Created attachment 164228 [details] Patch
<rdar://problem/12302561>
http://trac.webkit.org/changeset/128656
Build fix in http://trac.webkit.org/changeset/128660