«

On Sat, 17 Jan 2004 23:42:12 +0100, Ekkehard Morgenstern
<> wrote:

> "Janwillem Borleffs" <> wrote:
>> As mentioned many times in this NG, parsing the user agent property is
>> an unreliable way of browser detection.
>>
>> See http://jibbering.com/faq/#FAQ4_26 for info.
>
> BTW, in other languages, like PHP, the HTTP user agent string is the only
> way to recognize the user's web browser.

And that has what bearing on JavaScript? In any event, it is unreliable
and should not be used for the purpose of detecting implemented
functionality.

> In my library, I might use browser identification by objects, but it's
> unsafe also, because it doesn't tell you exactly what browser the user
> has, and hence it might be that a presumed implementation does not behave
> as expected, whereas when I use the HTTP user agent string, I can
> identify the browser.

As I said above, you can't. For example, Opera, by default, masquerades as
Internet Explorer 6.0, probably to get around sites like yours that use
the user agent string to distinguish between browsers for no valid reason.

> If the user doesn't tamper with the UserAgent string, it should be
> sufficient, so I could use object recoginition as a fallback method.
>
> And if the user sets the UserAgent string to a particular value,
> they might _want_ to pretend they use a specific browser. Either for
> testing, or for other purposes. If someone changes the string just
> for the fun of it or to introduce some "anonymity" (which doesn't
> exist on the internet anyway), then it's their problem, IMO.

If a user wishes to change the User-Agent header, or a browser uses a
value that does not accurately reflect the actual software, it is you that
should suffer the consequences, not the user. There is nothing in either
RFC 1945 or RFC 2616 about what the User-Agent header must contain, other
than the general syntax of the value. In fact, the header isn't even
required.

If you intend to write a viable, robust library, you must to accept the
fact that the User-Agent header can be inaccurate, particularly when such
a situation is perfectly valid.

> There are also lots of browser-version specific JavaScript issues,
> which can only be shipped around by checking the HTTP user agent string.

Such as?

On to a different subject (you've probably seen enough of "User-Agent
header"). From your website:

"...Also, the toString() method is defined differently than the
toSource() method. Have a look at the ECMA 262 standard!..."

I don't quite know what you're referring to there, but I think you should
look at ECMA-262. There is no such method, of any object, called toSource.

"...Also you mention in the documentation for Opera 7, that it
doesn't support the script tag in XHTML, which isn't true. Also,
event handling for IE-type mouseovers do work (in contrast to the
documentation). DOM 2.0 implementations have to support
document.implementation.hasFeature( "Core", "2.0" ), which Opera 7
doesn't. Hence, it's not DOM 2.0 compliant, unlike what you state
in the documentation.)"

The Opera documentation does NOT state that the SCRIPT element in XHTML is
unsupported. It states that with XHTML 1.0 and 1.1 "in 'XML mode'...the
script element is not supported". For 'XML mode' to be enabled, a document
must have a MIME type other than "text/html". According to W3C's SGML
parser, your documents have a MIME type of "text/html", so Opera will not
interpret them as XML and so the SCRIPT element will be supported.

There is no mention of 'IE-type mouseovers' in the Opera documentation
that I could see. Could you point to it?

Opera does NOT state that is DOM Level 2 compliant. It specifically
states that "Opera 7 has full support for the [DOM Level 2 Core]
Fundamental interfaces, apart from these exceptions...". As it does
not fully support the Core module, it is not supposed to, and does
not, return 'true' in response to
document.implementation.hasFeature('core', '2.0').

Mike

--
Michael Winter
d (replace ".invalid" with ".uk" to reply)

"Ekkehard Morgenstern" <> wrote in
message news:bubvr3$53m$...
<snip>
> Well, if you had read my post properly, you would've noticed that I
> mentioned that I haven't tested it with Opera yet.

My expectation would be that any code intended to provide a consistent
API for browsers including any good DOM browsers would work unaltered on
any browser with a good DOM implementation, and especially Opera 7. When
Opera 7 was first released about 14 months ago I was very happy to find
that they had done such a good job of their DOM implementation that I
did not have to alter one line of the code I had written previously.

