Quantcast

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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

rickyp
Hi Everyone,

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

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.
2. Where the interpolation for each frame between the specified keyframes is computed

Next steps once answered:
Wherever that interpolation is occurring, it should be as simple as calculating the before and after and applying the same interpolation as we already are for any other eUnit type.

If anything in here sounds incorrect please feel free to correct me as I would be greatly appreciated!
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

L. David Baron
On Tuesday 2016-12-06 21:00 -0800, [hidden email] 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

rickyp
In reply to this post by rickyp
When you say have calc support auto do you mean in a similar way as calc supports percent? If so that should give me a pretty good basis of searching for _Percent in the code base and implementing auto in all those locations, correct?
_______________________________________________
dev-tech-layout mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

L. David Baron
On Tuesday 2016-12-06 22:34 -0800, [hidden email] wrote:
> When you say have calc support auto do you mean in a similar way as calc supports percent?

Yes.

> If so that should give me a pretty good basis of searching for _Percent in the code base and implementing auto in all those locations, correct?

To some degree, except 'auto' is preserved further through the
process than percent is, so you'd need to trace further than where
percent is resolved.

-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
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-layout

signature.asc (817 bytes) Download Attachment
Loading...