Feature detection vs browser detection

[Conrad Lender]

In a recent thread in this group, I said that in some cases object
detection and feature tests weren't sufficient in the development of
cross-browser applications, and that there were situations where you
could improve the application by detecting the browser vendor/version.
Some of the posters here disagreed. Since then, I've had to deal with a
few of these cases; some of them could be rewritten to use object
detection, and some couldn't. I'd like to present a selection of these
cases here, and ask your opinion about how to accomplish the required
features without browser detection.

To avoid unnecessary side-tracking in the discussion, let me state in
advance that

- I fully understand that object detection and feature tests are to be
used whenever possible. I've never said otherwise (check the archives).

- I completely agree that many popular libraries and scripts rely far
too heavily on browser sniffing. I agree that this is in most cases
unnecessary and invites problems in the future.

- I'm not necessarily talking about parsing the user agent string. There
are often more reliable ways to detect the UA, especially for the most
problematic one (MSIE).

- When I'm proposing the use of browser detection, I'm doing it to
improve the user experience on older browsers. These old versions have
bugs and quirks that are well known and can be avoided or worked around.
I am *not* trying to predict how a future version of a browser is going
to behave.

- Usually I am not in a position to decide what is or isn't a reasonable
feature request. The client wants a feature; I say that it could break
in older browsers unless I do something that might become a problem with
future releases; they say go ahead - the competition is doing it too,
we'll deal with the problem when it's there.

- In my opinion, a UA that pretends to be something else, and goes as
far as to implement and mimick another UA's proprietary objects and
behaviors, wants to be treated as that UA. If it can't handle it, that's
not my problem anymore, and outside of my control (classic user error).
Again, I'm not talking about sniffing the UA string.
That said, here are the cases where I'm having trouble with the "pure"
object detection methods:
Case #1: Too much data in memory
--------------------------------

In one application, we're using a custom grid control with features
similar to a spreadsheet, that is used to view and edit data in tables
with several 100k of rows, sometimes more than 1M, without paging. Of
course, we can't display all that data at once, so we fetch the relevant
area via XHR. The server-side action to retrieve that data is very
processor intensive, and the performance is best when there are as few
requests as possible. Fewer requests means fetching a larger chunk of
data at once. Experience with this application has shown that the
overall responsivity of the browser deteriorates when too many elements
are displayed or kept in memory at once. MSIE6 is by far the worst
performer here, IE7 is better but still far behind the competition. So
what we're doing in this case is *determine the user agent* and then
decide how much data to fetch to get an optimal trade-off between server
delay and browser sluggishness. How could I do that without browser
sniffing?
Case #2: Designer relies on :hover
----------------------------------

Different application, still intranet. This one was designed for use
with IE7, and the designer used the :hover pseudo-class to show or hide
additional information (the dev team uses different browsers, but they
all handle :hover on any element correctly). Unfortunately, after a
corporate merger there are now users who are still using IE6, which
doesn't support :hover anywhere. Now we could either change the whole UI
design (pretty huge task in this case), or add a few event handlers to
support IE6 as well. We went with the event handlers, which took about
one day for the whole application. How could we handle this without
checking the browser version?
Case #3: Alpha support
----------------------

I'll keep this short, because I've already mentioned it here before.
Same application as #2, design relies on the PNG alpha channel for
flashy things like drop shadows and composite images. Transparent GIFs
are not good enough. IE6 can be made to understand alpha transparency
with a little ugly hack, but we wouldn't want to do that for all UAs.
Why not check for IE6 and apply the hack only when necessary?
Case #4: Memory leaks
---------------------

IE still, after all this time, has horrible memory leaks (circular
references between JScript objects and COM objects). If the application
provides a common way to register event handlers, they can be purged on
unload. I admit, I haven't timed this exactly, but on a JS-driven page
with a lot of event handlers that's going to take a while. How do I find
out if it's necessary to clear all existing event handlers if I can't
check for IE?
Case #5: How to recognize that the DOM is safe for scripting?
-------------------------------------------------------------

There are many different strategies for detecting the point in time when
the DOM can be modified (before window.onload), and most of them try to
use the most efficient strategy for the current UA. I've tried to make
this process UA-agnostic, but I don't think it can be done reliably
without unreasonable assumptions. Here's a short example (attach_ is a
generic wrapper for addEventListener/attachEvent):

