641239 - library.gnome.org - Double line breaks on <br></br> because HTML5 unified quirks/standards behaviors

Status: RESOLVED INVALID

(Web Compatibility :: Site Reports, defect)

Description

[Dieter Verfaillie]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

The Synopsis section of http://library.gnome.org/devel/pygtk/2.22/class-gtkwidget.html
(or any other class in pygtk's reference documentation) is rendered
incorrectly.

Reproducible: Always

Comment 1

[Dieter Verfaillie]

Attachment: Result with Firefox 3.6.15

Comment 2

[Dieter Verfaillie]

Attachment: Result with Firefox 4.0

Comment 3

[Jo Hermans]

The website uses different code for Firefox 3.6 as for Firefox 4.0 :

3.6 :

<code class="methodsynopsis">    def <span class="methodname"><a href="class-gtkwidget.html#method-gtkwidget--get-allocation" class="link" title="gtk.Widget.get_allocation">get_allocation</a></span>(<span class="methodparam"></span>)</code><br>

4.0 :

<code class="methodsynopsis">    def <span class="methodname"><a href="class-gtkwidget.html#method-gtkwidget--get-allocation" class="link" title="gtk.Widget.get_allocation">get_allocation</a></span>(<span class="methodparam"></span>)</code><br><br>

There's an extra <br> at the end, which causes the empty line.

Comment 4

[Dieter Verfaillie]

That's strange. I get:

<code class="methodsynopsis">    def <span class="methodname"><a href="class-gtkwidget.html#method-gtkwidget--get-allocation" class="link" title="gtk.Widget.get_allocation">get_allocation</a></span>(<span class="methodparam"></span>)</code><br></br>

with Firefox 3.6 (both windows XP and Ubuntu 10.10) and Firefox 4 on Windows XP.

Note that's a <br></br> and not 2x <br>

Comment 5

[Jo Hermans]

I double checked (after clearing the cache, and there is really a single <br> in Firefox 3.6.

Comment 6

[Mats Palmgren (inactive)]

I get <br></br> in both 3.6 and 4.  The HTML5 parser in Firefox 4 does
what spec says and treats </br> as a <br>.
The markup error should be fixed at the site.  Google Chrome 11 renders
it the same as Firefox 4, fwiw.

http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody

"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."

Comment 7

[Dieter Verfaillie]

Ok, thanks for the info. That last sentence is a bit confusing though,
especially the "Ignore the end tag token" part, but then again I'm
unfamiliar with the spec and English is not my native language...

I'll report this on GNOME's bugzilla to see if the markup can somehow be
fixed.

Comment 8

[Jo Hermans]

(In reply to comment #5)
> I double checked (after clearing the cache, and there is really a single <br>
> in Firefox 3.6.

Now I see why I saw different code - I was using 'View Selection Source', which displays the DOM source, not the actual view source (ctrl-U). Firefox 3.6 ignored the </br> tag (so it wasn't in DOM source), while Firefox 4.0 treated it like a <br>, and had thus 2 <br> tags. Freaky.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to comment #6)
> I get <br></br> in both 3.6 and 4.  The HTML5 parser in Firefox 4 does
> what spec says and treats </br> as a <br>.
> The markup error should be fixed at the site.  Google Chrome 11 renders
> it the same as Firefox 4, fwiw.
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tokenization.html#parsing-main-inbody
> 
> "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 don't know the history of this, but it seems inherently wrong for <br></br> to be interpreted as two <br>s. And the description quoted does seem a bit ambiguous. It sounds as though it's talking about a "stray" </br> end-tag that lacks a matching start tag. In that case, it's understandable to "act _as if_ a start tag token...had been seen". But here, the matching start tag _has_ in fact been seen, making the "act as if..." instruction rather confusing.

This also leads to the anomaly that
  foo<br></br>bar
renders differently from
  foo<br/>bar
even though the latter ought to simply be a shorthand for the former.

Perhaps this has all been carefully discussed and thought through, but it seems bizarre to me if this is really the intention of the spec.

Comment 10

[Jonathan Kew [:jfkthame]]

One further data point: IE9 renders with the "extra" blank lines (i.e., same as FF4) in IE8 or IE9 "standards mode", but without the blanks in "IE7 standards" or Quirks mode.

I think FF4 will also drop the blanks in Quirks mode (if you try a copy of the page with the DOCTYPE declaration removed).

It still seems a rather muddled "standard" to me....

Comment 11

[Mats Palmgren (inactive)]

The "Act as if a start tag token with the tag name X had been seen"
is an idiom used throughout the description of the parsing rules.
It simply means "execute the rule for the X start tag and then
come back here".

The BR element has an empty content model, so discussing in terms of
"end-tag that lacks a matching start tag" doesn't really make sense.
End tags for such elements are always a markup error.

About the <br/> syntax:
http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#elements-0
10.1.2
  Void elements
    ... br ...

10.1.2.1 Start tags
  ...
  6. Then, if the element is one of the void elements ... then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements ...

So <br/> is valid markup and is equivalent to <br>

Comment 12

[Mats Palmgren (inactive)]

I think the commit comment makes it clear that it's intentional:

From: whatwg at whatwg.org (whatwg at whatwg.org)
Date: Tue, 26 Jun 2007 16:19:22 -0700 (PDT)
Subject: [html5] r961 - /
Message-ID: <[e-mail]>

Author: ianh
Date: 2007-06-26 16:19:19 -0700 (Tue, 26 Jun 2007)
New Revision: 961

Modified:
   index
   source
Log:
[cgowt] (2) Make </p> and </br> introduce corresponding empty elements for compatibility with IE

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to comment #11)
> The "Act as if a start tag token with the tag name X had been seen"
> is an idiom used throughout the description of the parsing rules.
> It simply means "execute the rule for the X start tag and then
> come back here".
> 
> The BR element has an empty content model, so discussing in terms of
> "end-tag that lacks a matching start tag" doesn't really make sense.
> End tags for such elements are always a markup error.

Ok, I see HTML specifications say they're forbidden. Fair enough.

> About the <br/> syntax:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/syntax.html#elements-0
> 10.1.2
>   Void elements
>     ... br ...
> 
> 10.1.2.1 Start tags
>   ...
>   6. Then, if the element is one of the void elements ... then there may be a
> single U+002F SOLIDUS character (/). This character has no effect on void
> elements ...
> 
> So <br/> is valid markup and is equivalent to <br>

Yes, I'd expect that to be valid. What surprises me is that <br></br> isn't equivalent to it. But ok, I can see that the HTML specs say it's an error, so I suppose I'm wrong to have any particular expectation.

What about XHTML, though, which is (as I understand it) is an application of XML? Surely XML makes it quite clear that <br></br> and <br/> _are_ synonymous (and <br> alone would be an error). If the document declares its doctype as XHTML, then following those HTML rules seems inherently wrong - but in a small testcase, it appears that we still do.

(In reply to comment #12)
> I think the commit comment makes it clear that it's intentional:

> [cgowt] (2) Make </p> and </br> introduce corresponding empty elements for
> compatibility with IE

It seems surprising to treat </p> and </br> the same, when the latter is a void element (and so the </br> must be an error) while the former isn't (and so </p> is perfectly legitimate in HTML, it only needs this error-handling if it has been used in an invalid context).

Comment 14

[Mats Palmgren (inactive)]

> What about XHTML, though, which is (as I understand it) is an application
> of XML? Surely XML makes it quite clear that <br></br> and <br/> _are_
> synonymous (and <br> alone would be an error).

Correct.  http://www.w3.org/TR/xml11/#sec-starttags
(it even uses BR for the example)

> If the document declares its doctype as XHTML, then following those HTML
> rules seems inherently wrong.

Yes, but having a XHTML doctype isn't enough for documents served over HTTP.
It must be served with an XML MIME type such as "application/xhtml+xml".
If it's served as "text/html" is will be parsed as HTML.

Using file:// it needs to have a .xhtml or .xml file extension.

> - but in a small testcase, it appears that we still do.

It seems to work fine for me.  There's only one BR in the DOM for
<!DOCTYPE html 
    PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head><title></title></head>
<body>a<br></br>b</body>
</html>

Comment 15

[Jonathan Kew [:jfkthame]]

(In reply to comment #14)
> > If the document declares its doctype as XHTML, then following those HTML
> > rules seems inherently wrong.
> 
> Yes, but having a XHTML doctype isn't enough for documents served over HTTP.
> It must be served with an XML MIME type such as "application/xhtml+xml".
> If it's served as "text/html" is will be parsed as HTML.
> 
> Using file:// it needs to have a .xhtml or .xml file extension.

Ah, that's what I was doing wrong - thanks.

Comment 16

[Henri Sivonen (:hsivonen)]

Resummarizing, because the rendering in Firefox 4 is correct according to the most official definition of correctness.

Comment 17

[Karl Dubost💡 :karlcow]

The Web site design has been changed.