But the problem is not only that it failed on Opera for no good reason,
but how it failed. The result of that failure was to render a site that
could have been functionally implemented with pure HTML unusable. That
demonstrates a shortfall in script design, as it doesn't plan for either
the certain condition where the script fails entirely due to the absence
of client-side script support, or the inability of the script to
successfully execute due to the browser's lack of support for the
required language features. Preventing any chance of achieving clean
degradation.

Failing to make suitable provision for clean degradation is a common
feature of attempts to provide API libraries for browsers. That isn't
particularly surprising as the path of fall-back and clean degradation
is something that relates almost entirely to the application the script
is put to. So the best that any library can do is provide a clear
indicator of its inability to act and leave it to the author employing
the API library to test those indicators and react accordingly.

That significantly undermines the usefulness of API libraries as the
page author's task still includes all of the design and planning for
appropriate degradation and he/she still has to implement all of the
testing and checking code needed to achieve a reliable outcome.

So instead of learning browser DOMs and then coding to test, examine and
exploit those they need to learn a library specific API and how to cope
with its behaviour. Relying on the library to handle the task of
standardising the interface with the browser and appropriately indicate
the viability and outcome of that interaction.

One of the consequences of an author understanding browser DOMs and
scripting directly for the problem(s) specific to the page/site is that
he/she only creates enough code to address the situation and no more.
While the API library approach usually requires that the entire library
be downloaded whenever any of its components/features are used. And in
trying to shield the author from learning the DOMs of the browsers the
API library also serves to shield such an author from understanding how
to trim the library down to just those parts needed in the situation of
application.

That is particularly the case for libraries based on a small number of
large complex objects as in order to trim those down to only the
required code the page author also has to fully understand the code for
those objects. But an API based on a small number of large objects
would also find it hard to exploit a browser that implements enough to
address an isolated problem but not sufficient to fully support the
whole API.

On the whole I don't think that API libraries are suited to the problem
of browser scripting. The benefits can be achieved with a collection of
useful functions and objects tailored to isolated parts of the
browser-scripting task. But the overheads in attempting to completely
standardise the whole DOM in one API quickly become significant and
still doesn't significantly reduce the design and implementation task.

Richard.

"Richard Cornford" <> wrote:
> My expectation would be that any code intended to provide a consistent
> API for browsers including any good DOM browsers would work unaltered on
> any browser with a good DOM implementation, and especially Opera 7. When

That is what I also expected.

In the ISKEET library, the ISKEET_DocEncap class encapsulates DOM.
Only things not supported in DOM are passed to the compatibility layer,
in the ISKEET_CompatEncap class.

Unfortunately, DOM isn't even implemented the same across browsers.
Refer to the Gecko DOM reference (for Netscape/Mozilla), the Opera DOM
reference, and Internet Explorer's DOM reference.

For example, Internet Explorer and Opera support some aspects of DOM 2.0,
but instead of supporting all features to justify DOM 2.0 Core, Event
and CSS compliance, which would've been simple to implement, they
expose simply some 2.0 features that they happen to support.

DOM 2.0 is already old, and 3.0 in the works. This shows how browser
implementors adhere to standards.

The ISKEET library relieves the programmer from thinking about such
stuff. If a feature doesn't work, I can put it into the DocEncap or
CompatEncap layers without the programmer knowing about it.

Abstract libraries have been proven successful on Java, C++, C,
and other languages, and ECMAScript / JavaScript makes no exception.

I certainly don't want to hardcode my JavaScript support for every
web page I'm writing.

JavaScript is not a toy language for little bits of script, it's a
full-blown object-oriented scripting language that can be used for
other things than providing little expressions in HTML tag script
attributes.

> Opera 7 was first released about 14 months ago I was very happy to find
> that they had done such a good job of their DOM implementation that I
> did not have to alter one line of the code I had written previously.

