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

On Tue, Dec 31, 2013 at 9:25 AM, Dirk Schulze <dschulze@adobe.com> wrote:

> On Dec 30, 2013, at 8:21 PM, 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.
>
> CSSOM View says: “Return a DOMRectList object containing a list of DOMRect
> objects in content order describing the bounding border boxes”[1]
>
> This actually doesn’t say much. It says you should have a list of bounding
> border boxes. It does not say that an element can consist of more than one
> fragment. It does not say that the bounding border box is the containing
> rectangle of all fragments of a block. In fact, it does not even say what a
> bounding border box is or even reference a spec text that explains it.


OK, I think one source of confusion is the word "bounding", which simply
shouldn't be there.

Another source of confusion is that the CSS3 Fragmentation spec does not
explicitly say that each fragment is (or has) a border-box. It talks about
a single box being broken into multiple fragments (which doesn't make much
sense to me since such a "box" is no longer rectangular.) On the other
hand, it references CSS 2.1 for fragmentation of inline elements, which
talks about inline boxes being split into multiple boxes. We need to clear
up this confusion in the fragments spec; I'll start another thread for that.

Anyway I guess it would be clearer for getClientRects to explicitly say
that it returns one rectangle for each fragment associated with the
element. That was certainly always the intent, and is what browsers have
already implemented for inline elements.

> 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.
>
> I do neither agree nor disagree with this comment. There may be different
> ways to think about it.
> * Authors could want to have one containing rect of all fragments of a
> block (as IE and FF do).
>

That's not what IE and FF do for getClientRects. This is what
getBoundingClientRect is for.,


> * Authors could want to have a DOMRect for each fragment of a block.
>

This is what getClientRects is for.

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