On 3/28/13 12:55 PM, Elliott Sprehn wrote:
and isPositioned is a bitfield check
That happens to be a WebKit-specific claim, as far as I can tell.
> parse the property name
As is this.
But yes, the general claim that the JS APIs for doing this right now are
full of performance fail stands.
On 3/28/13 12:49 PM, Elliott Sprehn wrote:
var rect = node.offsetParent.getBoundingClientRect();
node.style.top = computePosition(rect);
node.style.left = computePosition(rect);
Nothing guarantees the result of this to be sane today, unless you have
extra information about the precise styles o
On Thu, Mar 28, 2013 at 12:49 PM, Elliott Sprehn wrote:
> On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney wrote:
>
>> On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn wrote:
>>
> offsetParent is very useful to find your positioned parent, and you're
>>> crippling that feature and making authors us
On Wed, Mar 27, 2013 at 2:02 PM, Boris Zbarsky wrote:
> Scott Miles wrote:
>
> > This is a thorny problem, but my initial reaction is that you
> > threaded the needle appropriately. I don't see how we avoid some
> > lossiness in this situation.
>
> Note that if you're using offsetWith/Height/Top/
On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney wrote:
> On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn wrote:
>
>>
>> On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney wrote:
>>
>>> ...
>>>
>>> I think the offset{Parent, Top, Left} properties should be adjusted.
>>> This means that in the above e
On 3/27/13 2:02 PM, Boris Zbarsky wrote:
Note that if you're using offsetWith/Height/Top/Bottom you already lose,
s/Bottom/Left/, of course.
-Boris
Scott Miles wrote:
> This is a thorny problem, but my initial reaction is that you
> threaded the needle appropriately. I don't see how we avoid some
> lossiness in this situation.
Note that if you're using offsetWith/Height/Top/Bottom you already lose,
because they return integers.
I think w
On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn wrote:
>
> On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney wrote:
>
>> ...
>>
>> I think the offset{Parent, Top, Left} properties should be adjusted. This
>> means that in the above example, b.offsetParent would be and
>> b.offsetLeft would be sile
On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney wrote:
> ...
>
> I think the offset{Parent, Top, Left} properties should be adjusted. This
> means that in the above example, b.offsetParent would be and
> b.offsetLeft would be silently adjusted to accumulate an offset of 10px
> from c. I think thi
Sorry for the late response, this is one of those bad cases where agreement
was expressed as silence.
This is a thorny problem, but my initial reaction is that you threaded the
needle appropriately. I don't see how we avoid some lossiness in this
situation.
Scott
On Mon, Mar 18, 2013 at 1:48 AM
Summary: I think the Shadow DOM spec should specify how offset* properties
are handled around shadows. Further, I think "traversable" and
"non-traversable" shadows should be handled uniformly. The offsetParent
property should return the first offsetParent at the same level of shadow
as the receiver
11 matches
Mail list logo
