Why does inline-block work differently when overflow: hidden is applied? - html

I wanted to display two <div> elements that have width and height side-by-side. I applied inline-block to the <div>s, but the position of the left element is strange:
HTML:
<body>
<div id="myDivTag">content</div>
<div id="map-canvas">for google map API</div>
</body>
CSS:
#myDivTag, #map-canvas {
display: inline-block;
height: 95%;
width: 49%;
z-index: 0;
}
The only difference between the two elements is the overflow: hidden option. When I apply overflow: hidden to #myDivTag, it works normally, but I don't know why. I think it has nothing to do with the overflow property. But my thought is clearly wrong. Why?

By default inline boxes in a line are vertically aligned by their baselines (since the default value of the vertical-align property is baseline) and the baseline of inline-blocks depends on the value of the overflow property. If the value of the overflow property on an inline-block is visible, then the baseline of this inline-block is the baseline of its last line, but if the overflow property has another value (for example hidden), then its baseline is the bottom margin edge.
The documentation says
The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge.
I also suggest you reading this great article in order to understand completely the vertical alignment of inline stuff.

Add vertical-align to your css and it should work:
#myDivTag, #map-canvas {
display: inline-block;
vertical-align:top;
height: 95%;
width: 49%;
z-index: 0;
}

Related

Understand inline-element, vertical-align, line-box and line-height