// this shouldn't hurt if the UA doesn't know the event:
attach_(document, "DOMContentLoaded", handleReady);

// use polling for UA's who don't
// [but we shouldn't have to, if only we could use browser detection]
initReadyPolling();

/*
what initReadyPolling could do:
- in Safari, we can trust the document.readyState values of "loaded"
and "complete" (as far as the released versions are concerned)
- in MSIE, we can't trust "loaded". We could trust "complete", but that
won't help much, since it fires about the same time as window:load.
- Mozilla (AFAIK, I might be wrong here) doesn't have useful values in
document.readyState at all.
- In YUI, they attempt to apply the proprietary doScroll() on a dummy
element on each poll for IE, and when it doesn't throw an exception,
the DOM is ready
*/

// if all else fails, try to get the window's load event
attach_(window, "load", handleLoad); // handleLoad calls handleReady

I realize this is sub-optimal (and yes, I've read Peter Michaux's
excellent articles on this subject). There are so many browser
dependencies in initReadyPolling that any attempt to avoid UA sniffing
would rely on current circumstantial evidence (for example, if
attachEventListener is available, don't go the IE route). What if MS
decided to support the W3C event model?
Case #6: Various browser bugs
-----------------------------

Specific versions of browsers are known to have bugs and quirks that
could be addressed if we knew which browser/version we're dealing with.
There's a lot of different bugs in this category; let me use two of them
as examples:

1) Older Safari versions returned Mac-specific key codes for
keydown/up/press events (63232 instead of 38 for ArrowUp, 63234 instead
of 37 for ArrowLeft, etc). There are also cases where different (normal)
key codes are returned if a modifier key is pressed.

2) With XHR requests, IE sometimes returns the HTTP status code as 1223
instead of 204. That wouldn't could as a "success" code (2xx), and has
to be dealt with specially.

In the case of those two exemplary bugs it won't hurt much to just
accept the different numeric values and translate them, but you can see
where I'm going. These are bugs that can't be feature tested.
Those are just the situations I encountered since the last discussion. I
decided not to post in that thread again, because I'm not interested in
flame wars. Still, I think it's worthwhile to discuss this topic on its own.
- Conrad
PS: Before I forget it, Garrett was absolutely correct in mentioning
that the outerHTML test in my previous posted example needed to be case
insensitive. Unfortunately, the other suggestions, while interesting,
couldn't be applied to radio buttons, so that would be my Case #7, if
the workaround with outerHTML is deemed unacceptable.

[Gregor Kofler]

Conrad Lender meinte:

Case #1: Too much data in memory
--------------------------------

In one application, we're using a custom grid control with features
similar to a spreadsheet, that is used to view and edit data in tables
with several 100k of rows, sometimes more than 1M, without paging. Of
course, we can't display all that data at once, so we fetch the relevant
area via XHR. The server-side action to retrieve that data is very
processor intensive, and the performance is best when there are as few
requests as possible. Fewer requests means fetching a larger chunk of
data at once. Experience with this application has shown that the
overall responsivity of the browser deteriorates when too many elements
are displayed or kept in memory at once. MSIE6 is by far the worst
performer here, IE7 is better but still far behind the competition. So
what we're doing in this case is *determine the user agent* and then
decide how much data to fetch to get an optimal trade-off between server
delay and browser sluggishness. How could I do that without browser
sniffing?

This might work in a completely controlled environment - but then: why
sniff at all? In a real-world scenario, users not only have different
browsers, but also different OS, different hardware. Believe me: IE on a
normal Desktop PC is *much* faster than Safari on the iPhone. Or take
Firefox: Performance relies heavily on what plugins are installed. And
we haven't even discussed what "sluggish" means to different people with
different expectations.

Bottom line: Drop the browser sniffing. Offer options to the user, how
many records/rows he wants to edit in one batch. It's the same with the
options that allow you to see 10, 20, 50 or whatever search results.

Case #2: Designer relies on :hover
----------------------------------

Different application, still intranet. This one was designed for use
with IE7, and the designer used the :hover pseudo-class to show or hide
additional information (the dev team uses different browsers, but they
all handle :hover on any element correctly). Unfortunately, after a
corporate merger there are now users who are still using IE6, which
doesn't support :hover anywhere. Now we could either change the whole UI
design (pretty huge task in this case), or add a few event handlers to
support IE6 as well. We went with the event handlers, which took about
one day for the whole application. How could we handle this without
checking the browser version?

