Closed
Bug 215004
Opened 21 years ago
Closed 21 years ago
bad rendering when parsing xslt into xhtml (using the browser)
Categories
(Core :: XSLT, enhancement)
Core
XSLT
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: jasper-bz, Assigned: peterv)
References
()
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030721 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5a) Gecko/20030721 When the xslt-stylesheet has the following output tag, mozilla is convinced that needs to show xml: <xsl:output method="xml" version="1.0" encoding="iso-8859-1" indent="no" omit-xml-declaration="no" doctype-public="-//W3C//DTD XHTML 1.0 Transitional//EN" doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" standalone="yes" media-type="text/html" /> Even though the generated document clearly is xhtml, and should be rendered as such, something strange happens. At http://lkml.org/lkml/last100/html , this page is transformed at the server-side, and shows correct behaviour. Finally, http://lkml.org/lkml/last100 contains a slightly modified stylesheet which breaks standards but renders correctly. Reproducible: Always Steps to Reproduce: 1. Go to http://testing.lkml.org/lkml/last100 Actual Results: Dumping of contents without any rendering. Expected Results: Show a rendered page, which does happen with pretranslated xslt found at http://lkml.org/lkml/last100/html
Comment 1•21 years ago
|
||
My debug build shows: Security Error: Content at http://testing.lkml.org/lkml/last100 may not load data from http://lkml.org/templates/article-list.xsl. Works like charm once you move both onto the same site, tried this from file://
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Can you retry this again? The stylesheet included in the xml-one was the wrong one - has been fixed at the server right now and it 'FAILSFORME'™
Comment 3•21 years ago
|
||
still WORKSFORME. You output XML, and if your output would actually be XHTML, it would probably render fine. Just, it ain't XHTML, because it doesn't have an XHTML namespace. If you really wanna output XHTML instead of html, be sure that *all* your generated content belongs into the XHTML namespace. That is, you have to explicitly specify that in xsl:element, for example. Look into attribute value templates, btw. Note that specifying the xhtml namespace on the html element won't make *all* the generated content xhtml, as that namespace definition is only valid for the descendents of the html element. IE has no clue about XML and feeds stuff to it's HTML parser, which fixes these kinds of page errors.
You don't have to explicitly specify the namespace on the xsl:element, it will use the namespace mappings (including the default one) available at the element. So to get the stylesheet working you need to add a xslns="http://www.w3.org/1999/xhtml" attribute on the top xsl:stylesheet element.
Yep, found out that adding the xmlns attribute to the root element works fine. Last note from my side, at this moment: can this bugreport be transformed into a feature request, or will you drop that directly? My point being: doesn't the DTD carry enough information to allow an implicit namespace (in the absence of a real one)? (Just thinking of 'Be liberal in what you accept etc.)
well, the DTD does carry enough information, but we would be breaking specs if we added namespaces where the stylesheet creates content in the null namespace. Marking verified per reporters comment
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•