What Is a Non-Replaced Inline Element

what is a non-replaced inline element?

For most practical purposes, it is best to read “replaced” as “embedding”. So “non-replaced element” is just an element that is rendered as such, instead of causing some external content to appear in its place.

The expression “non-replaced inline element” has no definition of its own: it simply refers to any element that is both a non−replaced element and an inline element. Such as <a>. Most elements in HTML are non-replaced. A non-replaced element is simply an element that is not a replaced element.

However, in CSS specifications, there are just general characterizations the concept “replaced element”, not any definitive list of such elements. This is understandable, since HTML evolves rather independently of CSS.

The concept has somewhat changed over time. The CSS 1 spec said: “In HTML, IMG, INPUT, TEXTAREA, SELECT, and OBJECT elements can be examples of replaced elements.” In newer specs, form fields are not included any more. This is reflected in the HTML5 draft, where the Rendering section explicitly lists form controls under Non-replaced elements. The only replaced elements, according to it, are those that embed external content, such as an image, video, applet, or HTML5 canvas into an HTML document – except that the revamped menu element is mentioned too (it is expected to be implement in a manner that echoes browser controls, so it sort-of embeds external content too).

This change reflects browser development. Early browsers implemented form fields using system routines in a manner that was immune to anything in CSS, and there are still some remains of such approaches, but nowadays form fields can mostly be formatted with CSS, so they have effectively changed from replaced to non-replaced elements.

What Are Non-Replaced Inline Blocks?

The terms inline block and inline-block refer to the same thing (an inline-level, block container box) and are completely interchangeable. An element with display: inline-block does, indeed, generate an inline-block box, or an inline block box (with or without the hyphen). The hyphen is only there so CSS is able to define inline-block as a single keyword value.

The non-hyphenated form appears several times throughout section 9 of CSS2, but doesn't appear anywhere else in that spec (it appears once in css-display-3, in a sentence lifted almost verbatim from CSS2, so it doesn't count). I don't know why this is the case, but it is not the intention that the non-hyphenated form refers to something different from the hyphenated form. In fact, section 9 itself uses both forms interchangeably — see section 9.2.4 for an example of the hyphenated form being used:

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.

I can see why readers would get confused, though. Fortunately, the rest of the CSS2 spec, and most CSS3 specs (that I've examined anyway) are all consistent in the use of the hyphenated form.

Also, the presence or absence of the word "box" doesn't change the meaning of "inline-block". Generally, the spec leaves it out because it's needlessly verbose; everything in the formatting structure that's not a text run is a box anyway, and "inline-block" as a noun rolls off the tongue rather nicely.

---

If non-replaced inline blocks are block container boxes, and elements with display:inline-block are inline-level boxes (i.e. not block-level boxes and thus not block container boxes) then it logically falls out that non-replaced inline blocks cannot be the result of elements with display:inline-block.

I think there is some misunderstanding here. The quote above lists inline-blocks as an example of a block container box that is not block-level; the purpose of that quote is to convey to the reader that not all block containers are block-level boxes, and not all block-level boxes are block containers — indeed, that the two concepts are distinct and should not be conflated. From my answer to this related question:

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.

Therefore, again, display: inline-block does cause an element to generate an inline-block (except when other parts of the layout force it to be formatted as block-level, or blockified, which is a separate topic altogether). Whether this inline-block is replaced or non-replaced depends on the element; for example, an <img> element with display: inline-block generates a replaced inline-block, whereas a <div> element with display: inline-block generates a non-replaced inline-block.

A replaced inline-block cannot actually form a block container, because its contents are rendered outside of the rules of CSS formatting. This is why the spec distinguishes non-replaced inline-blocks as block containers. There really isn't more to it than that.

alignment box for inline-block non-replaced elements

The statement

for inline non-replaced elements, the box used for alignment is the box whose height is the 'line-height'

does not apply to inline-blocks. Inline-blocks are not inline elements. Inline elements are elements with display: inline, and generate inline boxes. Inline-blocks are not inline boxes, but inline-level (the "-level" part is important!) block container boxes. Therefore, the statement

For all other elements, the box used for alignment is the margin box.

applies instead, which results in vertical-align: text-top causing the top outer edge of the inline-block to align with the top of the line box.

Any part of the specification that is said to apply to inline elements does not apply to inline-blocks.

Why img takes a height when it's an inline element?

<img> tag is not strictly an inline element, but a inline-replaced element.

In a nutshell, it means that <img> (and other elements, as <video> or, <object> if you still use it), has intrinsic dimensions. So CSS can handle those dimensions (and other properties, such as margins). Because <img> is an inline tag, that is replaced by its own source file (well, it's still an inline element).

Some doc about that :

• https://developer.mozilla.org/en-US/docs/Web/CSS/Replaced_element
• http://www.w3.org/TR/REC-html40/struct/objects.html#edef-IMG

Funny fact (I guess) : you can't override (or simply handle) inline-replaced behavior to "normal" inline behavior on those elements with CSS (when it works when you set it to inline-block or block or whatever you want). See this example : http://jsfiddle.net/s8apbbof/

Is HTML label a replaced element?

Is HTML label a replaced element?

No

You cannot apply generated content to replaced elements. That is, you cannot apply the pseudo-element selectors :before or :after to them.

But I can.

The quote says you can't use :before or :after on replaced elements.

Since label is not a replaced element, you can use :before and :after on it.

So you aren't seeing anything that contradicts the documentation you are reading.

---

Setting line-height on wrapping form, and override it on div and label - Not OK, the two elements behave differently

They should behave differently.

The inline boxes inside the form are the line height for the form.

The label is inline, so its inline boxes go inside the inline boxes for the form. The label's inline boxes are smaller than the inline boxes they are inside.

The div is a block element, so its inline boxes go inside the div itself and not inside the inline boxes for the form.

If you make the div display: inline then you compare two elements that are display: inline instead of one that is inline and one that is block and you get the same results for each.

Why can't inline elements be transformed?

As @Shikkediel mentioned, inline elements do not have strong boundary like block elements do. They don't influence the flow of the document in the same way, if at all, and are tightly bound to their neighboring text or elements. CSS transforms operate on the bounding box (which inline elements do technically have) in a way that wouldn't really make sense for inline elements.

Consider a <strong> within a <span> (or div). The bold text is defined only by the change in style, but can flow across multiple lines and does not have a predictable rectangular bounding area. If you were to apply a CSS rotation, where would it rotate from? How would it reflow, if at all, while rotating?

On the other hand, the containing <span> does have rectangular bounds, so finding the center and corners, rotating and scaling, are all predictable and well-defined.

As an example, take this fiddle. The background of the inline element is:

but the bounds shown by the editor are:

You can clearly see that the background and the element's bounds do not match at all. Without clear bounds, transforms because difficult and not very useful.

---

Related Topics