Bug 14530 - XSLT processing doesn't preserve certain XML DOM trees when the output is HTML
Summary: XSLT processing doesn't preserve certain XML DOM trees when the output is HTML
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 523.x (Safari 3)
Hardware: All OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.websandbox.net/media/examp...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-07-05 03:58 PDT by Robert Burns
Modified: 2007-07-05 14:25 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Burns 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.
Comment 1 Robert Burns 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>
Comment 2 Robert Burns 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.
Comment 3 Alexey Proskuryakov 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.
Comment 4 Robert Burns 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?
Comment 5 Robert Burns 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 :-).
Comment 6 Robert Burns 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).