Do you have examples where authors are doing this caching to work around
performance problems?
If so, it seems that this should be fixed in the browsers themselves (ie by
caching the last result of getComputedStyle). No need to invent a new API
surface.
On Sat, Aug 24, 2013 at 12:55 PM, Francois REMY <
francois.remy.dev@outlook.com> wrote:
> > Nonetheless, if this is really the best use
> > I can make of my time, I'll try to find other
> > use cases during the weekend, we'll see
> > what comes out of it.
>
> Saturday's morning idea:
>
> - since getComputedStyle return a new object every time, you do not want to
> call this function multiple times.
> - as a result, your code contains functions where you can give a reference
> to the computed style of an element in addition to the element itself (ie:
> cache parameters)
> - let's figure out that you made a mistake somewhere in your code and gave
> a
> reference to the wrong style object, how do you find this out?
>
> If you've parentElement you can do sanity checks at the beginning of your
> function:
>
> if(elementStyle.parentElement != element) {
> if("debug" in window) debugger;
> elementStyle = getComputedStyle(element);
> }
>
> The only option now would be to call getComputedStyle again and comparing
> all properties in the hope you find a difference. This is so slow you
> couldn't even keep that sanity check in production. Since you're calling
> getComputedStyle anyway, it cancels the effect of the cache.
>
>
Received on Saturday, 24 August 2013 20:33:35 UTC