Conditional comments. But again: You are talking about a more-or-less
completely controlled environment. What's that got to do with browser
sniffing on the WWW?

Case #3: Alpha support
----------------------

I'll keep this short, because I've already mentioned it here before.
Same application as #2, design relies on the PNG alpha channel for
flashy things like drop shadows and composite images. Transparent GIFs
are not good enough. IE6 can be made to understand alpha transparency
with a little ugly hack, but we wouldn't want to do that for all UAs.
Why not check for IE6 and apply the hack only when necessary?

Conditional comments. I'm sure David as pointed that out several times.
You're pretty tenacious...

Case #4: Memory leaks
---------------------

IE still, after all this time, has horrible memory leaks (circular
references between JScript objects and COM objects). If the application
provides a common way to register event handlers, they can be purged on
unload. I admit, I haven't timed this exactly, but on a JS-driven page
with a lot of event handlers that's going to take a while. How do I find
out if it's necessary to clear all existing event handlers if I can't
check for IE?

You can clear them on any browser - would do no harm. I can't verify any
serious speed penalties because of that. Some smarter assignment of
listeners might already do the job (e.g. my tree widget needs one
listener in the container box, for checking boxes, handling links,
collapsing and expanding trees, etc.)

>

Case #5: How to recognize that the DOM is safe for scripting?
-------------------------------------------------------------
I realize this is sub-optimal (and yes, I've read Peter Michaux's
excellent articles on this subject).

And still not understood?

What if MS
decided to support the W3C event model?

If you forgot about browser sniffing, your scripts will still work.

Case #6: Various browser bugs
-----------------------------

Specific versions of browsers are known to have bugs and quirks that
could be addressed if we knew which browser/version we're dealing with.
There's a lot of different bugs in this category; let me use two of them
as examples:

1) Older Safari versions returned Mac-specific key codes for
keydown/up/press events (63232 instead of 38 for ArrowUp, 63234 instead
of 37 for ArrowLeft, etc). There are also cases where different (normal)
key codes are returned if a modifier key is pressed.

2) With XHR requests, IE sometimes returns the HTTP status code as 1223
instead of 204. That wouldn't could as a "success" code (2xx), and has
to be dealt with specially.

Never experienced that, but why would you need "browser sniffing" for
that? Or are there browsers which deliver a "1223" with a different meaning?

In the case of those two exemplary bugs it won't hurt much to just
accept the different numeric values and translate them, but you can see
where I'm going. These are bugs that can't be feature tested.

So far I've weeded out any of such issues with conditional comments,
since IE is more or less the only nasty one. There are other issues,
like the inability to focus non-form elements for example in Safari. So
what? It "degrades" gracefully (Safari users can't use the keyboard for
scrolling the div). One could write a more universal approach which
might work in Safari, too. But this approach wouldn't need browser
sniffing either.

Gregor

[Conrad Lender]

On 2008-11-12 11:38, Gregor Kofler wrote:

>Case #1: Too much data in memory --------------------------------

[snip]

This might work in a completely controlled environment - but then:
why sniff at all? In a real-world scenario, users not only have
different browsers, but also different OS, different hardware.
Believe me: IE on a normal Desktop PC is *much* faster than Safari on
the iPhone. Or take Firefox: Performance relies heavily on what
plugins are installed. And we haven't even discussed what "sluggish"
means to different people with different expectations.

The customers are using IE6 and IE7, but we're using a variety of
browsers and a platforms for development and testing, with and without
extensions (no phones though). By "sluggishness" I mean that the user
interface is slow to react to events like mouseovers or clicks. The grid
component has to load, process, and display a lot of data at once, and
the slowdown in IE was _very_ noticable (especially on IE6) compared to
the other combinations. It made sense for us to automatically adjust the
settings for IE. We could of course reduce the settings for all
browsers, but why should we artificially limit the performance on
browsers that don't have that problem?

Bottom line: Drop the browser sniffing. Offer options to the user,
how many records/rows he wants to edit in one batch. It's the same
with the options that allow you to see 10, 20, 50 or whatever search
results.

That would require an extra step for the users, and prevent us from
setting reasonable "best guess" defaults.

>Case #2: Designer relies on :hover

