Open Bug 1273569 Opened 8 years ago Updated 1 year ago
Behavior of background-clip:text while child text object is animating
Follow up of Bug 1273068. Let said we have a division with background-clip:text. There is a <p> in in this division, and we animate this <p> at a specific moment, such as mouse hover. After animation start, that text object move from A to B, what is the correct behavior of text shape on the background at this moment? 1. no shape for that text object exist on the background This is current behavior. 2. text shape on the background follow the animated text object Very difficult I would said. We need to repaint background in each frame, while text object itself uses OMTA. 3. Display text shape on the original place before animation kick off.  https://bug1273068.bmoattachments.org/attachment.cgi?id=8752835
Hi Mike, may I have your opinion here?
Huh, we seem to split the behavior between Chrome and Safari looking at the test case from https://bug1273068.bmoattachments.org/attachment.cgi?id=8752835. I think in a perfect world we would want the text shape to follow the animated text object. But, given that our primary motivation for supporting this property (in its prefixed form, anyways) is web compat, and Chrome and Safari don't do it, I think we punt on that. Looking at #1 (Safari's behavior) and #3 (Chrome's behavior), I think #1 feels less broken to me. You can actually get #1 behavior in Chrome by doing text selection, which makes me think their behavior is unintended. I filed https://github.com/whatwg/compat/issues/55 so we can spec what we go with here. I suppose we could say something like "user agents may choose to ignore clipping (masking?) background text while text is being animated". That would leave wiggle room for implementations to animate the bg text if they wanted.
Actually... looking at transformed text, it seems the clipped bg isn't shown at all in Chrome or Safari (but it is in Nightly).
fantasai, any thoughts (as one of the editors of background and borders)?
I agree with the logic in comment 2: we're only adding this for Web Compat -- the actual feature will be handled using the stroke/fill properties we're going to borrow from SVG. (Rough sketch of the idea is currently in https://drafts.csswg.org/css-text-decor-4/ and will move to a new Paint module in the FXTF.) So as the spec editor, I'd say, do the minimum amount of work necessary for Web compat, then tell us what that is so we spec it. :)
As a developer, I support comment 2, the effect of this animation is so wonderful. At the same time also hope that as soon as standardized.
You need to log in before you can comment on or make changes to this bug.