On Tuesday 2016-12-06 21:00 -0800, [email protected] wrote: > Goal: > I'm looking into a future proposal that I made regarding animating to > height/width auto (and in general to and from auto). The GitHub request can > be found here: > https://github.com/w3c/csswg-drafts/issues/626#issuecomment-265073790
So, as I said in that issue, I think the right approach here is to add support for 'auto' to calc(). This is a large project (see below). > Right now I'm focusing mainly on animation as that is what the request > entails. It can further be extended so that auto gets calculated to any unit > type value but that's out of the scope of my exploration. > > Current understanding: > 1. StyleAnimationValue::Compute* are all the methods that pertain to > animation of specific styles. These are calculated on load. > 2. In these methods it's easy to find eUnit_Auto which currently is set to > return false (meaning no computation occurred). > > What I can't seem to find is: > 1. Where the actual computation for auto actually occurs to be able to > provide the beginning and end coords the animation should take. So the actual computation for auto occurs throughout the layout code. For example, when nsStylePosition::mWidth has eStyleUnit_Auto (which represents the computed value in CSS), there's all sorts of layout code scattered through various frame classes that acts based upon that. (For example, in ReflowInput, nsBlockFrame, nsTableFrame, nsGfxTextControlFrame, etc.) Implementing calc() that handles 'auto' would require teaching *all* of these frame classes to support calc()s that contain 'auto' values. I don't think trying to teach the animation code to use a particular beginning and end coordinate value for 'auto' is the right approach. It has a number of problems: 1. it doesn't handle cases wher the value that 'auto' represents dynamically changes during the automation (or, if it does, it's even more inefficient (see (2)) 2. it requires performing layout to determine what such an 'auto' value represents. This is inefficient. 3. Requiring doing a separate layout to determine what an 'auto' value represents is unclear about what should happen if there's more than one such value. How would they interact? I think it is both more efficient and matches expected behavior better if such animations are implemented in terms of calc() supporting 'auto'. However, as I said, it is a lot of work to do that. > 2. Where the interpolation for each frame between the specified keyframes is > computed This is in StyleAnimationValue::AddWeighted, but that's only relevant to the small patch to animations that would need to be written at the end of a large project. -David -- 𝄞 L. David Baron http://dbaron.org/ 𝄂 𝄢 Mozilla https://www.mozilla.org/ 𝄂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
signature.asc
Description: PGP signature
_______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
