- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Apr 2019 15:13:46 +0000
- To: public-css-archive@w3.org
> I think it makes more sense as part of filter (@Martin-Pitt ) That's very similar to the proposal from w3c/fxtf-drafts#50. I definitely still support having the ability to specify more complex blurs in the filter property. But what is distinct about @argyleink's proposal here is that the blur would be calculated automatically based on the device's frame rate and the actual differences from one frame to the next. The author wouldn't need to figure out how to animate the amount of blur and its direction to match up with the speed of the motion. That kind of automatic calculation doesn't really make sense in `filter`. All the other filter functions (even SVG filters) are simple pixel manipulations that can just as easily be applied to a static image representing the flattened rendering of the current element. > I'm a bit wary of global 'motion-rendering' thing. I agree with Adam, that we should probably not think of this as a "global" setting, but as an effect targeted to a specific element that represents a moving layer. In other words, the property wouldn't inherit, and it would only have an effect if the same element is moving around. …which basically answers one of my own questions: this should be solely about transform-like properties (aka, transform, the individual transform properties, SVG viewBox, and the motion path properties) and not about properties that change the paint rendering of the layer. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3837#issuecomment-484926712 using your GitHub account
Received on Friday, 19 April 2019 15:13:48 UTC