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

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.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w