RobG wrote:
cwdjrxyz wrote:
RobG wrote:
DavidB wrote:
[...]
Thanks to all for the help. I am not sure how to fix the issue of spoofing
IE (and I can learn that in time).
Simple: ditch browser detection altogether:
if (document.getElementById){
/* use document.getElementById */
} else if (document.all){
/* use document.all */
}
Of course IE6 supports both document.getElementById and document.all,
and IE4 supports only document.all. If the document.getElementById leg
also works properly on IE5, which it should but which I can not test
for lack of IE5, then a more elegant way might be to route to the
document.getElementById path if both document.getElementById and
document.all are supported and route to a document.all path if only it
is supported.
That seems confused - what about browsers that support getElementById
but not document.all?
The *only* reason to test for document.all is as a fall-back if
document.getElementById is not supported. If the latter is supported
(which it is in perhaps 99.9% of browsers in use), there is no need to
test for the former.
I see what you are talking about. I failed to notice that your test for
document.all was an "else if" rather than just "else", which makes a
considerable difference. Still I can see a few cases where one might
want a more extensive test. Besides IE, even recent Opera browsers will
support document.all in addition to getElementById. I doubt if there
ever was an early Opera browser that only supported document.all, but
since I had no experience with them, I could not say for sure. Also
earlier versions of WebTV supported only document.all - or at least
some parts of it. The point is that it can not be assumed that one is
dealing with an IE browser if it supports document.all with or without
document.getElementById support. At least in the case of WebTV one
could test for appCodeName. For most computer browsers, this returns
Mozilla, which is not at all useful. However WebTV returned "bowser",
which allowed you provide a special path for WebTV to overcome the many
things it did not support.
In a few cases, the Microsoft html conditional comment also can be
useful. Such a comment appears as just an ordinary comment to most
browsers, but Microsoft browsers can see through the comment tags to
view code within. This becomes more interesting when one notices that
Microsoft conditional comments can be used to write one script when the
browser is Microsoft and another when it is not. This approach can be
useful when one wishes to use some of the many IE specific codes only
if one is viewed by an IE browser and use something else for other
browsers. I have used such an approach to allow Microsoft to use an
ActiveX WMP object for playing certain media files, and for using an
ordinary object for other browsers which often do not support ActiveX.
I found one case when a video file would start streaming at once on
most browsers using an ordinary object, but it would not stream until
completly downloaded on IE6. Allowing the ActiveX object for IE only
corrected this problem, and streaming started at once. So far as I
know, the Microsoft conditional comment has not been spoofed, but it
likely could be if other browser writers wanted to.
