Conditional comments: is this new?

[Benjamin Niemann]

Hello,

I've been just investigating IE conditional comments - hiding things from
non-IE/Win browsers is easy, but I wanted to know, if it's possible to hide
code from IE/Win browsers.
I found <![if ..]> in the original MSDN documentation, but this is (although
it is working) unfortunately non-validating gibberish.
So I fooled around trying to find a way to make it valid. And voila:

<!--[if IE]><![if !IE]><![endif]-->
<p>IE/Win ignores this</p>
<!--[if IE]><![endif]><![endif]-->

Seems like IE has some very strange nesting rules that make a programmers
heart scream in agony...

Did I found something new, or is this common knowledge?

A complete test page can be found at:
http://testbox.puppetmaster.homelinu...ndcomment.html
(warning: DSL connected host with dynamic IP, might be offline once in a
while)

Greetings to you all!

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

[Lachlan Hunt]

Benjamin Niemann wrote:

I've been just investigating IE conditional comments - hiding things from
non-IE/Win browsers is easy, but I wanted to know, if it's possible to hide
code from IE/Win browsers.
Conditional comments are evil for the same reasons that browser sniffing
is evil. See this thread on www-style which has just been discussing
this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

In particular, my post sums up why conditional comments should not be
used, but there's a lot more useful information from other people
elsewhere in the thread too.
http://lists.w3.org/Archives/Public/...5Apr/0072.html
I found <![if ..]> in the original MSDN documentation, but this is (although
it is working) unfortunately non-validating gibberish.
Other than browser sniffing, this is the other reason why conditional
comments are evil, as discussed in bugzilla
https://bugzilla.mozilla.org/show_bug.cgi?id=124751#c10
So I fooled around trying to find a way to make it valid. And voila:

<!--[if IE]><![if !IE]><![endif]-->
<p>IE/Win ignores this</p>
<!--[if IE]><![endif]><![endif]-->
That's a clever way to get around it, but it's still evil. Why do you
want to hide some content from IE, but not other browsers?
Seems like IE has some very strange nesting rules that make a programmers
heart scream in agony...
IE has some very strange behaviour that makes all developer's hearts
scream in agony...
Did I found something new, or is this common knowledge?

Conditional comments have been around since IE 5, as described in the
documentation, so why would they be new?

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Benjamin Niemann]

Lachlan Hunt wrote:

Benjamin Niemann wrote:

I've been just investigating IE conditional comments - hiding things from
non-IE/Win browsers is easy, but I wanted to know, if it's possible to
hide code from IE/Win browsers.
Conditional comments are evil for the same reasons that browser sniffing
is evil. See this thread on www-style which has just been discussing
this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

In particular, my post sums up why conditional comments should not be
used, but there's a lot more useful information from other people
elsewhere in the thread too.
http://lists.w3.org/Archives/Public/...5Apr/0072.html

mmm.. I would consider hacks like

* html div { margin: 20%; }

as being more evil than conditional comments, because it exploits a bug in
IE that might be fixed at any time by MS (whereas the other bugs that you
want to work around with such constructs may remain).

But my intention was not to discuss the evilness of such things - this has
obviously already been done elsewhere.
Thanks for the references. I will have a deeper look at them later.
[snip]

So I fooled around trying to find a way to make it valid. And voila:

<!--[if IE]><![if !IE]><![endif]-->
<p>IE/Win ignores this</p>
<!--[if IE]><![endif]><![endif]-->

That's a clever way to get around it, but it's still evil. Why do you
want to hide some content from IE, but not other browsers?

Nothing particular at the moment. But sometimes conditional comments are
useful (IMHO).
[snip]

Did I found something new, or is this common knowledge?

Conditional comments have been around since IE 5, as described in the
documentation, so why would they be new?

I wanted to know, if my 'clever way to get around it' is new in the meaning
of 'not yet discovered'.

Ciao

--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/

[Lachlan Hunt]

Benjamin Niemann wrote:

Lachlan Hunt wrote:

Benjamin Niemann wrote:

I've been just investigating IE conditional comments - hiding things from
non-IE/Win browsers is easy, but I wanted to know, if it's possible to
hide code from IE/Win browsers.
Conditional comments are evil for the same reasons that browser sniffing
is evil. See this thread on www-style which has just been discussing
this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

In particular, my post sums up why conditional comments should not be
used, but there's a lot more useful information from other people
elsewhere in the thread too.
http://lists.w3.org/Archives/Public/...5Apr/0072.html

mmm.. I would consider hacks like

* html div { margin: 20%; }

as being more evil than conditional comments

