346885 - DOM xmlns call-template missing attributes

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Paul Miller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060414 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060414 Firefox/1.5.0.1

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 divtag.id.match(/something/) will fail stating the node has no attributes!

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

Comment 1

[Alex Bishop]

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 http://www.w3.org/TR/xslt#output 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.

Comment 2

[Paul Miller]

(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.