Do Inline elements establish a Line Box for their content?

Question

W3 is very ambiguous about this. I've read everything about Inline-boxes, Line-boxes, anonymous boxes, block-boxes and all kinds of boxes, but nowhere is explicitly stated whether line boxes are formed inside inline-level elements.

W3 states that

"line box is the rectangular area that contains the (inline)boxes that form a line".

Then it says that

"Line boxes are created as needed to hold inline-level content within an inline formatting context"

So far, it seems that inline elements do contain line boxes, as they can contain inline-boxes, and their content participates in an inline formatting context.

However then it states that

Any text that is directly contained inside a block container element (not inside an inline element) must be treated as an anonymous inline element.

So, therefore, the text inside an inline-level element like span is not being wrapped inside an anonymous inline box.

Then they give the example of <P>Several <EM>emphasized words</EM> appear <STRONG>in this</STRONG> sentence, dear.</P> and explain that

The P element generates a block box that contains five inline boxes, three of which are anonymous. To format the paragraph, the user agent flows the five boxes into line boxes. In this example, the box generated for the P element establishes the containing block for the line boxes. If the containing block is sufficiently wide, all the inline boxes will fit into a single line box. If not, the inline boxes will be split up and distributed across several line boxes.

This explanation is confusing because the first sentence states that P generates a block-box that contains the inline-boxes, but the second sentence states that the containing block generated by the P element contains the line boxes.

Block box is a block container that is also a block-level box. So, inline-elements don't generate block boxes, but apparently they generate containing blocks. Are block-boxes and containing blocks the same thing in this context?

Since an inline-level box, like Span can contain other inline-boxes, like strong or em, that means that inline-level elements can also be block containers, but they don't form block boxes (or do they?), and their text content does not get wrapped inside an anonymous box.

It is stated that the Inline-boxes do have a containing block, but it is also explicitly stated that the line-boxes are contained inside the block-box, not the containing block.

So, are they the same? .. and does that mean that inline-level boxes like span also form a line box? If so, why doesn't the text inside inline-boxes get wrapped inside an anonymous inline box?

If line boxes only exist inside the block box, and if containing blocks are not block boxes, then that would mean that inline elements do not form line boxes for their content.

I wish W3 would be more explicit with their explanation.

Answer 1

Your heading and first paragraph ask two different questions:

• Do Inline elements establish a Line Box for their content?
• [Are] line boxes are formed inside inline-level elements?

They have different answers, "No", and "Sometimes" respectively, so the first thing that needs to be dealt with is the -level suffix.

An inline-level box is a broader category than an inline box. A span element which contains only text generates, by default, a sequence of inline boxes sufficient to lay out that text content over as many lines as is necessary. All inline boxes are also inline-level boxes, but the opposite is not true. Elements whose computed display is inline-block, inline-table, inline-flex and inline-grid all generate boxes that are inline-level, but are not inline boxes.

Similar applies to block versus block-level. Block-level describes how a box lays out relative to its parents and siblings. Block containers are boxes in which their child boxes are laid out either as sequence of block-level boxes, or within a stack of line boxes, and never as a mixture of both.

Elements whose computed display value is block, flow-root and list-item and are being laid out in a block formatting context (i.e. they're not a flex item or a grid item) generate a single box that is both block-level and a block container. These are called block boxes.

But boxes generated for elements that have computed display values of table, flex, and grid are block-level, but they are not block containers. Their descendants are laid out using different rules. These are not block boxes.

Conversely, elements that have computed display values of inline-block and table-cell generate boxes that are block containers but they are not block-level. They interact with their parents and siblings differently than block level boxes do.

So, specifically, inline-block boxes, which are inline-level, contain either a sequence of block-level boxes, or a stack of line boxes in which other inline-level boxes are laid out.

---

Now, an inline box can contain other inline-level boxes, but that does not make it a block container, even if one of those inline-level boxes is itself a block container. The block container of the inline box and all its descendant inline-level boxes that are not themselves inside other formatting contexts is the nearest ancestor that is a block container.

So, suppose we have this tree of boxes

 display:block                     block level, block container
   |                                                     ↑   ↑ 
   + - display:inline              inline level ---------+   |    \  
         |                                                   |     |- In the same line box
         + - display:inline-block  inline level, block container  /
               |                                          ↑
               + some text         anonymous inline box --+       in a line box 

where the arrows point from inline-level boxes to their block container.