I noticed that people covered specifics of some display properties in a 1:1 comparison, but there are quite a few that have not been covered in illustrating the differences. Could someone explain the differences between the various inline-something display tags?
A more elaborated definition over places like w3schools would do wonders.
The only difference, for any display type that has block and inline variants, is that the inline-* display type has the box laid inline (i.e. in an inline formatting context) while the other has the box formatted as a block-level box, subject to most of the same formatting conventions as other block-level elements in a block formatting context. The difference between a block-level box and an inline-level box is covered in depth elsewhere.
Everything concerning how the box lays out its contents is pretty much the same (the specifics of which, of course, are governed by the display type itself); any other nuanced differences would have been stated explicitly in the spec. As far as I'm aware, there are in fact no such differences.
When in doubt, prefer block-level display types. If you find yourself asking whether inline-level is appropriate, chances are the answer is no. Certain scenarios may prevent a box from ever being formatted as an inline-level box anyway, such as absolute positioning or floating, or being formatted as a flex item or grid item instead. The result is a direct conversion from the inline-* variant to its usual block variant. That is, inline-block is converted to block, inline-table to table, inline-flex to flex, and inline-grid to grid. Again, this does not directly affect how an element's contents are formatted, not as far as the specifications go.
Examples of each display type and its inline-level counterpart follow.
In CSS2.1, section 9.2.4 describes block and inline-block as follows:
block
This value causes an element to generate a block box.
inline-block
This value causes an element to generate an inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.
Note that "block box" is a shorthand for "block-level block container", and a block container is something that can contain block-level boxes.
You can see that both of these two values cause an element to generate a block container box, in which its contents will always follow the same set of formatting rules, but that block container box itself is either formatted as block-level, or inline-level.
There is one additional difference between block and inline-block: an inline-block box always establishes a new block formatting context; block boxes only do so under a set of conditions. This does not hold true for any of the other display types that have block-level and inline-level counterparts.
Section 17.2 describes table and inline-table as follows:
table (In HTML: TABLE)
Specifies that an element defines a block-level table: it is a rectangular block that participates in a block formatting context.
inline-table (In HTML: TABLE)
Specifies that an element defines an inline-level table: it is a rectangular block that participates in an inline formatting context).
The Flexbox module describes flex and inline-flex as follows:
flex
This value causes an element to generate a block-level flex container box.
inline-flex
This value causes an element to generate an inline-level flex container box.
And the Grid Layout module describes grid and inline-grid as follows:
grid
This value causes an element to generate a block-level grid container box.
inline-grid
This value causes an element to generate an inline-level grid container box.
Again, in all of these scenarios, a table, a flex container, or a grid container will behave exactly the same way whether it is block-level or inline-level. A flex container always establishes a flex formatting context for its flex items, and a grid container always establishes a grid formatting context for its grid items.
Related
I am reading CSS Spec 2.1 and find the concepts hard to distinguish:
Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes.
May I interpret the description above as follow?:
Your interpretation is correct.
Here are some additional details:
The reason a table box is not a block container is because it establishes a table layout, not a block layout. Content goes into the cell elements rather than the table element, which is why it is the cell boxes that are block containers rather than the table box itself.
A replaced element doesn't contain any other content and therefore cannot be a block container.
The only difference between a block box and an inline-block is that the former is block-level while the latter is inline-level. Hence the display values display: block and display: inline-block respectively. As both are block containers, there is no difference in how their contents are formatted.
Note that replaced elements and table boxes can be either inline-level or block-level. Inline tables and inline replaced elements are simply excluded from the section you quote because that section only pertains to block-level boxes; you'll find references to them elsewhere in section 9, or in sections 10 and 17 respectively.
Also, even though a block container box can only either contain block-level boxes or inline-level boxes, you can still mix both in the same block container box; internally it simply segregates the block-level and inline-level boxes via anonymous block boxes.
Remember that HTML is a tree so each node can act as both a parent (of children) and child (of a parent)
Bearing this in mind, things start to make sense, Block-level box refers to box act as chlid
Block-level boxes are boxes that participate in a block formatting
context.
On the other hand, block container box refer to a parent who can contain others
A block container box either contains only block-level boxes or
establishes an inline formatting context and thus contains only
inline-level boxes
Just like a node can either be a child and a parent, an HTML node can either act as a parent(block container box) or child (block-level box) or BOTH
For example, if children in a node are not allowed (replaced element), it can never be a parent, it can only be a child (Block-level boxes) at most, not a parent (block container box)
And there is no reason to prevent a non-block parent contain a block parent. An inline-block itself is not a block, but it can contain block-level box
The point is a spec is easier to understand from a parent-child view
Flex items are element of flex level, but is that an element of the block level?
According to Chapter 4 of CSS Flexible Box Layout Module Level 1, flex items are considered to be at the flex level and not at the block level.
A flex item establishes an independent formatting context for its contents. However, flex items themselves are flex-level
boxes, not block-level boxes: they participate in their container’s flex formatting context, not in a block formatting context.
However, if you read chapter 4 later, it is written that the flex item's display value will be "blockified".
Does blockified indicate that the element is block level? If so, the "flex item is flex level" described above is a mistake.
The display value of a flex item is blockified: if the specified display of an in-flow child of an element generating a flex container is an inline-level value, it computes to its block-level equivalent. (See CSS2.1§9.7 [CSS21] and CSS Display [CSS3-DISPLAY] for details on this type of display value conversion.)
What does "blockified" mean here? Also, are flex items at the flex level? Or is it a blockified block level?
If it interprets as a specification, it will be the contradictory conclusion that "flex item is flex level, not block level but it becomes block level by blockified".
Both specifications are, of course, correct, but you forget the keyword display in the second section. Each element has a display value and for flex items this value is block which means that if, for example, you specify inline-block it will get computed to block. If you specify inline-grid, it will get computed to grid and so on.
if the specified display of an in-flow child of an element generating a flex container is an inline-level value, it computes to its block-level equivalent
So flex items are flex-level boxes with a display: block; value but they aren't block-level boxes.
Related: Usage of display property of flex box items
To make it easier, imagine you have two worlds, the outside world and the inside world. If we look at a flex item from the outside world, it's a flex-level box participating in its container's flex formatting context. From the inside world, it's a block element which means that an element inside a flex item will see the flex item as a block element.
If you set inline-[flex/table/grid/block] to the flex item it will be seen as a [flex/table/grid/block] container from the inside. The inline is gone because it's blockified.
I noticed that people covered specifics of some display properties in a 1:1 comparison, but there are quite a few that have not been covered in illustrating the differences. Could someone explain the differences between the various inline-something display tags?
A more elaborated definition over places like w3schools would do wonders.
The only difference, for any display type that has block and inline variants, is that the inline-* display type has the box laid inline (i.e. in an inline formatting context) while the other has the box formatted as a block-level box, subject to most of the same formatting conventions as other block-level elements in a block formatting context. The difference between a block-level box and an inline-level box is covered in depth elsewhere.
Everything concerning how the box lays out its contents is pretty much the same (the specifics of which, of course, are governed by the display type itself); any other nuanced differences would have been stated explicitly in the spec. As far as I'm aware, there are in fact no such differences.
When in doubt, prefer block-level display types. If you find yourself asking whether inline-level is appropriate, chances are the answer is no. Certain scenarios may prevent a box from ever being formatted as an inline-level box anyway, such as absolute positioning or floating, or being formatted as a flex item or grid item instead. The result is a direct conversion from the inline-* variant to its usual block variant. That is, inline-block is converted to block, inline-table to table, inline-flex to flex, and inline-grid to grid. Again, this does not directly affect how an element's contents are formatted, not as far as the specifications go.
Examples of each display type and its inline-level counterpart follow.
In CSS2.1, section 9.2.4 describes block and inline-block as follows:
block
This value causes an element to generate a block box.
inline-block
This value causes an element to generate an inline-level block container. The inside of an inline-block is formatted as a block box, and the element itself is formatted as an atomic inline-level box.
Note that "block box" is a shorthand for "block-level block container", and a block container is something that can contain block-level boxes.
You can see that both of these two values cause an element to generate a block container box, in which its contents will always follow the same set of formatting rules, but that block container box itself is either formatted as block-level, or inline-level.
There is one additional difference between block and inline-block: an inline-block box always establishes a new block formatting context; block boxes only do so under a set of conditions. This does not hold true for any of the other display types that have block-level and inline-level counterparts.
Section 17.2 describes table and inline-table as follows:
table (In HTML: TABLE)
Specifies that an element defines a block-level table: it is a rectangular block that participates in a block formatting context.
inline-table (In HTML: TABLE)
Specifies that an element defines an inline-level table: it is a rectangular block that participates in an inline formatting context).
The Flexbox module describes flex and inline-flex as follows:
flex
This value causes an element to generate a block-level flex container box.
inline-flex
This value causes an element to generate an inline-level flex container box.
And the Grid Layout module describes grid and inline-grid as follows:
grid
This value causes an element to generate a block-level grid container box.
inline-grid
This value causes an element to generate an inline-level grid container box.
Again, in all of these scenarios, a table, a flex container, or a grid container will behave exactly the same way whether it is block-level or inline-level. A flex container always establishes a flex formatting context for its flex items, and a grid container always establishes a grid formatting context for its grid items.
I am reading CSS Spec 2.1 and find the concepts hard to distinguish:
Except for table boxes, which are described in a later chapter, and replaced elements, a block-level box is also a block container box. A block container box either contains only block-level boxes or establishes an inline formatting context and thus contains only inline-level boxes. Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells are block containers but not block-level boxes. Block-level boxes that are also block containers are called block boxes.
May I interpret the description above as follow?:
Your interpretation is correct.
Here are some additional details:
The reason a table box is not a block container is because it establishes a table layout, not a block layout. Content goes into the cell elements rather than the table element, which is why it is the cell boxes that are block containers rather than the table box itself.
A replaced element doesn't contain any other content and therefore cannot be a block container.
The only difference between a block box and an inline-block is that the former is block-level while the latter is inline-level. Hence the display values display: block and display: inline-block respectively. As both are block containers, there is no difference in how their contents are formatted.
Note that replaced elements and table boxes can be either inline-level or block-level. Inline tables and inline replaced elements are simply excluded from the section you quote because that section only pertains to block-level boxes; you'll find references to them elsewhere in section 9, or in sections 10 and 17 respectively.
Also, even though a block container box can only either contain block-level boxes or inline-level boxes, you can still mix both in the same block container box; internally it simply segregates the block-level and inline-level boxes via anonymous block boxes.
Remember that HTML is a tree so each node can act as both a parent (of children) and child (of a parent)
Bearing this in mind, things start to make sense, Block-level box refers to box act as chlid
Block-level boxes are boxes that participate in a block formatting
context.
On the other hand, block container box refer to a parent who can contain others
A block container box either contains only block-level boxes or
establishes an inline formatting context and thus contains only
inline-level boxes
Just like a node can either be a child and a parent, an HTML node can either act as a parent(block container box) or child (block-level box) or BOTH
For example, if children in a node are not allowed (replaced element), it can never be a parent, it can only be a child (Block-level boxes) at most, not a parent (block container box)
And there is no reason to prevent a non-block parent contain a block parent. An inline-block itself is not a block, but it can contain block-level box
The point is a spec is easier to understand from a parent-child view
I read that a block formatting context is created in some cases from MDN:Block formatting context.
I wonder when does a box establish an inline formatting context?
One case I know is: when a block container box contains only inline-level boxes.
To answer your question, I reread Section 9.2.1 of the CSS 2.1 spec.
Based on my reading, you have your answer: the inline formatting context is triggered when a block container box contains only inline elements.
In contrast to a block formatting context that can be triggered explicitly (for example, setting overflow: hidden to a block-level element), an inline formatting context cannot be triggered explicitly.
Inline formatting contexts appear to always exist as descendant block boxes within a "principal block-level box", and these descendant block boxes may be anonymous.
I offer the following description as a mental model for understanding block/inline formatting contexts.
A block-level element (e.g. a <div>) fulfills two responsibilities: one, positioning, and two, content formatting.
When dealing with positioning, a block-level element acts as a "block-level box".
When dealing with formatting, a block-level element acts as a "block container box".
Acting as a "block-level box", the block-element behaves according to the type of positioning (static, absolute, relative, fixed) specified by the position property.
Acting as a "block container box", the block-element establishes a block-formatting context if the block-element has at least one child block-level element. If all the child elements are inline-level boxes, then an inline-formatting context is established.
If the "block container box" contains text and block elements, then the text is treated as being contained in one or more anonymous block-level boxes, and a block-formatting context is established.
Aside
The CSS spec is not exactly light reading. I have reread Chapters 9 and 10 several times and I have yet to come up with a plain-English translation.