Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Thu, Mar 28, 2013 at 12:49 PM, Elliott Sprehn <esprehn@gmail.com> wrote:

> On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney <dominicc@chromium.org>wrote:
>
>> On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn <esprehn@gmail.com>wrote:
>>
> offsetParent is very useful to find your positioned parent, and you're
>>> crippling that feature and making authors use distributedParent +
>>> getComputedStyle() repeatedly which is considerably more expensive.
>>>
>>
>> What are those use cases, except finding the position of an element
>> relative to another element, which I think is not excessively complicated
>> by what I am proposing here?
>>
>
> Not complicated, just very expensive. getComputedStyle allocates a new
> object on every invocation and does string parsing. Unfortunately it seems
> jQuery already does this:
> https://github.com/jquery/jquery/blob/master/src/offset.js#L126
>

I read this last sentence as "The most popular JavaScript library doesn't
suffer from any problems with this proposal. This is unfortunate." I'm sure
you meant that it's unfortunate that we take the slow path, but as Boris
has already stated "Note that if you're using offsetWith/Height/Top/Left
you already lose, because they return integers." We tried to ignore this
problem for years. Unfortunately, he's right and using offset* will
eventually sneak up and cause seemingly inexplicable bugs. Also,
considering that jQuery is already doing this, it seems clear that this
isn't a performance bottleneck.

FWIW, I was going to make the same exact argument that this proposal was
going to break code for positioning elements relative to other elements,
which is something we do dynamically all the time in jQuery UI. But then I
looked at the code in jQuery core and asked Mike Sherov if he could provide
feedback. I think he never did because there just doesn't seem to be a good
response. Coincidentally, a few days later, Mike and I were reviewing some
completely unrelated code and spent at least half an hour trying to figure
out why some elements were being positioned 1px off from their expected
location and it came down to offset* being lossy.

Received on Thursday, 28 March 2013 17:26:56 UTC