CSS hacks are evil too, but their not as evil as conditional comments
because:
* They don't depend on the UA identification.
* When a browser vendor releases a new version that fixes the bugs that
allow the hack and the bugs that require the hack in the first place,
the new version will automatically work like other standards compliant
browsers.
* For conditional comments that test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and update the
version number as required.
* For conditional comments that don't test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and add a version
number so the new version doesn't apply the hack if necessary.
* Conditional comments are nested within the document markup, where each
and every occurance needs to be updated, whereas CSS hacks can be
managed in a single external file.

All forms of hacks inlcuding CSS hacks, conditional comments, javascript
hacks, or whatever should be used sparingly, and browser sniffing should
never be done without an exceptionally good reason.

So far, the *only* possibly acceptable use of a conditional comment I've
seen is for Dean Edward's IE7 script, so that other browsers won't
bother downloading a script they don't need.

Ideally hacks should be used only where absolutely necessary to maintain
accessibility and graceful degredation. Using them to achieve pixel
perfection should generally be avoided, IMHO.
because it exploits a bug in IE that might be fixed at any time by MS
And when it is fixed, the hack should no longer apply! So what's the
problem?
(whereas the other bugs that you want to work around with such
constructs may remain).
There's not as much wrong with exploiting a bug to work around another,
as there is with techniques that assume a single user agent will always
have a bug, or that a bug is associated with particular version numbers.
Although both kinds of techniqes are evil, one is less evil than the
other.
Nothing particular at the moment. But sometimes conditional comments are
useful (IMHO).

I don't want to get involved in another argument about their evilness vs
their usefulness, so no further comment.

Did I found something new, or is this common knowledge?

Conditional comments have been around since IE 5, as described in the
documentation, so why would they be new?

I wanted to know, if my 'clever way to get around it' is new in the meaning
of 'not yet discovered'.

Well, in that case, I've never seen that particular technique before.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

Conditional comments are evil for the same reasons that browser sniffing
is evil. See this thread on www-style which has just been discussing
this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

IIRC that discussion is mainly about the desirability of having CCs for
browsers other than IE, which would likely be misunderstood and misused
by many.

Currently only NS4 and IE5+ have implemented CCs (in a different way),
and there's no evidence that other browser developers are likely to
implement them.

Microsoft's "Uplevel revealed" (cringe on the name) CC's are a 100%
reliable way to feed additional code to IE. The same cannot be said for
"css hacks".

IE's CCs are predominantly used by authors who want to feed good quality
browsers proper code, and feed something propriety or sub standard to
IE.

Microsoft "Downlevel revealed" CCs are a different matter, they cause
validation errors.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

Currently only NS4 and IE5+ have implemented CCs
How did NS4 conditional comments work? I've never heard of them before.
Microsoft's "Uplevel revealed" (cringe on the name)
do you mean "downlevel-hidden"?
Microsoft "Downlevel revealed" CCs are a different matter, they cause
validation errors.

<!--[if IE]>downlevel-hidden conditional comments can cause
validation -- errors too<![endif]--> and their
comment parsing implementation is broken, even
in standards compliance mode -->

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Alan J. Flavell]

On Thu, 7 Apr 2005, Lachlan Hunt wrote:

Conditional comments are evil for the same reasons that browser
sniffing is evil.
I'm not sure that I could agree with that as written.

Conditional comments are evaluated by the browser itself. You /know/
what it's going to do on browsers which are not addressed by it (since
they take the form of HTML comments and will be parsed as such; of
course I would disain to use the other MS variant which causes syntax
validation errors).

"Browser sniffing" mostly turns out to rely on server-side parsing of
user agent strings (that's how the participants seem to be
interpreting it on your cited www-style thread), and that's subject to
a whole catalogue of objections on both practical and theoretical
grounds.
See this thread on www-style which has just been discussing this
very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6
The other deployed technique, as you know, is to capitalise on known
bugs in particular browser/versions - for example to persuade a
particular browser to ignore some stuff that it doesn't properly
support, as discussed in
http://w3development.de/css/hide_css_from_browsers/

But that too is potentially unreliable, since browser developers might
fix one bug without fixing the other(s).

I found <![if ..]> in the original MSDN documentation, but this is
(although it is working) unfortunately non-validating gibberish.

If it doesn't validate, then it can't be said in any real sense to be
working. Even if it does what its misguided inventor intended, it
still isn't "working" in any real WWW-compatible sense.

Well, my objection to IE conditional comments is not that they don't
work reliably, but that they merely confirm the belief that IE is not
a WWW-compatible browser and should not be used as one. And then
there's no further need for this anti-WWW technique. But
unfortunately there's a whole mass of users out there who haven't got
- and presumably won't be likely to get - that message.
IE has some very strange behaviour that makes all developer's hearts
scream in agony...

Amen to that.

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

Currently only NS4 and IE5+ have implemented CCs

How did NS4 conditional comments work? I've never heard of them before.

I'm sure SE's have.

Microsoft's "Uplevel revealed" (cringe on the name)

do you mean "downlevel-hidden"?

