Feature detection in XSL template

Is there any possibility to detect any of UA's feature in the template?

I have an XML data file with XSL template linked having HTML page as
output. I would love to make some adjustments during the transformation
depending on target UA, say add xmlns:v="urn:schemas-microsoft-com:vml"
to html element for IE.

Or XSLT transformer exludes such option as such (only resulting
documents gets on hold of the environment)?

VK

VK wrote:

> Is there any possibility to detect any of UA's feature in the template?

You can detect the XSLT processor in XSLT using
<http://www.w3.org/TR/xslt#function-system-property>
e.g.
<xsl:if test="system-property('xsl:vendor') = 'Microsoft'">

By now however there are several XSLT processor products from Microsoft,
several MSXML versions (3, 4, 5, 6) and two .NET versions (XslTransform,
XslCompiledTransform) so simply checking the vendor might not tell you
enough.


--

Martin Honnen
http://JavaScript.FAQTs.com/

VK wrote:
> Is there any possibility to detect any of UA's feature in the template?

No, test for them outside the XSLT-processor and pass a flag into the
stylesheet.

This is a good approach (particularly with the M$oft tools under ASP)
because it still lets you cache loading the (slow) stylesheet and just
repeat the (quick) transformation as needed.

Don't make the mistake of assuming that testing for features of the
XSLT processor (which you can certainly do) tells you anything about
the features of the final client viewing the output. That's only the
case for client-side transforms (at most)

Martin Honnen wrote:
> You can detect the XSLT processor in XSLT using
> <http://www.w3.org/TR/xslt#function-system-property>
> e.g.
> <xsl:if test="system-property('xsl:vendor') = 'Microsoft'">

Aha! Great thanks!

Andy Dingley <> wrote:
> VK wrote:
> > Is there any possibility to detect any of UA's feature in the template?
>
> No, test for them outside the XSLT-processor and pass a flag into the
> stylesheet.

I still prefer Martin's solution (if it works cross IE/Gecko)

> Don't make the mistake of assuming that testing for features of the
> XSLT processor (which you can certainly do) tells you anything about
> the features of the final client viewing the output. That's only the
> case for client-side transforms (at most)

This is exactly my case: all transformations will be made client-side,
the initial entry point is the pure transformer's data, like:
<http://www.geocities.com/schools_ring/tmp/demo01/index.xml>

VK wrote:
> Andy Dingley <> wrote:
> > VK wrote:
> > > Is there any possibility to detect any of UA's feature in the template?
> >
> > No, test for them outside the XSLT-processor and pass a flag into the
> > stylesheet.
>
> I still prefer Martin's solution (if it works cross IE/Gecko)

The problem with that is that it only tells you "where you are", once
you've arrived there. If your intention is to serve text/html output
vs. application/xml (or a variant), then by the time you make this
test, you've already completed the HTTP transfer and its headers.

As "All XSLT 1.0 processors are basically equal" (to an amazingly
consistent level for any multi-vendor software product) then you're
left with the question _why_ you'd want to test and discover which
processor you're running under. There's a very narrow window left to
you between "It's too late to do anything about it" and "It doesn't
matter anyway".

I certainly wouldn't build code on the lines of "If I'm running under
XSLT processor <foo>, then assume that DOM feature <bar> is usable".
That's very far from maintainable over time and this is an area
historically of great instability.

Andy Dingley <> wrote:
> VK wrote:
> > I still prefer Martin's solution (if it works cross IE/Gecko)
>
> The problem with that is that it only tells you "where you are", once
> you've arrived there. If your intention is to serve text/html output
> vs. application/xml (or a variant), then by the time you make this
> test, you've already completed the HTTP transfer and its headers.

Sorry to say, but I'm not working with XHTML: first of all I don't like
it, secondly it is just not not supported enough to bother with
alternative solution. I'm using the HTML 4.01 Transitional (see the
link in the previous post). I just need some runtime template
adjustment, mainly in declared namespaces for IE. The first one is VML
namespace (counterpaired with SVG in Gecko/Opera 9 Beta). That could be
scripted over document.namespaces.add later, but why to patch something
later if it can be done on place? The second issue (that was the actual
reason of my post) is the anonymous content. While XBL allows to use
anonymous content on any element, Microsoft Viewlink requires to
pre-declare custom elements in a separate namespace. Doing all this
afterwards over scripting gets too messy and unreliable.

And yes, I know the next arguments - "so use only universally supported
features" Thanks for advise (if it was ment), but with the same
success it can be applied to XSLT itself

I received a virus (which only an idiot would have opened) in a email
from your account at codesmiths.com.

You should be aware of this.

wrote:
> I received a virus (which only an idiot would have opened) in a email
> from your account at codesmiths.com.
>
> You should be aware of this.

"You" means who? Please quote who you are replying to.

VK wrote:
>>You should be aware of this.
> "You" means who? Please quote who you are replying to.

Note too that viruses routinely falsify their sending address. Unless
you've examined the headers in enough detail to guard against that,
you're probably wasting time by reporting 'em, since you're probably
sending mail to the wrong person.