Bug 76707

Summary:

Two HTML line breaks are generated with XSL transformation of

Product:

WebKit

Reporter:

Rob S. <RobS.webkit6>

Component:

XML

Assignee:

Nobody <webkit-unassigned>

Status:

NEW

Severity:

Normal

CC:

abarth, ap, ian, mike, wlt-ml

Priority:

Version:

525.x (Safari 3.2)

Hardware:

Unspecified

OS:

Unspecified

URL:

http://www.ExampleOnly.com/br-tag/test.html

Bug Depends on:

Bug Blocks:

41115

Attachments:

Description	Flags
HTML <br/> tag in Chrome - incorrectly double spaced	none
Chrome developer tools shows two <br> tags where only one appears in the source code	none
HTML <br/> tag in Firefox - single spaced as expected	none
HTML <br/> tag in RockMelt - incorrectly double spaced	none
HTML <br/> tag in Safari - incorrectly double spaced	none
View source shows only one <br/> tag in the original source code	none
Files for test cases - see comment	none

Rob S.

Reported 2012-01-20 08:43:23 PST

Created attachment 123327 [details] HTML tag in Chrome - incorrectly double spaced When I saw this problem in various forums including some workarounds such as using JavaScript to replace 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 tag is rendered as two tags in Chrome (16.0.912.75) and other WebKit-based browsers. The Chrome developer tools (br-tag-dev-tools.png) clearly shows two tags where there is only a single 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 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 tag in the source code. 5. If it's double spaced, use developer tools to see if there is one or two s for each 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"> John & Jane Doe 123 Second St. Riverside, LA 17654 </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"> John & Jane Doe 123 Second St. Riverside, LA 17654 </div> Attachments: br-tag-chrome.png - HTML tag in Chrome - incorrectly double spaced br-tag-firefox.png - HTML tag in Firefox - single spaced as expected br-tag-rockmelt.png - HTML tag in RockMelt - incorrectly double spaced br-tag-safari.png - HTML tag in Safari on Mac - incorrectly double spaced My minimal code example: http://www.ExampleOnly.com/br-tag/

Attachments
HTML <br/> tag in Chrome - incorrectly double spaced (3.09 KB, image/png) 2012-01-20 08:43 PST, Rob S.	no flags	Details
Chrome developer tools shows two <br> tags where only one appears in the source code (111.18 KB, image/png) 2012-01-20 08:53 PST, Rob S.	no flags	Details
HTML <br/> tag in Firefox - single spaced as expected (2.94 KB, image/png) 2012-01-20 08:53 PST, Rob S.	no flags	Details
HTML <br/> tag in RockMelt - incorrectly double spaced (3.02 KB, image/png) 2012-01-20 08:54 PST, Rob S.	no flags	Details
HTML <br/> tag in Safari - incorrectly double spaced (7.48 KB, image/png) 2012-01-20 08:54 PST, Rob S.	no flags	Details
View source shows only one <br/> tag in the original source code (38.52 KB, image/png) 2012-01-20 08:55 PST, Rob S.	no flags	Details
Files for test cases - see comment (3.49 KB, application/zip) 2012-01-22 22:18 PST, Rob S.	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Rob S.

Comment 1 2012-01-20 08:49:37 PST

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

Rob S.

Comment 2 2012-01-20 08:53:12 PST

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

Rob S.

Comment 3 2012-01-20 08:53:56 PST

Created attachment 123329 [details] HTML tag in Firefox - single spaced as expected

Rob S.

Comment 4 2012-01-20 08:54:30 PST

Created attachment 123330 [details] HTML tag in RockMelt - incorrectly double spaced

Rob S.

Comment 5 2012-01-20 08:54:53 PST

Created attachment 123331 [details] HTML tag in Safari - incorrectly double spaced

Rob S.

Comment 6 2012-01-20 08:55:43 PST

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

Alexey Proskuryakov

Comment 7 2012-01-22 18:34:08 PST

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

Rob S.

Comment 8 2012-01-22 20:18:24 PST

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 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 with (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

Comment 9 2012-01-22 21:19:11 PST

Actually, I'm not confident that it's a Firefox bug any more. 1. Some XSLT engines produce , while some produce a plain . I don't know which is right per the spec. 2. For WebKit+libxslt, this behavior is an HTML5 parser regression. Before HTML5, was parsed as in strict mode, and as in quirks. Firefox 3.5 worked exactly the same - but HTML5 standardized on quirks behavior always.

Alexey Proskuryakov

Comment 10 2012-01-22 21:25:18 PST

Looks like a libxslt bug - per <http://www.w3.org/TR/xslt#section-HTML-Output-Method>, XSLT processors should know better than output in HTML mode. The parser change is still a curious one, and an immediate reason for the regression.

Alexey Proskuryakov

Comment 11 2012-01-22 21:43:29 PST

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.

Comment 12 2012-01-22 22:18:40 PST

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 elements into new lines: <xsl:template match="html:br"> <xsl:apply-templates select="@*"/>   </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 elements with new lines test3.xsl - xsl:stylesheet with a template that transforms elements to new lines Thanks much for all the help.

Adam Barth

Comment 13 2012-01-22 22:40:10 PST

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

Alexey Proskuryakov

Comment 14 2012-08-01 09:29:36 PDT

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.

Comment 15 2017-03-29 18:03:00 PDT

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

Note You need to log in before you can comment on or make changes to this bug.