<br><br> versus </div><div>

i think it is true that


will make the two lines one above the other in the HTML rendering.
and then with


and extra black line is added. so let’s say we establish that

rule #1: Two consecutive line-breaks will give an extra blank line

also, is it true that the blank line is taken to be 1em tall, which is line-height?

now however, for the case of


since it is generally true that </div> will generate a line break, and that <div> will always start a line break, so there are two consecutive breaks </div><div> right there, but it doesn’t generate an extra line break, and that would contradict rule #1 above.

I couldn’t find any rule to discuss difference between <br> and <div> in the HTML 4.01 spec. Is it true that they are of different nature of “break”? It may appear that <br> is breaking with inline flow, and break with some empty content, but <div> just means “make sure it starts on new line”, and if it is already on a new line, then don’t worry - don’t break again and just do nothing, as in:


which will show them just one right on top of the other.

since this is related to both design layout and to HTML, I think I will post to both CSS and HTML discussion.

having said that, it is strange that

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

will not generate 3 blank lines in IE 7, Firefox 2, and Safari 3 in 4.01 strict mode. Note that there is a space between <div> and </div>. So we can’t really have a div that only contain a space and have it rendered as an empty line? is it just a pragmatic exception rule?

Note however, that


does give 3 blank lines in IE7, Firefox 2, and Safari 3 in 4.01 strict mode.

</div> doesn’t generate a line break, it’s just that divs by default are block-level elements, and as such will sit one below the other.

And using empty divs to generate whitespace is a really, really pointless thing to do.

