What is the reason for the presence of additional space below when using x-overflow:hidden?

Question

What is the reason for the presence of additional space below when using x-overflow:hidden?

When I place two spans inside each other and use overflow-x:hidden on the inner span, it results in extra space below the inner span. Why does this happen?

<span style="" class="yavbc-color-tip"><span style="">Some text</span></span>

To see an example, you can view the Fiddle here: http://jsfiddle.net/U92ue/

Please note that I have only tested this in the latest version of Chrome.

html css overflow

Answer 1

Answer №1

Visual formatting model - 9.4.1 Block formatting contexts

When floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' establish new block formatting contexts for their contents.

It is important to note that a new block formatting context is established when the overflow property is changed. Normally, an element's vertical-align property value is baseline, but this can be altered to something like top to resolve any display issues.

See Updated Example Here

span.yavbc-color-tip span {
    display: inline-block;
    padding: 3px;
    border-radius: 8px;   
    border: none;
    background-color:#005e8e;
    color:#7cd3ff;
    overflow-x: hidden; /* This gives extra space under this span. Why? */
    vertical-align:top;
}

This issue does not occur when the element's display is not set to inline-block. It only happens with inline elements - see this example for clarification.

Answer 2

Visual formatting model - 9.4.1 Block formatting contexts

When floats, absolutely positioned elements, block containers (such as inline-blocks, table-cells, and table-captions) that are not block boxes, and block boxes with 'overflow' other than 'visible' establish new block formatting contexts for their contents.

It is important to note that a new block formatting context is established when the overflow property is changed. Normally, an element's vertical-align property value is baseline, but this can be altered to something like top to resolve any display issues.

See Updated Example Here

span.yavbc-color-tip span {
    display: inline-block;
    padding: 3px;
    border-radius: 8px;   
    border: none;
    background-color:#005e8e;
    color:#7cd3ff;
    overflow-x: hidden; /* This gives extra space under this span. Why? */
    vertical-align:top;
}

This issue does not occur when the element's display is not set to inline-block. It only happens with inline elements - see this example for clarification.

Answer 3

Answer №2

Contrary to what is mentioned in the accepted answer, the behavior discussed here is not related to Block Formatting Context or the "block" aspect of the inline-block value. It primarily concerns the "inline" component.

All inline-* elements contribute to the Inline Formatting Context. This implies that they are placed within "line boxes" alongside text and other inline-level elements. The alignment of these elements and text is such that the height of each line box is calculated from the highest element's top to the lowest one's bottom.

By default, inline-level elements align with the baseline of their fonts (as seen in the first line of the example below). Even if the parent element lacks actual text, the baseline's position and the minimum line box height are computed as if there were text present (referred to as the element's "strut"). Consequently, there is always some space above the baseline for ascenders and diacritics and below it for descenders, as illustrated in the second line.

The complexity arises for inline-block elements due to the overflow property altering what constitutes the baseline for these elements (referenced in section 10.8.1 of the spec):

An 'inline-block' element's baseline is its last line box's baseline in normal flow, unless it lacks in-flow line boxes or has a computed 'overflow' value other than 'visible', in which case the baseline becomes the bottom margin edge.

Hence, even though the space below the baseline is always reserved technically, with the default overflow: visible, the inline-block element positions itself such that its text's baseline aligns with the parent's baseline while its lower part extends beneath it. Though this setup often makes the inline-block the line's lowest element, obscuring space reserved for font descenders, adjusting the overflow reveals this space entirely.

p {
  margin: .5em;
  font: 32px/1.5 serif;
  color: #fff;
  background: #888;
}

span {
  display: inline-block;
  font: 12px/1 sans-serif;
  background: #fff;
  color: #000;
  padding: 2px;
  border: 1px solid green;
}

.ovh {
  overflow: hidden;
  border-color: red;
}

<p>Text with image <img src="http://via.placeholder.com/30x15"> and <span>two</span> <span>inline-block</span>s</p>

<p><img src="http://via.placeholder.com/30x15"> <span>only</span> <span>inline-blocks</span></p>