[snip]

Conditional comments.

Do you mean
- conditional comments in the HTML templates to include a script that
adjust the behavior for IE6?
- or conditional compilation in the script source?

The former would require us to maintain a separate script file for IE6,
and to move the IE6-specific adjustments from the source modules to that
file. Doesn't sound very attractive to me.

The latter has problems of its own - CC uses /*comments*/, which means
that we can't use automatic validation for these parts (JSLint, for
example). It also reduces the level of compression that can be achieved
with tools like the YUI compressor.

IMHO, conditional comments/compilation are just another way of asking
the UA "are you an Internet Explorer?" It might break in the future,
just like any of the other tests (for example, Opera could decide to
implement CC). If we're going this route instead of object detection, we
might as well use a combination of other well-known IE-proprietary
objects and methods, like ScriptEngineMajorVersion, for example.

But again: You are talking about a more-or-less
completely controlled environment. What's that got to do with
browser sniffing on the WWW?

I sort of got the impression that browser detection was frowed upon
regardless of environment. Besides, a question like that could just as
well occur during normal (non-intranet) development.

>Case #3: Alpha support ----------------------

[snip]

Conditional comments. I'm sure David as pointed that out several
times. You're pretty tenacious...

David only said that transparent GIFs should be used, because alpha
transparency didn't affect his designs. That's good for him, but not a
solution. And yes, I'm tenacious, because I think that the strict
refusal to add exceptions for well-known bugs in well-known browser
versions borders on dogma. Browser detection is a tool; an overused and
dangerous tool, but still useful in specific cases.

>Case #4: Memory leaks ---------------------

[snip]

You can clear them on any browser - would do no harm. I can't verify
any serious speed penalties because of that. Some smarter assignment
of listeners might already do the job (e.g. my tree widget needs one
listener in the container box, for checking boxes, handling links,
collapsing and expanding trees, etc.)

