|
RE: [xsl] XSL template "namespace" problem
2006-03-29 14:34:18
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(_at_)mulberrytech(_dot_)com
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
======================================================================
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
|
|