Yes (they label IE5 as "Uplevel browser").

Microsoft "Downlevel revealed" CCs are a different matter, they cause
validation errors.

<!--[if IE]>downlevel-hidden conditional comments can cause
validation -- errors too<![endif]--> and their
comment parsing implementation is broken, even
in standards compliance mode -->

Not an argument against proper usage.

--
Spartanicus

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

mmm.. I would consider hacks like

* html div { margin: 20%; }

as being more evil than conditional comments
CSS hacks are evil too, but their not as evil as conditional comments
because:
* They don't depend on the UA identification.

CSS parsing bugs are often shared amongst various browsers, so that's a
reason in *favour* of CCs.
* When a browser vendor releases a new version that fixes the bugs that
allow the hack and the bugs that require the hack in the first place,
the new version will automatically work like other standards compliant
browsers.
And if the CSS parsing bug gets fixed but not the reason for the hack
you are screwed.
* For conditional comments that test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and update the
version number as required.
Same applies to CSS hacks. MS CCs can be limited to current browser
versions with 100% accuracy, so that's another plus for CCs.
* For conditional comments that don't test the version number:
Which is unwise.
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and add a version
number so the new version doesn't apply the hack if necessary.
Same check is necessary with CSS hacks.
* Conditional comments are nested within the document markup, where each
and every occurance needs to be updated, whereas CSS hacks can be
managed in a single external file.

Ever heard of S&R?

--
Spartanicus

[Lachlan Hunt]

Benjamin Niemann wrote:

<!--[if IE]><![if !IE]><![endif]-->
<p>IE/Win ignores this</p>
<!--[if IE]><![endif]><![endif]-->

This is a little less verbose than that, but I still don't approve of
it's usage, under any circumstances.

<!--[if IE 1]>-->IE/Win 5/6 ignores this<!--<![endif]-->

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

[conditional comments]

I still don't approve of
it's usage, under any circumstances.

It's more than a little arrogant to suggest that anyone needs, or should
care about your "approval". Opinions are nice, but unless accompanied by
arguments best kept to yourself.

So far your arguments have been found flawed.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

[conditional comments]

I still don't approve of
it's usage, under any circumstances.
It's more than a little arrogant to suggest that anyone needs, or should
care about your "approval".

I just didn't want it to seem as though my suggestion of a simpler
syntax in any way countered my earlier arguments against their use.
Opinions are nice, but unless accompanied by arguments best kept to yourself.

My arguments were contained in prior postings, I felt no need to repeat
them again.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Frances Del Rio]

Lachlan Hunt wrote:

Benjamin Niemann wrote:

I've been just investigating IE conditional comments - hiding things from
non-IE/Win browsers is easy, but I wanted to know, if it's possible to
hide
code from IE/Win browsers.

Conditional comments are evil for the same reasons that browser sniffing
is evil. See this thread on www-style which has just been discussing
this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

just curious Lachlan, why is browser-sniffing evil? sometimes you DO
have to code stuff differently for diff. browsers b/c diff. browsers
interpret some things differently.. here at work we do webcasts in
Windows Player and Real Audio and slide flips and well, a whole lot of
complex stuff, and we just now started supporting N/FF/M, and we've had
to recode a lot of stuff for these three browsers.. is it wrong in yr
view to do things like, for example

if (navigator.userAgent.indexOf('MSIE') == -1 ) /// etc....

just wondering... thanks... Frances

[Henri Sivonen]

In article
<42**********************@per-qv1-newsreader-01.iinet.net.au>,
Lachlan Hunt <sp***********@gmail.com> wrote:

CSS hacks are evil too, but their not as evil as conditional comments
because:
* They don't depend on the UA identification.
Isn't whole point is to work around the bugs of IE6 specifically?
* When a browser vendor releases a new version that fixes the bugs that
allow the hack and the bugs that require the hack in the first place,
the new version will automatically work like other standards compliant
browsers.
What if selector bugs are fixed but other bugs not? Selectors are easier
to fix than profound layout issues.
* For conditional comments that test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and update the
version number as required.
With a CSS hack, you'd have to test whether the bug the hiding is based
on is fixed but the bug being worked around not.
* Conditional comments are nested within the document markup, where each
and every occurance needs to be updated, whereas CSS hacks can be
managed in a single external file.
What if the conditional comment is in a single file on the server and a
server-side program replicates it?
So far, the *only* possibly acceptable use of a conditional comment I've
seen is for Dean Edward's IE7 script, so that other browsers won't
bother downloading a script they don't need.

Ah, so you approve of that. :-)

Styling fieldsets is borked in IE. What method do you suggest for
serving advanced styles to others and dumbed-down styles to IE?

I'm not a fan of conditional comments, either, but when working around
the bugs of IE, the risk of collateral damage with conditional comments
seems smaller than the risks with selector hacks or UA sniffing.