If the DOM implementation was good, they would've supported all relevant
modules of DOM 2.0, which is already an old standard.

But you're right, Opera is suprisingly compatible to Internet Explorer,
which is a good thing.

> But the problem is not only that it failed on Opera for no good reason,

It would've also failed if I had used object-recognition for browser
detection, since in Opera 7, the JavaScript implementation is broken,
which I provided a workaround for. So all my pages using ISKEET 0.0.4 are
working now unchanged on Opera 7.

> but how it failed. The result of that failure was to render a site that
> could have been functionally implemented with pure HTML unusable.

I'm using mouseovers and click handlers on the ISKEET web site, which can't
be implemented in pure HTML.

> That
> demonstrates a shortfall in script design, as it doesn't plan for either
> the certain condition where the script fails entirely due to the absence
> of client-side script support,

When JavaScript isn't enabled, the ISKEET library is never called.

Hence, the web site developer has to include "<noscript>" tags on their
web site. (currently I haven't done so on the ISKEET home page, but that
hasn't anything to do with the ISKEET library itself)

> or the inability of the script to
> successfully execute due to the browser's lack of support for the
> required language features. Preventing any chance of achieving clean
> degradation.

ISKEET 0.0.4 provides clean degradation. Refer to the ISKEET manual.

> That isn't
> particularly surprising as the path of fall-back and clean degradation
> is something that relates almost entirely to the application the script
> is put to.

That is not true -- if the application programmer can rely on a library
to handle browser-specifics, they don't have to code browser-specifics
for any script application.

If their script application fails, it's a problem that can be corrected
in the library then, in the ideal case.

> That significantly undermines the usefulness of API libraries as the
> page author's task still includes all of the design and planning for
> appropriate degradation and he/she still has to implement all of the
> testing and checking code needed to achieve a reliable outcome.

With ISKEET, the program can rely entirely on the library.

> So instead of learning browser DOMs and then coding to test, examine and
> exploit those they need to learn a library specific API and how to cope
> with its behaviour.

The behaviour of the ISKEET library is supposed to be a black box, but the
programmer can have a look at the manual to find out what it exactly does.

> Relying on the library to handle the task of
> standardising the interface with the browser and appropriately indicate
> the viability and outcome of that interaction.

Yes. ISKEET is designed just for that purpose.

If there's an incompatibility, it can be corrected within ISKEET.

> One of the consequences of an author understanding browser DOMs and
> scripting directly for the problem(s) specific to the page/site is that
> he/she only creates enough code to address the situation and no more.

That is a common misconception about JavaScript.

ECMAScript / JavaScript is a full object-oriented scripting language.
It is designed for more than just small bits of script code.

With DOM 2.0, and DOM 3.0, provided there'll be standard-conformant
implementation across all browsers, JavaScript becomes the standard
tool for scripting web sites.

If a JavaScript developer hardcodes a script, they're not protected
from browser incompatibilities. A library can do that.

> While the API library approach usually requires that the entire library
> be downloaded whenever any of its components/features are used.

ISKEET is a small, modular library. The programmer decides which modules
they use.

> And in
> trying to shield the author from learning the DOMs of the browsers the
> API library also serves to shield such an author from understanding how
> to trim the library down to just those parts needed in the situation of
> application.

In the ISKEET manual, it is mentioned how the programmer can omit parts
of the library.

"Michael Winter" <> wrote:
> > BTW, in other languages, like PHP, the HTTP user agent string is the only
> > way to recognize the user's web browser.
>
> And that has what bearing on JavaScript?

That JavaScript can safely use the HTTP User Agent string.

Of course, you have to know what you're doing.

> In any event, it is unreliable
> and should not be used for the purpose of detecting implemented
> functionality.

I need it to work around a specific Opera 7 bug, but I've added object
detection support and proper fall-back mechanisms in version 0.0.4 of ISKEET.

It's not that I wouldn't listen to members of this NG!

> As I said above, you can't. For example, Opera, by default, masquerades as
> Internet Explorer 6.0, probably to get around sites like yours that use
> the user agent string to distinguish between browsers for no valid reason.

ISKEET 0.0.4 can recognize Opera, Opera 6 and Opera 7.

For compatibility-mode document and event handling, ISKEET 0.0.4 assumes
the Internet Explorer semantics, which seems to work.

> If a user wishes to change the User-Agent header, or a browser uses a
> value that does not accurately reflect the actual software, it is you that
> should suffer the consequences, not the user. There is nothing in either
> RFC 1945 or RFC 2616 about what the User-Agent header must contain, other
> than the general syntax of the value. In fact, the header isn't even
> required.

So, yeah, the ISKEET library 0.0.4 currently relies on the de-facto usage
of the HTTP User Agent string.

It is only the matter of minutes to change it into using object detection
only.

However, my library wouldn't have worked on Opera 7 that way, because
it has a bug in its JavaScript implementation.

> If you intend to write a viable, robust library, you must to accept the
> fact that the User-Agent header can be inaccurate, particularly when such
> a situation is perfectly valid.

Yes, and 0.0.4 has stronger checks for that. If the string contains
no useful information, it resorts to pure object presence detection.

> > There are also lots of browser-version specific JavaScript issues,
> > which can only be shipped around by checking the HTTP user agent string.
>
> Such as?

Like the JavaScript bug in Opera 7, that permits setting a load handler
for a window only hardcoded.

If you pass the window and code objects thru a number of function calls
and then assign them, it doesn't work.

The internal function ISKEET_CEO_AddEventHandler() handles that special
case, which would be impossible without HTTP User Agent check.

> On to a different subject (you've probably seen enough of "User-Agent
> header"). From your website:
>
> "...Also, the toString() method is defined differently than the
> toSource() method. Have a look at the ECMA 262 standard!..."
>
> I don't quite know what you're referring to there, but I think you should
> look at ECMA-262. There is no such method, of any object, called toSource.

JavaScript on Opera, for function objects, assumes toSource() semantics
where toString() would be appropriate.

toSource() is a browser-specific function introduced in Netscape Navigator.
It is present on all Netscape/Mozilla-type implementations.

That's just minor glitch in Opera that I've noticed that doesn't affect
the ISKEET library.

> The Opera documentation does NOT state that the SCRIPT element in XHTML is
> unsupported. It states that with XHTML 1.0 and 1.1 "in 'XML mode'...the
> script element is not supported". For 'XML mode' to be enabled, a document
> must have a MIME type other than "text/html". According to W3C's SGML
> parser, your documents have a MIME type of "text/html", so Opera will not
> interpret them as XML and so the SCRIPT element will be supported.

OK.

But why not support the script tag in XML mode?

> There is no mention of 'IE-type mouseovers' in the Opera documentation
> that I could see. Could you point to it?

In the event reference for Opera 7, it says that images support only
"complete". However, mouse down, up, over and out events are also
supported.

> Opera does NOT state that is DOM Level 2 compliant. It specifically
> states that "Opera 7 has full support for the [DOM Level 2 Core]
> Fundamental interfaces, apart from these exceptions...". As it does
> not fully support the Core module, it is not supposed to, and does
> not, return 'true' in response to
> document.implementation.hasFeature('core', '2.0').

Yeah, but some people think it _is_ DOM 2.0 compliant.

Since I have Opera 7 now, I can take all browser-specifics of it
into account when extending the ISKEET library.

Version 0.0.4 already works for Opera 7 with my sites, and that
just suits me well.

I will also test with a number of other browsers, like Konqueror
and the like, as soon as I get around to it.

"Randy Webb" <> wrote:
> Opera 7, in any spoof mode, contains the word "Opera" in the user agent
> string.

That's sufficient for the ISKEET library to detect Opera.

Version 0.0.4 now supports Opera 7.

> If you had bothered testing that, you would know it. And your
> statements seem to indicate that your knowledge base of Opera is very
> limited with regards to its userAgent string and how to detect Opera in
> general.

I have downloaded and installed Opera 7, so I'll be able to test the
current and future versions of ISKEET with it.

> > As soon as the Opera developers correct their JavaScript implementation
> > to conform to the standard (i.e. do proper parameter passing of objects
> > by reference), then I can lift the workaround for the new version.
> >
> > This would be impossible to detect without the HTTP UserAgent field,
> > and that's exactly what it's there for.
>
> if (window.opera){
> //opera code here.
> }
>
> <sarcasm>
> Wait, I didn't check the userAgent string, I must have done it wrong.
> </sarcasm>

What I was referring to was a JavaScript bug in Opera 7.

By testing "window.opera" you can only detect you're running on Opera.

But thanks, I will use this to detect Opera in the fall-back mechanism.

> > Then the user has to deal with the results. Many sites depend on the
> > UserAgent string, especially PHP sites, but also JavaScript sites.
>
> Then "many sites" are poorly written by amateurs posing as professionals
> that know what they are doing.

In PHP you have no other way to detect the browser type, since it's
server-based. A PHP script runs on the server side.

There are valid reasons for using the UserAgent string in JavaScript also,
despite this NG might think you can do without it.

> > Which will never happen, because then a lot of sites depending on this
> > will stop working. For example, PHP sites that generate optimized JavaScript
> > code for specific browser types.
>
> Again, if you are trying to "optimize" javascript, PHP is *not* the
> place to try to do it. If you want javascript optimized, use javascript
> to do it.

PHP sites that generate browser-specific HTML and JavaScript, can reduce
the amount of data transferred to the user.

It's not very uncommon and also used by high-end web sites and content-management
systems.

And "using JavaScript to do it", is just what I've done with ISKEET 0.0.4.

Perhaps someday I will add a JavaScript generator to my PHP library
(formerly named TigerPaw PHP Toolkit), and incorporate all of ISKEET's
functionality into it. Which might be a significant portion of code, in
the future.

"Ekkehard Morgenstern" <> wrote in
message news:bucn7n$sme$...
>"Janwillem Borleffs" <> wrote:
>>Take a look at Opera, the user can specify how this browser
>>should identify itself.
>
>Actually, for version 0.0.4, which I've just released, I had to
>work around a specific Opera bug (non-standard JavaScript
>implementation that does not conform to the ECMAScript 262 standard,
>unlike Netscape/Mozilla and Internet Explorer). If the user changes
>the user agent string to omit "Opera", then *poof* all sites using
>ISKEET will not load properly anymore. Tough luck, eh!

So following recommendations of techniques that avoid any need to be
interested in the User Agent string your reaction to failure due to your
insistence on using the UA string is "Tough luck"?

>As soon as the Opera developers correct their JavaScript
>implementation to conform to the standard (i.e. do proper
>parameter passing of objects by reference), then I can
>lift the workaround for the new version.
>
>This would be impossible to detect without the HTTP UserAgent field,

There is very little that cannot be determined by feature detection,
including language bugs. That is a good thing as in reality it is
impossible to identify the browser with the User Agent string.

>and that's exactly what it's there for.

The User Agent header has nothing to do with client side scripts at all.
And its (unspecified) inclusion as a property of the - navigator -
object has no implications beyond possibly letting a script find out how
the browser is identifying itself.

>>It's not the user, but the vendor which may temper the user
>>agent string because it's never a fixed value as a rule.
>
>Then the user has to deal with the results.

If the vendors did not include mechanisms for spoofing other browsers
then the consequences would be worse for the users of their browsers.

>Many sites depend on the UserAgent string,
>especially PHP sites, but also JavaScript sites.

Authoring to the lowest observable standard?

What do you expect those sites to return if the UA identified itself as
"IceBrowser 5.4" or "Web Browser 2.0"? They are going to either be
excluded from the site or get a minimal default (possibly text based)
pages, aren't they? Your attitude is not to support either in your API
library. Yet they both are capable of displaying images, using CSS,
executing ECMA Script and they even have W3C DOM support (dynamic in the
first case). In reality they both claim to be IE, what other option do
they have?

>>Per example, when the developers of the Mozilla browser decide to
>>use "gecko" instead of "Gecko", your detection is broken.
>
>Which will never happen, because then a lot of sites depending
>on this will stop working. For example, PHP sites that generate
>optimized JavaScript code for specific browser types.

Of current Gecko browsers, one has a type-in field in its preferences
for the user to enter a User Agent string of their own choosing and at
least one other has a drop-down list which includes UA strings identical
to both Opera and IE (and others).

Your PHP sites that attempt to use the UA string to identify the browser
are broken now, its just that their authors are not bright (or don't
care) enough understand the issues.

A large part of the reason that browsers spoof other browsers
(habitually, or by user options) is to avoid the consequences of this
sort of server-side browser detecting, because these idiots do not
recognise many browsers by name so the only way the unrecognised
browsers can access these sites is to give the impression that they are
recognised browsers. Very simply, the strategy of making
content/script/CSS decisions based on the UA string on the server sowed
the seeds of its own invalidity as a technique. It is currently invalid
and the results meaningless, browsers cannot be identified using the UA
string.

>>better to skip detection all together and test for the
>>objects/methods you want to use...
>
>Which doesn't work for problems like a broken JavaScript
>implementation in Opera 7.

To demonstrate a language implementation problem on Opera you need to
produce an isolated test case. Mixing it with the rest of your garbled
code demonstrates nothing beyond your limited understanding of ECMA
Script authoring.

But even if there were a language implementation problem it would still
be entirely feasible to create a discrimination test for that feature
rather than relying on bogus attempts to identify the browser. And, as
usual, directly testing the feature will produce results that always
have a one to one relationship with the occurrence of that feature, even
if that feature is a language bug.

>See my website, http://www.iskeet.de for a detailed problem
>description. Download version 0.0.4 to see my workaround.

Notes which read:-

<quote cite=" http://www.iskeet.de/ ">
(if Opera developers are viewing: parameter passing or sth. in your
JavaScript implementation doesn't seem to work, have a look at the file
"iskeet_compatencap.js", what workaround I had to do in
ISKEET_CEO_AddEventHandler(), setting a load handler for a window works
only hard-coded, as it seems, correct me if I'm wrong! In JavaScript,
objects are always passed by reference. Also, the toString() method is
defined differently than the toSource() method. Have a look at the ECMA
262 standard!). Also you mention in the documentation for Opera 7, that
it doesn't support the script tag in XHTML, which isn't true. Also,
event handling for IE-type mouseovers do work (in contrast to the
documentation). DOM 2.0 implementations have to support
document.implementation.hasFeature( "Core", "2.0" ), which Opera 7
doesn't. Hence, it's not DOM 2.0 compliant, unlike what you state in the
documentation.)
</quote>

The toSource and toString method should not be expected to do anything
but return a string in the case of toString. The ECMA spec has this to
say:-

<quote cite="ECMA 262 page 87">
15.3.4.2 Function.prototype.toString()
An implementation-dependent representation of the
function is returned.
...
</quote>

- and implementation-dependent means that Opera cannot be wrong whatever
it does. While the toString method of Object.prototype appears to do
exactly what is required of it.

And toSource is no part of ECMA Script at all so there can be no
expectation of its behaviour.

Whatever you do you can only use window.onload or window.attachEvent in
Opera 7 as from about 7.02 they removed the addEventListener method from
the global object. As the global object is not part of the DOM specs
there are no grounds for complaining about this.

Opera's XHTML documents do not currently support script elements (only
intrinsic events) but your pages written as - XHTML 1.0 Strict - are
being served as - text/html - instead of - application/xhtml+xml - and
if you tell a browser that you are sending it an HTML page then they
have a strong tendency to take you at your word and treat what they get
an unusually formed HTML document and error-correct it back to normal
tag soup HTML. The result is an HTML DOM and support for any feature
normally found in HTML DOMs. (Appendix C is a bit of a con really it
does not result in XHTML documents)

