A stylesheet for IE, another one for web browsers

[Spartanicus]

Re: A stylesheet for IE, another one for web browsers

"Jón Fairbairn" <jon.fairbairn@ cl.cam.ac.uk> wrote:
[color=blue][color=green][color=darkred]
>> >The .php script can sniff the browser[/color]
>>
>> No it can't.[/color]
>
>Well, it can, but if it smells fish it can't know whether it
>is fish.[/color]

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]

Re: A stylesheet for IE, another one for web browsers

On Mon, 17 Jan 2005, Spartanicus wrote:
[color=blue]
> "Jón Fairbairn" <jon.fairbairn@ cl.cam.ac.uk> wrote:
>[color=green][color=darkred]
> >> >The .php script can sniff the browser
> >>
> >> No it can't.[/color]
> >
> >Well, it can, but if it smells fish it can't know whether it
> >is fish.[/color]
>
> 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][/color]

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]

Re: A stylesheet for IE, another one for web browsers

Spartanicus <me@privacy.net > writes:
[color=blue]
> "Jón Fairbairn" <jon.fairbairn@ cl.cam.ac.uk> wrote:
>[color=green][color=darkred]
> >> >The .php script can sniff the browser
> >>
> >> No it can't.[/color]
> >
> >Well, it can, but if it smells fish it can't know whether it
> >is fish.[/color]
>
> 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][/color]

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

I think you missed the joke :-(

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

[Spartanicus]

Re: A stylesheet for IE, another one for web browsers

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

[UA sniffing]
[color=blue]
>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[/color]

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]

Re: A stylesheet for IE, another one for web browsers