--
Henri Sivonen
hs******@iki.fi
http://hsivonen.iki.fi/
Mozilla Web Author FAQ: http://mozilla.org/docs/web-developer/faq.html

[Adrienne]

Gazing into my crystal ball I observed Frances Del Rio <fd***@yahoo.com>
writing in news:42***********************@news.sunsite.dk:

Lachlan Hunt wrote:

Benjamin Niemann wrote:

I've been just investigating IE conditional comments - hiding things
from non-IE/Win browsers is easy, but I wanted to know, if it's
possible to hide code from IE/Win browsers.

Conditional comments are evil for the same reasons that browser
sniffing is evil. See this thread on www-style which has just been
discussing this very issue.
http://lists.w3.org/Archives/Public/.../thread.html#6

just curious Lachlan, why is browser-sniffing evil? sometimes you DO
have to code stuff differently for diff. browsers b/c diff. browsers
interpret some things differently.. here at work we do webcasts in
Windows Player and Real Audio and slide flips and well, a whole lot of
complex stuff, and we just now started supporting N/FF/M, and we've had
to recode a lot of stuff for these three browsers.. is it wrong in yr
view to do things like, for example

if (navigator.userAgent.indexOf('MSIE') == -1 ) /// etc....

just wondering... thanks... Frances

I use Opera almost exclusively, and it is really annoying and insulting so
see "This page requires at least IE5 or Netscape 4. Click here to upgrade
your browser". My bank thinks that Opera is not secure enough, so Opera
tricks BofA by indentifying itself as MSIE. Of course, everything works
just fine.

The real problem with browser sniffing, as I see it, is that developers get
lazy and don't bother to check if the page works in other browsers. A lot
of times, it's just bad coding on the developer's part, if the errors
and/or proprietary markup were fixed/removed, then the page would work just
fine.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share

[Lauri Raittila]

in comp.infosystems.www.authoring.html, Frances Del Rio wrote:

just curious Lachlan, why is browser-sniffing evil?
if (navigator.userAgent.indexOf('MSIE') == -1 ) /// etc....

Because you do it wrong (above thing doesn't do anything useful, AFAIK).
And getting it right is not too easy, and is often impossible...

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
Utrecht, NL.
Support me, buy Opera:
https://secure.bmtmicro.com/opera/bu...tml?AID=882173

[Eric Bohlman]

Adrienne <ar********@sbcglobal.net> wrote in
news:Xn****************************@207.115.63.158 :

I use Opera almost exclusively, and it is really annoying and
insulting so see "This page requires at least IE5 or Netscape 4.
Click here to upgrade your browser". My bank thinks that Opera is not
secure enough, so Opera tricks BofA by indentifying itself as MSIE.
Of course, everything works just fine.

I've sometimes come across newspaper sites where, if I let Opera identify
itself honestly, I get a message stating that they haven't yet developed
mobile-friendly content.

The biggest problem with browser sniffing is that it almost always ends up
treating the newest, most capable browsers as if they were the oldest and
least capable. The second-biggest problem is that it requires site
maintenance each time a new browser version comes out.

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

* They don't depend on the UA identification.

CSS parsing bugs are often shared amongst various browsers, so that's a
reason in *favour* of CCs.

/* \*/
* html { ... }
/* */

I believe that will only be applied in IE/Win, so there is no reason to
pollute the document markup with conditional comments to replace CSS hacks.

* When a browser vendor releases a new version that fixes the bugs that
allow the hack and the bugs that require the hack in the first place,
the new version will automatically work like other standards compliant
browsers.

And if the CSS parsing bug gets fixed but not the reason for the hack
you are screwed.

You are screwed by the existence of broken browsers anyway, so nothings
changed.

* For conditional comments that test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and update the
version number as required.

Same applies to CSS hacks. MS CCs can be limited to current browser
versions with 100% accuracy, so that's another plus for CCs.

Yeah, but when a new browser is released with all the same bugs and your
conditionl comments only apply to current versions, your screwed with
either CCs or Doritos.

* For conditional comments that don't test the version number:

Which is unwise.

Testing the version assumes the bugs won't apply in the next release.
Not testing it assumes they will. Either assumption has equal chance of
being incorrect, so you really are screwed either way.

* Conditional comments are nested within the document markup, where each
and every occurance needs to be updated, whereas CSS hacks can be
managed in a single external file.

Ever heard of S&R?

Yes, but that's more difficult than managing a single CSS file and it
doesn't pollute the markup with unnecessary bloat.
There are a number of possibilities after a browser version upgrade,
with relation to the bugs being fixed or not. The following table
indicates the result of using each kind of workaround compared with the
possible browser fixes after a browser version upgrade.

The browser hack and bug columns indicate whether or not the hack/bug
was fixed in a browser version upgrade. The workaround type column
indicates whether or not a change is requred by the author after the
upgrade.

Legend:
Y = Yes (fixed | change requried)
N = No (not fixed | no change required)
Hack = Hack fixed?
Bug = Bug fixed?
CC+v = using conditional comment with version number
CC-v = Using conditional comment without version number
CSS = Using CSS hack

Browser Workaround Type
Hack Bug | CC+v. CC-v. CSS
N N | Y N N
Y N * | Y N Y
N Y | N Y Y
Y Y | N Y N

* It is unlikely that a browser vendor would fix the hacks, without
fixing the bugs that require the hacks because that would result in
many standards compliant pages rendering incorrectly.

CSS hacks also have the benefit of being kept completely seperate from
the markup. Embedding a conditonal comment for the purpose of fixing
presentation is not really achieving that goal.

It is more likely that bugs will be fixed without fixing the hacks or
that both will be fixed together, as that will be the most bugwards
compatible option with the least harmful effect on authors and users.
While it is possible that some individual bugs and hacks will not be
fixed at all, history has shown that significant improvements usually
come with new major versions (ie. that statement does not necessarily
include minor version number updates). Thus, it is more likely that
one or both the hack and bug will be fixed, than it is that neither will
be fixed.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Lachlan Hunt]

