- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 09 Dec 2015 18:52:03 +0100
- To: robert@ocallahan.org, "Dirk Schulze" <dschulze@adobe.com>, fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style list" <www-style@w3.org>
On Fri, 04 Dec 2015 02:10:15 +0100, fantasai <fantasai.lists@inkedblade.net> wrote: > On 12/30/2013 07:39 PM, Robert O'Callahan wrote: >> >> >> 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. > > I've updated the definition for "fragment" to say: > # Each fragment has its own share of the box’s border, > # padding, and margin, and therefore has its own > # padding area, border area, and margin area. > # (See box-decoration-break, which controls how these > # are affected by fragmentation.) > http://drafts.csswg.org/css-break/#box-fragment > > Let me know if this is clear enough, or if you have further > suggestions for improvement. > >> 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'll need zcorpan to make these edits... Fixed in https://github.com/w3c/csswg-drafts/commit/a46621810b7a798faf61a1118ec7899e0d0d4252 Let me know if it needs more tweaks or if I got something wrong. Thanks -- Simon Pieters Opera Software
Received on Wednesday, 9 December 2015 17:52:38 UTC