[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] XSL template "namespace" problem

---

---

Ian,

At 01:31 PM 3/29/2006, you wrote:

<A NAME="linkone"><xsl:attribute
name="HREF">javascript:process('linkone',<xsl:value-of
select='/rootnode/value'/>)</xsl:attribute>Click me, value
is: <xsl:value-of select="/rootnode/value" />.</A>

(Notice the <xsl:value-of> tag inside the Javascript call
inside the A
HREF, and inside the A HREF data field.)

This is now well-formed (though not very pretty) XML, and it's correct XSLT.
The HTML it generates is slightly dubious, because javascript:process(.....)
is not a legal URL, so some HTML validators may get upset about it (and the
XSLT serializer will replace spaces by %20, which would probably stop it
working); you may be better off generating attributes like onClick that are
designed to hold Javascript rather than URLs.

This is all well and good, but then that means that there is no way to create javascript-linked links in XSLT. The reason I'm doing it this way is because I'm trying to create a menu system that is based on an XML file to define its content. Unfourtunately, using a structure like:

<A OnClick="funccall()">Some text</A>

doesn't create a clickable link, even though it might be more "well formed" than:

<A HREF="javascript:funccall()">Some text</A>

This latter code actually creates a link that one can click on.

In that page I pointed to earlier, mouse events are layered onto HTML spans, and it all works. (I have no idea if it's "correct", but validated only by testing. :-) I guess debate here might start by asking what's a "link". Nevertheless these are HTML/Javascript questions (on the upper layer), not XSLT questions.

From what I'm understanding, this type of structure, because its not well formed, is completely incompatible with XSLT, even thought xsltproc processes it properly and IE interprets it correctly.

Not quite. It is perfectly "well-formed" in the technical sense of that term, meaning syntactically-correct XML. Mike is just drawing your attention to potential problems in the handling this stuff *as HTML*: an issue of "HTML semantics" not of "well-formedness".

As Mike also said, it's *correct XSLT*, and will work fine to generate *a result*. Whether that result is a good thing to give to a browser and get predictable results is an entirely different question.

XSLTProc processes it properly because it's correct XSLT. So does MSXML (IE's XSLT engine). IE happens to do the "right thing" with the Javascript as composed in the HTML result of the transform. That may be fine for your purposes. Going a bit off topic, experts might also point out that even though IE is okay with it, you might have trouble getting other browsers to do what you expect.

I guess I'm a little confused why these browsers and processors are interpreting it if its technically illegal.

The XSLT is legal. As for why browsers do stuff with illegal HTML/Javascript ... it's a long and painful story (but not for this forum, heh).

One of the good things about XSLT is that the line between what's legal and what's illegal is much clearer than it is with HTML and its associated technologies like Javascript and CSS. So too are those related but different questions: what works and doesn't work, what's portable and isn't.

Cheers,
Wendell

======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

---