The claim about passing objects by reference seems to be a
misinterpretation of the consequences of other conditions and there are
plenty of those in your code. For example:-

<quote cite="iskeet_document.js">
function ISKEET_DocEncap_AddEventHandler( EventType, Elem, Code ) {
var listener = new Array();
listener.handleEvent = Code;
listener.iskeet = new Array();
listener.iskeet.elem = Elem;
listener.iskeet.type = EventType;
if(this.HasDOM && this.HasCoreDOM2 && this.HasDOM2Events){
listener.iskeet.elem.addEventListener
(listener.iskeet.type,listener,false);
}
else {
ISKEET_CEO_AddEventHandler
(listener.iskeet.type,listener.iskeet.elem,
listener.handleEvent );
}
return listener;
}
</quote>

- in which you are creating an Array (and for some reason not the Object
that would better suite the usage) as the - listener - local variable.
and then implementing the w3C events Level 2 - EventListener interface
on it (as defined in the IDL, with a handleEvent method). But the ECMA
Language Binding defines EventListener as:-

<quote cite="http://www.w3.org/TR/2000/
REC-DOM-Level-2-Events-20001113/ecma-script-binding.html">
Object EventListener
This is an ECMAScript function reference. This method has
no return value. The parameter is a Event object.
</quote>

- which unambiguously state that the interface _is_ a reference to a
function object (and the example code demonstrates this). Your
implementation is Java style rather than ECMA Script style. If it works
the Java way as well on Gecko browsers then good for them, but it also
works the ECMA Script way and that is how Opera have implemented it.

