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

How can you use PHP to dynamically create a table with custom row sizes?

Tips on invoking a factory method from a different service method in AngularJS

Prevent users from saving changes made to dropdown menu values (as well as other user-inputted content) using Inspect Element on the website before it

Div element to animate and vanish in a flash

Using Javascript to Treat an HTML Document as a String

When a link is clicked, submit a form and send it to several email addresses simultaneously

Creating a cutoff with CSS: A step-by-step guide

Utilizing XPath in Selenium: Extracting text from elements based on their adjacent elements

How to Insert a Background Image into Advanced Custom Fields (ACF) using CSS

Moving specified data from one interactive table to another interactive table

Loading tab content on click using jQuery

Assistance required: The database is not found upon page reload. How can this be resolved?

Encountered an error while trying to download a PDF document in React

What is causing Microsoft Edge to highlight this span and behave as though it's a hyperlink?

Does text disappear when hovered over in CSS?

"PHP MySQL news error" - An unexpected error occurred

Tips for creating semi-circular shapes using CSS gradients

What impact do varying screen sizes have on the width of CSS?

What is the reason behind the Chrome icon flickering momentarily while loading certain web pages?

Show me all the posts from the database in a single row