Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Carl 65 posts 87 karma points MVP
    Jul 19, 2010 @ 18:48
    Carl
    0

    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&amp;v=3&amp;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&amp;v=3.0&amp;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&amp;v=3&amp;key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" />
    <script src="http://www.google.com/uds/api?file=uds.js&amp;v=3.0&amp;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&amp;v=3&amp;key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" /></script>
    <script src="http://www.google.com/uds/api?file=uds.js&amp;v=3.0&amp;key=ABQIAAAAP6x8GjzhKnwovAQF9kJJ9xSYiKF5f3oB6h54jfSipAxF8jD1EhR0SbBJDTxkdICf9yXYwazTfUxSUQ" type="text/javascript" /></script>
    <script src="/scripts/GoogleMaps.js" type="text/javascript"></script>

     

  • dandrayne 1138 posts 2262 karma points
    Jul 19, 2010 @ 18:59
    dandrayne
    0

    Hi Carl

    Try putting

    <xsl:comment />

    before your closing script tag - this will force an html comment tag and keep the script tag from self-closing

    Cheers,
    Dan

  • Carl 65 posts 87 karma points MVP
    Jul 19, 2010 @ 19:29
    Carl
    0

    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

  • dandrayne 1138 posts 2262 karma points
    Jul 19, 2010 @ 19:37
    dandrayne
    0

    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!

  • Carl 65 posts 87 karma points MVP
    Jul 19, 2010 @ 20:38
    Carl
    0

    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.

     

  • Carl 65 posts 87 karma points MVP
    Jul 19, 2010 @ 20:43
    Carl
    0

    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

  • Chriztian Steinmeier 2733 posts 8347 karma points MVP 5x admin c-trib
    Jul 19, 2010 @ 21:53
    Chriztian Steinmeier
    0

    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

Please Sign in or register to post replies

Write your reply to:

Draft