Frances Del Rio wrote:

just curious Lachlan, why is browser-sniffing evil?
For several reasons, which I'll do my best to summarise:

* It encourages the development of web pages designed for a select few
browsers, usually the most popular and at the very least, IE.

* This leads to sites that are poorly built and either:
- Simply don't work in any browser, but those tested by the developer
- Putting "best viewed with..." messages on the site,
See the Any Browser campaign: http://www.anybrowser.org/campaign/
- In the worst case, redirecting to an unsupported browser page
whether or not the page acually works in other browsers.
eg. http://www.toontown.com/ (view in anything but IE)
(In that case, it really doesn't work in anything but IE (probably
only IE/Win) which is an example of an exceptionally poorly
built site.)

* Browser sniffing has led to UAs intentionally spoofing their UA
string, so it is unreliable.

* Web sites that are built to follow the standards should work in all
standards compliant browsers without any browser sniffing.

* Authors that rely on browser sniffing to make a site work, all too
often blatently disregard standadrds.

* Browser sniffing is not future proof for any new browser, or even new
versions of existing browsers whether or not version numbers are
tested as well.

* Browser sniffing that doesn't check the version number, inherently
assumes that all future implementations of the same user agent will
still contain the same bugs; however this is not always the case.
sometimes you DO have to code stuff differently for diff. browsers b/c diff.
browsers interpret some things differently..
In which case, you test for the features, not for the browser version.
For example:

if (document.getElementById) {
// this browser supports (some of) the DOM
} else if (document.all) {
// must be old version of IE before DOM support, though these versions
// are obsolete anyway. I think IE5 and later support getElementById.
}

Or, another example for attaching events:

var element = ...;
if (element.addEventListener) {
// Standards compliant DOM supporting UAs.
} else if (element.attachEvent) {
// IE's proprietary extension.
} else if (element.onclick) {
// Obsolete, non-standard method of attaching events for very old
// browsers.
}

Note: Both of those examples are future proof because they continue to
work when new browser versions add support for the standards compliant
methods. Thus, when IE adds support for addEventListener(), the script
will not need to be updated (assuming IE implements it correctly,
without any serious bugs).
here at work we do webcasts in Windows Player and Real Audio and slide
flips and well, a whole lot of complex stuff, and we just now started
supporting N/FF/M, and we've had to recode a lot of stuff for these
three browsers.. is it wrong in yr view to do things like, for example

if (navigator.userAgent.indexOf('MSIE') == -1 ) /// etc....

Absolutely! Such tests are unreliable due to UAs lying about their UA
string. Although, these days, most non-standard IE extensions that are
depended upon by a large number of sites are supported by other browsers
anyway. eg. IE's proprietary document.all was recently implemented in
Mozilla because so many authors use it unnecessarily, despite the fact
that getElementById() serves exactly the same purpose and is standardised.

The proper way to embed media is to use this, which doesn't involve any
browser sniffing.

<object type="video/whatever-it-is" src="video.wmv" ... >
<object type="video/whatever" src="video.real" ... >
(I can't remember the correct file extension for
real player files)
<p>Insert suitable alternate content for user's that don't support
either. You should also include a link to both files so the
user may launch it externally.</p>
</object>
</object>

Unfortunately, broken browsers don't implement that properly, though you
may be able to write a script to handle that when script is available.
Without script available in a broken browser, the users will at least be
able to see the alternate content.

In general, *always* develop for the most standards compliant browser
available using all the standardised methods where possible. Then, add
support for browsers that don't support the standards, as necessary, but
don't sniff the UA string to do so. Test for feature support instead,
as that is both forwards and backwards compatible.

