- From: Alan Stearns <stearns@adobe.com>
- Date: Wed, 27 Nov 2013 10:47:06 -0800
- To: "www-style@w3.org list" <www-style@w3.org>
Hey all, I brought up the issue of animating <position> last week, and Tab noted that background-position is defined incorrectly [1]. Testing interop shows differences in how background-position animates as well [2, point 2]. The problem is that by default, transitions occur over computed values. The computed value for background-position include keywords, and there is no interpolation between keywords defined. This could be fixed by defining the computed value of background-position to be a list, with each item in the list containing two values of length, percentage or calc). This appears to be what Gecko does. But I’m not sure it’s useful to have a value of ‘right 10px’ be converted to ‘calc(100% - 10px)’ in the computed value. And Fantasai raised the concern of future extensions to <position> that might not be reducible to calc() expressions. If we should leave the computed value definition as it is, then we’ll need to specify some keyword interpolation. An interim fix would add a definition that allows interpolation between identical keywords - so that ‘left top 50px’ could interpolate with ‘left top 100px’. This is what browsers appear to interopably implement. This would not define animating from ‘left top 50px’ to ‘right top 100px’ - which is something Blink does not do currently, but Gecko and IE11 appear to handle. A full fix would define current <position> keyword interpolation for all combinations. Thanks, Alan [1] http://lists.w3.org/Archives/Public/www-style/2013Nov/0391.html [2] http://lists.w3.org/Archives/Public/www-style/2013Nov/0376.html
Received on Wednesday, 27 November 2013 18:47:55 UTC