So basically I came across this problem whats the difference between Block-Level and Inline Elements was.
And the difference is that a Block-Level is for example a <p>Texttexttexttext</p> and a inline element could be for example the bold inside the paragraph <p>textext<b>BOLD</b>texttext</p>?
I get it like 50%, so far in my “webdesign career” I’ve only used display:inline to inline my listed items in a unorderd list. I looked at Ben Hunts tutorial and he gave some examples but I’m still confused.
For example. In wich situations would I be using display:block?
And when would I be using display:inline except for inlining listed items?
And in his tutorial you can see in the beginning what he describes about block:
“Block
Takes up the full width available, with a new line before and after (display:block;)”
I don’t understand what he mean by “with a new line before and after”
It’s a good guide, and most of them are. But still, I’m just not sure where and why to use them except fo inlining unlisted items, but I guess along the way as I build websites I will encounter some problem with this, and then Ill ask for help and maybe Ill get it then.
<!-- width has no effect -->
<span style='text-align:center; background-color:#cfc; width:42em'>
This is a test to see if it works
</span>
<br />
<!-- width has no effect -->
<span style='text-align:center; background-color:#cfc; display:inline; width:42em;'>
This is a test to see if it works
</span>
<br />
<!-- Yes we have a width -->
<span style='text-align:center; background-color:#cfc; width:42em; display:inline-block; '>
This is a test to see if it works
</span>
I get it a little more, but I think I have to work more with text since I have now mainly focused on the design but, more examples, more I understand, and your example took me “a grade higher”.
You mean stylewise? I’m not sure if every browser does that, but yeah in general nobody puts default margins or padding on divs.
But what Kevin has to keep in mind is how divs vs p’s are displayed by default should never be the reason you choose one over the other. Instead you choose them by what they are meant to represent, in your data/content.
And don’t worry, Kevin: you kinda absorb a lot of this stuff over time. In fact, you can’t stop it. It’s already seeping into you
John showed a big difference between regular inlines and static blocks (that inlines generally can’t be given dimensions, and don’t create “newlines” (don’t force the next element to sit underneath them). But as you look further into blocks, you’ll see more types: positioned, inline-block, float, table… these all follow different rules for display than static blocks.
Most of the time, you don’t need to put display:block; or display:inline; in the stylesheet, because it’s the default setting. So any <p>, <div>, <li>, <h1> etc is automatically given display:block; unless you tell it to use something else, and any <b>, <span>, <a> etc is automatically given display:inline; unless you tell it to use something else.
The main thing you need to know about block and inline is that elements that are (by default) inline must not contain elements that are (by default) block … no matter what you have defined in the CSS. So, for example, the following code is never allowed:
<a href="home.htm"><h1>Welcome!</h1></a>
because you can’t have a block element inside an inline element. It doesn’t matter if you have also got
a {display:block;}
because <a> is still a block element, even when you change the display properties for it.
Some block elements such as <p> or <h1> can only contain text or inline elements; others such as <div> or <li> can contain either text/inline elements or more block elements.
Another angle: a block element, by default, fills out all horizontal space available and other elements have to sit above or below it, whereas an inline element is designed to sit ‘inline’, or in other words, sit alongside other elements. So an <a> is an inline element, for example, as you don’t want a link to suddenly site on its own line, but to mix in nicely with a paragraph. Also, when you insert an image, by default it sits next to other elements.
You can change the default behavior of an element via CSS, such as setting a <li> to display: inline or an <a> to display: block for layout purposes, though.
Because inline elements have to sit alongside other elements, you can’t apply styles some styles as freely to them as to block elements. So things like top margin and padding don’t have to much effect on inline elements. To help with this, CSS also offers other options like display: inline-block, allowing an element to sit inline with other elements but also have top/bottom margin and padding etc.
A problem I’m seeing with a LOT of this discussion is the lines being blurred between HTML “level” and CSS “display” – while the display state on MOST block level and MOST inline-level elements line up with their CSS display state, that is NOT what they mean and they are NOT the same thing!
HTML Block level containers exist to break flow text into subsections – that’s it. A heading section, a paragraph section. Inline-level containers exist to say what small elements are (ABBR, STRONG, EM, SAMP, KBD for example), add behaviors to those elements (A), or provide hooks for style that we lack a proper semantic tag for (SPAN, B, I). Inlines are ‘inline with flow’, blocks ‘break flow’ dividing it up, this is why a block level element can’t go inside inline-level. It’s part of making sure we have logical document structures; NOT that most people bother even trying to use any of the tags properly which is why you still see people sleazing out HTML 3.2 with a 4 tranny doctype on it, and why HTML5 is like a trip in the wayback machine to 1998 so far as improvements go. GOD FORBID we have rules and be expected to follow them.
The CSS ‘display’ property is JUST presentation for whatever device you are targeting, and has absolutely NOTHING to do with HTML Level apart from the default appearance.
… and if you are choosing your tags based on their default appearance, you are most likely choosing the wrong tags! That’s not what HTML is for or how it’s supposed to WORK, because HTML is NOT about what it looks like – it’s about saying what things are and letting the user agent (browser) best figure out how to show it within the limitations of the target device, be it a printer, a teletype, a handheld screen, a desktop screen, whatever.