vertical-align:bottom, means the bottom inline-box matches the bottom of its line-box, so in my case, the inline-box of span2 is the green one, whose line-height is 100px, inherited from its parent. Its line-box is the black one, also has line-height:100px. so they are bottom aligned.
see pic:
I've already learned that:
1.vertical-align works only for inline/inline-block element
2.vertical-align is based on line-height, not the height of its container!
3.in a line-box, its line-height is the line-height of the inline box(in my opinion, its either inline-element or inline-block element) which has the highest line-height. like pic:
Everything works fine on inline-block element, but it seems that there is a problem with inline-element.
explanation:
parent: height:200px, line-height;100px;
div.child:inline-block, vertical-align bottom;
span1: inline, line-height:inherit from parent, which is 100px
span2: inline, line-height:inherit from parent, which is 100px, vertical align: bottom.
To me, the line-box for the code below is like this(you can run the code first):
strange behavior for span2 !!! and it becomes even stranger if I set its vertical-align to text-top or text-bottom
another thing which I found interesting is, if I set display of span to inline block or set the line-height of span to normal (which is 1.16 of its font-size), everything works fine.
can someone explain it? Thanks
div.parent {
width: 300px;
background-color: coral;
/*key-part*/
height: 200px;
line-height: 100px;
}
div.child {
width: 50px;
height: 50px;
background-color: yellow;
/*key-part*/
display: inline-block;
vertical-align: bottom;
line-height: normal;
}
.span1 {
background-color: white;
font-size: 50px;
/*key-part*/
vertical-align: middle;
}
.span2 {
background-color: green;
font-size: 12px;
/*key-part*/
vertical-align: top;
}
<body>
<div class="parent">
<div class="child">inline-block div</div>
<span class="span1">Text1</span>
<span class="span2">Text2</span>
</div>
</body>
Let's try to cover it step by step:
1.vertical-align works only for inline/inline-block element
Vertical-align applies to inline-level elements. That's currently: inline, inline-block, inline-table, inline-flex, inline-grid. Vertical-align is also used, but in a different way, for table cells.
2.vertical-align is based on line-height, not the height of its container!
Except for table cells, correct.
3.in a line-box, its line-height is the line-height of the inline box(in my opinion, its either inline-element or inline-block element) which has the highest line-height.
That's correct for simple cases but not for complex alignment ones. A better approximation goes something like this. Remove all the elements that are vertical-align:top and vertical-align:bottom. Align all the other elements so that their vertical alignment lines are level with one another. Call the box that contains them from the highest top of the aligned elements to the lowest bottom of the aligned elements the proto-line box. The actual height of the line box is then the maximum of the height of the proto-line box and all of the heights of the elements that are aligned top and bottom.
Now the relevant part of the specification for your question is this:
... for inline non-replaced elements, the box used for alignment is the box whose height is the 'line-height' (containing the box's glyphs and the half-leading on each side, see above). For all other elements, the box used for alignment is the margin box.
So for the span2, the green background area is the box's glyphs and above that are each glyph's upper half-leading, a value which is taken from the 100px line-height inherited from the container block element. It's the top of these half-leadings that aligns with the top of the line-box, not the top of the green background area.
On the other hand, the inline-block div aligns to the bottom of the line box, by the bottom of its bottom margin, and not by any half-leading.

Do block elements ignore floating elements?

W3C states that:
Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float did not exist. However, the current and subsequent line boxes created next to the float are shortened as necessary to make room for the margin box of the float.
This work as expected with divs:
#a
{
width: 100px;
height: 100px;
background-color: blue;
float: left;
}
#b
{
width: 200px;
height: 200px;
display: block;
border: 1px solid black;
background-color: red;
}
<body>
<div id=a></div>
<div id=b></div>
</body>
Here the red div is block-level element, therefore it's ignoring the floating one. (if I changed red one to display: inline-block it would appear next to floating one)
But, if I apply display: block to an image ,it won't ignore the floating div, Why?
#a
{
width: 100px;
height: 100px;
background-color: blue;
float: left;
}
#b
{
width: 200px;
height: 200px;
display: block;
border: 1px solid black;
}
<body>
<div id=a></div>
<img id=b src="https://www.gravatar.com/avatar/5cb44dcd4ebddfea3ede8c6d46b02795?s=328&d=identicon&r=PG&f=1">
</body>
Several paragraphs after the one you quote, the spec says:
The border box of a table, a block-level replaced element, or an element in the normal flow that establishes a new block formatting context (such as an element with 'overflow' other than 'visible') must not overlap the margin box of any floats in the same block formatting context as the element itself.
Although you've applied display: block to your image, being an image it's a replaced element, and therefore the float cannot intrude into its bounds.
Only non-replaced block boxes that don't establish block formatting contexts and are in the same flow as a float may ignore the float.1 A block-level replaced element is not a block box, because a replaced element cannot be a block container box.2
1 You're probably thinking, that's a ridiculously specific statement, and it is. It's why terms like "block element" are considered extremely vague in CSS parlance. Then again, it doesn't help that CSS itself defines almost equally vague terms like "block box" to specifically refer to boxes that are both block-level boxes and block container boxes.
2 This does imply that "non-replaced block box" is somewhat of a tautology, which reinforces just how ridiculously specific that statement is.
W3C
These are the two things that stuck out to me when viewing the W3C. It's considering it as a line box.
A floated box is shifted to the left or right until its outer edge touches the containing block edge or the outer edge of another float. If there is a line box, the outer top of the floated box is aligned with the top of the current line box.
A line box is next to a float when there exists a vertical position that satisfies all of these four conditions: (a) at or below the top of the line box, (b) at or above the bottom of the line box, (c) below the top margin edge of the float, and (d) above the bottom margin edge of the float.

Why does x-overflow:hidden cause extra space below?

I have two spans inside each other. On the inner span I have overflow-x:hidden. This causes extra space below the inner span. Why?
<span style="" class="yavbc-color-tip"><span style="">Some text</span></span>
Fiddle: http://jsfiddle.net/U92ue/
Note: I have only tested in latest Chrome.
Visual formatting model - 9.4.1 Block formatting contexts
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' (except when that value has been propagated to the viewport) establish new block formatting contexts for their contents.
More specifically, a new block formatting context is established when the overflow property is changed. By default, an element's vertical-align property value is baseline. You can simply change this to something like top in order to fix this.
Updated Example
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;
}
Notice this doesn't happen when the element's display isn't changed to inline-block? It doesn't occur with inline elements - example demonstrating this.
Despite the above quote in the accepted answer, this behavior has nothing to do with Block Formatting Context and with "block" part of the inline-block value at all. It's all about the "inline" part of it.
All inline-* elements participate in the Inline Formatting Context. That means, they are placed inside the so called "line boxes" along with text and other inline-level elements. These elements and text are aligned with each other, so the height of each line box is calculated from the top of the highest element to the bottom of the lowest one.
By default, inline-level elements are aligned with the baseline of their fonts (see first line in the example below). Even if parent element has no actual text, the position of the baseline and the minimal height of the line box are calculated as if it had text (the spec calls this "imaginary" text the "strut" of the element). That's why the line box always has some space above the baseline (for the font ascenders and diacritics) and below it (for the font descenders) — see the second line of the example.
The tricky part for the inline-block elements is that overflow property changes what is considered the baseline for these elements (end of section 10.8.1 of the spec):
The baseline of an 'inline-block' is the baseline of its last line box in the normal flow, unless it has either no in-flow line boxes or if its 'overflow' property has a computed value other than 'visible', in which case the baseline is the bottom margin edge.
So, while technically the space below the baseline is always reserved, with default overflow: visible, the inline-block element is placed so that its text's baseline is aligned with the parent baseline, and its bottom part is moved below it. In many cases this makes this inline-block the lowest element in the line, so the space reserved for font descenders is not visible. However, changing the overflow value makes the whole element render above the baseline (like an <img> element), making all this space visible.
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>
In general, inline formatting is tricky. You can find a good explanation of some of its gotchas and surprises in this article: http://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align.
I'd say that a good rule of thumb would be not using display: inline-* for its side effects, if you aren't really going to place the element inside the text. In the OPs example, the best solution would be to use display: block for the inner span, that doesn't involve any "magic" like line box calculation.

Why my inline-block divs are not aligned when only one of them has text? [duplicate]

