I've searched around the forums for this topic, but tend to either get lots of hits on browser detection (css) or XSLT script parameters. What I need is a combination of both. Explanation below:
I'm trying to build a top level menu that fills the width of the page area. This template applies to multiple top-level sites (multi-territory) deployment and each territory will have a different, variable number of top-level site nodes (between 5 and 8).
My node tree looks something like this:
Content - Territory A (www.mysite.com) -- Top Level Page 1 --- sub pages... -- Top Level Page 2 --- sub pages... -- Top Level Page 3 -- Top Level Page 4 -- Top Level Page 5 - Territory B (www.mysite.be) -- Top Level Page 1 --- sub pages... -- Top Level Page 2 --- sub pages... -- Top Level Page 3 -- Top Level Page 4 -- Top Level Page 5 -- Top Level Page 6
Using a simple XSLT script to select the Top Level pages and render out a:
For modern browsers, life is great. My css has rules like:
#nav { display: table; width: 916px; etc... }
#nav ul { display: table-row; etc... }
#nav ul li { display: table-cell; etc... }
This effectively spreads the <li> items out and they render like a table. If you added another top level page, the menu widths would automatically balance themselves out.
So the problem... IE does not support display: (anything to do with table). Surprise! surprise! IE doesn't work - who would have seen that coming?!?!? (sarcasm)
Unfortunately, targeting IE with a conditional CSS selector like:
<!--[if IE]> Special instructions for IE 6 here <![endif]-->
... is not going to help me. I cannot achieve the effect I need with CSS.
What I really need is to alter my NavigationMenu.xslt script and have it render a <table> when the browser is IE...
<xsl:choose> <xsl:when test="$browserName = 'IE'"> output menu with table, using for-each here... </xsl:when> <xsl:otherwise> output menu with ul list, using for-each here... </xsl:otherwise> </xsl:choose>
</xsl:stylesheet>
The question, whats the most straightforward way of getting the $browserName parameter set from the calling Page / Template / Macro.
I'm wondering if something like <xsl:variable name="browserName" select="umbraco.library:RequestServerVariables('HTTP_USER_AGENT')" /> would work, if I could wrap another function around that to search for an IE user agent?
Thanks for having a go at it Dan. The system-property(...) bit returns the server-side xslt processor capabilities and I'm looking for the client-side browser user_agent.
If I didn't make my original post clear though - let me know. It was a bit of a long one.
I'm busy testing out an idea and will post back if it works out.
If your test is only to check if the browser is IE, then the xsl:vendor thing may work? Check the source of http://documenta.rudolphina.org/c-cond-html.xsl and you can see how he is targeting IE in only xslt.
Of course, you could always do it with javascript (such as http://sites.google.com/site/fluwijqueryplugin/), ; I'd put something like this into the "non-essential, progressive enhancement" box. Using JS would also have the positive side-effect of not having to use tables for navigation
@Dan Ah ok - I'll go and look it up again. Initially it didn't seem logical that those properties would relate back to the user_agent...
I had pretty much completed the table option in the end anyway. The <table> is targeted to IE6 & 7 and its specifically to deal with IE6 & IE7's non-standard's compliance. Therefore I don't feel so dirty by feeding just IE6 & 7 a non-standard's compliant solution to deal with their behaviour.
<xsl:otherwise> ...more usable <ul> based solution here... </xsl:otherwise>
</xsl:choose>
... that pretty much did the job.
I'd been working with Umbraco 3.x mostly and definitely liking the inclusion of Exslt in the 4.x branch. Its been made really easy to use so credit to the core team!
Sorry Dan - can't give you much credit for your help :(
"
You cannot
vote yet
You need at least 70 karma points to be able to
rate items on our.umbraco.org
You gain karma points every time
you do something constructive, like answering topics on the forum, or
starting new ones or publishing your work as a project"
Heh no worries! You can probably mark a post as solved though? This doesn't give any Karma out (any more, AFAIK) but does help new users find answers to their problems - if they can see a post is marked as solved, they know there's a good chance of getting a bit of useful info from the thread.
Karma is just a nice (recently added) side-effect of helping out newer members. Without the forum when I started with umbraco I probably would have given up ;-)
Browser detection and parameter to XSLT script
I've searched around the forums for this topic, but tend to either get lots of hits on browser detection (css) or XSLT script parameters. What I need is a combination of both. Explanation below:
I'm trying to build a top level menu that fills the width of the page area. This template applies to multiple top-level sites (multi-territory) deployment and each territory will have a different, variable number of top-level site nodes (between 5 and 8).
My node tree looks something like this:
Content
- Territory A (www.mysite.com)
-- Top Level Page 1
--- sub pages...
-- Top Level Page 2
--- sub pages...
-- Top Level Page 3
-- Top Level Page 4
-- Top Level Page 5
- Territory B (www.mysite.be)
-- Top Level Page 1
--- sub pages...
-- Top Level Page 2
--- sub pages...
-- Top Level Page 3
-- Top Level Page 4
-- Top Level Page 5
-- Top Level Page 6
Using a simple XSLT script to select the Top Level pages and render out a:
<div id="nav">
<ul>
<li><a href...>Page 1</a></li>
<li><a href...>Page 2</a></li>
etc..
</ul>
</div>
For modern browsers, life is great. My css has rules like:
#nav {
display: table;
width: 916px;
etc...
}
#nav ul {
display: table-row;
etc...
}
#nav ul li {
display: table-cell;
etc...
}
This effectively spreads the <li> items out and they render like a table. If you added another top level page, the menu widths would automatically balance themselves out.
So the problem... IE does not support display: (anything to do with table). Surprise! surprise! IE doesn't work - who would have seen that coming?!?!? (sarcasm)
Unfortunately, targeting IE with a conditional CSS selector like:
<!--[if IE]>
Special instructions for IE 6 here
<![endif]-->
... is not going to help me. I cannot achieve the effect I need with CSS.
What I really need is to alter my NavigationMenu.xslt script and have it render a <table> when the browser is IE...
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxml="urn:schemas-microsoft-com:xslt"
xmlns:umbraco.library="urn:umbraco.library" xmlns:Exslt.ExsltCommon="urn:Exslt.ExsltCommon" ...">
<xsl:output method="xml" omit-xml-declaration="yes" />
<xsl:param name="browserName"/>
...
<xsl:choose>
<xsl:when test="$browserName = 'IE'">
output menu with table, using for-each here...
</xsl:when>
<xsl:otherwise>
output menu with ul list, using for-each here...
</xsl:otherwise>
</xsl:choose>
</xsl:stylesheet>
The question, whats the most straightforward way of getting the $browserName parameter set from the calling Page / Template / Macro.
I'm wondering if something like <xsl:variable name="browserName" select="umbraco.library:RequestServerVariables('HTTP_USER_AGENT')" /> would work, if I could wrap another function around that to search for an IE user agent?
http://www.w3schools.com/xsl/func_systemproperty.asp might do the trick for you. (also see http://documenta.rudolphina.org/cond-css-demo.xml)
Dan
Thanks for having a go at it Dan. The system-property(...) bit returns the server-side xslt processor capabilities and I'm looking for the client-side browser user_agent.
If I didn't make my original post clear though - let me know. It was a bit of a long one.
I'm busy testing out an idea and will post back if it works out.
If your test is only to check if the browser is IE, then the xsl:vendor thing may work? Check the source of http://documenta.rudolphina.org/c-cond-html.xsl and you can see how he is targeting IE in only xslt.
Of course, you could always do it with javascript (such as http://sites.google.com/site/fluwijqueryplugin/), ; I'd put something like this into the "non-essential, progressive enhancement" box. Using JS would also have the positive side-effect of not having to use tables for navigation
Dan
@Dan Ah ok - I'll go and look it up again. Initially it didn't seem logical that those properties would relate back to the user_agent...
I had pretty much completed the table option in the end anyway. The <table> is targeted to IE6 & 7 and its specifically to deal with IE6 & IE7's non-standard's compliance. Therefore I don't feel so dirty by feeding just IE6 & 7 a non-standard's compliant solution to deal with their behaviour.
<xsl:variable name="ieUserAgentMatches" select="Exslt.ExsltRegularExpressions:match(umbraco.library:RequestServerVariables('HTTP_USER_AGENT'), 'MSIE [67]\.0', 'gi')"/>
<xsl:choose>
<xsl:when test="count($ieUserAgentMatches) > 0">
<table>
etc.....
</xsl:when>
<xsl:otherwise> ...more usable <ul> based solution here... </xsl:otherwise>
</xsl:choose>
... that pretty much did the job.
I'd been working with Umbraco 3.x mostly and definitely liking the inclusion of Exslt in the 4.x branch. Its been made really easy to use so credit to the core team!
Sorry Dan - can't give you much credit for your help :(
"
You cannot vote yet
You need at least 70 karma points to be able to rate items on our.umbraco.org
You gain karma points every time you do something constructive, like answering topics on the forum, or starting new ones or publishing your work as a project"
Heh no worries! You can probably mark a post as solved though? This doesn't give any Karma out (any more, AFAIK) but does help new users find answers to their problems - if they can see a post is marked as solved, they know there's a good chance of getting a bit of useful info from the thread.
Karma is just a nice (recently added) side-effect of helping out newer members. Without the forum when I started with umbraco I probably would have given up ;-)
Dan
is working on a reply...