IE7 is suppose to be pretty decent with CSS. In fact I know that several
hacks to get IE6 to look right, actually screw up IE7. Also, sending out
the xml header throws a monkey wrench into how IE6 renders the page. It
forces it into quirks mode. Getting rid of the xml header has fixed some
problems with IE6 showing content from Lenya. Our sister organization
uses TYPO3. When I mentioned to them to drop the xml header, things
started to work better for them as well. They had to remove some IE6
hacks at that point.
[EMAIL PROTECTED] wrote:
Hi Martin,
Many thanks for the links!
We looked at using IE conditional comments, but decided against them
because using the "not IE" style comments invalidates our XHTML (and
also, the way we've got Lenya set up, Lenya, rightly, complains). Plus
We're not prepared to accommodate Microsoft's inability or
unwillingness to make a standards-compliant browser. Currently our
(fully standards-compliant pages) render perfectly in Opera, FF,
Safari, Lynx, PalmOS etc. but look worse in IEn - IE7 than if
stylesheets are switched off altogether.
Without Lenya (or a similar less superior system), we'd be back to the
old days of plain pages or ugly hacks (thanks guys!).
Whilst browser sniffing has the side-effect of allowing us completely
to isolate the CSS we chuck at IE, the main reason we're using it is
to spot Lynx and PalmOS for now (we'll probably add MSPIE at some point).
For now we're only switching CSS based on the user agent. It might be
useful to switch more (e.g., have page2xhtml-page-palmos.xsl, switch
image sizes / types etc.). Has anyone tried this? If yes, is it
practical maintaining such a multiplicity of xsls? Presumably it's
better to have multiple xsls than to have one big xsl per doctype that
has lots of choose / when / otherwise based on various request
variables. (In practice what we've got now is a series of css files
e.g., core.css, menu.css, tabs.css (and IE specific versions where
necessary) etc. that get @imported in as needed) as well as imported
xsl templates (e.g., tabs.xsl, menu.xsl etc.) that adapt to e.g.,
different browsers as needed. For now this works well and is managable
but I've no doubt we'll continue to re-factor things as we go).
Regards,
James
On Thu, 26 Oct 2006, Martin Heiden wrote:
Date: Thu, 26 Oct 2006 10:43:04 +0200
From: Martin Heiden <[EMAIL PROTECTED]>
Reply-To: [email protected], Martin Heiden <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[email protected]>
Subject: Re: Using the browser selectors in webapp/sitemap.xmap
Hi!
I wouldn't do it that way because browser sniffing isn't reliable.
You should use IEs conditional comments instead:
http://msdn.microsoft.com/workshop/author/dhtml/overview/ccomment_ovw.asp
But to answer your question: the request-header variables are
documented in the HTTP-RFC. For the User-Agent:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43
A list of user agent strings:
http://www.pgts.com.au/pgtsj/pgtsj0208c.html
regards
Martin
am Mittwoch, 25. Oktober 2006 um 17:58 schrieben Sie:
Hi,
Given IE7's super-dooper standard CSS rendering, I'm trying to serve
alternative CSS links to MSIE browsers.
I've noticed the:
<map:selectors default="browser">
<map:selector name="browser" logger="sitemap.selector.browser"
src="org.apache.cocoon.selection.BrowserSelector">
...
<browser name="explorer" useragent="MSIE"/>
...
bit in webapp/sitemap.xmap. How would we actually use this within
our .xsl
files to select CSS links based on e.g., the useragent?
For now, we've added:
<map:parameter name="browser" value="{request-header:user-agent}"/>
(a lucky guess that seems to work!) to our publication-sitemap.xmap
and pick it up with a:
<xsl:param name="browser"/>
and e.g.,
<xsl:value-of select="$browser" />
What is the best way to do this and are the request-header: variables
etc. documented anywhere?
Regards,
James
--
[EMAIL PROTECTED]
SDF-EU Public Access UNIX System - http://sdf-eu.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
[EMAIL PROTECTED]
SDF-EU Public Access UNIX System - http://sdf-eu.org
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Frovarp
EduTech System Administrator
1-701-231-5127 or
1-800-774-1091
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
