4

Here's the complete source of an HTML page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head></head>
<body>
one<br>
two<br />
three<br></br>
four    
</body>
</html>

Can anyone explain why an extra blank line appears between the "three" and the "four" when I view the page in IE8 or chrome?

I thought standards were supposed to make all browsers look the same and as far as I can see this page conforms to the XHTML transitional standard

Josh Darnell
  • 11,304
  • 9
  • 38
  • 66
Andy
  • 10,412
  • 13
  • 70
  • 95

6 Answers6

8

Because the XHTML spec HTML Compatability Guidelines specify that br must should be self closing. Apparently Chrome and IE8 are not follwing the spec and closing the open one for you, thus creating a second line break.

Rob Stevenson-Leggett
  • 35,279
  • 21
  • 87
  • 141
  • The XHTML spec doesn't require any element to be self-closing. That is the HTML Compatibility Guidelines. – Quentin Feb 15 '11 at 17:10
  • Wow, thanks - I'd always thought that XHTML specified br must be self closing. – Rob Stevenson-Leggett Feb 15 '11 at 17:14
  • Chrome and IE8 are following the spec — the HTML spec. This is the problem with pretending XHTML is HTML. – Quentin Feb 15 '11 at 17:24
  • Thanks for this and to Alohci. I was really surprised to find this, and a bit shocked that even the latest standards have legacy stuff like this in. The reason my HTML comes out like this is because I am using ASP.NET to create a "br" element inside the control tree which seems like a perfectly reasonable thing to do. instead I'll just have to create a text node with the text "
    " inside it - how smelly :-(     – Andy Feb 16 '11 at 10:43
  • I'd use a Literal and set the text to
    -that's probably the cleanest way.     – Rob Stevenson-Leggett Feb 16 '11 at 11:05
8

Some good answers already, but just to point out that HTML5 actually specifies that <br></br> should be parsed as two <br> start tags when parsing as text/html.

See An end tag whose tag name is "br" in http://dev.w3.org/html5/spec/tokenization.html#parsing-main-inbody

Firefox 3.x only does this in quirks mode, but Firefox 4 does this in Standards mode as well.

Alohci
  • 78,296
  • 16
  • 112
  • 156
  • +1 For the references. However ... 'An end tag whose tag name is "br": Parse error. Act as if a start tag token with the tag name "br" had been seen. Ignore the end tag token.' -- I'm not reading it the same way :-/ –  Feb 15 '11 at 18:16
  • +1 ditto. @pst it means "replace `` with `
    ` then discard the ``", which basically means "interpret `` as `
    `". Thus the HTML code `
    ` *MUST* be interpreted as `

    `.     – Matty K Nov 22 '12 at 06:05
5

Although valid, this is highly unusual code. What is much more likely is developers mistakenly using <br> or </br> when they mean <br/>. For this reason most browsers will interpret both as <br/>.

fredley
  • 32,953
  • 42
  • 145
  • 236
  • I don't understand the "for this reason" bit. It seems most logical that `` would simply be ignored. (But are browsers even reasonable?) –  Feb 15 '11 at 18:13
  • A browser's job isn't to conform to standards, it is to display webpages. Often these will have errors, and a browser that breaks the rules to deal with these errors rather than failing is a better browser IMO. – fredley Feb 15 '11 at 18:22
  • I cannot agree. That thinking has, unfortunately, has led to the "mess" we're jut starting to come out of. It just seems that if `
    ` *was* a BR then any `` could/would just be ignored -- e.g. *point* of BR was open-tag only (contents of element are irrelevant). I am kind of disappointed this case has been left in HTML5.     –  Feb 16 '11 at 06:18
  • Interesting point, but I'd say that in this case, the chances of anyone using `
    ` are so slim (compared to the chance someone did it in error) that you'd piss off more people interpreting it as a single `
    ` than as two.     – fredley Feb 16 '11 at 09:44
  • the chances of anyone manually coding it as 2 separate tags are low, but (see my note above) I am using asp.net to generate a br element in the control tree. i guess you could argue it's a bug in asp.net but since there will be an increasing number of people using XML tools to generate XHTML web pages, I am definitely on the side of pst in this case. – Andy Feb 16 '11 at 10:52
3

The extra line between three and four is because there are two <br /> tags between them. The first one moves content onto the next line and the second one moves it one more line down. This is expected behaviour.

Edit Sorry, thought it was strict for the following.
Also, <br /> tags are empty tags and so, must be closed. Because of this, I don't think that <br> is technically xhtml compliant. It should be <br />.

Richard Marskell - Drackir
  • 13,080
  • 3
  • 33
  • 54
1

I.E appears to interpret
and both as "link break" and adds a like break for each.

DwB
  • 37,124
  • 11
  • 56
  • 82
1

In XHTML — they are the same — and if you serve the document as application/xhtml+xml there will be no difference in browsers (assuming the browser supports XHTML, which IE 8 and lower do not).

If you serve the document as text/html, it will be treated as HTML, not XHTML, and in HTML <br> is an element where the end tag is forbidden. If you include an explicit end tag then some browsers will error correct to assume that </br> is a <br> start tag.

There are various additional rules that must be followed if you are claiming your XHTML is text/html. These are described in the compatibility guidelines. This particular one is for elements that can never have content.

Serving as text/html was a hack intended to be a short term measure during the transition to XHTML proper. Various things (including lack of support from Microsoft) prevented this transition from ever finishing, and the HTML 5 movement has given up on the idea and moved back to optional and forbidden end tags (but adding in /> as syntactic sugar).

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • I'm loading the document from a local file in this case, but I tried adding the header line `` and it doesn't seem to have made any difference – Andy Feb 16 '11 at 10:58
  • Dealing with local files, browsers tend to care about file extensions. `.html` Vs. `.xhtml`. Browsers **never** care about the media type specified in meta http-equiv (they sometimes care about the charset, but never the media type). – Quentin Feb 16 '11 at 11:00