Event delegation is a great thing, and I use it a lot. I'll have to do
some benchmarking on how expensive it is to remove the listeners on all
browsers (which is what I'm doing, btw). Maybe it's not a big deal.

>Case #5: How to recognize that the DOM is safe for scripting?
------------------------------------------------------------- I
realize this is sub-optimal (and yes, I've read Peter Michaux's
excellent articles on this subject).

And still not understood?

What are you referring to?

I'm using a combination of DOMContentLoaded, polling, and window.onload
as a fallback. The only question is *what* to poll for. Unfortunately,
as I've described in my post, this decision isn't simple without
branching by browser vendor/version.

If you see a problem with what I've suggested, I'd like to know.
- Conrad

[Gregor Kofler]

Conrad Lender meinte:

On 2008-11-12 11:38, Gregor Kofler wrote:

>>Case #1: Too much data in memory --------------------------------

[snip]

>This might work in a completely controlled environment - but then:
why sniff at all? In a real-world scenario, users not only have
different browsers, but also different OS, different hardware.
Believe me: IE on a normal Desktop PC is *much* faster than Safari on
the iPhone. Or take Firefox: Performance relies heavily on what
plugins are installed. And we haven't even discussed what "sluggish"
means to different people with different expectations.

The customers are using IE6 and IE7, but we're using a variety of
browsers and a platforms for development and testing, with and without
extensions (no phones though). By "sluggishness" I mean that the user
interface is slow to react to events like mouseovers or clicks. The grid
component has to load, process, and display a lot of data at once, and
the slowdown in IE was _very_ noticable (especially on IE6) compared to
the other combinations. It made sense for us to automatically adjust the
settings for IE. We could of course reduce the settings for all
browsers, but why should we artificially limit the performance on
browsers that don't have that problem?

>Bottom line: Drop the browser sniffing. Offer options to the user,
how many records/rows he wants to edit in one batch. It's the same
with the options that allow you to see 10, 20, 50 or whatever search
results.

That would require an extra step for the users, and prevent us from
setting reasonable "best guess" defaults.

Your *customers* are using IE6 and 7. So why not make it a pleasant
experience for them. Are you (or rather your customer) in a controlled
environment or not?

You could do some sort of "benchmark", estimate the speed of the JS
engine and adapt to that. This would make it smooth for people with fast
browsers on slow machines, too.

>>Case #2: Designer relies on :hover

[snip]

>Conditional comments.

Do you mean
- conditional comments in the HTML templates to include a script that
adjust the behavior for IE6?

Yes.

The former would require us to maintain a separate script file for IE6,
and to move the IE6-specific adjustments from the source modules to that
file. Doesn't sound very attractive to me.

I've only needed it for specific CSS rules so far. You could have one
simple file with flags and all your browser specific adaptations in the
main JS file.

IMHO, conditional comments/compilation are just another way of asking
the UA "are you an Internet Explorer?" It might break in the future,
just like any of the other tests (for example, Opera could decide to
implement CC).

Quite likely that Opera would not react on <!--[if IE]>
Come on, that's plain ridiculous.

If we're going this route instead of object detection, we
might as well use a combination of other well-known IE-proprietary
objects and methods, like ScriptEngineMajorVersion, for example.

No - CC are a completely different approach. Transparent and robust.

I sort of got the impression that browser detection was frowed upon
regardless of environment. Besides, a question like that could just as
well occur during normal (non-intranet) development.

Why? It's always trade-off. If the customer desperately wants to use IE6
plus transparent PNGs, I'd either resort to hacks - or flash.

And yes, I'm tenacious, because I think that the strict
refusal to add exceptions for well-known bugs in well-known browser
versions borders on dogma. Browser detection is a tool; an overused and
dangerous tool, but still useful in specific cases.

What's wrong with dogmatism in a NG. In my experience most Usenet groups
tend certain dogmas. After all that's pretty good. If I want to have
wishy-washy "discussions" I can resort to a web forum. Anyway, you can
use browser sniffing whenever you want - just don't expect that other
people here get excited about this, even if you bring forth your best
arguments.

Gregor

[Thomas 'PointedEars' Lahn]

Gregor Kofler wrote:

Conrad Lender meinte:

>On 2008-11-12 11:38, Gregor Kofler wrote:

>>Bottom line: Drop the browser sniffing. Offer options to the user,
how many records/rows he wants to edit in one batch. It's the same
with the options that allow you to see 10, 20, 50 or whatever search
results.

That would require an extra step for the users, and prevent us from
setting reasonable "best guess" defaults.

Your *customers* are using IE6 and 7. So why not make it a pleasant
experience for them. Are you (or rather your customer) in a controlled
environment or not?

I daresay the "controlled environment" is nothing but a convenient illusion,
and the corresponding argument is essentially the result of dangerous
short-sightedness in the decision-making process (no offense meant):

You never know when the next (V)VIP with rather exotic hard- and software
needs access to your intranet, or when the next generation browser comes up.
BTDT.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[dhtml]

Conrad Lender wrote:

On 2008-11-12 11:38, Gregor Kofler wrote:

The customers are using IE6 and IE7, but we're using a variety of
browsers and a platforms for development and testing, with and without
extensions (no phones though). By "sluggishness" I mean that the user
interface is slow to react to events like mouseovers or clicks. The grid
component has to load, process, and display a lot of data at once, and
the slowdown in IE was _very_ noticable (especially on IE6) compared to
the other combinations. It made sense for us to automatically adjust the
settings for IE. We could of course reduce the settings for all
browsers, but why should we artificially limit the performance on
browsers that don't have that problem?

It sounds like you have a server-side bottleneck. And so instead of
processing many request, you rather process one big one, and, since IE6
slows down, you use browser detection.

The connection from the client to the server is not the bottleneck. The
bottleneck is whatever the server is doing (connecting to a database).
You can cache those results temporally on the server and associate the
data with a client (like using a session), sending only a portion of the
data back.

Client requests data, the server checks to see if there is data already
associated with that request. If not, it processes a chunk of data for
that client and saves it. Finally, the response sends a smaller bite
back, to the client.

Ideally you should fix the bottleneck on the server.

>Bottom line: Drop the browser sniffing. Offer options to the user,
how many records/rows he wants to edit in one batch. It's the same
with the options that allow you to see 10, 20, 50 or whatever search
results.

That would require an extra step for the users, and prevent us from
setting reasonable "best guess" defaults.

It would require an extra step for the user, but if the user saw an
option to make the app be less slow (and if it was really slow), he
would use that option.

>
I'm using a combination of DOMContentLoaded, polling, and window.onload
as a fallback. The only question is *what* to poll for. Unfortunately,
as I've described in my post, this decision isn't simple without
branching by browser vendor/version.

If you see a problem with what I've suggested, I'd like to know.

I prefer a bottom script.

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[David Mark]

On Nov 12, 12:36*am, Conrad Lender <[e-mail]:

In a recent thread in this group, I said that in some cases object
detection and feature tests weren't sufficient in the development of
cross-browser applications, and that there were situations where you
could improve the application by detecting the browser vendor/version.

You say a lot of things.

Some of the posters here disagreed. Since then, I've had to deal with a

Putting it kindly.

few of these cases; some of them could be rewritten to use object
detection, and some couldn't. I'd like to present a selection of these

Some things can be feature detected and/or tested, some cannot.
Nothing useful can be inferred form the UA string. Even the library
authors know this, hence the list of three or four browsers that are
"supported" by those things.

cases here, and ask your opinion about how to accomplish the required
features without browser detection.

Assuming this will be an IE discussion, it depends on what you call
"browser detection." Conditional comments (or compilation) are
considered good practice to deal with IE6 (and under if needed)
quirks. They've been in use for over a decade.

>
To avoid unnecessary side-tracking in the discussion, let me state in
advance that

- I fully understand that object detection and feature tests are to be
used whenever possible. I've never said otherwise (check the archives).

Who said you said anything?

>
- I completely agree that many popular libraries and scripts rely far
too heavily on browser sniffing. I agree that this is in most cases
unnecessary and invites problems in the future.

Yeah, the present too. Why do you think that nobody of note uses
them? I doubt their authors use them.

>
- I'm not necessarily talking about parsing the user agent string. There

Then what are you talking about?

are often more reliable ways to detect the UA, especially for the most
problematic one (MSIE).

We've been over IE6. It is one lousy browser from ten years ago that
came with a built-in workaround for its many quirks (conditional
comments.) What is the question?

>
- When I'm proposing the use of browser detection, I'm doing it to
improve the user experience on older browsers. These old versions have

It doesn't matter why you think it needs to be done. The fact is that
it doesn't.

bugs and quirks that are well known and can be avoided or worked around.
I am *not* trying to predict how a future version of a browser is going
to behave.

No matter.

>
- Usually I am not in a position to decide what is or isn't a reasonable
feature request. The client wants a feature; I say that it could break
in older browsers unless I do something that might become a problem with
future releases; they say go ahead - the competition is doing it too,
we'll deal with the problem when it's there.

Is this a hypothetical conversation or are you actually involved in
such decision-making?

>
- In my opinion, a UA that pretends to be something else, and goes as
far as to implement and mimick another UA's proprietary objects and
behaviors, wants to be treated as that UA. If it can't handle it, that's
not my problem anymore, and outside of my control (classic user error).
Again, I'm not talking about sniffing the UA string.

What are you talking about then? Object inferences? Where is the one
example that requires such chicanery?

>
That said, here are the cases where I'm having trouble with the "pure"
object detection methods:

What does "pure" mean in this context? There are good inferences and
bad inferences (and anything to do with the UA string is bad.)

>
Case #1: Too much data in memory
--------------------------------

In one application, we're using a custom grid control with features

A what?!

similar to a spreadsheet, that is used to view and edit data in tables

[snip confused nonsense]

delay and browser sluggishness. How could I do that without browser
sniffing?

A better question is how you think browser sniffing would help in this
case.

>
Case #2: Designer relies on :hover
----------------------------------

Different application, still intranet. This one was designed for use
with IE7, and the designer used the :hover pseudo-class to show or hide

Why was it designed for IE7? In what way?

additional information (the dev team uses different browsers, but they
all handle :hover on any element correctly). Unfortunately, after a
corporate merger there are now users who are still using IE6, which
doesn't support :hover anywhere. Now we could either change the whole UI

Sure it does. On anchors, which is probably what your "designer"
should have used in the first place.

design (pretty huge task in this case), or add a few event handlers to

A "huge task" to change the style sheets?

support IE6 as well. We went with the event handlers, which took about
one day for the whole application. How could we handle this without
checking the browser version?

Asked and answered. Are you kidding?

>
Case #3: Alpha support
----------------------

I'll keep this short, because I've already mentioned it here before.

Yeah, too late.

[snip]

Kidding right? Same answer as two weeks ago.

>
Case #4: Memory leaks
---------------------

IE still, after all this time, has horrible memory leaks (circular
references between JScript objects and COM objects).

[snip]

So? Avoid leaky patterns. Or if you must, use an unload listener to
clean up after yourself. Again, where does browser sniffing enter
into this?

As an aside, the only people I ever saw use browser sniffing to handle
leaks were a couple of Flash mavens who decided to take up browser
scripting (and sniffing) to provide a really lousy alternative to
Adobe's really lousy deployment script. They "succeeded" and now lots
of Flash sites are "powered" by their clueless creation. I forget the
name of it, but it is recent. And yes, I told them they were out of
their minds. The answer is a matter of public record: "It's good
enough for jQuery, Dojo, etc."

>
Case #5: How to recognize that the DOM is safe for scripting?
-------------------------------------------------------------

There are many different strategies for detecting the point in time when
the DOM can be modified (before window.onload), and most of them try to
use the most efficient strategy for the current UA. I've tried to make

Most scripts are written by nitwits. That is rule #1 with this
stuff. Ignore 99.9% of everything you see in the field (and the
endless, disorganized blathering at the bottom of each page.)

this process UA-agnostic, but I don't think it can be done reliably

You need to use onload event. Period. If that causes you hassles,
lighten up on the images, Flash, etc.

without unreasonable assumptions. Here's a short example (attach_ is a
generic wrapper for addEventListener/attachEvent):

