DOM xmlns call-template missing attributes




12 years ago
12 years ago


(Reporter: gbugzilla, Unassigned)


1.5.0.x Branch

Firefox Tracking Flags

(Not tracked)





12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060414 Firefox/
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060414 Firefox/

This is rather difficult to explain, but it feels like firefox fails to add _any_ attributes to tags built in a <xsl:call-template/> call iff there is an xmlns present in the html tag...

I have provided two examples.  Sorry in advance if I'm simply failing to understand something.

Reproducible: Always

Steps to Reproduce:
1. Go to the URL above and try both with_bugs and sans_bugs
2. The .xml files contain no real thrills, but simply invoke some .xsl
3. The only difference between the .xsl documents (besides colors and text) is the  xmlns attribute on the html of the buggy .xsl ...

Actual Results:  
Any tags built in the call-template context will have NO attributes desipte using xsl:attribute or building the attributes by hand.  The javascript will fail stating the node has no attributes!

Expected Results:  
The tags should have attributes.  The javascript shouldn't generate a js error even if you fail to set the tag id.


12 years ago
Summary: DOM xmlns call-template → DOM xmlns call-template missing attributes


12 years ago
Version: unspecified → 1.5.0.x Branch

Comment 1

12 years ago
I don't think any attributes are going missing (I see all the attributes I expect to see when I look at the transformed documents in the DOM Inspector) but I believe namespace issues may be causing your problems.

In your 'buggy' example, you're setting a namespace on your 'html' attribute but creating some div elements in another template, where they end up in the null namespace and not the XHTML namespace. When the document is displayed, these div elements are just treated as arbitrary XML elements, so they are displayed inline (the default) rather than as blocks. In addition, the style attribute on an arbitrary XML element has no special meaning, so your CSS does not get applied, leading to a transparent background rather than red.

I expect that this namespace confusion is also the cause of your scripting woes.

In your 'notbuggy' example, no elements are explicitly placed in a namespace in the output document, so everything ends up in the null namespace. So why does the output get styled as if it's HTML? Section 16 of the XSLT 1.0 spec at lists the conditions under which an XSLT processor should output as HTML by default rather than XML (there's no non-whitespace characters in any text nodes before the first child of the root element, which has the name "html" and is in the null namespace). I believe your XML/XSLT combination meets these conditions, so your XML actually gets transformed into HTML. This means that it gets styled as HTML (with div elements being block by default and inline style attributes respected). You can also script the document using the HTML DOM.

In summary, your 'notbuggy' example produces HTML. Your 'buggy' example produces an XHTML/XML document with elements in two different namespaces (well, one namespace and the null namespace). I've not really looked into the scripting side of things but I expect that namespaces are what's causing your JavaScript not to match the right nodes.

Changing bug status to RESOLVED INVALID. Reopen if you disagree.
Last Resolved: 12 years ago
Resolution: --- → INVALID

Comment 2

12 years ago
(In reply to comment #1)
> Changing bug status to RESOLVED INVALID. Reopen if you disagree.

I'm going to leave this resolved-invalid, since I obviously don't know any better.  

However, I think the behavior is much stranger than alex thinks.  That is just a feeling.  If anyone reads this and thinks it might be stranger than alex thinks... please reopen.
You need to log in before you can comment on or make changes to this bug.