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

On Dec 31, 2013, at 1:39 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> 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.

I fully agree with all comments.

Greetings,
Dirk

>  
> 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

Received on Tuesday, 31 December 2013 10:49:42 UTC