Inline Anonymous Boxes

Inline anonymous boxes?

Section 9.2.2.1 in the Visual Formatting Model actually has an almost identical example to yours, e.g.

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

In a document with HTML markup like this:

<p>Some <em>emphasized</em> text</p>

the <p> generates a block box, with several inline boxes inside it. The box for "emphasized" is an inline box generated by an inline element (<em>), but the other boxes ("Some" and "text") are inline boxes generated by a block-level element (<p>). The latter are called anonymous inline boxes, because they do not have an associated inline-level element.

What you're seeing in Chrome's developer tools is the display value for the element that the anonymous boxes lives in, not of the inline boxes themselves. They're all actually inline boxes, but "In 1912" & "sank on her maiden voyage" would be anonymous while the <em> element would create a non-anonymous inline box as it is an inline-level element.

What is an anonymous inline box?

So the text your read comes from https://www.w3.org/TR/CSS2/visuren.html#anonymous

9.2.2.1 Anonymous inline boxes

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

In a document with HTML markup like this:
<p>Some <em>emphasized</em> text</p>
the <p> generates a block box, with several inline boxes inside it. The box for "emphasized" is an inline box generated by an inline element (<em>), but the other boxes ("Some" and "text") are inline boxes generated by a block-level element (<p>). The latter are called anonymous inline boxes, because they do not have an associated inline-level element.

Such anonymous inline boxes inherit inheritable properties from their block parent box. Non-inherited properties have their initial value. In the example, the color of the anonymous inline boxes is inherited from the P, but the background is transparent.

White space content that would subsequently be collapsed away according to the 'white-space' property does not generate any anonymous inline boxes.

If it is clear from the context which type of anonymous box is meant, both anonymous inline boxes and anonymous block boxes are simply called anonymous boxes in this specification.

There are more types of anonymous boxes that arise when formatting tables.

p {
  background-color: red
}

em {
  background-color: yellow
}

<p> Anonymous inline box #1 <em> inline emphasized box </em> Anonymous inline box #2 </p>

Box model properties on anonymous inline boxes

No; since margins, borders and padding are not inherited properties, and you cannot style anonymous boxes directly with CSS (not even with the universal selector, or pseudo-elements), anonymous inline boxes cannot have margins, borders or padding.

Line boxes cannot have margins, borders or padding either.

Identifying Anonymous Block Boxes

Box Generation will treat any boxes inside this block container as a block-level boxes. And by doing so, any boxes that is not a block-level box will be internally/conceptually treated as an anonymous block boxes, which is basically a block-level box anyway.

No, it creates anonymous block boxes with inline formatting contexts, which enclose the inlines. The inlines (or whatever other boxes that aren't block-level boxes) do not change. They continue to participate in the same formatting contexts they normally would; this algorithm ensures those formatting contexts are established by anonymous block boxes, that in turn participate in the same block formatting context as the parent element.

The illustration is mostly correct, with the exception that the principal block-level box doesn't always establish a block formatting context. You may also be getting the terms "block formatting context", "block-level box", "block container box", and "block box" mixed up; see my answers to these questions for additional clarification:

• CSS Spec: block-level box, block container box and block box
• Block Level Element vs Block Formatting Context

Do Inline elements establish a Line Box for their content?

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.

CSS: When are empty anonymous block boxes removed?

I believe that the answer is in this portion of the CSS2 specification, which reads:

"Line boxes are created as needed to hold inline-level content within an inline formatting context. Line boxes that contain no text, no preserved white space, no inline elements with non-zero margins, padding, or borders, and no other in-flow content (such as images, inline blocks or inline tables), and do not end with a preserved newline must be treated as zero-height line boxes for the purposes of determining the positions of any elements inside of them, and must be treated as not existing for any other purpose."

The above paragraph explains the observed behavior. [There is also another part of the spec, on collapsing margins, which refers to the above paragraph. I'm mentioning this because readers that come across this answer may find it useful.]

---

Related Topics