Re: [cssom-view][css-break] getBoundingClientRect and getClientRects on fragmentation

On Mon, Dec 30, 2013 at 11:21 AM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> On Tue, Dec 31, 2013 at 5:37 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> In general it seems save to assume that Internet Explorer and Firefox
>> create a containing rect of all fragments on the screen.
>> Safari and Chrome return a dimension as if the element was not fragmented.
>>
>> I couldn’t find a hint in CSS Fragmentation or CSSOM View if the bounding
>> client rect should be the result after the fragmentation and getting the
>> smallest rect where all fragments fit into. Or, if the rect should be the
>> value before fragmentation happens.
>
>
> I don't think you can read CSSOM-View in a way that allows the Webkit/Blink
> behavior. Fragmentation determines how an element is split into boxes and
> where those boxes are placed. getClientRects then computes a rectangle for
> each box, and getBoundingClientRect is explicitly defined to union together
> those rectangles. Nothing says getClientRects can return results from
> "before fragmentation happens" instead of the actual box geometry.
>
> I also think that Webkit/Blink's behavior is not useful to authors, and it
> doesn't make sense for getClientRects to return separate rects for boxes
> split in the inline direction but combine them when split in the block
> direction. That is purely an artifact of the way multicol is implemented in
> Webkit/Blink.

Agreed.  I can see a use-case for "give me numbers in 'internal
coordinates' for a given element", which ignores fragmentation - this
can be useful when setting up sizes or positions relative to a given
element.  But that's not what the functions in question do, and so
they can only reasonable be read as working after fragmentation.

~TJ

Received on Friday, 3 January 2014 21:49:01 UTC