Why?

>
// this shouldn't hurt if the UA doesn't know the event:
attach_(document, "DOMContentLoaded", handleReady);

And it doesn't, at least if that function does what I think it does.

[snip]

If you are really interested in this subject, look at the example in
my library.

>
Case #6: Various browser bugs
-----------------------------

Specific versions of browsers are known to have bugs and quirks that
could be addressed if we knew which browser/version we're dealing with.

But we don't, so we can't without proper feature detection/testing.

There's a lot of different bugs in this category; let me use two of them
as examples:

1) Older Safari versions returned Mac-specific key codes for
keydown/up/press events (63232 instead of 38 for ArrowUp, 63234 instead
of 37 for ArrowLeft, etc). There are also cases where different (normal)
key codes are returned if a modifier key is pressed.

That does it. Please stop talking about this subject.

[Conrad Lender]

On 2008-11-19 02:40, David Mark wrote:

You say a lot of things.

Ah, David's back. I was beginning to wonder why this group had become
relatively peaceful and constructive in the past few days. Oh well, it
was good while it lasted. Like I told you before: as long as you insist
on being rude and overly argumentative, I'm going to ignore your
replies. If you want to talk to me, bring some arguments; if you don't,
why bother writing all this crap?
- Conrad

[David Mark]

On Nov 18, 9:43*pm, Conrad Lender <[e-mail]:

