I'm getting the weirdtest error. I've done a multisite implementation of umbraco where I have 3 sites, each with their own google maps implementation running under their own domain name. Because of this, they have separate API keys, so I've created a macro to generate the google maps api script, but my xslt dosn't work in firefox or ie. Works fine in safari and chrome, so I looked at the output and there are subtle differences
You legend. Thank you. It's strange behaviour that I have to do something explicit to keep a script tag open - I guess it's the XSLT engine in firefox/ie that cause this to happen
If the output method of your xslt file is "xml" it will self close any empty tags, and athough using "html" as the output method should sort these problem it can create others when attempting to validate code as xhtml, e.g.
<br> <img src="wha.jpg"> <br>
So forcing a comment seems to be the most commonly used method to stop self-closing elements here.
What's new to me is that chrome does this "correctly". The (x)html should be being rendered server-side and not in the browser, so it may be that chrome takes it upon iself to "fix" this code so that it works, whereas firefox accepts it as-is. This theory could use some testing though!
That is a very useful snippet of information to know - about the output method. I've never delved this deeply into XSLTs before.I also found the cross browser behaviour strange which led me to (mistakenly) think the code would be compiled client side. Thanks for your solution though.
Just had a thought - Surely since most XSLTs used in Umbraco are used to generate HTML rather than XML, surely it should be the default output type. That would at least cause people to validate their HTML output correctly. I will go and change all my XSLT macros that output HTML directly and test them
Hi Carl - while the behaviour is different between browsers, we should make it clear that the actual output generated is the same - it's only when you use the inspector tools you get the different views (self-closing or with explicit close-tag). If you use view the source, it's a self-closing tag in all browsers. So it's the browser's interpretation of the elements that are different.
The really cool thing about the output method is that if you supply the doctype attributes (doctype-public + doctype-system) for XHTML, theoretically you should be able to use output method="xml" and NOT get self-closing script + div tags, because the processor knows which doctype or "language" to output... but that doesn't work in the .NET XSLT processor (Saxon does it right, though...).
XSLT Differences in firefox and chrome
Hi all
I'm getting the weirdtest error. I've done a multisite implementation of umbraco where I have 3 sites, each with their own google maps implementation running under their own domain name. Because of this, they have separate API keys, so I've created a macro to generate the google maps api script, but my xslt dosn't work in firefox or ie. Works fine in safari and chrome, so I looked at the output and there are subtle differences
First this is the XSLT
<xsl:template match="/">
<xsl:variable name="apiKey" select="$currentPage//data [@alias ='apiKey']" />
<script>
<xsl:attribute name="src">
<xsl:text>http://maps.google.com/maps?file=api&v=3&key=</xsl:text>;
<xsl:value-of select="$apiKey" />
</xsl:attribute>
<xsl:attribute name="type" >text/javascript</xsl:attribute>
</script>
<script>
<xsl:attribute name="src">
<xsl:text>http://www.google.com/uds/api?file=uds.js&v=3.0&key=</xsl:text>;
<xsl:value-of select="$apiKey" />
</xsl:attribute>
<xsl:attribute name="type" >text/javascript</xsl:attribute>
</script>
</xsl:template>
The difference appears to only be the closing script tag, but it's broken firefox. Any ideas?
This is what firefox generates (does not work)
<script src="http://maps.google.com/maps?file=api&v=3&key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" />
<script src="http://www.google.com/uds/api?file=uds.js&v=3.0&key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" />
<script src="/scripts/GoogleMaps.js" type="text/javascript"></script>
This is what chrome generates (works)
<script src="http://maps.google.com/maps?file=api&v=3&key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" /></script>
<script src="http://www.google.com/uds/api?file=uds.js&v=3.0&key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" /></script>
<script src="/scripts/GoogleMaps.js" type="text/javascript"></script>
Hi Carl
Try putting
before your closing script tag - this will force an html comment tag and keep the script tag from self-closing
Cheers,
Dan
Hi Dan
You legend. Thank you. It's strange behaviour that I have to do something explicit to keep a script tag open - I guess it's the XSLT engine in firefox/ie that cause this to happen
thanks,
Carl
If the output method of your xslt file is "xml" it will self close any empty tags, and athough using "html" as the output method should sort these problem it can create others when attempting to validate code as xhtml, e.g.
So forcing a comment seems to be the most commonly used method to stop self-closing elements here.
What's new to me is that chrome does this "correctly". The (x)html should be being rendered server-side and not in the browser, so it may be that chrome takes it upon iself to "fix" this code so that it works, whereas firefox accepts it as-is. This theory could use some testing though!
That is a very useful snippet of information to know - about the output method. I've never delved this deeply into XSLTs before.I also found the cross browser behaviour strange which led me to (mistakenly) think the code would be compiled client side. Thanks for your solution though.
Just had a thought - Surely since most XSLTs used in Umbraco are used to generate HTML rather than XML, surely it should be the default output type. That would at least cause people to validate their HTML output correctly. I will go and change all my XSLT macros that output HTML directly and test them
Hi Carl - while the behaviour is different between browsers, we should make it clear that the actual output generated is the same - it's only when you use the inspector tools you get the different views (self-closing or with explicit close-tag). If you use view the source, it's a self-closing tag in all browsers. So it's the browser's interpretation of the elements that are different.
The really cool thing about the output method is that if you supply the doctype attributes (doctype-public + doctype-system) for XHTML, theoretically you should be able to use output method="xml" and NOT get self-closing script + div tags, because the processor knows which doctype or "language" to output... but that doesn't work in the .NET XSLT processor (Saxon does it right, though...).
/Chriztian
is working on a reply...