<p><img src="http://via.placeholder.com/30x15"> <span>regular</span>, the <span class="ovh">overflowed</span> trick</p>

Understanding inline formatting can be challenging. For further insights into its nuances and surprises, check out this article: .

A sensible guideline would be to avoid using display: inline-* solely for side effects unless you plan on incorporating the element within text. In the scenario described by OP, switching the inner span to display: block presents a straightforward solution without intricate line box calculations.

Answer 4

Contrary to what is mentioned in the accepted answer, the behavior discussed here is not related to Block Formatting Context or the "block" aspect of the inline-block value. It primarily concerns the "inline" component.

All inline-* elements contribute to the Inline Formatting Context. This implies that they are placed within "line boxes" alongside text and other inline-level elements. The alignment of these elements and text is such that the height of each line box is calculated from the highest element's top to the lowest one's bottom.

By default, inline-level elements align with the baseline of their fonts (as seen in the first line of the example below). Even if the parent element lacks actual text, the baseline's position and the minimum line box height are computed as if there were text present (referred to as the element's "strut"). Consequently, there is always some space above the baseline for ascenders and diacritics and below it for descenders, as illustrated in the second line.

The complexity arises for inline-block elements due to the overflow property altering what constitutes the baseline for these elements (referenced in section 10.8.1 of the spec):

An 'inline-block' element's baseline is its last line box's baseline in normal flow, unless it lacks in-flow line boxes or has a computed 'overflow' value other than 'visible', in which case the baseline becomes the bottom margin edge.

Hence, even though the space below the baseline is always reserved technically, with the default overflow: visible, the inline-block element positions itself such that its text's baseline aligns with the parent's baseline while its lower part extends beneath it. Though this setup often makes the inline-block the line's lowest element, obscuring space reserved for font descenders, adjusting the overflow reveals this space entirely.

p {
  margin: .5em;
  font: 32px/1.5 serif;
  color: #fff;
  background: #888;
}

span {
  display: inline-block;
  font: 12px/1 sans-serif;
  background: #fff;
  color: #000;
  padding: 2px;
  border: 1px solid green;
}

.ovh {
  overflow: hidden;
  border-color: red;
}

<p>Text with image <img src="http://via.placeholder.com/30x15"> and <span>two</span> <span>inline-block</span>s</p>

<p><img src="http://via.placeholder.com/30x15"> <span>only</span> <span>inline-blocks</span></p>

<p><img src="http://via.placeholder.com/30x15"> <span>regular</span>, the <span class="ovh">overflowed</span> trick</p>

Understanding inline formatting can be challenging. For further insights into its nuances and surprises, check out this article: .

A sensible guideline would be to avoid using display: inline-* solely for side effects unless you plan on incorporating the element within text. In the scenario described by OP, switching the inner span to display: block presents a straightforward solution without intricate line box calculations.

What is the reason for the presence of additional space below when using x-overflow:hidden?

Answer №1

Answer №2

Similar questions

HTML links remain enclosed in a box even after the code has been finalized

The mysterious case of the vanishing jQuery traversal box

Using Material-UI to add a pseudo class '::before' with component class properties

Dynamic visuals created with Jquery and Ajax

HTMLElement addition assignment failing due to whitespace issues

Looking to spice up your jQuery modal dialog with unique and varied styles?

Show the button only when the text is updated

Repurpose the identical popup window

Concealing the path of a file input in CSS

Implement automatic data replacement using PHP and MySQL triggers

Guidelines for crafting an intricate selector by utilizing mergeStyleSets and referencing a specific class

What is the best way to prevent right floated DIVs from interfering with each other's positioning, specifically within a specified space?

How to access bespoke attributes in Scene Builder using JavaFX?

Positioning the icon within the input field

Display a specific section of an image as the background in a div, with the image scaled and positioned perfectly

Designing websites using elements that float to the right in a responsive manner

Is it possible to swap images by clicking on them?

What is the best way to calculate the number of squares required to completely fill a browser window in real-time?

The file is definitely present, yet a 404 error is still showing up

Smoothly automate horizontal scrolling using JavaScript