Richard.

"Richard Cornford" <> wrote:
> So following recommendations of techniques that avoid any need to be
> interested in the User Agent string your reaction to failure due to your
> insistence on using the UA string is "Tough luck"?

If I can use window.opera to test for Opera, as someone else suggested,
then it'll be no problem to detect Opera in the absence of the UA string.

I had to work around a bug with window.onload = code, which seems to
work only hard-coded.

Have a look at the ISKEET_CEO_AddEventHandler() function and its documentation
for details.

(version 0.0.4)

> There is very little that cannot be determined by feature detection,
> including language bugs.

How so?

How can I detect a language bug?

> That is a good thing as in reality it is
> impossible to identify the browser with the User Agent string.

In fact, it's very possible to do that, since not only PHP sites
depend on the proper setting of it.

I do not compare the entire string for equality, I just for keywords
in the string, like "Opera <version>" or "MSIE <version>", which
are guaranteed to be set anyway.

> The User Agent header has nothing to do with client side scripts at all.
> And its (unspecified) inclusion as a property of the - navigator -
> object has no implications beyond possibly letting a script find out how
> the browser is identifying itself.

In version 0.0.4 I use object and feature detection in conjunction with
the UA string, and it also works when the UA string isn't set at all,
so I guess the problem is solved now.