On 2008-11-19 02:40, David Mark wrote:

You say a lot of things.

Ah, David's back. I was beginning to wonder why this group had become

Keeping tabs?

relatively peaceful and constructive in the past few days. Oh well, it

Oh brother.

was good while it lasted. Like I told you before: as long as you insist
on being rude and overly argumentative, I'm going to ignore your

Like I told you before. Shut up until you get your bearings straight.

[snip]

[Lasse Reichstein Nielsen]

David Mark <dm***********@gmail.comwrites:

On Nov 18, 9:43*pm, Conrad Lender <[e-mail]:

>was good while it lasted. Like I told you before: as long as you insist
on being rude and overly argumentative, I'm going to ignore your

Like I told you before. Shut up until you get your bearings straight.

That would seem to be what he said he would do.
Conrad is correct in his assessment, though. If you want to attract
positive attention, a more diplomatic approach is likely to better
achieve that.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[David Mark]

On Nov 19, 12:56*am, Lasse Reichstein Nielsen <[e-mail]>
wrote:

David Mark <[e-mail]:

On Nov 18, 9:43*pm, Conrad Lender <[e-mail]:

was good while it lasted. Like I told you before: as long as you insist
on being rude and overly argumentative, I'm going to ignore your

Like I told you before. *Shut up until you get your bearings straight..

That would seem to be what he said he would do.

But then he didn't do it (e.g. this thread.)

Conrad is correct in his assessment, though. If you want to attract
positive attention, a more diplomatic approach is likely to better
achieve that.

Attention from whom? Conrad is a confused newcomer, whose
"assessments" have been mostly bunk so far.