Re: Where is the css value 'auto' rationalized to an actual value?

"L. David Baron" <[email protected]> Tue, 6 Dec 2016 19:37:25 -1000
Newsgroups	gmane.comp.mozilla.devel.layout
Message-ID	<[email protected]>
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)

_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
signature.asc (application/pgp-signature, 801 B)