I think you need to familiarise yourself a little bit more with div and [URL=“http://www.w3schools.com/tags/tag_br.asp”]br (and maybe even a few more like [URL=“http://www.w3schools.com/tags/tag_span.asp”]span and [URL=“http://www.w3schools.com/tags/tag_p.asp”]p), and what their actual use case is.

the question here is, what is the actual rule. i can imagine these people a few hundred years ago would say, “what’s the point of asking why an apple will fall to the ground? should it fly up instead? what’s your point?” and that’s just brilliant.

You can read up on the rules in the specifications, for example HTML 4.01.

Your analogy doesn’t work, as the web and everything associated with it was created by man and man created the rules for it, no god or flying spaghetti monster was involved here.

The actual rule is that HTML doesn’t specify what should happen with extra white space characters, it leaves it up to the browsers to decide. Divs are just block-level elements - they take up a line.

However, browsers don’t render extra whitespace. They will render ‘a_____________________b’ the same as ‘a_b’ (imagining that _ is a space character) (exactly the same as I’ve just found out these forums will do if you try to type ‘a______________________b’ >.>).

A non-breaking space (the   character) is not ordinary whitespace. It’s designed to be rendered where whitespace will not (HTML code of many moons ago used to be full of        to indent text).

So if there’s nothing but normal whitespace in a div, the div has no real content and is empty, and as such will be rendered as empty. Fifteen empty divs will not add any extra whitespace to your page, other than useless markup. The non-breaking space, however, is classified as content, and will get rendered.

analogy is NEVER the same. it is only to describe, not to prove. did you learn that in university? or did you go to a university?

maybe it is just an exception that the browsers are doing it this way. There is a difference between “extra white space” or “the only white space”. For example, “helloworld” is not the same as “hello world”. The space is not “extra white space” but is “the only white space”. So in the case of <div> </div> that space in the middle is not “extra white space” but is “the only white space” and can be honored. It is just that the browsers decide to not honor it in this case.

and what is the difference between invented by man or whether it is a nature phenomenon? So one can be discussed for what the rule might be, and the other one cannot be discussed for what the rule might be? Which one can be discussed and which one cannot, according to your high IQ?

Now you’re just arguing for the sake of arguing. It’s an exception that every browser does things the same way? Exception to what? Your way?

exception to the rule that a single space is honored, but extra white space in addition to the exisitng white space is ignore.

A <br> denotes a line break. It should only be used when the line break has semantic value, such as in poetry, song lyrics, postal addresses, etc. I can’t think of a single case where <br><br> would be semantically correct.

A <div> is a semantically neutral, generic block-level element. It has no intrinsic height, so five empty divs won’t create any vertical space (5×0=0).

Neither <br> nor <div></div> (or any other HTML element) should ever be used to create space between other elements. That’s a presentational matter and belongs firmly in the realm of CSS (preferably using the margin properties).

Yes, this guy argues just for the sake of it. This’ll be the second thread that I unsubscribe

There’s a huge difference between created by man and a natural phenomenon. In fact the difference is so large that you analogy doesn’t make sense at all. If you don’t know the difference, maybe you need to go back to school.

And as I said, I’ll unsubscribe from this thread, so you won’t get an answer from me, so don’t even bother replying.

A new question for the original poster along the same lines as the original question (ie almost as meaningless). Is it better to have a slice of toast or a rusty fish hook as the main singer at a concert?

Oh definitely the slice of toast. Toast is lekker.

The reason “hello world” keeps the single white space is because there’s only one. This is a holdover from old coding days, and some word processors. However, any extra white space (more spacebars) collapse. This is a rule; it’s hard-coded somewhere that any whitespaces more than one (exception & nbsp; because it’s an actual character) are collapsed.

Div has no whitespace at all, actually. So it’s not like the browser is doing anything wrong by rendering <div></div><div></div><div></div> as nothing. There’s nothing there. At least when you have text (which is inline) and you hit the spacebar once, there’s a height in there (plus it’s inside an element-- notice that any spaces or returns you hit in your HTML editor do not show up on your page either, except when IE has a bug). <div></div> is nothing. It’s not a character, or a box, or anything. It’s as if you never typed it, and that’s per the spec. Empty elements do not render unless they are of a special type.

The fact that whitespace collapses is normal, and if you need it to show, you actually need a special tag to stop the browser from collapsing it, like <pre>.

And so what is the real difference between br br and div div? br is a character whose sole purpose is to make a line break. Div is simply a type of milieu-friendly plastic that wraps things and tells the browser “Everything inside has been grouped together in a box.” That’s all.

I’m thinking because it’s a block element and a space by itself doesn’t count as content.
I’ve noticed a difference in honouring spaces in some inlines. Not spans, but with <a>s I’ve seen it. I sometimes want an empty <a href=“#”> </a> for fake image maps. I found (at least in FF, I didn’t test in anyone else), if I didn’t stick a spacebar-generated space between the tags, the browser collapsed the whole thing and didn’t show anything. When I put a space in, I could click.

OK - Now all calm down a bit and treat each other will a little more respect.

In answer to the original question as Tommy said a div is a neutral element and has no intrinsic styling so produces nothing but a line feed at the end of the line when wrapped around any content. (If divs had margins then they would still collapse to one margin if they were empty elements.)

If the divs are all empty then there is nothing on the page at all.

A break will insert a line-height space between elements and is defined by the UA in such a way as not to collapse its height when successive breaks are used. However if we address a few properties that we can guess the UA has set for the break element then we can make then generate no space at all in most browsers.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Untitled Document</title>
<style type="text/css">
p{border:1px solid red}
br {
    display:block;/* this needed for Firefox */

<h1>Break Test</h1>
<h2>IE, Firefox and  Opera no gaps between lines but Safari still show the breaks as having some height.</h2>
<p>test - one break between items<br />test<br />test<br />test<br />test<br />test<br />test<br /></p>
<p>test - two breaks between items<br /><br />test<br /><br />test<br /><br />test<br /><br />test<br /><br />test<br /><br />test<br /><br /></p>
<p>test - three breaks between items<br /><br /><br />test<br /><br /><br />test<br /><br /><br />test<br /><br /><br />test<br /><br /><br />test<br /><br /><br />test<br /><br /><br /></p>

<p>10 breaks between this line<br /><br /><br /><br /><br /><br /><br /><br /><br /><br />and this line</p>


In all the browsers I’ve tested except Safari the height of the break is now collapsed to zero.

This is one of the reasons you shouldn’t use breaks just to make space because its very difficult to control their height in a cross browser way and means your layout can’t be controlled from the stylesheet.

This is also one of the reasons you shouldn’t use a break as your clearing element to clear floats with clear:both applied as you will get a line-break gap in Safari.

As already said above breaks should only be used in the correct semantic context and not just to make room on a page.

Answers from Tommy and Paul made a lot of sense. So the point I take from them is that <br> has semantic value, to actually break the line and shift to the next available position vertically by 1em. And it carries a “meaning” that the content has a line break or empty line such as in a postal address, or in a poem, such as 3 line breaks to indicate hesitation between writing.

And it is also confirmed that <div> will just make sure it is already on a new line. If it already is, it won’t break it again, like the case


will make sure the block element has vertical break, but


in this case the <div> will not generate an extra break, because it is already on a new vertical position.

the idea that <div> and <span> are semantically neutral is quite important in HTML and CSS, that <p> is like <div> except it means a paragraph in a document, and <strong> is like a <span> except it means emphasized content.

So if we make <p> not to have line breaks above and below, or <br> not to break the line, then it is against the semantics of the element, as a common paragraph usage is supposed to have line breaks before and after.

However, would it be true that <div> and <span> still have one semantic meaning, and that’s <div> is supposed mean vertically stacked items, and <span> is to mean flowing inline kind of element. The idea of “flowing element vs new section element” does carry one meaning.

By the way, it is by asking questions like these a few months ago that I found out about collapsing margins, the box model difference in quirks mode between IE and Firefox, and why many experienced developers get confused by vertical-align:middle and thought it doesn’t work. And there are people who will step in and tell you it is meaningless to ask these questions.

:slight_smile: :slight_smile: :slight_smile:

The vertical space will be equal to the computed value of line-height, which usually isn’t exactly the same as 1em, but you’re basically right. Three successive line breaks don’t make semantic sense at all, in my opinion. Hesitation is traditionally expressed with a horizontal ellipsis (…).

Yes, a block-level element will by default have an implict line break before or after. You can’t have two block-level elements side by side without using some CSS (or deprecated presentational attributes).

No, you’re comparing apples to oranges here. The semantics of the paragraph or line break cannot be changed with CSS. You’re only affecting the presentation. This may be detrimental to usability in some cases, while actually improving usability in other cases (like styling a <ul> as a horizontal menu bar).

Similarly, using display:block for an <a> tag only changes its presentation, not its semantics. It doesn’t alter the syntactic rules of HTML, which are set in the DTD, so you can’t nest an <h1> inside a link even if you make the link generate a block-level box.

This also hints at a confusion about presentation vs semantics. The semantic difference is that <div> is a block-level container while <span> is an inline element. They’re both semantically neutral, i.e., infer no particular meaning about their contents.

There’s a need for a neutral element on both levels, since the syntactic rules of HTML will only allow one or the other in some contexts. For instance, if you want a neutral element as an immediate child of body or a form, it has to be block-level (in the Strict DTD). But if you want a neutral element as part of a paragraph it has to be inline-level.

That a <div> will cause a line break is secondary; it’s an effect rather than the cause.