"Jón Fairbairn" <jon.fairbairn@ cl.cam.ac.uk> wrote:
[color=blue][color=green][color=darkred]
>> >> >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.[/color]
>>
>> 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][/color]
>
>Smells like fish to me. I've no idea whether it is fish though.
>
>I think you missed the joke :-([/color]

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

[Alan J. Flavell]

Re: A stylesheet for IE, another one for web browsers

On Tue, 18 Jan 2005, Spartanicus wrote:
[color=blue]
> "Alan J. Flavell" <flavell@ph.gla .ac.uk> wrote:
>
> [UA sniffing]
>[color=green]
> >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[/color]
>
> I know little about HTTP,[/color]

I fear that we're headed to far off-topic for this group, and would do
better to get our ideas peer-reviewed on a group that deals with
servers; but at least let me say this much...
[color=blue]
> 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.[/color]

Good point. The client agent talks HTTP to the proxy; the proxy talks
HTTP to the origin server; but the two transactions are quite
separate, even though the UA header will normally be passed-through
(possibly modified).

In any realistic implementation, any UA-dependent modification of the
HTTP transaction details would be a downgrading to some older or
simpler procedure that was thought to be more reliably implemented,
albeit maybe less efficient etc. This would do the proxy no harm,
even if the proxy didn't in fact need the downgrading for the reason
that you've rightly pointed out.
[color=blue]
> Afaik proxies are not required or supposed to
> alter the UA string,[/color]

Actually, there -is- a convention for the proxy to make itself known
by means of "via" detail appended to the agent string. Google
suggests http://www.philosophe.com/audience/s...agent_log.html for
examples (look for user agent strings with "Via" in them).

But I see that our campus proxy (squid) is no longer doing this:
instead, it's adding HTTP Via: and X-Forwarded-For: headers, and
leaving the user agent alone.

Certainly there's no -requirement- for a modification, or for any
other extra information. Indeed, the whole point of privacy proxies
would be to -remove- such otherwise-informative details!!
[color=blue]
> making UA sniffing for the purpose of avoiding
> limitations in UA HTTP protocol support fundamentally flawed.[/color]

Less than ideal, I agree: but still feasible, I'd say. Of course, the
whole idea is to avoid a known bug *by using some other conforming
option of the protocol*. It would be crazy to implement a fixup
method which *relied* on some known bug or shortcoming of a particular
user agent.

hope this makes sense

[Jón Fairbairn]

Re: A stylesheet for IE, another one for web browsers

Spartanicus <me@privacy.net > writes:[color=blue]
> "Jón Fairbairn" <jon.fairbairn@ cl.cam.ac.uk> wrote:[color=green][color=darkred]
> >> >> >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.[/color]
> >I think you missed the joke :-([/color]
>
> Responses on usenet that are not supposed to be taken
> serious are best delineated by adding an emoticon.[/color]

Sorry. I thought the idea of a browser smelling fishy was
silly enough on its own (particularly since the most common
confounding habit is to disguise sweet smelling browsers
with fish :-)
[color=blue]
> I read it as "you can find out the browser used, but it
> may not be correct".[/color]

Ah. I meant "you can sniff all you like but the smell you
get doesn't tell you about the browser.".

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

[Jón Fairbairn]

Re: CSS and IE's CC evaluation (Was: Re: A stylesheet for IE, another one for web browsers)


Apologies for delayed followup.

Jan Roland Eriksson <jrexon@newsguy .com> writes:
[color=blue]
> On 09 Jan 2005 12:24:39 +0000, "Jón Fairbairn"
> <jon.fairbairn@ cl.cam.ac.uk> wrote:
>[color=green]
> >Daniel Déchelotte <maitre_yodan@f r.club-internet.invali d> writes:[color=darkred]
> >> 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:[/color][/color]
>
> [...]
>[color=green][color=darkred]
> >> I am wondering whether a better method exists, especially one that would:
> >> * not rely on a IE bug to hide the CSS file[/color][/color]
>
> [...]
>[color=green]
> >I have no idea whether this would work (don't have IE
> >handy), but what does IE make of something like this:
> >
> ><!--[IF IE]>
> ><![IF !IE]>
> ><![endif]-->
> >baz
> ><!--[IF IE]>
> ><![endif]>
> ><![endif]-->
> >
> >-- for everything else it's just baz surrounded by a pair of
> > comments?[/color]
>
> As reported, at least by Daniel, this CC attempt is "working" but it
> also made me think a bit about what is really happening inside IE in
> that case. Let's structure the "code" a bit at first.
>
> 1. <!--[IF IE]>
> 2. <![IF !IE]>
> 3. <![endif]-->
> 4. baz
> 5. <!--[IF IE]>
> 6. <![endif]>
> 7. <![endif]-->
>
> I have always assumed that IE's CC evaluation is based on some form of
> standard principle, similar to how conditional execution would take
> place in any other "programmin g language". In which case I can not see
> how that CC "code snip" could hide 'baz' from IE in the first place.[/color]

When I wrote it, I didn't have chance to check it on IE. Not
knowing how IE really works, I chose something that would
work under two of the numerous possibilities, namely a
macro-preprocessor and cautious bracket matching. (I don't
even know whether IE interprets nesting of conditional
comments; after all, if IE inside if not IE is a little bit
strange).

Given the more likely cautios bracket matching, the code
would be interpreted like this:
[color=blue]
> 1. <!--[IF IE]> -- (1)
> 2. <![IF !IE]> -- (2)
> 3. <![endif]--> -- non-matching endif (because of the "--"
> 4. baz
> 5. <!--[IF IE]> -- nested conditional
> 6. <![endif]> -- matches (2), so error recovery closes the[/color]
nested conditional, and then (2)[color=blue]
> 7. <![endif]--> -- closes (1)
>
> It would be really good, from a practical standpoint, to
> find a reliable way to exclude some CSS from IE all
> together, but I can not make the ins and outs of the
> presented "code", as seen in the light of a report that it
> really does "work" as expected?
>
> What gives?[/color]

I think the above is a plausible explanation. However, even
Daniel Déchelotte's neater version of the code cannot be
relied upon. The *only* thing we can assume will work in
future versions of IE is the invalid (from an html point of
view) syntax given in Microsoft's description of conditional
comments.

After all, it would have been perfectly possible for them to
have chosen a syntax something like this:

<!--[IF IE]>
stuff to be processed by IE, cannot contain comment sequences.
<![else]-->
stuff to be processed by non-IE
<!--[endif]-->

or handle the not IE case thus:

<!--[IF !IE]-->
stuff to be processed by non-IE
<!--[endif]-->

I disdain to comment on whether their choice reflects
<del>malice</del><ins>sound commercial practice</ins> or
language design incompetence.


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