> If the vendors did not include mechanisms for spoofing other browsers
> then the consequences would be worse for the users of their browsers.

If you know what you're doing when parsing the UA string, it's not
a problem that it contains flags to indicate compatibility with
other browsers.

> What do you expect those sites to return if the UA identified itself as
> "IceBrowser 5.4" or "Web Browser 2.0"? They are going to either be
> excluded from the site or get a minimal default (possibly text based)
> pages, aren't they?

Nope. If they support DOM, they'll get as much DOM-handling as possible,
if they support "document.all", they'll get MSIE-compatible handling,
and if they support "document.layers", they'll get old Netscape-compatible
handling.

Refer to the documentation of ISKEET 0.0.4 for more information.

On Sun, 18 Jan 2004 10:56:48 +0100, Ekkehard Morgenstern
<> wrote:

> "Richard Cornford" <> wrote:

<snip>

>> But the problem is not only that it failed on Opera for no good reason,

<snip>

>> but how it failed. The result of that failure was to render a site that
>> could have been functionally implemented with pure HTML unusable.
>
> I'm using mouseovers and click handlers on the ISKEET web site, which
> can't be implemented in pure HTML.

Links can't be implemented in pure HTML. Since when? True, mouseover and
click events can't be used, but something as simple as a link can easily
be dual-natured. Any competent JavaScript author knows that one can do
this:

