W3C home > Mailing lists > Public > www-style@w3.org > August 2013

Re: [css-om] CSSStyleDeclaration.parentElement

From: Mike Sherov <mike.sherov@gmail.com>
Date: Sat, 24 Aug 2013 17:40:09 -0400
Message-ID: <3202072503730133139@unknownmsgid>
To: Rik Cabanier <cabanier@gmail.com>
Cc: François REMY <francois.remy.dev@outlook.com>, Sylvain Galineau <galineau@adobe.com>, Simon Pieters <simonp@opera.com>, www-style list <www-style@w3.org>
Mike Sherov
Chief Technologist
SNAP Interactive, Inc. | Ticker: STVI
http://snap-interactive.com | http://ayi.com

On Aug 24, 2013, at 4:45 PM, Rik Cabanier <cabanier@gmail.com> wrote:

Did you file bugs on this?
It seems like an easy fix to implement.

TBH, it didn't seem like a bug (rather an enhancement) given the assumption
that its a live object and that browsers implement caching on their own.

I'm fairly sure there's already an effort in Blink to fix this, but I'll
double check to make sure.

Anyway, even if this wasn't fixed, using this as a use-case for
parentElement seems less convincing then the polyfill use case.

On Sat, Aug 24, 2013 at 1:41 PM, Mike Sherov <mike.sherov@gmail.com> wrote:

> Mike Sherov
> Chief Technologist
> SNAP Interactive, Inc. | Ticker: STVI
> http://snap-interactive.com | http://ayi.com
> On Aug 24, 2013, at 4:34 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> Do you have examples where authors are doing this caching to work around
> performance problems?
> Yes. I specifically wrote code into jQuery that caches the results of gCS
> for use in tight loops. It only sped up perf in a few browsers, which means
> that several browsers do this already.
> 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 21:40:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:31 UTC