Span VS Div (Inline-Block)

Why does adding a span to an inline-block div change it's layout?

The alignment issue you're having is the expected result of using display: inline-block on your .button elements. Using inline-block elements basically makes the element act like a block element, but its bottom aligns as an inline element would. Take this for example:

<p>example example example <img src="something.jpg" /></p>

Which renders like this:

inline elements example

The image is inline with the paragraph. Notice that the bottom of the image aligns with the bottom of the text. This same thing is happening in your Fiddle – the bottom of the span text aligns with the bottom of the images (once you remove the relative positioning). You have inline elements inside inline-block elements, so the bottom alignment is naturally behaving like it would on inline elements.

Inline-block elements are extremely useful, but probably not in this scenario, where you have several distinct buttons, which are in themselves distinct elements. I would suggest doing this:

.button {
border: 1px outset;
background-color: #FACC43;
color: darkgreen;
display: block;
margin : 10px;
margin-right : 0px;
margin-bottom: 0px;
float:left;}

Make the buttons block elements by using display: block and float:left. They'll behave much more predictably as elements that are 30px x 30px on a common alignment.

If for whatever reason your really want to use inline-block, apply vertical-alignment: bottom to the .button style you currently have.

Both solutions I gave you will result in this:

Sample Image

What is the difference between HTML div and span elements?

  • div is a block element
  • span is an inline element.

This means that to use them semantically, divs should be used to wrap sections of a document, while spans should be used to wrap small portions of text, images, etc.

For example:

<div>This a large main division, with <span>a small bit</span> of spanned text!</div>

Note that it is illegal to place a block-level element within an inline element, so:

<div>Some <span>text that <div>I want</div> to mark</span> up</div>

...is illegal.


EDIT: As of HTML5, some block elements can be placed inside of some inline elements. See the MDN reference here for a pretty clear listing. The above is still illegal, as <span> only accepts phrasing content, and <div> is flow content.


You asked for some concrete examples, so is one taken from my bowling website, BowlSK:

<div id="header">  <div id="userbar">    Hi there, <span class="username">Chris Marasti-Georg</span> |    <a href="/edit-profile.html">Profile</a> |    <a href="https://www.bowlsk.com/_ah/logout?...">Sign out</a>  </div>  <h1><a href="/">Bowl<span class="sk">SK</span></a></h1></div>

Difference between div and span

There is two differences between div and span elements:

  • The div has display:block as default, while span has display:inline as default.
  • The div is a block element, and can contain block elements and inline elements, while span is an inline element and can only contain other inline elements.

Once you have applied the display:inline-block they behave the same.

When the HTML code is parsed, the style is not considered. While you can change the display style to make the elements behave the same, you still have to follow the rules in the HTML code.

This for example is valid:

<div>
<div>
<span></span>
</div>
<span></span>
</div>

This for example is invalid:

<span>
<div>
<span></span>
</div>
<div></div>
</span>

The browser will try to rearrange the elements in the invalid code, which usually means that it moves the div elements outside the span elements. As the HTML specification (prior to version 5) only told how correct code should be handled, each browser has its own way of dealing with incorrect code.

Why does overflow:hidden on an inline-block span/ make the following text a little bit lower?

Specifying overflow other than visible creates a new block formatting context, which does not have a baseline anymore, so it can't be aligned with the surrounding baseline.

You can fix up the alignment with vertical-align: bottom:

.s1 {
display: inline-block;
overflow: hidden;
vertical-align: bottom;
}
<span class='s1'>Hello</span> world (why am I a litter lower than "Hello"?)

Difference between DIV as-is and a SPAN with display:block

Yes they are different.

Even though you style a span with display: block you still can't put block-level elements inside it:

<div><p>correct</p></div>
<span style="display: block;"><p>wrong</p></span>

The (X)HTML still has to obey the (X)HTML DTD (whichever one you use), no matter how the CSS alters things.

How to display inline span inside div ?

<span> is inline by default, and <div> is block by default. But in your CSS you're overwriting those default styles with display: block (in #main, etc). If you want them to resize as the screen does, and be inline, a better way overall is just to use flexbox:

HTML:

<div class="whole">
<span id="main">
<p></p>
</span>
<span id="second-main">
<p></p>
</span>
<span id="third-main">
<p></p>
</span>
<span id="fourth-main">
<p></p>
</span>
<span id="fifth-main">
<p></p>
</span>
</div>

CSS:

body {
margin: 0;
padding: 0;
border: 0;
font: inherit;
font-size: 100%;
vertical-align: baseline;
overflow: scroll;
}

.whole {
width: 100%;
height: 400px;
-ms-display: flexbox;
display: flex;
margin: 0px 0px 0px 240px;
}

.whole > span {
-ms-flex: 1;
flex: 1;
height: 100%;
}

#main {
background-color: #212121;
}

#second-main {
background-color: #424242;
}

#third-main {
background-color: #616161;
}

#fourth-main {
background-color: #757575;
}

(you were also missing a closing CSS bracket for body, and your font-size: 100% was being overwritten in the very next line by a shorthand font rule)

Here is a working fiddle: https://jsfiddle.net/tceqx58x/

Why does inline-block behave differently inside a p vs inside a div?

This is the classic case of flow elements not belonging in a p element manifesting in two interesting ways. To preface: a p element cannot contain flow elements, including table. See the spec. Such flow elements are placed as following siblings of the p element instead. So:

  1. <p><table></table></p> is really <p></p><table></table><p></p>, and
  2. <p><span><table></table></span></p> is really <p><span></span></p><table></table><p></p>.

(The reason the stray </p> end tag is matched with a new <p> start tag in both cases is explained in Why does a stray </p> end tag generate an empty paragraph?)

You already know the expected behavior when the containing element is a div, so we'll just focus on Test1 and Test3 with the p element.

In Test1, the inline-block element is preceded by a line break because it's in a new paragraph that follows the p. (Note that displaying a table element as inline-block actually simply causes that table element to generate an anonymous table box to contain its descendants — which is why the table layout appears to be preserved.) The following "Test1" text flows alongside it because it's in the same anonymous paragraph and on the same line as the inline-block.

Note that the paragraph generated by matching the stray </p> end tag with its own start tag does not actually enclose that text. This behavior is described in the same question I link to above.

In Test3, the p element is able to contain the inline-block as it is a span element. However, the p element ends right where the table element starts, so the inline-block span is fully enclosed within the p element and does not contain the table (in fact, it's completely empty). So the table appears on its own line, its layout intact, and the following "Test3" text appears on yet another line following the table, because tables are block-level by default and as such never appear on the same line as any other elements (including inlines).

Also note that all of this behavior is very well-defined (in the respective specifications), and that while a p element cannot contain a table element, everything in Test1 leading up to but not including the </p> end tag is technically valid HTML. It just doesn't behave as you might have expected.



Related Topics



Leave a reply



Submit