bad rendering when parsing xslt into xhtml (using the browser)

VERIFIED WORKSFORME

Status

()

Core
XSLT
--
enhancement
VERIFIED WORKSFORME
15 years ago
15 years ago

People

(Reporter: jasper-bz, Assigned: peterv)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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

15 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
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 2

15 years ago
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

15 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.
(Reporter)

Comment 5

15 years ago
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.