Ekkehard Morgenstern said:
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.
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?
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.
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.