<A href="resource.html" onclick="<jscode>;return false">...</A>

to provide both a scripted, and pure HTML, interface for the site.

>> That demonstrates a shortfall in script design, as it doesn't plan for
>> either the certain condition where the script fails entirely due to
>> the absence of client-side script support,
>
> When JavaScript isn't enabled, the ISKEET library is never called.
>
> Hence, the web site developer has to include "<noscript>" tags on their
> web site. (currently I haven't done so on the ISKEET home page, but that
> hasn't anything to do with the ISKEET library itself)

Based on your logic, it's OK that 99% of a site is completely unusable, as
long as NOSCRIPT is used. Ideally, if JavaScript is non-functional (for
whatever reason), the entire site will still be fully usable.

>> or the inability of the script to
>> successfully execute due to the browser's lack of support for the
>> required language features. Preventing any chance of achieving clean
>> degradation.
>
> ISKEET 0.0.4 provides clean degradation. Refer to the ISKEET manual.

<snip>

ISKEET might, but your site certainly doesn't.

Mike

--
Michael Winter
d (replace ".invalid" with ".uk" to reply)

"Michael Winter" <> wrote:
> > I'm using mouseovers and click handlers on the ISKEET web site, which
> > can't be implemented in pure HTML.
>
> Links can't be implemented in pure HTML. Since when?

I didn't say that. I won't degrade the website, which works with Internet Explorer,
Netscape/Mozilla and Opera, as long as JavaScript is enabled, just to satisfy
your notion to do whatever thing with links.

> True, mouseover and
> click events can't be used, but something as simple as a link can easily
> be dual-natured. Any competent JavaScript author knows that one can do
> this:
>
> <A href="resource.html" onclick="<jscode>;return false">...</A>
>
> to provide both a scripted, and pure HTML, interface for the site.

Which may cause a page load failure on browsers that aren't scripted
by JavaScript. Then, the script tag could refer to whatever default
language the browser uses, like MyGreatScriptLanguage 128.39.

Hence, ISKEET and site-specific scripts are loaded on the ISKEET web page
explicitly by script tags in the header, declaring the language used
as JavaScript.

> Based on your logic, it's OK that 99% of a site is completely unusable, as
> long as NOSCRIPT is used. Ideally, if JavaScript is non-functional (for
> whatever reason), the entire site will still be fully usable.

I didn't say that. I just said I haven't included NOSCRIPT and NOFRAME
handling on the website yet.

On Sun, 18 Jan 2004 13:24:11 +0100, Ekkehard Morgenstern
<> wrote:

> "Michael Winter" <> wrote:
>
>> True, mouseover and click events can't be used, but something as
>> simple as a link can easily be dual-natured. Any competent JavaScript
>> author knows that one can do this:
>>
>> <A href="resource.html" onclick="<jscode>;return false">...</A>
>>
>> to provide both a scripted, and pure HTML, interface for the site.
>
> Which may cause a page load failure on browsers that aren't scripted
> by JavaScript. Then, the script tag could refer to whatever default
> language the browser uses, like MyGreatScriptLanguage 128.39.

How? If I state that intrinsic events use JavaScript[1] and the browser
doesn't support it, it won't handle the event. If it does, that's a flaw
in the browser's implementation, not my authoring.

I don't rely on the browser's default scripting language. It states
clearly in Section 18.2.2 of the HTML 4.01 Recommendation that authors
must explicity inform the browser of the scripting language used for both
intrinsic events and SCRIPT elements.

Mike

[1] Performed by including the following META element, as per the W3C HTML
4.01 Recommendation, Section 18.2.2 - Specifying the scripting language.

<META http-equiv="Content-Script-Type" content="text/javascript">

--
Michael Winter
d (replace ".invalid" with ".uk" to reply)