Open Bug 726550 Opened 11 years ago Updated 8 months ago

Can't transition from text-shadow with a color to text-shadow without a color


(Core :: CSS Parsing and Computation, defect)





(Reporter: mardeg, Unassigned)


(Blocks 1 open bug, )


(Keywords: dev-doc-complete)


(1 file)

Attached file testcase #1
1. Hover pointer over text, watch text-shadow values transition for 2 seconds
2. Unhover pointer within the next 2 seconds, watch text-shadow smoothly transition back
3. Hover point over text again, this time wait 4 seconds until text-shadow animation begins
4. Unhover pointer, text-shadow SNAPS back without a transition

CSS properties other than text-shadow seem able to transition smoothly back from whatever the values are during animation, so too should text-shadow.
OS: Windows XP → All
Hardware: x86 → All
The issue is that the page is trying to transition between values like "-0.1em 0.1em 0.2em" and values like "black 0 0.05em 0.1em".  Note that one lists the color and one does not.

The shadow transitioning code has this to say:

  if (color1.GetUnit() != color2.GetUnit() ||
      inset1.GetUnit() != inset2.GetUnit()) {
    // We don't know how to animate between color and no-color, or
    // between inset and not-inset.
    return false;

Simply listing a color on the animation makes it work fine.

Not sure whether there's a sane way to do the transition here, given that the computed value is still missing the color...
Ever confirmed: true
Summary: CSS transition of text-shadow not smooth from CSS animation → Can't transition from text-shadow with a color to text-shadow without a color
IE10 Developer Preview and Chrome 18 dev get this right.  (I couldn't get Opera to transition text-shadow at all.)  It should be the same case as transitioning to/from currentColor, right?  test_shadow_transition() in test_transitions_per_property.html tests for Gecko's current (probably incorrect) behavior.  This

  is(cs.getPropertyValue(prop), defaultColor + "2px 2px 2px" + spreadStr,
     "shadow-valued property " + prop + ": non-interpolable cases");

should probably be changed to todo_is.
Although when I say Chrome 18 dev gets this right, that's with the caveat that it treats text-shadow color as transparent when it's not specified.  IE does get it entirely right AFAICT.
This behavior isn't the same as currentColor because it inherits differently.
See Also: → 1286151
See Also: 1286151
Now the spec describes about currentColor clearly.

 If the color of the shadow is not specified, it defaults to currentColor,
Marking as part of documentation plan for intentional stylo differences
Keywords: dev-doc-needed
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.