Also, in general, all hacks are evil. However, there are good methods,
acceptable (yet still bad) mehtods and exceptionally bad methods.

* Testing for DOM support is a good method, as shown above.
* CSS hacks are (sometimes) acceptable, yet bad because they depend on
one bug (the hack) to fix another (the bug), which is not totally
future proof, however they do help remove unnecessary bloat
(conditional comments) from the markup.
* Browser sniffing is exceptionally bad and unreliable for all the
reasons I gave earlier.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Alan J. Flavell]

On Fri, 8 Apr 2005, Lachlan Hunt wrote:

Frances Del Rio wrote:

just curious Lachlan, why is browser-sniffing evil?
For several reasons, which I'll do my best to summarise:

[list of actual abuses committed by misguided authors - which, I'm
afraid, are mostly spurious arguments against "browser sniffing"
as a principle]
In general, *always* develop for the most standards compliant
browser available using all the standardised methods where possible.
Then, add support for browsers that don't support the standards, as
necessary,
I don't see anything wrong with that as an idea (although the KISS
principle would tend to steer authors towards simply avoiding making
pages critically reliant on stuff which is known to be wrongly
implemented in browsers).
but don't sniff the UA string to do so.
Good advice indeed.

But my objections to doing it are more along these lines...

Anything which *relies on* client-side scripting (as opposed to merely
using it to make non-essential adjustments when it's available) is
that some users will have it turned-off or filtered out - maybe even
selectively - for untrusted sites, which can make these techniques
ineffective, or even produce illogical results.

Anything which *relies on* (usual litany) server-side adjustments is
criticially dependent on information sent to it by the browser, and
this can be missing or deliberately faked. Worse, it behaves badly in
the face of shared caches.
* Testing for DOM support is a good method, as shown above.
* CSS hacks are (sometimes) acceptable, yet bad because they depend on
one bug (the hack) to fix another (the bug), which is not totally
future proof, however they do help remove unnecessary bloat
(conditional comments) from the markup.
* Browser sniffing is exceptionally bad and unreliable for all the
reasons I gave earlier.

Seems a reasonable summary, modulo the details I mentioned.

thanks

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

CSS parsing bugs are often shared amongst various browsers, so that's a
reason in *favour* of CCs.
/* \*/
* html { ... }
/* */

I believe that will only be applied in IE/Win

Allow me to be sceptical about your belief that you know every css
parser in existence, more so that you've tested them all.

Furthermore it is impossible to allow for future css parsers. If an
upcoming version of a non IE browser has a bug that causes the above css
to be applied, but if it doesn't share the IE problem for which the hack
was deployed your css hack fails. A MS CC would continue to be applied
only to IE.
so there is no reason to
pollute the document markup with conditional comments to replace CSS hacks.
For non IE parsers CCs are just comments, ignored, thus no pollution.
The few extra bytes of properly used CCs are nigh irrelevant.

CSS hacks are more worthy of being labeled as "pollution" since the
effect on the rendering is not restricted to a single defined parser
and/or version(s).

* When a browser vendor releases a new version that fixes the bugs that
allow the hack and the bugs that require the hack in the first place,
the new version will automatically work like other standards compliant
browsers.

And if the CSS parsing bug gets fixed but not the reason for the hack
you are screwed.

You are screwed by the existence of broken browsers anyway, so nothings
changed.

Assuming responsible application of hacks, i.e. serving a simpler
alternative but correct method to a less capable renderer, CCs are more
future proof. If the capabilities of IE are enhanced the fall back
solution won't stop working. CSS hacks are more fragile in this regard,
they rely on 2 bugs that have nothing to do with each other and
regularly the same bugs also exist in other clients, but regularly not
paired.

* For conditional comments that test the version number:
- When a new version is released, the author needs to check whether or
not the conditional comment should still apply, and update the
version number as required.

Same applies to CSS hacks. MS CCs can be limited to current browser
versions with 100% accuracy, so that's another plus for CCs.

Yeah, but when a new browser is released with all the same bugs and your
conditionl comments only apply to current versions, your screwed with
either CCs or Doritos.

* For conditional comments that don't test the version number:

Which is unwise.

Testing the version assumes the bugs won't apply in the next release.
Not testing it assumes they will. Either assumption has equal chance of
being incorrect, so you really are screwed either way.

On principle I favour serving correct and standard compliant code to
unknown UAs. For future IE versions this can be achieved by limiting CCs
to current IE versions with their defined and known flaws. It's likely
that I will have to make adjustments to my code when the next version of
IE is released to account for it's shortcomings, but if for some reason
I'm unable to do so then it should get correct and standard compliant
code, not the hacks meant for older versions.

* Conditional comments are nested within the document markup, where each
and every occurance needs to be updated, whereas CSS hacks can be
managed in a single external file.

Ever heard of S&R?

Yes, but that's more difficult than managing a single CSS file

Not with proper tools.
and it
doesn't pollute the markup with unnecessary bloat.
Again, the few extra bytes of properly used CCs are nigh irrelevant,
labeling that as bloat is ludicrous.
There are a number of possibilities after a browser version upgrade,
with relation to the bugs being fixed or not. The following table
indicates the result of using each kind of workaround compared with the
possible browser fixes after a browser version upgrade.

The browser hack and bug columns indicate whether or not the hack/bug
was fixed in a browser version upgrade. The workaround type column
indicates whether or not a change is requred by the author after the
upgrade.

Legend:
Y = Yes (fixed | change requried)
N = No (not fixed | no change required)
Hack = Hack fixed?
Bug = Bug fixed?
CC+v = using conditional comment with version number
CC-v = Using conditional comment without version number
CSS = Using CSS hack

Browser Workaround Type
Hack Bug | CC+v. CC-v. CSS
N N | Y N N
Y N * | Y N Y
N Y | N Y Y
Y Y | N Y N

* It is unlikely that a browser vendor would fix the hacks, without
fixing the bugs that require the hacks because that would result in
many standards compliant pages rendering incorrectly.
It is ludicrous to suggest that it is feasible to keep fixing css
parsing bugs paired with the many varied reasons for which they are
applied.

Also, there is imo not nearly enough justification for the argument that
CCs should be implemented by other browser vendors. The discussion
pertains to MS CCs, therefore the benefits and drawbacks of using them
apply only to IE. This changes the argument since it is by some margin
the most deficient of the current clients.
CSS hacks also have the benefit of being kept completely seperate from
the markup. Embedding a conditonal comment for the purpose of fixing
presentation is not really achieving that goal.

A lofty ideal, but not realistic. For that same token you could argue
that we should not use extra markup to deal with IE's limited support
for CSS selectors. We do so because responsible authoring for the web
means that we should not knowingly cause problems in a client. It's not
ideal, but it's needed given the popularity of this particular browser.

Furthermore the relevancy of a few extra bytes per page to the
functional quality of the code is virtually nil.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

/* \*/
* html { ... }
/* */

I believe that will only be applied in IE/Win
Allow me to be sceptical about your belief that you know every css
parser in existence, more so that you've tested them all.

No, I haven't tested them all personally, but there has been a lot of
effort put into determining which browsers apply which hacks by many others.

http://centricle.com/ref/css/filters/

Although the published results may not include every single CSS parser
in existence, hacks are designed and (hopefully) used in a way that
allows fully standards compliant parsers to recieve styles for standards
compliant rendering engines.

Non-standard parsers that few people have ever heard of and with even
less market share, that happen to incorrectly apply a hack designed for
IE, are not worth worrying about at all since well designed web pages
should degrade gracefully anyway.
Furthermore it is impossible to allow for future css parsers. If an
upcoming version of a non IE browser has a bug that causes the above css
to be applied,
Since such hacks are very well known, any future CSS parser that doesn't
exist yet would surely test that none of the well known hacks and bugs
from other browsers exists in their implementation. Any non-existent
future implementation that doesn't test for such things and suffers from
the same bugs is extremely broken and not worth worrying about. Future
standards compliant implementations will ignore the hacks appropriately.
Also, there is imo not nearly enough justification for the argument that
CCs should be implemented by other browser vendors.

I never suggested they should, so I don't understand why you brought
that up.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

Allow me to be sceptical about your belief that you know every css
parser in existence, more so that you've tested them all.

No, I haven't tested them all personally, but there has been a lot of
effort put into determining which browsers apply which hacks by many others.

http://centricle.com/ref/css/filters/

If the above resource is the best you can do to demonstrate that
sufficient effort has gone into testing reliability in current renderers
then you've underlined my point nicely. The only KHTML browser
explicitly mentioned is Konqueror, no specific mobile renderers, no
reference to minor version numbers. I have for example encountered quite
a few parsing bugs specific to minor Opera 7 versions.

Yet the best you can come up with as an argument against the 100%
reliable way of targeting IEWin via CCs is that it costs a few more
bytes in the html and the false suggestion that using CCs is any
different from other authoring practices used by virtually all
knowledgable and responsible authors to maintain compatibility with IE.

Also, there is imo not nearly enough justification for the argument that
CCs should be implemented by other browser vendors.

I never suggested they should, so I don't understand why you brought
that up.

By including your CSS hack/CC comparison table and by stating:

* It is unlikely that a browser vendor would fix the hacks

you attempted to take the argument beyond MS CCs used to target IE.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

Spartanicus wrote:

Also, there is imo not nearly enough justification for the argument that
CCs should be implemented by other browser vendors.

I never suggested they should, so I don't understand why you brought
that up.

By including your CSS hack/CC comparison table and by stating:

* It is unlikely that a browser vendor would fix the hacks

you attempted to take the argument beyond MS CCs used to target IE.

I fail to see how my comparison table, nor my use of "browser vendor"
instead of being more specific by saying Microsoft, in any way suggested
that I think "CCs should be implemented by other browser vendors".

Although, as already stated earlier in the thread, IE is not the only
browser with CCs, Netscape 4 had them too. And (while its very
unlikely) who's to say no other browser vendor in the future will make
the same mistake Netscape and IE did? So, perhaps it is valid to take
the argument beyond the scope of IE; however that was not, and is not,
my intention.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

No, I haven't tested them all personally, but there has been a lot of
effort put into determining which browsers apply which hacks by many others.

http://centricle.com/ref/css/filters/

If the above resource is the best you can do to demonstrate that
sufficient effort has gone into testing reliability in current renderers

I didn't say sufficient, I said "a lot". I also didn't say it was an
extensive list of all known browser versions, I just provided as one
example of some of the research done.
no specific mobile renderers,
Since IE is screen media, and mobile renders are handheld media, correct
labeling of stylesheets for different media appropriately hides all such
hacks from conformant processors for that, and other, media.
Yet the best you can come up with as an argument against the 100%
reliable way of targeting IEWin via CCs is that it costs a few more
bytes in the html and the false suggestion that using CCs is any
different from other authoring practices used by virtually all
knowledgable and responsible authors to maintain compatibility with IE.

Its reliability still does not change the fact that it is both a form of
browser sniffing and a non-standard proprietary extension who's use
should be limited to where absolutely necessary, like all hacks, to
maintain accessibility, usability and graceful degradation, and avoided
where there are more suitable alternatives available. IMHO, CSS hacks
*are* a more suitable alternative, although (as I have stated many
times) CSS hacks should be avoided also.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

no specific mobile renderers,

Since IE is screen media, and mobile renders are handheld media, correct
labeling of stylesheets for different media appropriately hides all such
hacks from conformant processors for that, and other, media.

You clearly have no experience or knowledge of mobile platforms. Most of
the mobile renderers offer both a screen and handheld mode between which
the user can choose, others only parse screen css.

Yet the best you can come up with as an argument against the 100%
reliable way of targeting IEWin via CCs is that it costs a few more
bytes in the html and the false suggestion that using CCs is any
different from other authoring practices used by virtually all
knowledgable and responsible authors to maintain compatibility with IE.

Its reliability still does not change the fact that it is both a form of
browser sniffing and a non-standard proprietary extension who's use
should be limited to where absolutely necessary, like all hacks, to
maintain accessibility, usability and graceful degradation, and avoided
where there are more suitable alternatives available. IMHO, CSS hacks
*are* a more suitable alternative, although (as I have stated many
times) CSS hacks should be avoided also.

I repeat, your opinion has no relevance unless when you can combine it
with arguments that stick, this you've failed to do.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

You clearly have no experience or knowledge of mobile platforms. Most of
the mobile renderers offer both a screen and handheld mode between which
the user can choose, others only parse screen css.

I'm aware that mobile browsers, such as Opera, apply screen media
stylesheets when there is no handheld. However, as I have said before,
non-conformant browsers that happen to suffer from the same hacks as IE
as well as applying a stylesheet that was not meant for them, are of
absolutely no concern.

That, combined with the fact that very few hacks should get used and the
properties applied within them should have no detrimental effect even if
applied by a non-conformant browser, I really couldn't care less.

Conformant browsers will apply the correct styles, that is how CSS hacks
are designed to work, so using them will not affect any untested
conformant browser in anyway whatsoever.

The point of CSS hacks is to completely seperate them from the markup,
which conditional comments fail to do, and it seems we are going to have
agree to disagree on the whole /which one is more appropriate/ argument.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox

[Spartanicus]

Lachlan Hunt <sp***********@gmail.com> wrote:

The point of CSS hacks is to completely seperate them from the markup,
which conditional comments fail to do, and it seems we are going to have
agree to disagree on the whole /which one is more appropriate/ argument.

I don't know why it took me so long to realise that you are trolling,
fixed now, bye.

--
Spartanicus

[Lachlan Hunt]

Spartanicus wrote:

Lachlan Hunt <sp***********@gmail.com> wrote:

The point of CSS hacks is to completely seperate them from the markup,
which conditional comments fail to do, and it seems we are going to have
agree to disagree on the whole /which one is more appropriate/ argument.

I don't know why it took me so long to realise that you are trolling,
fixed now, bye.

Failure to reach an agreement with your opinion, does not make someone a
troll. If, at the end of the day, you can't accept a difference of
opinion and move on without name calling, then that's your problem not mine.

*plonk*

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://GetThunderbird.com/ Reclaim your Inbox