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

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. Logically, it can be interpreted as everything including the behavior of WebKit and Blink. The text should be much more explicit and include a normative description of bounding border box… including the behavior on fragmentation.

> 
> 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).
* Authors could want to have a DOMRect for each fragment of a block.

The former could easily be determined by the latter possibility and provides more information. We know that fragmentation happens before positioning and transforming while getClientRects() already includes these information. Therefore, fragmentation must be included in getClientRects() one way or the other.

However, I agree that the returned DOMRect of WebKit and Blink might not be in the interest of web authors.

The point is just that the current specs (CSSOM View and CSS Fragmentation) do not define how fragmentation influences getClientRect().

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  

[1] g/csswg/cssom-view/#dom-element-getclientrects (step 3)

Received on Monday, 30 December 2013 20:26:04 UTC