Consider the following code:
<div></div>
div{
display: inline-block;
}
div block is generated atomic inline-level box now. As said in spec. 9.2.2
Inline-level boxes that are not inline boxes (such as replaced
inline-level elements, inline-block elements, and inline-table
elements) are called atomic inline-level boxes because they
participate in their inline formatting context as a single opaque box.
What does 'opaque' mean in this case? Is inline boxes participated in the inline formatting context as a transparent box?
So I'm interested in what difference between atomic inline-level box and inline box?
From the WC3 CSS2.1 Specification, Chapter 9 Visual formatting model:
An inline box is one that is both inline-level and whose contents
participate in its containing inline formatting context. A
non-replaced element with a 'display' value of 'inline' generates an
inline box.
Inline-level boxes that are not inline boxes (such as
replaced inline-level elements, inline-block elements, and
inline-table elements) are called atomic inline-level boxes because
they participate in their inline formatting context as a single opaque
box.
Therefore
Elements with display: inline generates inline boxes.
Elements with display: inline-table | inline-block and replaced inline-level elements (like <img>) generates inline-level atomic boxes.
With regards to your question on what opaque means, #BoltClock explains it in a great way here:
CSS Spec - Atomic Inline Level Boxes
Opaque means that the box is a singular, solid unit, and that it
cannot be split across lines like an inline box can when its text
cannot all fit on a single line.
And here is some additional detail from me, that might help
Inline-level boxes includes boxes...
...whose content participate in its containing inline formatting context
These are called inline boxes
They are generated by elements with display: inline
Note the words "...whose content participate in its containing...". This means that inline-level child elements inside this inline-level box, are in the same inline formatting context as the parent. This, in turn, means that the individual child inline-level elements will separate and fall to a new line if there is white space (and the white-space property is not changed). In effect, the parent inline box will split into several boxes. Here, all the inline-level elements inside the parent inline box, live in one big happy inline formatting context.
...that participate in their inline formatting context as a single opaque box
These are called atomic inline-level boxes
They are generated by elements with display: inline-table | inline-block | inline-flex | inline-grid
Opaque means that the box is one single solid box
A consequence of that is that the box cannot be split, even if inline-level boxes inside it normally should fall to the next line
Instead, scrollbars would appear
Contents inside this atomic inline-level box does not participate in the same inline formatting context as its parent
And finally, as seen, inline-level boxes is a super-set of inline boxes.
Hope that helps someone in the future.
Indeed. Referring to Visual Formatting Model
<p>Some <em>emphasized</em> text</p>
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
Related
This MDN doc says:
In CSS we broadly have two types of boxes - block boxes and inline
boxes.
But in this MDN doc that talks about normal flow, block boxes are never mentioned. Only block-level elements are mentioned.
What is the difference?
Block vs Block-Level
Lots. Block boxes are both block-level and also block containers. That's display:block, display:flow-root, the principal box of display:list-item and the table wrapper box of display:table.
Boxes that are block-level, but not block containers, and therefore not block boxes are those which have e.g. display:flex, display:grid and the table grid box of display:table
Boxes that are block containers, but not block-level, and therefore not block boxes are those which have e.g. display:inline-block and display:table-cell.
Stating that there are broadly two types of boxes - block and inline - is at best misleading, if not outright wrong. We could better say that there are broadly two types of boxes - block-level and inline-level, but even then, only broadly. Block-level boxes are participants in a Block Formatting Context. Inline-level boxes are participants in an Inline Formatting Context. Boxes that are participants in other formatting contexts, such as flex items, grid items, and some of the internal table and ruby boxes are neither.
Elements vs Boxes
Elements are objects of SGML, HTML and DOM. Boxes are objects of CSS. A block-level element is one that when the CSS box tree is being formed, by default generates at least a principal box which is block-level.
In the CSS specifications in part 9.2.4 the description of the inline-block value for the display property says:
This value causes an element to generate a principal 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.)
What does the following sentence mean?
The inside of an inline-block is formatted as a
block box
Does it mean that an inline-block has a block box inside?
W3C source for the quotes below.
The following values of the 'display' property make an element
inline-level: 'inline', 'inline-table', and 'inline-block'
Thus, an element with display: inline-block is an inline-level element.
Inline-level elements generate inline-level boxes, which are boxes
that participate in an inline formatting context.
Thus, all inline-level boxes participate in an inline formatting context.
An inline box is one that is both inline-level and whose contents
participate in its containing inline formatting context
If all inline-level boxes participate in an inline formatting context, and an inline box is one that is both an inline-level box and participates in an inline formatting context, it must be true that all inline-level boxes are inline boxes, and vice versa.
And finally, here comes the statement that then breaks the logic:
Inline-level boxes that are not inline boxes (such as replaced
inline-level elements, inline-block elements, and inline-table
elements) are called atomic inline-level boxes...
In other words:
First we are told, via logical implication, that all inline-level boxes are inline boxes. Then, we are told the opposite: That several inline-level boxes (like those generated by elements with display: inline-block), are in fact not inline boxes.
Am I missing something or are the quotes contradicting each other?
EDIT
I found the following post by #BoltClock, which is really good: CSS Spec - Atomic Inline Level Boxes
I also posted an answer to another question, after understanding the whole concept a bit better. It can be found here: Difference between inline box and atomic inline box
There is not a contradiction in the standard, but we have to read carefully to spot the differences.
Inline-level boxes are boxes that participate in an inline formatting context.
An inline box is a inline-level box whose contents participate in its containing inline formatting context
A span-element inside a paragraph is an inline box, because the text inside the span-element participate in the paragraphs' surround content.
An element with display: inline-block; will flow with surrounding content as if it were a single inline box, but since this element actually will generate a block element box, the elements contents do not participate in its containing inline formatting context.
What is the difference between a HTML element that is a block level element and a HTML element that forms a block formatting context?
Can a HTML element be both a block level element and form a block formatting context?
Does being a block level element imply that it forms a block formatting context, or conversely, does forming a block formatting context imply that it must be a block level element?
In a similar vein, how does this translate to inline elements and elements that form an inline formatting context?
(For some context, I've been trying to read Learn CSS Layout - The Pedantic Way but it's been a bit challenging to follow Chapter 1)
Note that this answer uses the term "box" in lieu of "element", as CSS makes a distinction between elements and boxes. For the purposes of this answer, an HTML element is represented by a single box in CSS layout. In reality an element may generate any number of boxes (or none at all, as in display: none), but that's outside the scope of this question.
Can a HTML element be both a block level element and form a block formatting context?
Yes. The criteria in which a block box (i.e. a block-level block container box) may establish a BFC are stated in section 9.4.1 of CSS2.1, namely:
floats,
absolutely positioned elements, and
"block boxes with 'overflow' other than 'visible' (except when that value has been propagated to the viewport)" (as directly quoted from the spec)
Does being a block level element imply that it forms a block formatting context, or conversely, does forming a block formatting context imply that it must be a block level element?
Neither:
The above answer implies that not all block boxes establish block formatting contexts. A block box with the CSS properties display: block; overflow: visible; float: none; position: static (or position: relative) does not establish a BFC.
Conversely, an inline-block is an example of a box that establishes a BFC, but is itself inline-level, not block-level.
In a similar vein, how does this translate to inline elements and elements that form an inline formatting context?
An inline box is an inline-level box whose contents participate directly in its parent's inline formatting context (see section 9.4.2). Notably, the only boxes that can establish inline formatting contexts are block container boxes.
The difference between an inline box and an inline-block is that an inline-block's contents participate in the BFC that it establishes, not in the parent's IFC. Instead, only the inline-block itself participates in its parent's IFC.
Consider this HTML:
<div id="x">Foo</div>
<div id="y">Bar <span>Baz</span></div>
And this CSS:
#x {
background: orange;
display: inline;
font-size: 200%;
}
#y {
background: cyan;
display: inline;
vertical-align: top;
}
Here is the JSFiddle demo: http://jsfiddle.net/ePBZz/
With Firefox 28.0 and Internet Explorer 8, both 'Bar' and 'Baz' appear on the same line. However, with Chrome 33.0, they do not appear on the same line.
(Output with Firefox on left; Output with Chrome on right)
From the 'Inspect element' feature of Firefox and Chrome I figure that in both cases the span element obeys the standard of using vertical-align: baseline (the default). So Chrome must be using a different definition of baseline for the span element than Firefox when vertical-align: top is used for the parent element, otherwise I do not know how to explain the difference in the output between Chrome and Firefox.
By the way, I know how to fix this code. By adding the following to the CSS.
#y span {
vertical-align: inherit;
}
This would force the child span element to inherit vertical-align: top from the parent #y element. However, that is not my question.
I want to know which one is the buggy behaviour and which one is the correct behaviour as per the W3C CSS standard for my code without the fix I mentiond later, or if the result of this kind of code is unspecified by the standard. If possible, please quote the sections from the W3C documents that clarifies the behaviour for such code.
After reading CSS 2.1 specification (W3C Recommendation 07 June 2011) it seems to me that both Chrome and Firefox are correct and they are free to choose different baselines.
Section 9.2.2. defines what an inline-level box is.
9.2.2 Inline-level elements and inline boxes
Inline-level elements are those elements of the source document that
do not form new blocks of content; the content is distributed in lines
(e.g., emphasized pieces of text within a paragraph, inline images,
etc.). The following values of the 'display' property make an element
inline-level: 'inline', 'inline-table', and 'inline-block'.
Inline-level elements generate inline-level boxes, which are boxes
that participate in an inline formatting context.
An inline box is one that is both inline-level and whose contents
participate in its containing inline formatting context. A
non-replaced element with a 'display' value of 'inline' generates an
inline box. Inline-level boxes that are not inline boxes (such as
replaced inline-level elements, inline-block elements, and
inline-table elements) are called atomic inline-level boxes because
they participate in their inline formatting context as a single opaque
box.
Section 9.4.2 defines what a line box is.
9.4.2 Inline formatting contexts
In an inline formatting context, boxes are laid out horizontally, one
after the other, beginning at the top of a containing block.
Horizontal margins, borders, and padding are respected between these
boxes. The boxes may be aligned vertically in different ways: their
bottoms or tops may be aligned, or the baselines of text within them
may be aligned. The rectangular area that contains the boxes that form
a line is called a line box.
Then section 10.8 mentions:
The inline-level boxes are aligned vertically according to their
'vertical-align' property. In case they are aligned 'top' or 'bottom',
they must be aligned so as to minimize the line box height. If such
boxes are tall enough, there are multiple solutions and CSS 2.1 does
not define the position of the line box's baseline (i.e., the position
of the strut, see below).
This seems to apply to the code at http://jsfiddle.net/ePBZz/. In this code, vertical-align: top has been applied to the div id="y" which has been defined as follows.
<div id="y">Bar <span>Baz</span></div>
There are two inline-level boxes in this element. The two inline-level boxes are:
Anonymous: "Bar"
SPAN: "Baz"
Now it is not clear what it really means for inline-level boxes to be tall enough, but if we assume that these two inline-level boxes are tall enough, then as per the last quoted text, the standard does not define the baseline of the line box that contains these two inline-level boxes. As a result, Chrome and Firefox are free to choose different baselines and align the baseline of the second inline level-box (SPAN: "Baz") with these differently chosen baselines, thereby producing different outputs.