Bug 14530

Summary: XSLT processing doesn't preserve certain XML DOM trees when the output is HTML
Product: WebKit Reporter: Robert Burns <robburns1>
Component: XMLAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, robburns1
Priority: P2    
Version: 523.x (Safari 3)   
Hardware: All   
OS: OS X 10.4   
URL: http://www.websandbox.net/media/examples/ietest.xml

Robert Burns
Reported 2007-07-05 03:58:43 PDT
<img>fallback</img> should not display the contents of the image element by default in XML processed documents. When an <img> element has a src attribute set, the <img> element should be replaced entirely by the sourced image. Opera and Mozilla both behave in this way. WebKit displays the fallback content after the image. It is important for WebKit to not display the contents of an image element so that the contents can be used for fallback for other UAs or at a users discretion. When the src referenced file is unavailable or invalid, then WebKit might want to display the value of the alt attribute or the fallback contents of the <img> element or both.
Attachments
Robert Burns
Comment 1 2007-07-05 04:21:31 PDT
Here's a sample drawn from: http://www.websandbox.net/media/examples/ietest.xml <?xml-stylesheet type="text/xsl" href="ietest.xsl" ?> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title>Test Page</title></head> <body> <h1>My Test Page</h1> <p><img src="fake.png"><b>rich</b> fallback</img></p> <p><img src="../../gallery/1_thumb"><b>rich</b> fallback</img></p> <p>Content after those images</p> </body> </html>
Robert Burns
Comment 2 2007-07-05 12:03:14 PDT
I believe it should be part of the DOM tree but not displayed on the page (as if display:none was set with regard to the img element's content nodes. (if that makes sense) Note also that the test case above has an xsl transform. This is merely for testing IE (which doesn't handle this like Opera and Firefox, but then again its not an XHTML browser). It could be omitted for WebKit.
Alexey Proskuryakov
Comment 3 2007-07-05 13:22:26 PDT
> It could be omitted for WebKit. Right - but then this issue no longer happens. So, this bug is actually about a difference in XSLT processing. The difference is that WebKit creates a text of XSLT transformation result, and parses it, while Firefox/Opera operate on DOM nodes. Since the stylesheet has output method="html", WebKit correctly parses '<img src="fake.png"><b>rich</b> fallback</img>' as '<img src="fake.png"><b>rich</b> fallback', and thus the "rich fallback" text is visible. On the other hand, Firefox and Opera create a document that cannot be even serialized to HTML, because its IMG elements have child nodes. I'm confirming this as a difference with Firefox and Opera, but my understanding is that WebKit is actually correct here, as the result of XSLT transformation is conceptually HTML source text.
Robert Burns
Comment 4 2007-07-05 13:52:56 PDT
My bad. Sorry, I should have thought that could effect things. Are you saying that without the XSLT and when loaded as XML it works (I guess I'll test it myself). However, I think that Opera and Firefox do the right thing with the xslt (not that that's what I was trying to report here). That is, I don't think it should be treated as HTML when delivered as XML. Rather it should be treated as XML with a document fragment from the HTML namespace. Do you agree?
Robert Burns
Comment 5 2007-07-05 14:01:21 PDT
Yeah... You're right (hangs head low). I tested it without the XSLT and it works fine (at least as I'd expect it to). Also on what I said about the XSLT, is it the attribute: "method="html"? I guess that means that whatever the resulting tree, treat this as MIME type HTML? I guess I'll go look that up at the XSLT spec. If I find anything you'll hear from me again :-).
Robert Burns
Comment 6 2007-07-05 14:25:16 PDT
AP, you're 100% correct on the XSLT too. WebKit has it right and the others don't get it right. For reference: http://www.w3.org/TR/xslt#section-HTML-Output-Method Clearly this wasn't my original concern with this bug (which is definitely invalid). So the team is free to do with the XSLT issue as it sees fit. I don't have a strong feeling one way or the other (matching spec or matching the others).
Note You need to log in before you can comment on or make changes to this bug.