I see the w3c writing
In the case that the ancestor is an inline element, the containing
block is the bounding box around the padding boxes of the first and
the last inline boxes generated for that element. In CSS 2.1, if the
inline element is split across multiple lines, the containing block is
undefined.
I don't quite understand what's this mean, what's the diff from when the containing block is block element, Can someone give me an example?
the containing block is the bounding box around the padding boxes of
the first and the last inline boxes
in other words, width of the inline element will be equal to it's content, while width of the block level element will extend on available area (padding of ancestor reduces this area, see qoute from spec).
Otherwise, the containing block is formed by the padding edge of the
ancestor.
Related
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.
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.
This question already has answers here:
Why does an inline element accept width and height when floated?
(2 answers)
Closed 5 years ago.
I was unable set the width for an inline element <span> while creating a table-row with multiple span elements. I was able to modify the width once I put a float: left as well.
Why was I not able to set the width and height of inline elements? How does adding a float change things?
Answer A:
You can't explicitly set the width of an inline element because it is relative to the surrounding elements, and thus is restricted by their widths.
Answer B:
Floating an element with float automatically makes it into a block-level element by applying display: block to it. A block-level element occupies the entire space of its parent element (container), thereby creating a 'block'.
Hope this helps! :)
Inline elements by definition do not take explicit width or height but are inline and conform to the surrounding elements. They only occupy space bounded by the tags. For example:
This is some <span>text</span>
<span>text</span> only occupies the space that houses text. It's in the same line with the other text nodes in the HTML.
The float property implies block layout and the display property of elements is changed to block (in most cases) thus making them block-level elements where you can set explicit width and height because they occupy all of their container. Per the MDN documentation:
As float implies the use of the block layout, it modifies the computed value of the display values, in some cases
In this case, the table (viewable at the MDN documentation) shows that any elements with display: table-row would blockified and have display: block when floated.
Let's say that I want to make a <p> element that has a fixed height and a width that only grows if the height is not sufficient to display all of the text. By default, <p> is a block level element. This means it has a greedy width and lazy height. I want the opposite, lazy dynamic width and fixed/greedy height. An inline-block element tries to display the text in one line if possible, which is not something I want. I want a pure CSS solution just because. Is it possible?
This is not possible.
9.4.2 Inline formatting contexts
In an inline formatting context, boxes are laid out horizontally
[...]. The rectangular area that contains the boxes that form a line
is called a line box.
The width of a line box is determined by a containing block and the
presence of floats. [...]
In general, the left edge of a line box touches the left edge of its
containing block and the right edge touches the right edge of its
containing block. However, floating boxes may come between the
containing block edge and the line box edge. Thus, although line boxes
in the same inline formatting context generally have the same width
(that of the containing block), they may vary in width if available
horizontal space is reduced due to floats. [...]
Line boxes are created as needed to hold inline-level content within
an inline formatting context. [...]
Therefore, the width of the line boxes will only be affected by the width of the containing block and the presence of floats. And then, there will be as many line boxes as necessary.
Am a right to conclude that a CSS margin (e.g. margin-left) influences the final position of an absolute postioned element? It seems a negative margin-left pulls it to the left (of it's absolute postion), a positive value to the right (of it's absolute postion).
Can someone explain me more about the combination absolute positioned elements and margins?
Thanks.
Correct. Margins influence where the edges of an absolutely positioned element begin.
Lets understand it this way:
When you have an statically-positioned element, the element is part of the normal flow of the document. Hence, any margins applied on it are considered 'with respect to its surrounding elements'.
When you have an relatively-positioned element, the element is still part of the normal flow of the document. Hence, any margins applied on it are still considered 'with respect to its surrounding elements'.
BUT,
When you have an absolutely-positioned element, the element is taken out of the normal flow of the document. This element's positioning is now dictated by the first parent container that is not statically positioned (or the top level body element as a fallback). Hence, when you apply margin, the parent container is taken as the 'surrounding element' and the margin in calculated with 'respect to it'.
Hope this helps.
which elements are affected by the line-height property?
It applies to all HTML elements, but has different behaviour depending on the element.
From the CSS spec:
All elements have a 'line-height'
property that, in principle, gives the
total height of a line of text.
It affects all of them according to the W3 line-height spec. It's behavior is different depending on the type of element it is applied to:
block-level, table-cell, table-caption or inline-block
[on one of the above] whose content is composed of
inline-level elements, 'line-height'
specifies the minimal height of line
boxes within the element.
inline-level
...specifies the height
that is used in the calculation of the
line box height (except for inline
replaced elements, where the height of
the box is given by the 'height'
property).
Line box height is then defined as:
the distance between the uppermost box top and the lowermost box bottom.
Applies to all elements, with different behaviour of course:
http://www.w3.org/TR/CSS2/visudet.html#line-height
On a block-level, table-cell,
table-caption or inline-block element
whose content is composed of
inline-level elements, 'line-height'
specifies the minimal height of line
boxes within the element. The minimum
height consists of a minimum height
above the block's baseline and a
minimum depth below it, exactly as if
each line box starts with a zero-width
inline box with the block's font and
line height properties (what TEX calls
a "strut").
On an inline-level element,
'line-height' specifies the height
that is used in the calculation of the
line box height (except for inline
replaced elements, where the height of
the box is given by the 'height'
property).