Bug 76707 – Two HTML line breaks are generated with XSL transformation of <br/>

• Status: NEW
• Component: XML

[Rob S.]

Created attachment 123327 [details]
HTML <br/> tag in Chrome - incorrectly double spaced

When I saw this problem in various forums including some workarounds such as using JavaScript to replace <br/>s with new lines (in white-space: pre styled elements? StackOverflow #7672460) I thought sure I should find this as a bug that has already been reported - am I missing it?

Problem:

In an HTML 5 document, a single <br/> tag is rendered as two <br> tags in Chrome (16.0.912.75) and other WebKit-based browsers.  The Chrome developer tools (br-tag-dev-tools.png) clearly shows two <br> tags where there is only a single <br/> tag in the source (br-tag-view-source.png).  I originally thought that maybe this was being caused by the site's stylesheet document, but I was able to create a version with minimal code that exhibits the same issue.

To recreate:

1. Search for "html br tag" in Google or other search engines.
2. Click on the result for HTML 5 that says "HTML <br/> Tag for Line Breaks in Paragraphs ...".
3. Verify that the outlined example is single spaced, not double spaced.
4. Do "View Source" to verify that there is only one <br/> tag in the source code.
5. If it's double spaced, use developer tools to see if there is one or two <br>s for each <br/> tag in the source code.
6. Try the same thing in other browsers to see the difference.

Original source code:

<div id="br-tag-demo" style="margin-bottom: 1em; border: 3px outset gray; padding: 0.5em; text-align: left">
<p>John &amp; Jane Doe<br/>
123 Second St.<br/>
Riverside, LA 17654</p>
</div>

Result as shown by Chrome developer tools:

<div id="br-tag-demo" style="margin-bottom: 1em; border: 3px outset gray; padding: 0.5em; text-align: left">
<p>John &amp; Jane Doe<br><br>
123 Second St.<br><br>
Riverside, LA 17654</p>
</div>

Attachments:

br-tag-chrome.png - HTML <br/> tag in Chrome - incorrectly double spaced
br-tag-firefox.png - HTML <br/> tag in Firefox - single spaced as expected
br-tag-rockmelt.png - HTML <br/> tag in RockMelt - incorrectly double spaced
br-tag-safari.png - HTML <br/> tag in Safari on Mac - incorrectly double spaced

My minimal code example: http://www.ExampleOnly.com/br-tag/

[Rob S.]

Correction:

My minimal code example: http://www.ExampleOnly.com/br-tag/test.html

[Rob S.]

Created attachment 123328 [details]
Chrome developer tools shows two <br> tags where only one appears in the source code

[Rob S.]

Created attachment 123329 [details]
HTML <br/> tag in Firefox - single spaced as expected

[Rob S.]

Created attachment 123330 [details]
HTML <br/> tag in RockMelt - incorrectly double spaced

[Rob S.]

Created attachment 123331 [details]
HTML <br/> tag in Safari - incorrectly double spaced

[Rob S.]

Created attachment 123332 [details]
View source shows only one <br/> tag in the original source code

[Alexey Proskuryakov]

This looks like a bug in Firefox. An XSL transformation of <br/> should produce <br></br> with html output method, which is equivalent to <br><br>. However, in Firefox the same transformation produces a single <br>.

[Rob S.]

Interesting. If you didn't need any JavaScript you could simply change from <xsl:output method="html"/> to <xsl:output method="xml"/> and render it as an XML document instead of HTML.  Unfortunately, when the document is rendered using the XML DOM, much of the JavaScript code, which previously worked with the HTML DOM, fails after that change is made.  I just tried it with the site I'm working on (http://TVSeries.com/) and various things stopped working, including the backgrounds, dynamic vertical positioning, the Google +1 button, etc, because it's throwing a bunch of undefined object errors.  The forums seem to indicate the same issue occurs when using <xsl:output method="xml"/> with IE, but I'm currently on a Mac without an easy way to test it.

I updated my minimal code test cases.  http://www.ExampleOnly.com/br-tag/test2.html clearly shows that with <xsl:output method="xml"/>, in Firefox at least, the document is an XMLDocument with no HTML-specific objects, such as document.body, which is what causes the JavaScript code to break, while http://www.ExampleOnly.com/br-tag/test1.html shows the document is an HTMLDocument.

So, is there any suggestion on the best way to render a single <br/> in the resulting document when it needs to support JavaScript and therefore requires the HTML DOM (<xsl:output method="html"/>)?  Maybe the workaround I had found provides one option that wasn't too far off - that is, to use JavaScript to detect when the user agent is a WebKit browser and then loop through the document tree to replace all instances of <br><br> with <br/> (I thought HTML 5 was supposed to help us avoid this kind of browser-specific funniness).  Wouldn't you also need to do the same thing with some of the other self-closed elements such as <hr/> which would become <hr></hr>, presumably equivalent to <hr><hr>? (Some elements created by self-closing tags would be OK, such as <img .../> becoming <img ...></img>, <embed .../> becoming <embed ...></embed>, etc.)

[Alexey Proskuryakov]

Actually, I'm not confident that it's a Firefox bug any more.

1. Some XSLT engines produce <br></br>, while some produce a plain <br>. I don't know which is right per the spec.

2. For WebKit+libxslt, this behavior is an HTML5 parser regression. Before HTML5, <br></br> was parsed as <br> in strict mode, and as <br><br> in quirks. Firefox 3.5 worked exactly the same - but HTML5 standardized on quirks behavior always.

[Alexey Proskuryakov]

Looks like a libxslt bug - per <http://www.w3.org/TR/xslt#section-HTML-Output-Method>, XSLT processors should know better than output <br></br> in HTML mode.

The parser change is still a curious one, and an immediate reason for the regression.

[Alexey Proskuryakov]

The libxslt issue was previously reported as <https://bugzilla.gnome.org/show_bug.cgi?id=651925>.

Rob, could you please attach your test here for posterity, so that we wouldn't need to rely on an external site keeping a copy?

[Rob S.]

Created attachment 123521 [details]
Files for test cases - see comment

I created a workaround using the stylesheet rather than having to use JavaScript.  The stylesheet uses this template to transform the <br> elements into new lines:

   <xsl:template match="html:br">
      <span>
         <xsl:apply-templates select="@*"/>
         <span style="white-space: pre">&#x200a;
</span>
      </span>
   </xsl:template>

Curiously, <hr/> elements do _not_ get transformed to <hr><hr> - horizontal lines appear just once as expected and therefore the workaround is not needed for <hr/> elements.

A working example with the workaround:  http://www.ExampleOnly.com/br-tag/test3.html

As requested, I have uploaded the test case files as brtag.zip.  The files that archive contains are:

test.html - simple test case, single spaced in Firefox, double spaced in Safari, Chrome, etc.
test.xsl - xsl:stylesheet with <xsl:output method="html"/> for test.html and test1.html
test1.html - same as test.html with alerts that show object types
test2.html - test that uses <xsl:output method="xml"/> in test2.xsl - JavaScript does not work in Firefox due to undefined objects
test2.xsl - xsl:stylesheet with <xsl:output method="xml"/>
test3.html - test that uses <xsl:output method="html"/> and workaround that replaces <br/> elements with new lines
test3.xsl - xsl:stylesheet with a template that transforms <br> elements to new lines

Thanks much for all the help.

[Adam Barth]

One of the design goals of the parser is not to have any difference in parsing between quirks.and standards mode.

[Alexey Proskuryakov]

Looks like this is what XSLT standard requires, and Firefox is "wrong" here.

The spec requirement makes little sense though, so perhaps HTML should override that. I filed <https://www.w3.org/Bugs/Public/show_bug.cgi?id=18460> for sanity, although that's something that would be hard for us to implement without forking libxslt or switching to another implementation.

[William L. Thomson Jr.]

I should have realized this was a webkit bug/issues. I reported it to chrome sometime ago. It has been effecting me for years.
https://bugs.chromium.org/p/chromium/issues/detail?id=142158