A stylesheet for IE, another one for web browsers

[Daniel Déchelotte]

Hi,

Once I was happy with my new deezign[1], I noticed how bad it breaks in IE
(all versions I tried). Since IE7[2] didn't give acceptable results, I
wrote a simplified style that I would fetch to IE. How to do it is the
point of my post.

I am using for now conditional comment[3] (clean) to give IE its CSS, and a IE
parsing bug[4] (not clean) to hide the real CSS from IE:

<!--[if IE]>
<link rel="stylesheet " type="text/css" href="site-IE.css">
<script src="navbar.js" type="text/javascript"></script>
<![endif]-->
<style type="text/css"><!-- @import url(site.css) all; --></style>

I am wondering whether a better method exists, especially one that would:
* not rely on a IE bug to hide the CSS file
* not break HTML validation (no <![if !IE]>...<![endif]>)
* provide good browsers with the two alternative stylesheets
* deal with several CSSes: all pages include (by SSI) site.css (or
site-IE.css), but some also include pro.css (resp. pro-IE.css), some
others perso.css (or perso-IE.css) (if I read the specs correctly,
<link rel="alternate stylesheet" ...> cannot fulfill this requirement)

A method that solves just one of the four points above would already be
great!

[1] http://yo.dan.free.fr/
[2] http://dean.edwards.name/IE7/
[3] http://msdn.microsoft.com/workshop/a...omment_ovw.asp
[4] http://www.phoenity.com/newtedge/hide_css_ie/

PS: I take this post as an opportunity to thank those who ansered my newbie
questions a while ago, and to thank everyone who intervenes in this forum:
you are definitely helping more than one person when you answer one
question! (I have been lurking for quite a while, as obviously many others
do.)

--
Daniel Déchelotte
http://yo.dan.free.fr/

[Daniel Déchelotte]

Dave Anderson a écrit :

| Daniel Déchelotte wrote:
|
| > 1. <!--[if IE]>
| > 2. <![if !IE]>
| > 3. < -->
| > 4. <p>Read by browsers, ignored by IE
| > 5. <!-- >
| > 6. <![endif]>
| > 7. <![endif]-->
|
| I've never seen whatever information Microsoft provides about how
| "conditiona l comments" *should* work and I don't have IE here to test
| with but, assuming that this was implemented in some vaguely rational
| manner (which I admit is a big assumption), shouldn't this simple code
| work:
|
| <!--[if !IE]-->
| <p>read by browsers, ignored by IE
| <!--[endif]-->

Nope, and it breaks strangely, as IE displays everything, including the
comments! Well, as proprietary as they are, CCs follow a syntax, described
at the page I gave in my original post (reference [3]). ;-)

In an attempt to summarize the thread, the minimum code would be:

<!--[if IE]>
... IE specific code here ...
<![if !IE]>< -->
... non-IE code here ...
<!-- ><![endif]><![endif]-->

W3C and Microsoft compliant, if not terribly legible.

--
Daniel Déchelotte
http://yo.dan.free.fr/

[Jan Roland Eriksson]

On Wed, 12 Jan 2005 17:53:14 +0100, Daniel Déchelotte
<ma**********@f r.club-internet.invali d> wrote:

Dave Anderson a écrit : | Daniel Déchelotte wrote:
| ...shouldn't this simple code work:
|
| <!--[if !IE]-->
| <p>read by browsers, ignored by IE
| <!--[endif]--> Nope... [...]In an attempt to summarize the thread,
the minimum code would be:

<!--[if IE]>
... IE specific code here ...
<![if !IE]>< -->
... non-IE code here ...
<!-- ><![endif]><![endif]-->

W3C and Microsoft compliant, if not terribly legible.

Thanks for the investigation guys.

I'm saving this thread for a new entry in the ciwas authoring FAQ.

--
Rex

[Ian Hobson]

In message
<20************ *************** *******@fr.club-internet.invali d>, Daniel
Déchelotte <ma**********@f r.club-internet.invali d> writes

| >not rely on a IE bug to hide the CSS file

I don't know if it helps any, but I have set up a style sheet in php.

The .php script can sniff the browser and generate a style sheet that
differs in just the necessary ways.

(It can also propagate color/colour changes through the css, which si
why I did it).

You need to start it with...

<?php
header("Content-type: text/css");

and then go on to generate the rest, or it is not recognised by some
browsers.

Regards

Ian

--
Ian - posting to a Newsgroup. Please remove everything to reply.

[Spartanicus]

Ian Hobson <Ne*******@ntlw orld.everything .com> wrote:

The .php script can sniff the browser

No it can't.

--
Spartanicus

[Jón Fairbairn]

Spartanicus <[e-mail] > writes:

Ian Hobson <Ne*******@ntlw orld.everything .com> wrote:

The .php script can sniff the browser

No it can't.

Well, it can, but if it smells fish it can't know whether it
is fish.

--
Jón Fairbairn Jo***********@c l.cam.ac.uk

[Spartanicus]

"Jón Fairbairn" <jo***********@ cl.cam.ac.uk> wrote:

>The .php script can sniff the browser

No it can't.

Well, it can, but if it smells fish it can't know whether it
is fish.

Then please tell me which browser I'm using:

+++GET 2+++
GET /TR/REC-CSS2/ HTTP/1.1
User-Agent: Code to W3C standards and stop that idiotic browser sniffing
(My OS; U) [en]

--
Spartanicus

[Alan J. Flavell]

On Mon, 17 Jan 2005, Spartanicus wrote:

"Jón Fairbairn" <jo***********@ cl.cam.ac.uk> wrote:

>The .php script can sniff the browser

No it can't.

Well, it can, but if it smells fish it can't know whether it
is fish.

Then please tell me which browser I'm using:

+++GET 2+++
GET /TR/REC-CSS2/ HTTP/1.1
User-Agent: Code to W3C standards and stop that idiotic browser sniffing
(My OS; U) [en]

Well, yes; but there are other considerations. And you *could* take
the view that if the client agent tells lies, then it deserves
whatever the server sends it.

Of course, the original statement would better have said something
like "the .php script can sniff what the client agent says it is, if
anything". But what conclusion do we draw from that observation?

The HTTP spec reminds us (see RFC2616 section 14.43) that this header
is optional, and could be used for statistical purposes (I've no
argument with that, as long as one understands its [un]reliability and
doesn't draw untenable conclusions from the results); for tracing of
protocol violations (yup), or for "tailoring responses to avoid
particular user agent limitations".

Now, this last is the one that I have a problem with, in the present
context. My *hunch* is that the RFC authors were thinking in terms of
modifying the *HTTP protocol response* to avoid certain user agent
limitations of HTTP support - you might recall stanzas of this kind in
Apache configurations:

SetEnvIf User-Agent ".*MSIE.*" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0

But if, on the other hand, you're using this to vary not just the
protocol response but even the contents of the actual response body,
then you have a server-negotiated response body which varies according
to the user-agent string - thus, your negotiated response shall
include a "Vary: User-Agent" header, and this is very hostile to
cacheability. (Mark Nottingham's tutorial applies - not that I'd need
to tell -you- that!).

If, on the other hand, you send a carefully-designed *static*
response, which capitalises on some known shortcoming of the affected
browser, then you can be sure that it will have its intended effect no
matter what untruths the browser might tell in its user-agent string,
and *without* the slightest harmful effect on other users. Examples
of this general idea are the "hiding advanced CSS from browsers"
techniques discussed at
http://w3development.de/css/hide_css_from_browsers/

Then again, there's MSIE's conditional comments wibble, which - as
long as one confines oneself to the subset that is decent HTML syntax,
seems to me to be OK as a practice, even if the very idea can be rated
as pandering to something that's determined not to support published
interworking specifications.

So, in conclusion, my argument against server-varied response
documents depending on user-agent string are not merely that it's
unreliable in practice, but that it can cause degraded performance to
a wide range of users, with possibly serious degradation for those who
are behind a cache server proxy.

[Jón Fairbairn]

Spartanicus <[e-mail] > writes:

"Jón Fairbairn" <jo***********@ cl.cam.ac.uk> wrote:

>The .php script can sniff the browser

No it can't.

Well, it can, but if it smells fish it can't know whether it
is fish.

Then please tell me which browser I'm using:

+++GET 2+++
GET /TR/REC-CSS2/ HTTP/1.1
User-Agent: Code to W3C standards and stop that idiotic browser sniffing
(My OS; U) [en]

Smells like fish to me. I've no idea whether it is fish though.

I think you missed the joke :-(

--
Jón Fairbairn Jo***********@c l.cam.ac.uk

[Spartanicus]

"Alan J. Flavell" <fl*****@ph.gla .ac.uk> wrote:

[UA sniffing]

The HTTP spec reminds us (see RFC2616 section 14.43) that this header
is optional, and could be used for statistical purposes (I've no
argument with that, as long as one understands its [un]reliability and
doesn't draw untenable conclusions from the results); for tracing of
protocol violations (yup), or for "tailoring responses to avoid
particular user agent limitations".

Now, this last is the one that I have a problem with, in the present
context. My *hunch* is that the RFC authors were thinking in terms of
modifying the *HTTP protocol response* to avoid certain user agent
limitations of HTTP support

I know little about HTTP, but afaik HTTP protocol support of the UA
doesn't matter if the connection is via a proxy, only the proxy's HTTP
protocol support matters. Afaik proxies are not required or supposed to
alter the UA string, making UA sniffing for the purpose of avoiding
limitations in UA HTTP protocol support fundamentally flawed.

--
Spartanicus

[Spartanicus]

"Jón Fairbairn" <jo***********@ cl.cam.ac.uk> wrote:

>> >The .php script can sniff the browser
>>
>> No it can't.
>
>Well, it can, but if it smells fish it can't know whether it
>is fish.

Then please tell me which browser I'm using:

+++GET 2+++
GET /TR/REC-CSS2/ HTTP/1.1
User-Agent: Code to W3C standards and stop that idiotic browser sniffing
(My OS; U) [en]

Smells like fish to me. I've no idea whether it is fish though.

I think you missed the joke :-(

Responses on usenet that are not supposed to be taken serious are best
delineated by adding an emoticon.

I read it as "you can find out the browser used, but it may not be
correct". This is not correct since as Alan pointed out the User-Agent
header is optional, and the string may not contain a reference to a UA
at all.

--
Spartanicus