613 bytes, text/plain
1.54 KB, text/html
1.97 KB, text/xml
144 bytes, text/xml
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040316 In the example provided below xsltbug.html you can hover over div and table links and the table is changed. but when this same HTML is generated by a XML and XSLT (xsltbug.xml) setting the innerHTML seems to just clear it Reproducible: Always Steps to Reproduce: 1.load xsltbug.html hover over div or table links 2.load xsltbug.xml hover over div or table links 3.see that step 2 does not modify the text like step 1 did Actual Results: see that step 2 does not modify the text like step 1 did Expected Results: behaved just like step1
Dup of XSLT not creating a HTML document, probably...
Assignee: parser → peterv
Component: HTML: Parser → XSLT
QA Contact: keith
Attachment #146230 - Attachment mime type: application/octet-stream → text/plain
This works as designed. Mozilla does not support innerHTML in XHTML. As your testcase is HTML, it works over there, generate a static XHTML testcase (with .xml ending, too), and you'll see that it doesn't work over there. XSLT does generate an HTML document if you use the html output method, so there is an easy workaround.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
Axel: I can't find where in the code we're disabling innerHTML for xhtmlelements. I wouldn't be surpriced if it's there and I just don't see it.
The codepath to "not supported" is rather involved. XHTML as in XML is received with a content type of text/xml, which is the content type of the document. innerHTML setter kicks of nsRange::CreateContextualFragment which creates a nsHTMLContentSink. Then htmlparser tries to find the right dtd, which happens to be the expat driver (as the content type is text/xml), and that requires the content sink to implement nsIExpatSink, which the html content sink doesn't do. That's why it doesn't work. jst said, yeah, fine that way. At least I recall him saying so ages ago.
IMHO it would be a good thing to support .innerHTML in XHTML too (of course it would require wellformed xml to be passed), though if everyone is fine with the current state it's no biggie to me. And in any case this isn't xslt related.
As the original bug filer(er) I'd really like to see support for .innerHTML in XHTML objects. I don't understand the technical reasons for it not being supported but as a (lame) web developer I was astounded at the reply that it wasn't 'supported' and will not be supported. This is probably going to rile people, but I don't intend it this way. but it works in IE :P the workaround was very simple to use though. and I am very grateful for that. the more people using XHTML the better in my opinion, I imagine it's infinitely easier to parse and reject badly made pages.
No, it does *not* work in IE. IE has *no* concept what so ever of XHTML. They feed it all through their HTML-parser and create a HTML DOM.
I guess that depends on your perspective (WRT IE and works and does not work). I'm not trying to start a flame war, or upset people. the example I provided works in IE, and does not in mozilla. I filed this bug because I think it 'should' work in mozilla. whatever the underlying technologies, difficulties etc... are interesting, but the fact it does not work for me is the critical issue. the workaround is good, but from what I can tell I'm not doing anything 'wrong' per se. in summary, it would be really really nice (and might even be considered missing functionality that it does) if XHTML DOM supported modifying innerHTML
I'm sorry, but your argument is pretty silly, IE is totally ignoring what you're telling them to and then you say it works in IE? Since you're obviously not needing any XHTML features just use HTML instead of XHTML and it'll work fine in all browsers. Problem solved.
I agree my argument is silly, now I understand more about what mozilla is doing and what IE is (or is not) doing it is more clear. sorry to everyone on the CC list for this bug's continued discussions. the fact remains that I think that it would be good if XHTML supported innerHTML but it has been proven that *I* really don't need it. But maybe someone finding this bug will also really need it and can vote for it, or bring it up again.
Alex, you want bug 155723.
repoened so I can close it as a dupe I really apologies for everyones wasted time on this. if it makes you feel better I learned some stuff and learned the bug that I should be following. I thought the XSLT was the cause but obviously not. *** This bug has been marked as a duplicate of 155723 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago → 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.