Re: [css3-break] fragments vs boxes (what is a box?)

On 31/12/2013 00:53, Robert O'Callahan wrote:
> In CSS 2.1, inline elements are described as splitting into multiple boxes:
> http://www.w3.org/TR/CSS2/visuren.html#inline-formatting
> I always assumed that therefore each fragment of an inline element had
> its own border-box, padding-box, content-box, etc. And therefore at that
> point it made sense for CSSOM-VIew to define getClientRects() to return
> a list of rectangles, one rectangle per border-box. Each fragment having
> its own border-box, padding-box, etc is also very useful for defining
> how those fragments are laid out and how they render borders,
> backgrounds etc.
>
> But I've just realized that the CSS3 Fragments spec talks about elements
> --- including inline elements --- having a single 'box' that breaks into
> multiple 'fragments'. So here are a couple of questions that need
> clarification:
> -- Does each fragment have its own border-box, padding-box, etc? If so,
> does it make sense for a spec to talk about "an element's border-boxes",
> meaning the border-boxes of its fragments? If not, how are we to
> describe the equivalent of the border-box of each fragment (the
> rectangle that's the outside edge of the border of the fragment)?
> -- Should we really be talking about a 'box' consisting of multiple
> fragments? To me a 'box' suggests something rectangular, not something
> whose geometry is a list of rectangles. If the answer is nevertheless
> "yes" then we need to indicate, probably in CSS3 Fragments, that the
> splitting of boxes described in CSS 2.1 is obsolete terminology. We
> would also need to eliminate all references to 'CSS boxes' that expect
> them to have rectangular geometry.

Just like CSS 2.1 in places still confuses elements and CSS boxes, IMO 
fragments and boxes are two different concepts that are often confused 
by our specs.

Despite the name "box" suggesting the opposite, only fragments have 
anything rectangular (at least in my understanding of all this.)

Elements generally generate one box, but they can generate zero 
(display: none) or more than one, (::before, a list item marker, a table 
wrapper, …)

Separating the two concepts also makes it easier to explain layout. 
Rather than having boxes with a size that is not know yet before they’re 
determined during layout, layout produces a tree of rectangular 
fragments from a tree of non-geometrical "boxes".


The 'box-decoration-break' property describes what to do with margins, 
borders, padding and backgrounds when fragmenting:

http://dev.w3.org/csswg/css-break/#break-decoration


I agree that it makes sense for getClientRects() to return a list, with 
one item for each fragment generated by (boxes generated by) the element.

Cheers,
-- 
Simon Sapin

Received on Tuesday, 7 January 2014 17:03:56 UTC