This question already has answers here:
Why is this inline-block element pushed downward?
(8 answers)
Closed 8 years ago.
Live page here.
Given this HTML page:
section[role=main] {
margin: 1em;
width: 95%;
border: 1px solid #999;
}
section[role=main] article {
width: 40%;
height: 180px;
margin: 1em;
display: inline-block;
border: 1px solid black;
}
<section role="main">
<article>Java</article>
<article></article>
</section>
<section role="main">
<article>Java</article>
<article>JavaScript</article>
</section>
I expect both of my articles to be aligned, but as it can be seen in the screenshot below, only when both of my articles have text the <article> elements are center aligned:
Any ideas what is causing this behavior and how can it be fixed?
Adding:
vertical-align: bottom;
To your second rule should make it work. Apparently, inline-blocks with no text are rendered as inline-images or something else, and the vertical-align of these elements are incorrect, so forcing them to be aligned to bottom fixes the issue.
Source: inline-block element with no text renders differently
This is the consequence of the "baseline" vertical alignment in CSS. From the CSS 2.1 spec, section 10.8 Line height calculations: the 'line-height' and 'vertical-align' properties
baseline
Align the baseline of the box with the baseline of the parent box. If the box
does not have a baseline, align the bottom margin edge with the parent's baseline. (my emphasis)
Because the default alignment for the inline-blocks is "baseline", unless it is overridden, this rule applies. When text is put in the inline-block, that text will create a baseline for the inline-block and the first (non-bolded) sentence applies.
When there is no text in the inline-block, then it has no baseline and so the second (bolded) sentence applies.
In the JSFiddle here: http://jsfiddle.net/WjCb9/1/ I have removed from your example the margin:1em which was creating (at least for me) a misleading illusion, and added the text baseline to show where the baseline of the containing box is. The baseline is along the bottom of the word "baseline", so you can see that the empty inline-block has its bottom margin edge aligned with the parent's baseline as required by the CSS rule above.
clone of this
Add vertical-align to article:
section[role=main] article {
...
vertical-align: middle;
}
http://jsbin.com/oqodol/6/edit
The inline-block elements are positioned by the text-align of their parent.
If there is no text within the block, there is nothing to align.
You can solve this problem by using display: block; and floats, or my suggestion is to insert a non-breaking, zero-width space with pseudo elements:
section[role=main] article:before {
content: "\2060";
}
Demo

Block-level elements within display: inline-block

I'm trying to put some (vertically-stacked) display:block elements within a display:inline-block element. According to the CSS specification, the inline-block element should be a containing block, so it can have display:block elements within it and those should not affect the rest of the layout.
However, the display:block elements inside the display:inline-block elements disrupt the rest of the page; so does having nothing at all within the inline-block, or even a basic element like a paragraph; only simple text avoids disruption of the rest of the page (by disruption I mean shifting other divs down, e.g. in this case the left red block moves down a line and has a blank white space above it). I'm using Firefox 3.0.6.
<html><head><style type="text/css">
#left {
display: inline-block;
background: red;
width: 20%;
height: 100%;
}
#right {
display: inline-block;
background: green;
width: 80%;
height: 100%;
}
</style></head><body>
<div id="left">Left</div><div id="right">Right</div>
</body></html>
The above shows as two panes, left red, right green, as expected. If I change "Right" to
<p>Right</p>
or remove it entirely, or (as I want to do) replace it with a couple of divs, I get the bad formatting.
Is this a Firefox bug, or am I doing something wrong, or are my expectations incorrect? (FWIW, IE 7 mangles them all equally, as if it doesn't understand inline-block; doesn't matter, this is an internal app. and I'm only using Firefox). I may be able to get the layout I want using float/margin, but I'd prefer not to have to do that.
Well display: inline-block can be a bit tricky to get cross-browser. It will require at minimum, a few hacks and, for Firefox 2, potentially an extra element.
CSS
.inlineBlock { display: -moz-inline-stack; display: inline-block; zoom: 1; *display: inline; }
display: -moz-inline-stack is for Firefox 2. All the immediate children will need to have display: block or otherwise be block level elements. Note if you need your inline-block element to shrink wrap I think you can use display: -moz-inline-box instead.
zoom: 1 gives hasLayout to the element (for IE 7 and below). Part 1 of the hack needed for IE7 and below compatibilty.
**display: inline* is a hack second part of the hack needed for IE7 and below compatibility.
I occasionally need to add overflow: hidden for IE compatibility as well.
For your specific situation i think what you need is:
<html><head><style type="text/css">
#left {
display: inline-block;
background: red;
width: 20%;
height: 100%;
vertical-align: top;
}
#right {
display: inline-block;
background: green;
width: 80%;
height: 100%;
vertical-align: top;
}
</style></head><body>
<div id="left">Left</div><div id="right"><p>Right</p><p>Right 2</p></div>
</body></html>
I get the bad formatting.
You are being bitten by margin collapsing, a CSS ‘cleverness’ which is a pain as often as it is a boon. The margin of the <p> collapses outwards to become a top margin on the inline-block; this then behaves as a margin would on an ‘inline’ element would, pushing the vertical-alignment of the text line out.
You can stop it happening by removing the margins from ‘p’ elements and using padding instead. Alternatively place a non-empty element with no top margin at the top of the block and one with no bottom margin at the bottom.
Is this a Firefox bug
I think possibly yes, according to the spec's:
Margins of inline-block elements do not collapse (not even with their in-flow children).
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.
visual rendering model