Closed Bug 119717 Opened 23 years ago Closed 23 years ago

Mixed form and list elements don't display

Categories

(Core :: XSLT, defect)

Product:
Core
Component:
XSLT
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: jeff, Assigned: keith)

Details

Hi, I'm using the <?xml-stylesheet?> PI to associate an XSLT stylesheet with an XML doc. When the output HTML contains mixed <input> and <li> elements, the text isn't rendered. I will attach an example XML and XSLT to this bugreport. Thanks, --Jeff
Damnit.. this is the third time, from two different bugzilla installations, that I've been unable to create attachments :/ Here are the files inline, then: ---- bugdemo.xsl ---- <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <!-- Note: the bug occurs with or without the doctype-* attributes --> <xsl:output method="html" doctype-public="-//W3C//DTD HTML 4.01 Transitional//EN" doctype-system="http://www.w3.org/TR/html4/loose.dtd"/> <xsl:template match="/"> <html> <body> <h1>Mozilla XSLT bug demo</h1> <p>The following consists of mixed form and list elements. The text isn't visible if rendered with Mozilla's built-in XSLT engine, but does render if the output is saved to HTML.</p> <ul> <form name="profiles"> <li><input type="checkbox" name="profile" value="base">Base profile</input></li> <li><input type="checkbox" name="profile" value="extras">Advanced profile</input></li> <li><input type="checkbox" name="profile" value="webapp">Webapp profile</input></li> <li><input type="checkbox" name="profile" value="ejb">EJB profile</input></li> </form> </ul> </body> </html> </xsl:template> </xsl:stylesheet> ---- bugdemo.xml ---- <?xml version="1.0"?> <?xml-stylesheet type="text/xsl" href="bugdemo.xsl"?> <bugdemo/>
first question that springs to mind is: why are placing content inside the <input>? Not sure if that is what causes the problem though
oh, the text in the <input> *is* the text that you want to see? That is not how it works and not how you do it in html. Instead of <input type="checkbox" name="profile" value="base">Base profile</input> you should do <input type="checkbox" name="profile" value="base"/>Base profile
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
<QAIgnore> jeff@socialchange.net.au: fwiw, the link on the page directly after filing a bug is broken. It is fixed in Bugzilla's CVS but mozilla.org hasn't updated to it yet. Get your Bugzilla admin to update to Bugzilla CVS if you want that problem fixed. In the meantime, just visit the bug directly and click the 'Create a New Attachment' link there. </QAIgnore>
Doh! Thanks, that fixes it :) There's still a bug somewhere though, because "normally" (w/o a doctype declaration, and with HTML 4.0 doctype declaration), Mozilla will render <input..>foo</input> just fine. However, if I force XHTML rendering (changing the content to XHTML, and renaming the file extension to .xhtml), then the text disappears. That it doesn't throw an error might also be considered a bug, because the XHTML DTD specifies that <form> is EMPTY (see http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd). So it looks like XHTML mode is being forced, despite me specifying that I want a HTML 4.0 "loose" doctype declaration. Odd.. anyway, thanks. --Jeff
marking verified per reporters comments (feel free to do this yourself when you file more bugs). The reason that it works when reading the result html is that the html-parser is "intelligent" and fixes your errors. That is something that we and the xml- parser can't and shouldn't do (which is why it doesn't work when parsed as xhtml). We *could* verify the output to see if it conforms to the specified doctype, however that is IMHO not something that is worth the extra time it will cost. And considering that nothing else in mozilla verifies content against DTDs it is IMHO pretty low priority
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.