Summary: | Two HTML line breaks are generated with XSL transformation of <br/> | ||
---|---|---|---|
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: | P2 | ||
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
Rob S.
2012-01-20 08:43:23 PST
Correction: My minimal code example: http://www.ExampleOnly.com/br-tag/test.html Created attachment 123328 [details]
Chrome developer tools shows two <br> tags where only one appears in the source code
Created attachment 123329 [details]
HTML <br/> tag in Firefox - single spaced as expected
Created attachment 123330 [details]
HTML <br/> tag in RockMelt - incorrectly double spaced
Created attachment 123331 [details]
HTML <br/> tag in Safari - incorrectly double spaced
Created attachment 123332 [details]
View source shows only one <br/> tag in the original source code
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>. 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.) 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. 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. 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? 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">  </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. One of the design goals of the parser is not to have any difference in parsing between quirks.and standards mode. 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. 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 |