Discussion:
Accessing the global object
(too old to reply)
Bob
2008-02-22 01:10:09 UTC
Permalink
Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?

Thanks
Joost Diepenmaat
2008-02-22 01:19:26 UTC
Permalink
Post by Bob
Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?
If you know the name of the global and you're sure you're not overriding
the name, you can use the global name.

IWO, yes and no.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Thomas 'PointedEars' Lahn
2008-02-24 01:33:48 UTC
Permalink
Post by Joost Diepenmaat
Post by Bob
Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?
If you know the name of the global and you're sure you're not overriding
the name, you can use the global name.
Utter nonsense. Objects have identity, not names.
Post by Joost Diepenmaat
IWO, yes and no.
No. The correct answer is no, and the approach described by the OP the only
correct one because interoperable one.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Peter Michaux
2008-02-22 01:35:33 UTC
Permalink
Post by Bob
Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object. I think your idea of creating your own
"_global" is better. In ECMAScript 4 there will be a default "global"
property of the global object that references the global object. It
will work like "window" but "window" is a bad name when scripting in a
non-browser host.

Peter
Thomas 'PointedEars' Lahn
2008-02-24 01:37:30 UTC
Permalink
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
Post by Peter Michaux
I think your idea of creating your own "_global" is better.
In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
I am looking forward to that.
Post by Peter Michaux
It will work like "window" but "window" is a bad name when scripting in a
non-browser host.
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Peter Michaux
2008-02-24 03:29:32 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
I think your idea of creating your own "_global" is better.
In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
I am looking forward to that.
Post by Peter Michaux
It will work like "window" but "window" is a bad name when scripting in a
non-browser host.
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?
this.opener

this.parent

this.frames

Peter
Thomas 'PointedEars' Lahn
2008-02-24 11:20:38 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
I am looking forward to that.
Post by Peter Michaux
It will work like "window" but "window" is a bad name when scripting in a
non-browser host.
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?
this.opener
this.parent
this.frames
That would imply ECMAScript Edition 4 is going to standardize properties of
Window host objects as built-in properties of the Global Object, and
therefore to disallow the creation of global variables named `opener',
`parent', and `frames'. I find that hard to believe.

But the question was instead whether and if, how ECMAScript 4 is going to
deal with the problem that one wants to refer to a *property *of the objects
these properties are referring to as a property of another global execution
context. Currently there is the agreement that a Window object (referred to
by the aforementioned properties) identifies the Global Object of the other
global execution context. I'd rather have a standard normatively specify
that agreement once and for all, not necessarily ECMAScript 4 though. Hence
my question.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Peter Michaux
2008-02-24 18:18:00 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
I am looking forward to that.
Post by Peter Michaux
It will work like "window" but "window" is a bad name when scripting in a
non-browser host.
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?
this.opener
this.parent
this.frames
That would imply ECMAScript Edition 4 is going to standardize properties of
Window host objects as built-in properties of the Global Object
I don't see a problem. As far as I know, they aren't standardizing the
properties of the global object, they are simply standardizing a way
to access the global object that can be sensibly used in a non-browser
host.

[snip <--- look Thomas, I snipped]

By the way, http://pointedears.de/scripts/ is still an error page.

Peter
Thomas 'PointedEars' Lahn
2008-02-24 18:36:25 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
[...]
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?
this.opener
this.parent
this.frames
That would imply ECMAScript Edition 4 is going to standardize properties of
Window host objects as built-in properties of the Global Object
I don't see a problem. As far as I know, they aren't standardizing the
properties of the global object, they are simply standardizing a way
to access the global object that can be sensibly used in a non-browser
host.
Then you probably meant to say global.window.opener aso. However, that
still does not answer my question.
Post by Peter Michaux
By the way, http://pointedears.de/scripts/ is still an error page.
Thanks, fixed. Apparently I accidentally uploaded the a newer version
of the ES Matrix index document to a location where it does not belong.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Peter Michaux
2008-02-24 19:06:54 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?

Peter
Thomas 'PointedEars' Lahn
2008-02-24 22:04:17 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?
Your continuously missing the point, and making just more fallacious
arguments (here again: shifting the burden of proof), is becoming tiresome.

http://en.wikipedia.org/wiki/List_of_fallacies


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$***@news.demon.co.uk>
Peter Michaux
2008-02-24 23:31:28 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?
Your continuously missing the point,
If you clearly state your point then I will not miss it.

I stated that the overwhelming majority JavaScript hosts are web
browsers similar to NN4+ and IE4+. By this I also mean browsers like
IE7, FF2, etc. I am right. You seem to think I am wrong but you are
not able to identify these billions of JavaScript hosts that I should
consider. I would like to know to which billions of JavaScript hosts
you refer. They don't exist so you cannot do so. Instead you are
resorting to nitpicking about who has the burden of proof. Where are
your billions of hosts, Thomas? I'll even take hundreds of millions of
hosts if you can come up with those.

If you are trying to make some other point completely then I'm
interested what that is. There is no need to be so oblique about it.
Just say what you want to say in plain language. It cannot be so
difficult.

Peter
Thomas 'PointedEars' Lahn
2008-02-24 23:49:01 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?
Your continuously missing the point,
If you clearly state your point then I will not miss it.
I find it rather boring to direct people from A to B to C, and therefore
first assume they are able to think for themselves.
Post by Peter Michaux
I stated that the overwhelming majority JavaScript hosts are web
browsers similar to NN4+ and IE4+. By this I also mean browsers like
IE7, FF2, etc. I am right. [...]
Not at all. You just don't know the whole (be it "browsers" or "JavaScript
hosts on earth", so you are not able to make a correct statement about a
majority in the whole. You can only make a correct statement about a
majority in the perceived subset (as listed above). However, such a
statement is rather irrelevant if the goal is interoperability, and it is
meaningless with regard to the foreseeable future. As simple as that.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$***@news.demon.co.uk>
Peter Michaux
2008-02-24 23:53:30 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?
Your continuously missing the point,
If you clearly state your point then I will not miss it.
I find it rather boring to direct people from A to B to C, and therefore
first assume they are able to think for themselves.
Post by Peter Michaux
I stated that the overwhelming majority JavaScript hosts are web
browsers similar to NN4+ and IE4+. By this I also mean browsers like
IE7, FF2, etc. I am right. [...]
Not at all. You just don't know the whole (be it "browsers" or "JavaScript
hosts on earth", so you are not able to make a correct statement about a
majority in the whole. You can only make a correct statement about a
majority in the perceived subset (as listed above). However, such a
statement is rather irrelevant if the goal is interoperability, and it is
meaningless with regard to the foreseeable future. As simple as that.
The overwhelming majority of JavaScript hosts are web browsers. Simple
as that.

Peter
Thomas 'PointedEars' Lahn
2008-02-25 01:09:42 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
[...]
I stated that the overwhelming majority JavaScript hosts are web
browsers similar to NN4+ and IE4+. By this I also mean browsers like
IE7, FF2, etc. I am right. [...]
Not at all. You just don't know the whole (be it "browsers" or "JavaScript
hosts on earth", so you are not able to make a correct statement about a
majority in the whole. You can only make a correct statement about a
majority in the perceived subset (as listed above). However, such a
statement is rather irrelevant if the goal is interoperability, and it is
meaningless with regard to the foreseeable future. As simple as that.
The overwhelming majority of JavaScript hosts are web browsers. Simple
as that.
Even if that was true, it says nothing about all Web browsers. You really
should get a new logic module.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Richard Cornford
2008-02-25 01:25:42 UTC
Permalink
Peter Michaux wrote:
<snip>
Post by Peter Michaux
The overwhelming majority of JavaScript hosts are web
browsers. Simple as that.
There is quite a tangled question of how you would set about counting
something that has very debatable substance. The worlds second most common
javascript host (note that is not capitalised into the trademark name, for
any pedants reading) must be windows scripting host. I say that because by
default it gets installed on every individual machine running Windows. Of
course that just means the software for WSH is on a very larger number of
hard disks. The bulk of people using Windows don't know they have WSH and so
never execute it (and a fair few that know they have it will never execute
it as well). So what would be being counted? Bytes stored on some sort of
media (how many AOL CDs have been distributed with a browser's code stored
on them), executing code, executed code, code that is executing at this
precise time, code stored in a way that gives it the potential to be
executed (as opposed to sitting at the bottom of a landfill)?

You can argue the definitions of terms forever (because you can always argue
about the terms used to argue about the first terms, and so on recursively).
The bottom line is that it is impossible to prove anything (except maybe in
mathematics), but if a statement has testable consequences it can be
demonstrated to be false. Thus knowledge grows by the elimination of the
things that can be shown to be false from the set of things that are
believed to be known (where the set of things that are believed to be know
does not include things that are metaphysical, as they are just believed (or
not)).

In the context of generalisations about web browsers the single example of a
browser being an exception is precisely the sort of thing that is needed to
falsify the generalisation. A good example might be the proposed
generalisation that the - DefaultView - property of documents specified in
the W3C Views DOM is always a reference to the ECMAScript global object
(and/or the window/frame object). That generalisation is shown to be false
by IceBrowser 5, where the document's - DefaultView - property refers to an
object that fully implements the W3C specified interface for the object but
is not the ECMAScript global object/window object. There may be other
browsers were that is also the case, or there may not. That does not matter
because the single example is enough to falsify the generalisation (thus you
can stop looking after finding the first).

Richard.
David Mark
2008-02-25 03:12:40 UTC
Permalink
Post by Richard Cornford
<snip>
Post by Peter Michaux
The overwhelming majority of JavaScript hosts are web
browsers. Simple as that.
There is quite a tangled question of how you would set about counting
something that has very debatable substance. The worlds second most common
javascript host (note that is not capitalised into the trademark name, for
any pedants reading) must be windows scripting host. I say that because by
default it gets installed on every individual machine running Windows. Of
course that just means the software for WSH is on a very larger number of
hard disks. The bulk of people using Windows don't know they have WSH and so
never execute it (and a fair few that know they have it will never execute
it as well). So what would be being counted? Bytes stored on some sort of
media (how many AOL CDs have been distributed with a browser's code stored
on them), executing code, executed code, code that is executing at this
precise time, code stored in a way that gives it the potential to be
executed (as opposed to sitting at the bottom of a landfill)?
You can argue the definitions of terms forever (because you can always argue
about the terms used to argue about the first terms, and so on recursively).
The bottom line is that it is impossible to prove anything (except maybe in
mathematics), but if a statement has testable consequences it can be
demonstrated to be false. Thus knowledge grows by the elimination of the
things that can be shown to be false from the set of things that are
believed to be known (where the set of things that are believed to be know
does not include things that are metaphysical, as they are just believed (or
not)).
In the context of generalisations about web browsers the single example of a
browser being an exception is precisely the sort of thing that is needed to
falsify the generalisation. A good example might be the proposed
generalisation that the - DefaultView - property of documents specified in
the W3C Views DOM is always a reference to the ECMAScript global object
Yes, I have heard that it is a bad assumption that
document.defaultView == window.
Post by Richard Cornford
(and/or the window/frame object). That generalisation is shown to be false
by IceBrowser 5, where the document's - DefaultView - property refers to an
object that fully implements the W3C specified interface for the object but
is not the ECMAScript global object/window object. There may be other
browsers were that is also the case, or there may not. That does not matter
because the single example is enough to falsify the generalisation (thus you
can stop looking after finding the first).
Is there a property of document in IceBrowser that leads to its parent
window? IE has the parentWindow property and defaultView is the only
other option I know of to find the appropriate window object (though
apparently it is not 100% reliable.) I don't often have the need to
find the parent window of a random document, but I would like to know
if there is a more reliable way to do it.
Peter Michaux
2008-02-25 03:19:59 UTC
Permalink
[snip]
Post by David Mark
Post by Richard Cornford
In the context of generalisations about web browsers the single example of a
browser being an exception is precisely the sort of thing that is needed to
falsify the generalisation. A good example might be the proposed
generalisation that the - DefaultView - property of documents specified in
the W3C Views DOM is always a reference to the ECMAScript global object
Yes, I have heard that it is a bad assumption that
document.defaultView == window.
In Safari 2.0 the following is false. It is true Safari 3

this.document.defaultView == this

[snip]

Peter
David Mark
2008-02-25 03:35:18 UTC
Permalink
Post by Peter Michaux
[snip]
Post by David Mark
Post by Richard Cornford
In the context of generalisations about web browsers the single example of a
browser being an exception is precisely the sort of thing that is needed to
falsify the generalisation. A good example might be the proposed
generalisation that the - DefaultView - property of documents specified in
the W3C Views DOM is always a reference to the ECMAScript global object
Yes, I have heard that it is a bad assumption that
document.defaultView == window.
In Safari 2.0 the following is false. It is true Safari 3
this.document.defaultView == this
I updated my function that finds a window from a random document to
test for this. I don't use it often, but I don't want it to return
the wrong object when I do!
Richard Cornford
2008-02-25 22:37:05 UTC
Permalink
David Mark wrote:
<snip>
Post by David Mark
Is there a property of document in IceBrowser that leads
to its parent window? ...
<snip>

The only value of the IceBrowser 5 document that refers to its parent window
is its - __parent__ - property.

Richard.
Peter Michaux
2008-02-25 23:43:09 UTC
Permalink
<snip>> Is there a property of document in IceBrowser that leads
Post by David Mark
to its parent window? ...
<snip>
The only value of the IceBrowser 5
Richard, it seems IceBrowser comes up quite a bit in your posts and I
have never heard of anyone using it. Is it something you use in your
work?

Peter
Richard Cornford
2008-02-26 23:08:49 UTC
Permalink
Post by Peter Michaux
<snip> Is there a property of document in IceBrowser
that leads to its parent window? ...
<snip>
The only value of the IceBrowser 5
Richard, it seems IceBrowser comes up quite a bit in
your posts
It is a fully dynamic, visual, scriptable, W3C DOM standard web browser so,
where it can be an example, it is a good example of exceptions to the
generalisations that expose the assumptions.
Post by Peter Michaux
and I have never heard of anyone using it. Is
it something you use in your work?
No, it is a browser that I acquired while collecting web browsers. I managed
to get fully scan it with my DOM recording script a couple of times before
the evaluation licence ran out so I have quite a good record of what it was
capable of.

Richard.
Peter Michaux
2008-02-27 05:20:21 UTC
Permalink
Post by Richard Cornford
Post by Peter Michaux
<snip> Is there a property of document in IceBrowser
that leads to its parent window? ...
<snip>
The only value of the IceBrowser 5
Richard, it seems IceBrowser comes up quite a bit in
your posts
It is a fully dynamic, visual, scriptable, W3C DOM standard web browser so,
where it can be an example, it is a good example of exceptions to the
generalisations that expose the assumptions.
I agree but I often wonder how far to take this attitude? If your
neighbor's teenage child writes a browser that is bug ridden and
breaks many feature detection scripts (i.e. requires more feature
testing rather than just detection) and breaks workarounds for
undetectable/untestable browser bugs (e.g. rendering bugs), what do
you do? At what point is a browser considered worthy of consideration?

It seems that each browser introduced to the market adds some positive
number of bugs to the overall browser bug count. If the number of
browsers increases indefinitely, as these bugs accumulate there is a
high (1?) probability that there will not be a feature detection/
testing path or workaround path that makes its way through all these
bugs for a particular feature. If discarding some less popular
browsers means that a path reappears then that would be a practical
choice.

Peter
Matt Kruse
2008-02-27 16:12:37 UTC
Permalink
Post by Peter Michaux
I agree but I often wonder how far to take this attitude? If your
neighbor's teenage child writes a browser that is bug ridden and
breaks many feature detection scripts (i.e. requires more feature
testing rather than just detection) and breaks workarounds for
undetectable/untestable browser bugs (e.g. rendering bugs), what do
you do? At what point is a browser considered worthy of consideration?
This is the question at the heart of why the "big libraries" choose to
support only limited browsers, and a question that some of the people
here who are against limiting support to the "big 4 browsers" don't
like to answer directly.

If you really want to support every browser that could ever exist,
then you can truly make no assumptions about behavior, because any
feature could be broken and any behavior could have quirks. You would
need to do exhaustive testing of every core language feature possible.

This quickly becomes impractical, so the first conclusion is that some
assumptions must be made. Core language features are assumed to work
correctly unless proven otherwise in some browser. But if I create a
browser tomorrow, used only by me, where document.getElementById()
always returns the BODY element, are you going to put a test in your
code for this behavior once you know my browser exists?

No, of course not. Because the second logical conclusion is that we
can only worry about a subset of all possible browsers. It would be
impractical code that would truly run on any arbitrary browser with
unknown quirks or bugs.

So the question is not "should we only worry about a subset of
browsers" but "how do you determine that subset?"

The big library authors limit their subset to the "major" browsers
because they constitute the huge majority of all users on the web, and
it makes their testing and development scope smaller and more
manageable.

The experts here tend to expand their subset to include more obscure
browsers, and write code that will try to work even on browsers that
are not known about. Or older browsers that may not actually be used
by anyone anymore.

Which approach is "better"? Depends on your goals and priorities.

Clearly, it would be better to support as many browsers as possible
and to have code that is as browser-agnostic as possible. But there is
a practical limitation to this, and a line must be drawn somewhere.

- Do you wait for a proven example of a browser having a broken
feature before you test for it?
- If you are aware of the broken feature but the browser is rare and
most likely never used by your site's visitors, do you spend the time
writing the fix for this browser, or just ignore it?
- Do you spend time investigating, testing, and writing work-arounds
for obscure browsers used by a fraction of a percentage of your users,
or should broken pages tell them that they need to use a better
browser?
- What percentage of your potential site visitors (if any) are you
willing to sacrifice if your code doesn't work for them, as a trade-
off for saved development/testing/debugging time and effort?

I don't think all the answers are as clear-cut as some would make them
out to be, and the answers really depend on specific situations.

Matt Kruse
David Mark
2008-02-27 20:17:05 UTC
Permalink
Post by Matt Kruse
Post by Peter Michaux
I agree but I often wonder how far to take this attitude? If your
neighbor's teenage child writes a browser that is bug ridden and
breaks many feature detection scripts (i.e. requires more feature
testing rather than just detection) and breaks workarounds for
undetectable/untestable browser bugs (e.g. rendering bugs), what do
you do? At what point is a browser considered worthy of consideration?
This is the question at the heart of why the "big libraries" choose to
support only limited browsers, and a question that some of the people
here who are against limiting support to the "big 4 browsers" don't
like to answer directly.
The reason that the "big libraries" support limited browsers is
because they use browser sniffing. You can't put an unlimited
database of user agent strings in a JavaScript library. The reason
they use browser sniffing is because the authors are incapable of
writing cross-browser code, even when the number of browsers supported
is limited to three or four in their default configurations. The end
result is that the "big libraries" break in virtually everything else,
in completely unpredictable ways, rendering pages unusable. That's
why they are inappropriate for use on the public Internet (or anywhere
else if you care about future maintenance costs.)
Post by Matt Kruse
If you really want to support every browser that could ever exist,
then you can truly make no assumptions about behavior, because any
feature could be broken and any behavior could have quirks. You would
need to do exhaustive testing of every core language feature possible.
Features of the JavaScript language are not the primary issue, but
assumptions about host objects are generally a bad idea.
Post by Matt Kruse
This quickly becomes impractical, so the first conclusion is that some
What is impractical is trying to branch by browser name, which is why
the "big libraries" stipulate that they work only with the current
versions of three or four browsers. It is also impractical to try to
keep up with new revisions of these browsers by constantly adding and
removing such branches. Oddly enough, there are veritable armies of
open source developers attempting to do just that. Application
developers would be wise to steer clear of their efforts.
Post by Matt Kruse
assumptions must be made. Core language features are assumed to work
Again with the language features.
Post by Matt Kruse
correctly unless proven otherwise in some browser. But if I create a
browser tomorrow, used only by me, where document.getElementById()
That is a method of a host object, not a language feature.
Post by Matt Kruse
always returns the BODY element, are you going to put a test in your
code for this behavior once you know my browser exists?
Of course not, because nobody is going to use your browser.
Post by Matt Kruse
No, of course not. Because the second logical conclusion is that we
What was the first one?
Post by Matt Kruse
can only worry about a subset of all possible browsers. It would be
There is no need to design for a subset of browsers. And there is
certainly no need to write code that attempts to pigeon-hole browsers
by name, version, revision, etc., especially when it is well known
that browsers lie about such things. If code assumes that anything
that claims to be IE is IE, then graceful degradation is impossible.
Unfortunately for those who would attempt to defend the currently
popular "big libraries", that is exactly what they do. Even worse,
all indications are that IE8 will behave more like a standards-based
browser, so in the near future, all assumptions based on IE's name
will be exposed as folly to a much broader audience.
Post by Matt Kruse
impractical code that would truly run on any arbitrary browser with
unknown quirks or bugs.
Nobody ever said that browser scripting is 100% reliable in every
known or unknown agent.
Post by Matt Kruse
So the question is not "should we only worry about a subset of
browsers" but "how do you determine that subset?"
Not the way that the "big libraries" do it, that's for sure.
Post by Matt Kruse
The big library authors limit their subset to the "major" browsers
because they constitute the huge majority of all users on the web, and
No, they do that because that is all they know how to do. And there
is no way to quantify this "huge majority of all users on the Web."
Post by Matt Kruse
it makes their testing and development scope smaller and more
manageable.
It doesn't matter why they do what they do. The fact is that they do
it incompetently, so their products cannot be relied upon, especially
not for applications destined for the public Internet.
Post by Matt Kruse
The experts here tend to expand their subset to include more obscure
browsers, and write code that will try to work even on browsers that
are not known about. Or older browsers that  may not actually be used
by anyone anymore.
Actually the recent trend is to create multiple versions of functions
to allow application developers to choose their own degradation path.
The difference is that none of the paths presented lead to ruined
pages.
Post by Matt Kruse
Which approach is "better"? Depends on your goals and priorities.
I think the answer is clear. No sane developer's goal is to mortgage
their future with code that branches by browser name. The exceptions
are those who purposely write obsolete code to ensure future
maintenance work.
Post by Matt Kruse
Clearly, it would be better to support as many browsers as possible
and to have code that is as browser-agnostic as possible. But there is
a practical limitation to this, and a line must be drawn somewhere.
If only the authors of the "big libraries" knew how to draw such a
line.
Post by Matt Kruse
- Do you wait for a proven example of a browser having a broken
feature before you test for it?
Typically. But you don't test for it by parsing the user agent
string.
Post by Matt Kruse
- If you are aware of the broken feature but the browser is rare and
most likely never used by your site's visitors, do you spend the time
writing the fix for this browser, or just ignore it?
On the public Internet, your site's visitors could be anybody. And
writing a fix for a specific browser is not always the best (or only)
alternative available.
Post by Matt Kruse
- Do you spend time investigating, testing, and writing work-arounds
for obscure browsers used by a fraction of a percentage of your users,
If you are distributing a general purpose library for use on the
public Internet, then you really have no choice. Often the best
choice is not to write a general purpose JavaScript library in the
first place. If only the authors of jQuery, Prototype, etc. had made
that choice, the Web would be far more usable.
Post by Matt Kruse
or should broken pages tell them that they need to use a better
browser?
Broken pages don't typically know that they are broken. That is the
problem. And no page should tell a user to get a "better browser."
Not only is that an insult to the user, but there is no reliable way
for a page to identify a browser. Pages should degrade gracefully
when required features are unavailable or determined to be unreliable.
Post by Matt Kruse
- What percentage of your potential site visitors (if any) are you
willing to sacrifice if your code doesn't work for them, as a trade-
off for saved development/testing/debugging time and effort?
You don't have to sacrifice any users. Some users may not be able to
use all of your enhancements, but that is hardly a concern. The
sacrifice comes when pages break in ways that their authors' did not
anticipate, leaving them in an unusable state.
Post by Matt Kruse
I don't think all the answers are as clear-cut as some would make them
out to be, and the answers really depend on specific situations.
Some answers are clear-cut.

* Don't use "big libraries" (or any scripts) that make ridiculous
assumptions about browsers.

* Don't write scripted enhancements unless you can clearly see the
required degradation paths.

* Never assume that host features exist.

* Test required features as thoroughly as is practical. When tests
are impractical (or impossible), design around features that are known
to be unreliable.

* General purpose JavaScript libraries that attempt to do everything
cannot always design around features, which is why they are generally
not a good idea. Resorting to browser sniffing is not a solution; it
only creates the illusion of viability.

* Applications intended for use on the public Internet should be
tested in as many agents as possible.
Richard Cornford
2008-03-02 16:28:20 UTC
Permalink
Post by Peter Michaux
Post by Richard Cornford
Post by Peter Michaux
<snip> Is there a property of document in IceBrowser
that leads to its parent window? ...
<snip>
The only value of the IceBrowser 5
Richard, it seems IceBrowser comes up quite a bit in
your posts
It is a fully dynamic, visual, scriptable, W3C DOM standard
web browser so, where it can be an example, it is a good
example of exceptions to the generalisations that expose
the assumptions.
I agree but I often wonder how far to take this attitude?
Take what attitude? If someone says "show me a browser where this thing
happens/doesn't happen" and you can cite such a browser then citing such a
browser seems an appropriate response. It is then useful if they cannot come
back and say "that browser is not modern", "that browser is not W3C
standard", "that browser is not dynamic", and so on.

After all, if the question is your 'in which browsers does - window - not
represent a reference to the global object?' my answer is; to date, no
scriptable web browsers have been observed or reported in which - window -
was not a reference to the global object. Which is a near meaningless
response from someone who has only ever heard of 3 or 4 browsers and a
little more significant from someone who goes out looking for new browsers
and studies them in some depth.
Post by Peter Michaux
If your neighbor's teenage child writes a browser that is
bug ridden and breaks many feature detection scripts (i.e.
requires more feature testing rather than just detection)
and breaks workarounds for undetectable/untestable browser
bugs (e.g. rendering bugs), what do you do?
How could you do anything? Nobody but its creator is going to use such a
browser (because it will look very broken when exposed to most of the web
sites that exist) and nobody is going to tell you of its existence.

A much more interesting question arises when the company next door creates a
new (scriptable) web browser and sells it to Nokia or someone, who then ship
it with 100 million new mobile phone handsets. Because in that case again
nobody is going to tell you it has happened, but this time there are going
to be 100 million potential users/customers with the software. The only
saving grace in that case being that it is unlikely that such a browser
would be getting put onto 100 million handsets without its first giving a
good impression of not being broken on a fair number of existing web sites.
Post by Peter Michaux
At what point is a browser considered worthy of
consideration?
The ability to ask a question often gives the false impression that the
question should (or could) be answered. An example might be the question
"What is the meaning of life?". The asking of the question implies that
there should be a 'meaning of/to life', and allows all manner of nonsense to
be injected into the void were the answer to the question would/could be.
That is at least so long as you don't observe that life is a natural
phenomenon like gravity and that "What is the meaning of gravity?" is such a
nonsense question that nobody would expect it to deserve an answer (or be at
all surprised when no obvious answer was forthcoming).

You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions. First
that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? I know that Opera, Safari and
NetFront will be in that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at all (and probably
more)).

Second, that there is a "point" that can be determined in some way. Given
that web statistics are inherently problematic to gather, tend to be
self-biasing and that the statistics gathering techniques that are used are
incapable of discriminating between web browsers (that is, many web browser
that are not IE will end up being listed as IE), can you ever say where any
one browser is at any time in order to decide whether that "point" means it
should be "worthy of consideration".

Third, that the single question should be asked prior to establishing the
context in which "worthy of consideration" should be applied. If, for
example, I am designing a web application for internal use by corporate
users I may well find myself in a position to know a grate deal about the
browsers/OSs in use and so find it very easy to say that every browser that
is not in a very short list is not 'worthy of consideration' (thus avoiding
needed to know the names of the unworthy contenders).
Post by Peter Michaux
It seems that each browser introduced to the market adds some
positive number of bugs to the overall browser bug count.
That is software for you.
Post by Peter Michaux
If the number of browsers increases indefinitely,
The total is unlikely to go down over time.
Post by Peter Michaux
as these bugs accumulate
While to total number of web browser can only go up the number of bugs can
go down, as bugs are only important when they are bugs in the browsers that
still may get used and bug fixes do happen.
Post by Peter Michaux
there is a high (1?) probability that there will not be a
feature detection/ testing path or workaround path that makes
its way through all these bugs for a particular feature.
The observation that it may be the case that all of the possibilities may
not be covered by feature detection/testing is only significant if there is
a better alternative. In that case it becomes a very solid justification for
using that alternative. But it is the case that the alternatives available
for handling browser differences are both significantly worse than feature
detection/testing. A potential shortcoming of the best strategy available is
hardly a reason for even considering worse alternatives, so the situation
does not change.
Post by Peter Michaux
If discarding some less popular browsers means that a path
reappears then that would be a practical choice.
But it is a very big 'if'. It would never be possible to say that a browser
that I have never heard of must be 'less popular' than one I have heard off
in a world where the very latest technology is being shipped with
pre-installed/embedded web browsers that are unidentified. I can tell you
that I don't care in the slightest what Netscape 3 (or any other
sufficiently ancient browser) might do with any script written in 2008 but
going much beyond that is putting yourself well into the area of guesswork.

In the end (and as you know) I favour a flexibility of approach, where the
requirements of the project are the starting point for the design and any
other questions that may need to be answered come after the precise
identification of the purpose that is to be achieved. In that way many
questions that could be asked can be seen to be irrelevant in the real
context, and many paths that would be problematic in other contexts may be
avoided entirely. So for an internal corporate web application that needs no
more than OS independence you might conclude that only IE and Firefox are
"worthy of consideration", while if you are trying to maximise turnover
while attempting to sell widgets to the global general public the bottom
line is that any web browser that can render HTML and submit forms over
HTTP(S) is capable of contributing to that turnover, and so, that any
scripted action may detract from that goal and so need very considered
handling.

Richard.
dhtml
2008-03-02 17:53:17 UTC
Permalink
Post by Richard Cornford
You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions. First
that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? I know that Opera, Safari and
NetFront will be in that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at all (and probably
more)).
As strange as it may sound, there actually is a comprehensive list of
all web browsers. It's called WURFL. In WURFL, you will find
attributes for browsers that support ajax, dom, et c.

WURFL includes info on mass marketed garbage browsers, such as Verizon
Motorola RAZR 3, to helio, et c.

Garrett
Post by Richard Cornford
Richard.
Thomas 'PointedEars' Lahn
2008-03-02 18:34:54 UTC
Permalink
Post by dhtml
Post by Richard Cornford
You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions. First
that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? [...]
As strange as it may sound, there actually is a comprehensive list of
all web browsers. It's called WURFL. In WURFL, you will find
attributes for browsers that support ajax, dom, et c.
WURFL includes info on mass marketed garbage browsers, such as Verizon
Motorola RAZR 3, to helio, et c.
JFTR: http://wurfl.sourceforge.net/

So we have a maybe complete list of browsers used on mobile devices today.
However, that does not mean anything for tomorrow or user agents on other
devices.

So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.

If it still happens that the code breaks in a user agent and that becomes
known to the developer, then one should maybe add a branch for that user
agent. That decision depends of course mostly on the bug in the user agent
that caused it, if it could be worked around at all. If not, the UA is
broken and should not be supported.


PointedEars
Peter Michaux
2008-03-03 00:07:03 UTC
Permalink
On Mar 2, 10:34 am, Thomas 'PointedEars' Lahn <***@web.de>
wrote:

[snip]
JFTR:http://wurfl.sourceforge.net/
So we have a maybe complete list of browsers used on mobile devices today.
However, that does not mean anything for tomorrow or user agents on other
devices.
So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.
But how to choose that limited set? I have never read anyone's
concrete rules for making this choice but I have read criticism of the
mainstream library writers for their choices.
If it still happens that the code breaks in a user agent and that becomes
known to the developer, then one should maybe add a branch for that user
agent. That decision depends of course mostly on the bug in the user agent
that caused it, if it could be worked around at all. If not, the UA is
broken and should not be supported.
"maybe"? "mostly"?

I agree this is all grey area but people are frequently derided for
their choices in the grey areas. When pressed for justification I
haven't seen the critics present anything concrete.

Is it ok for a developer to say "I know this script destined for the
general web is broken in Internet Explorer 5.5 and Opera 9 but I don't
care?" It seems as though he would be ripped to shreds and accused an
idiot on c.l.js but he would simply respond "Those browsers are not
supported". That doesn't seem sufficient to the critics that don't
have objective support for their own similar decisions.

Peter
Thomas 'PointedEars' Lahn
2008-03-03 00:31:06 UTC
Permalink
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.
But how to choose that limited set? I have never read anyone's
concrete rules for making this choice but I have read criticism of the
mainstream library writers for their choices.
I think that if you support the W3C DOM, the MSHTML DOM, the Opera DOM,
Apple WebCore, the KHTML DOM, and the NS4 DOM, you can be pretty sure that
your application does not break on the mobile device. The device's UA will
have to support at least one of those in order to compete. For example,
Pocket PCs would support the MSHTML DOM natively through built-in Windows
CE, and there is Opera Mobile. I do not consider myself to be an expert
about UAs on mobile devices, though.

As for the language features, that is much more difficult a question to answer.
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
If it still happens that the code breaks in a user agent and that becomes
known to the developer, then one should maybe add a branch for that user
agent. That decision depends of course mostly on the bug in the user agent
that caused it, if it could be worked around at all. If not, the UA is
broken and should not be supported.
"maybe"? "mostly"?
Yes, the world is not black and white. If production quality on a certain
device was required, that would require thorough tests of the application on
exactly that device. Otherwise, you can only hope for the best and expect
the worst.
Post by Peter Michaux
I agree this is all grey area but people are frequently derided for
their choices in the grey areas. When pressed for justification I
haven't seen the critics present anything concrete.
Is it ok for a developer to say "I know this script destined for the
general web is broken in Internet Explorer 5.5 and Opera 9 but I don't
care?"
Definitely not.
Post by Peter Michaux
It seems as though he would be ripped to shreds and accused an
idiot on c.l.js but he would simply respond "Those browsers are not
supported".
He might receive that treatment if he said it as-is ;-)
Post by Peter Michaux
That doesn't seem sufficient to the critics that don't
have objective support for their own similar decisions.
It should not be. Design decisions should be justifiable.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
Thomas 'PointedEars' Lahn
2008-03-03 00:33:51 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.
But how to choose that limited set? I have never read anyone's
concrete rules for making this choice but I have read criticism of the
mainstream library writers for their choices.
I think that if you support the W3C DOM, the MSHTML DOM, the Opera DOM,
Apple WebCore, the KHTML DOM, and the NS4 DOM, you can be pretty sure that
your application does not break on the mobile device. [...]
^^^^^^^^^^^^^^
That should have been "that you application works". Graceful degradation
and feature tests should prevent the application from breaking even if
exposed to an unknown DOM.


PointedEars
Matt Kruse
2008-03-03 03:11:43 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
I think that if you support the W3C DOM, the MSHTML DOM, the Opera DOM,
Apple WebCore, the KHTML DOM, and the NS4 DOM, you can be pretty sure that
your application does not break on the mobile device.
This may be true, but that assumes that you care that your web app
does not break on any mobile device. Is that a reasonable conclusion?
Under what situations would this be a good guideline, and when is it
not necessary to worry about it?
Post by Thomas 'PointedEars' Lahn
The device's UA will
have to support at least one of those in order to compete.
Are only UA's that are trying to "compete" worthy of consideration?
This may be a reasonable criteria, but a crtieria nontheless. Do you
think everyone should follow this reasoning in all contexts?
Post by Thomas 'PointedEars' Lahn
As for the language features, that is much more difficult a question to answer.
For someone who is building a web app and trying to code their js in
the best possible way, it might be a very important question to
answer. How will they go about learning what should be guarded against
and what is not worth their time?

What rules do you follow to determine which language features you will
test and possibly correct, and which you will require to work
correctly?
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Is it ok for a developer to say "I know this script destined for the
general web is broken in Internet Explorer 5.5 and Opera 9 but I don't
care?"
Definitely not.
Why not? Just saying "definitely not" without any justification or
reasoning will not be convincing to any reader.
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
That doesn't seem sufficient to the critics that don't
have objective support for their own similar decisions.
It should not be. Design decisions should be justifiable.
How would you justify your decision above?

Matt Kruse
Peter Michaux
2008-03-07 03:57:51 UTC
Permalink
Post by Matt Kruse
Post by Thomas 'PointedEars' Lahn
I think that if you support the W3C DOM, the MSHTML DOM, the Opera DOM,
Apple WebCore, the KHTML DOM, and the NS4 DOM, you can be pretty sure that
your application does not break on the mobile device.
This may be true, but that assumes that you care that your web app
does not break on any mobile device. Is that a reasonable conclusion?
Under what situations would this be a good guideline, and when is it
not necessary to worry about it?
Post by Thomas 'PointedEars' Lahn
The device's UA will
have to support at least one of those in order to compete.
Are only UA's that are trying to "compete" worthy of consideration?
This may be a reasonable criteria, but a crtieria nontheless. Do you
think everyone should follow this reasoning in all contexts?
Post by Thomas 'PointedEars' Lahn
As for the language features, that is much more difficult a question to answer.
For someone who is building a web app and trying to code their js in
the best possible way, it might be a very important question to
answer. How will they go about learning what should be guarded against
and what is not worth their time?
What rules do you follow to determine which language features you will
test and possibly correct, and which you will require to work
correctly?
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Is it ok for a developer to say "I know this script destined for the
general web is broken in Internet Explorer 5.5 and Opera 9 but I don't
care?"
Definitely not.
Why not? Just saying "definitely not" without any justification or
reasoning will not be convincing to any reader.
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
That doesn't seem sufficient to the critics that don't
have objective support for their own similar decisions.
It should not be. Design decisions should be justifiable.
How would you justify your decision above?
A pattern is emerging that Thomas is not able to give a consistent
justification for his stance on issues about cross-browser scripting
and which browsers to support or not. He simply stops participating in
the thread when the details go into an area where he wants to appear
to have all the answers but he does not.

Personally I think the c.l.js regulars who are vocally anti-library
draw their line for browser support at roughly the right vintage:
somewhere around IE4, IE5.0, NN6. The line is far enough back that a
large percentage of browsers in use will be supported. But this means
I believe something about browser statistics which is a really tricky
area. I do think the mainstream libraries support too few browsers and
leave many browsers with broken pages then they think they do. Also
due to their coding practices these authors make maintaining the
libraries more difficult. Hopefully that will start to change. In
fact, if the library authors started using feature detection in
earnest then the decision about where to draw the support line would
not be so critical because the unsupported browsers would still see
working page just the non-enhanced version.

Peter
Matt Kruse
2008-03-07 14:17:32 UTC
Permalink
Post by Peter Michaux
A pattern is emerging that Thomas is not able to give a consistent
justification for his stance on issues about cross-browser scripting
and which browsers to support or not. He simply stops participating in
the thread when the details go into an area where he wants to appear
to have all the answers but he does not.
Very true, and this can also be said for some others here as well.

It annoys me when people repeat their mantras about how things should
be done and what the ideal solutions are to everything, but when you
really dig deeper they don't want to answer the tough questions or
come up with real answers to problems that don't fit their model
exactly. This is why, in my opinion, although many here are
technically brilliant and are great to learn from, their advice and
opinions are sometimes not practical for many real people doing real
development work.
Post by Peter Michaux
Personally I think the c.l.js regulars who are vocally anti-library
somewhere around IE4, IE5.0, NN6. The line is far enough back that a
large percentage of browsers in use will be supported.
IE4 and 5? I personally don't know of anyone using either. Or NN6. I'm
sure there are people who do, but they must be so far in the minority
and so used to seeing problems on web sites that their "user
experience" on anything I build is irrelevant to me. I simply don't
care. To some extent, backwards-compatibility throttles innovation,
and I think it's reasonable to keep a little more current than IE4/5
in order to have a pleasant web experience.

But again, this is a personal preference. A typical response is "well,
you can't afford to leave out 1 customer!" but that's such a naive
argument that I wonder if the people saying it have ever had to make
business decisions. Of course you can leave out customers and be just
fine.

If it's super easy to support IE4/5 and NN6, then sure, go ahead. For
most developers, it's not that easy because they don't know what is
broken in browsers that old and it becomes quite difficult to test in
all those environments. Drawing the line of support a little closer to
the modern browsers often makes sense from a business and development
perspective. Anyone dismissing those arguments outright is not
interested in truly understanding and solving problems, IMO. They may
not AGREE, but certainly a person should be able to see different
sides to the argument.
Post by Peter Michaux
I do think the mainstream libraries support too few browsers and
leave many browsers with broken pages then they think they do.
That's easy to say, but have you ever used a big library and gotten
complaints? With the number of major sites out there using the big
libs these days, you would think that they would be flooded with
complaints from Opera5 and IE5 users by the way some people talk about
it. I've never had a user complaint about browser support in sites
I've built using major libraries.

The common response then is "well that's because users with older
browsers won't even take the time to visit your site or log a
complaint." While this may be true, I think the more reasonable
conclusion is that there just aren't that many people having problems.
Or the problems are minor enough that they don't care. If so many
sites/businesses can make the decision to use libraries and ignore
ancient browsers, and their business model doesn't suffer from it,
then that makes it a much harder to argue against using libraries and
ignoring ancient browsers. IMO.
Post by Peter Michaux
Also
due to their coding practices these authors make maintaining the
libraries more difficult. Hopefully that will start to change.
This I absolutely do agree with. I hope the libraries improve. Even if
they "work" in the most important browsers, they can be coded better
so as to work in other browsers that may not be explicitly supported
but _could_ be supported. And to be more future-proof.
Post by Peter Michaux
if the library authors started using feature detection in
earnest then the decision about where to draw the support line would
not be so critical because the unsupported browsers would still see
working page just the non-enhanced version.
This approach, and the one you take in your widget article, doesn't
really have much to do with the libraries, I don't think. It's an
approach to designing the page with an eye towards graceful
degradation. A library is just a tool to help you do that. In fact, in
your article you have a "library" of reusable functions that you use
to accomplish the task. It would be great if the major libraries would
do things more correctly internally, and also offer the tools and
shortcuts needed to make this kind of development approach easier and
more natural.

But using a major library and providing graceful degradation are not
mutually exclusive, IMO.

Matt Kruse
Peter Michaux
2008-03-07 15:29:16 UTC
Permalink
Post by Matt Kruse
Post by Peter Michaux
A pattern is emerging that Thomas is not able to give a consistent
justification for his stance on issues about cross-browser scripting
and which browsers to support or not. He simply stops participating in
the thread when the details go into an area where he wants to appear
to have all the answers but he does not.
Very true, and this can also be said for some others here as well.
It annoys me when people repeat their mantras about how things should
be done and what the ideal solutions are to everything, but when you
really dig deeper they don't want to answer the tough questions or
come up with real answers to problems that don't fit their model
exactly. This is why, in my opinion, although many here are
technically brilliant and are great to learn from, their advice and
opinions are sometimes not practical for many real people doing real
development work.
I don't like to discard advice or opinions from knowledgeable people.
I have always had a strong belief in academic research and think that
the purest opinions are valuable to explore to their limits to see
what becomes of them. They may not bear usable fruit for "people doing
real development work" right away only because it takes time to make
the ideas accessible to the masses.
Post by Matt Kruse
Post by Peter Michaux
Personally I think the c.l.js regulars who are vocally anti-library
somewhere around IE4, IE5.0, NN6. The line is far enough back that a
large percentage of browsers in use will be supported.
IE4 and 5?
I didn't say which side of those browsers to draw the line. I just
think somewhere around that vintage is the right place. I don't think
that only the newest versions of four browsers is even remotely close
to a good place to draw the line.
Post by Matt Kruse
I personally don't know of anyone using either.
I saw someone using Mac IE5 a year ago. Yes it is just one person but
given my small sample size of watching people browse the web that is
actually a reasonably high percentage of my observations.
Post by Matt Kruse
Or NN6. I'm
sure there are people who do, but they must be so far in the minority
and so used to seeing problems on web sites that their "user
experience" on anything I build is irrelevant to me. I simply don't
care. To some extent, backwards-compatibility throttles innovation,
To me, supporting an old browser does not necessarily mean the
JavaScript works in an old browser. It means it works or it gracefully
degrades.
Post by Matt Kruse
and I think it's reasonable to keep a little more current than IE4/5
in order to have a pleasant web experience.
But again, this is a personal preference. A typical response is "well,
you can't afford to leave out 1 customer!" but that's such a naive
argument that I wonder if the people saying it have ever had to make
business decisions. Of course you can leave out customers and be just
fine.
Yes you can leave out customers if the overall profitability is higher
by doing so. I think developers are too eager to employee this
argument. In many cases there is no need for an online store to be
only accessible by those with the most modern browsers. With a little
more thought, knowledge and care, the pages can be made to degrade
gracefully.
Post by Matt Kruse
If it's super easy to support IE4/5 and NN6, then sure, go ahead. For
most developers, it's not that easy because they don't know what is
broken in browsers that old and it becomes quite difficult to test in
all those environments. Drawing the line of support a little closer to
the modern browsers often makes sense from a business and development
perspective.
Yes it does but the newest versions of four browsers seems more
extreme.
Post by Matt Kruse
Anyone dismissing those arguments outright is not
interested in truly understanding and solving problems, IMO. They may
not AGREE, but certainly a person should be able to see different
sides to the argument.
Post by Peter Michaux
I do think the mainstream libraries support too few browsers and
leave many browsers with broken pages then they think they do.
That's easy to say, but have you ever used a big library and gotten
complaints?
I haven't used a mainstream library in production on the general web.
Post by Matt Kruse
With the number of major sites out there using the big
libs these days, you would think that they would be flooded with
complaints from Opera5 and IE5 users by the way some people talk about
it. I've never had a user complaint about browser support in sites
I've built using major libraries.
The common response then is "well that's because users with older
browsers won't even take the time to visit your site or log a
complaint." While this may be true, I think the more reasonable
conclusion is that there just aren't that many people having problems.
Or the problems are minor enough that they don't care. If so many
sites/businesses can make the decision to use libraries and ignore
ancient browsers, and their business model doesn't suffer from it,
then that makes it a much harder to argue against using libraries and
ignoring ancient browsers. IMO.
Post by Peter Michaux
Also
due to their coding practices these authors make maintaining the
libraries more difficult. Hopefully that will start to change.
This I absolutely do agree with. I hope the libraries improve. Even if
they "work" in the most important browsers, they can be coded better
so as to work in other browsers that may not be explicitly supported
but _could_ be supported. And to be more future-proof.
Post by Peter Michaux
if the library authors started using feature detection in
earnest then the decision about where to draw the support line would
not be so critical because the unsupported browsers would still see
working page just the non-enhanced version.
This approach, and the one you take in your widget article, doesn't
really have much to do with the libraries, I don't think.
I think the complete opposite is true. If looking backwards in the
browser timeline is not inspirational then we can look forward. We are
entering a new period of browser evolution and in about one or two
years graceful degradation will be very important again as we
transition out of the IE7/FF2/O9/S3 era. The only way to build a page
that degrades gracefully is to build a library that allows the app
developer to do so. For example, if the library defines functions when
they won't work then how will the app developer know when it will work
or not? If this happens in the library even just once then the ability
to build a gracefully degrading page is lost.
Post by Matt Kruse
It's an
approach to designing the page with an eye towards graceful
degradation. A library is just a tool to help you do that. In fact, in
your article you have a "library" of reusable functions that you use
to accomplish the task. It would be great if the major libraries would
do things more correctly internally, and also offer the tools and
shortcuts needed to make this kind of development approach easier and
more natural.
But using a major library and providing graceful degradation are not
mutually exclusive, IMO.
No but using the *current* major libraries and providing graceful
degradation are mutually exclusive because those libraries don't help
the developer in that regard.

All the techniques that the library authors need to build a state of
the art library that helps developers build gracefully degrading sites
are in the public domain. It should not be very difficult for library
authors to take a library like jQuery and just go line-by-line and
figure out what needs to be feature tested. Note I'm not saying it is
easy for app developers but it should be not too difficult for library
authors. I think a library author has implicitly signed up for that
task. What I don't understand is why they don't do it. I don't buy
"it's not practical" because these are supposed to be general purpose
libraries and that means all browsers (either with JavaScript
enhancements working or not) and the effort necessary is amortized by
the large number of sites using the library. Feature detection is a
forward-looking technique based on what has worked in the past so to
me writing a library that doesn't help the app developer build
graceful degradation pages amounts to just being lazy and not doing
the job of writing a library the best possible way known.

Peter
Richard Cornford
2008-03-09 16:58:07 UTC
Permalink
<snip>
Post by Peter Michaux
Personally I think the c.l.js regulars who are vocally
anti-library draw their line for browser support at roughly
the right vintage: somewhere around IE4, IE5.0, NN6.
That particular cut-off is till largely a practical consequence of the tasks
to be scripted. If, for example, you are attempting dynamic DOM manipulation
then IE 4 or Netscape 4 can do that, but not an a particularly standard way.
While more recent dynamic browsers will pretty much support a
'one-code-fits-all' approach. So that line is drawn when saying that the
extra effort needed to actively support such ancient browsers is not worth
it. On the other hand we have always had a 'one-code-fits-all' solution for
form validation, and so don't need to draw a line for that at all (beyond
client-side script support).
Post by Peter Michaux
The line is far enough back that a large percentage
of browsers in use will be supported.
It is still a line that should move depending on the task at hand.
Post by Peter Michaux
But this means I believe something about browser statistics
which is a really tricky area.
It is not necessary to believe web statistics in order to appreciate that
there will be a relationship between the passage of time and the use of old
software, even if that is a fairly fuzzy relationship.
Post by Peter Michaux
I do think the mainstream libraries support too few browsers
Or, and as often, too many for Intranet and web application use. The thing
with these libraries is that they support only one set of browsers, do so
regardless of their context of use and do so before the purpose of the
project that will use them has been determined. Thus browser support is not
a consequence of determining what is to be achieved, but instead is a
condition pre-imposed on what will be achieved.
Post by Peter Michaux
and leave many browsers with broken pages then they
think they do.
Only in the sense that the library authors doe not believe that people (or
rather people that they care about) ever use anything but 3 or 4 common web
browsers in their default configuration. If they were not aware that there
was an issue in this area they would not be pre-armed with a full set of
excuses and reasons for abdicating responsibility.
Post by Peter Michaux
Also due to their coding practices these authors make
maintaining the libraries more difficult. Hopefully that
will start to change. In fact, if the library authors
started using feature detection in earnest then the
decision about where to draw the support line would
not be so critical because the unsupported browsers
would still see working page just the non-enhanced version.
To some extent that could be the case. For example, in dojo there is an
IFRAME inserting function that has at least three sets of if-else branches
based upon UA string sniffing. The first thinks is it acting for IE and
'elses' every others browser, the second is for Firefox/Gecko and 'elses'
all the others, while the last is for Safari and 'elses' the others. It is
pretty obvious that such a logic structure is not going to do anything
useful when presented with any unknown (in terms of UA string) browsers.

On the other hand, making a greater use of feature detection will not solve
some of the fundamental design flaws in the libraries, because resolving
those issues will significantly impact on the existing library's APIs and
coding approaches and so not be back-compatible with the code that employs
them. John Resig's book has quite a lot of content geared towards emulating
"method overloading" in javascript. That is, functions/methods that are to
be used with many types/patters of arguments and then behave differently
depending on the type or pattern of those arguments. And when you look at
JQuery you see this employed extensively. Experience in javascript authoring
leads to the very obvious truth that just because you can do something that
doesn't necessarily mean that you do, and in specific relation to "method
overloading", that practical considerations suggest that this approach
should be infrequently employed and then only in a limited way. But to get
the unadvised overuse of 'method overloading' out of JQuery means changing
its very nature (and breaks all the code that currently uses it).

Richard.
Richard Cornford
2008-03-02 18:50:49 UTC
Permalink
<snip - irrelevant attributions>
Post by dhtml
Post by Richard Cornford
You question "At what point is a browser considered
worthy of consideration?" implies three things that are
dubious assumptions. First that there exists a
comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone
manufacturers and tell me which web browser ships with
each? I know that Opera, Safari and NetFront will be in
that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at
all (and probably more)).
As strange as it may sound, there actually is a comprehensive
list of all web browsers. It's called WURFL.
<snip>

Bullshit!

(And before you start arguing consider how you are going to prove that any
list of web browsers is a comprehensive list of all web browsers (hint: it
is not comprehensive just because someone says it is)).

Richard.
Peter Michaux
2008-03-03 00:08:45 UTC
Permalink
<snip - irrelevant attributions>>> You question "At what point is a browser considered
Post by dhtml
Post by Richard Cornford
worthy of consideration?" implies three things that are
dubious assumptions. First that there exists a
comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone
manufacturers and tell me which web browser ships with
each? I know that Opera, Safari and NetFront will be in
that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at
all (and probably more)).
As strange as it may sound, there actually is a comprehensive
list of all web browsers. It's called WURFL.
<snip>
Bullshit!
(And before you start arguing consider how you are going to prove that any
list of web browsers is a comprehensive list of all web browsers (hint: it
is not comprehensive just because someone says it is)).
The page itself implies it is not comprehensive

"The WURFL is an XML configuration file which contains information
about capabilities and features of many mobile devices."

It says "many" not "all"

Peter
Richard Cornford
2008-03-09 16:58:14 UTC
Permalink
Post by Peter Michaux
<snip - irrelevant attributions>>
Post by dhtml
Post by Richard Cornford
You question "At what point is a browser considered
worthy of consideration?" implies three things that
are dubious assumptions. First that there exists a
comprehensive list of all web browsers ...
<snip>
Post by Peter Michaux
Post by dhtml
As strange as it may sound, there actually is a
comprehensive list of all web browsers. It's
called WURFL.
<snip>
Bullshit!
<snip>
Post by Peter Michaux
The page itself implies it is not comprehensive
"The WURFL is an XML configuration file which contains
information about capabilities and features of many
mobile devices."
It says "many" not "all"
I noticed. The disclaimer on the page also says that there is no reason to
expect the information to be accurate. It is a non-comprehensive and
non-accurate list of web browsers, so where did that get us?

Richard.
VK
2008-03-02 18:43:07 UTC
Permalink
Post by Richard Cornford
You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions. First
that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? I know that Opera, Safari and
NetFront will be in that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at all (and probably
more)).
Second, that there is a "point" that can be determined in some way. Given
that web statistics are inherently problematic to gather, tend to be
self-biasing and that the statistics gathering techniques that are used are
incapable of discriminating between web browsers (that is, many web browser
that are not IE will end up being listed as IE), can you ever say where any
one browser is at any time in order to decide whether that "point" means it
should be "worthy of consideration".
Third, that the single question should be asked prior to establishing the
context in which "worthy of consideration" should be applied. If, for
example, I am designing a web application for internal use by corporate
users I may well find myself in a position to know a grate deal about the
browsers/OSs in use and so find it very easy to say that every browser that
is not in a very short list is not 'worthy of consideration' (thus avoiding
needed to know the names of the unworthy contenders).
The same boring fallacy you are feeding this NG six years in the row!
Are you not getting tired out of it? Leave you cabinet for once and
get your nose on the fresh air: by statements like above one may
decide that you did not do it since 1998 at least.

If one considers DOM/Javascript programming as a spiritual action,
some kind of "leading Web to its full potential" and other W3C-like
crap than she/he is welcome to spend the entire lifetime for making an
"absolutely robust program working for any known and unknown browser,
without browser sniffing and based on features detecting only". Before
to die she/he is welcome to proudly present this program here to be be
pointed to numerous failure cases of her program for _actual_
_popular_ UAs though it may stay highly robust for all imaginary never
existed situations created in the author's mind.

If it is not "leading Web to its full potential" spiritual crap but a
normal human for-money (for-glory, for-popularity etc.) business then
it is a pure and well calculated math: 2nd Level Web Developer gets
$40/h and it's great if you find a descent one for this money. The US
salary/employer cost ratio is approx 1.8, in EU approx. 2.2
That means that in order to pay $40/h to the developer, his employer
pays ~$72/h, ~$576/day. This way a small development office (1st level
developer and two 2nd level developers) comes to over $1,500/day for
salary only. Now imagine that say in two day you have paid out of your
pocket $3,000 in order to accommodate your script for potential
failures. Now imagine that on the day number three you have discovered
that these suckers spent their time and your money for Netscape 4.x,
IceBrowser x.x or Safari 2.x accommodation. Will you tell "Great job,
guys!" or will you get berserk out of that? If the first then I say
that you got your own money too easy.

Right now it is necessary to ensure that the script is functional for:
Firefox 2.x
IE 7.0
IE 6.0 to the end of this year. After that it will be actual only for
Win 2000 where the support contract with Microsoft is active till
2015. At the same time these Win2000/IE6 users is a very special
contingent mainly represented by different US governmental facilities
and office desktops respectively. Their pleasurable surfing experience
in the Web during the working hours can be safely disregarded by
developers targeted to the common public audience.

Is it possible that the list gets bigger or smaller? Any moment! How
to know that it got bigger? Don't worry, you will know... it will be
in the air. I don't recall any official statements "OK, stop support
Netscape 4.x from now on" or "Attention, from now on check your
solutions with Firefox". Whoever works for profit will always know
these things as soon as the time comes.
Peter Michaux
2008-03-02 23:55:33 UTC
Permalink
[snip]
Post by Richard Cornford
You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions. First
that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? I know that Opera, Safari and
NetFront will be in that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at all (and probably
more)).
I wasn't intending to imply there is a comprehensive list. Simply
knowing there are many browsers out there that are used by small
groups of users and the very likely existence of bugs specific to
these browsers is good enough.

[snip]
Post by Richard Cornford
Second, that there is a "point" that can be determined in some way. Given
that web statistics are inherently problematic to gather, tend to be
self-biasing and that the statistics gathering techniques that are used are
incapable of discriminating between web browsers (that is, many web browser
that are not IE will end up being listed as IE), can you ever say where any
one browser is at any time in order to decide whether that "point" means it
should be "worthy of consideration".
The "point" may be fuzzy to determine but I don't think that makes the
question useless.

[snip]
Post by Richard Cornford
Third, that the single question should be asked prior to establishing the
context in which "worthy of consideration" should be applied. If, for
example, I am designing a web application for internal use by corporate
I'm interested in pages/scripts for the general/public web as it is
the most extreme situation where there is no control over what browser
the user might be using.

[snip]
Post by Richard Cornford
While to total number of web browser can only go up the number of bugs can
go down, as bugs are only important when they are bugs in the browsers that
still may get used and bug fixes do happen.
So when scripting for the general web, when do you decide that a bug
is no longer "important"?

[snip]
Post by Richard Cornford
Post by Peter Michaux
there is a high (1?) probability that there will not be a
feature detection/ testing path or workaround path that makes
its way through all these bugs for a particular feature.
The observation that it may be the case that all of the possibilities may
not be covered by feature detection/testing is only significant if there is
a better alternative. In that case it becomes a very solid justification for
using that alternative. But it is the case that the alternatives available
for handling browser differences are both significantly worse than feature
detection/testing. A potential shortcoming of the best strategy available is
hardly a reason for even considering worse alternatives, so the situation
does not change.
Of course, using the currently best strategy is the best choice to
make. A compelling reason to use feature detection is it is more
future proof than browser sniffing but at the same time it is
important to recognize feature detection is not perfect and may fail
in the future.

[snip]
Post by Richard Cornford
Post by Peter Michaux
If discarding some less popular browsers means that a path
reappears then that would be a practical choice.
But it is a very big 'if'. It would never be possible to say that a browser
that I have never heard of must be 'less popular' than one I have heard off
in a world where the very latest technology is being shipped with
pre-installed/embedded web browsers that are unidentified. I can tell you
that I don't care in the slightest what Netscape 3 (or any other
sufficiently ancient browser)
What is "sufficiently ancient"? Some people think IE 5.5 and FF 1.5
are sufficiently ancient. If you disagree how do you justify your
position? This is a core disagreement of c.l.js regulars and the
mainstream library writers. I think the mainstream libraries are too
cavalier about discarding browsers like IE 5.x and it's
contemporaries. My question "At what point is a browser considered
worthy of consideration?" is one way to start exploring a
justification why IE 5.x should still be considered important, if it
should, and by what measurements of justification.

[snip]

Peter
Richard Cornford
2008-03-09 16:58:21 UTC
Permalink
Post by Peter Michaux
[snip]
Post by Richard Cornford
You question "At what point is a browser considered worthy
of consideration?" implies three things that are dubious
assumptions. First that there exists a comprehensive list
of all web browsers (so pick the top of the range handsets
from each of the big mobile phone manufacturers and tell
me which web browser ships with each? I know that Opera,
Safari and NetFront will be in that list, but I am also
pretty sure that there will be at lest one browser in there
that I never heard off at all (and probably more)).
I wasn't intending to imply there is a comprehensive list.
Probably not, but the question is calling for an answer in the form of a
list of web browsers, and any browser that cannot be named/identified cannot
appear on such a list.
Post by Peter Michaux
Simply knowing there are many browsers out there that are
used by small groups of users and the very likely existence
of bugs specific to these browsers is good enough.
It is good enough to make useful decisions, and statement about what
requirements can be made of those browsers before any specific script will
actively work on them. It is not gong to result in a list of browsers
"worthy of consideration". And either way the question should be preceded by
determining what the requirements of the specific project are, and once that
has been done the set of browsers that are capable of actively supporting
the resulting script has been defined.
Post by Peter Michaux
[snip]
Post by Richard Cornford
Second, that there is a "point" that can be determined
in some way. Given that web statistics are inherently
problematic to gather, tend to be self-biasing and that
the statistics gathering techniques that are used are
incapable of discriminating between web browsers (that
is, many web browser that are not IE will end up being
listed as IE), can you ever say where any one browser
is at any time in order to decide whether that "point"
means it should be "worthy of consideration".
The "point" may be fuzzy to determine but I don't think
that makes the question useless.
The "point" is not at all fuzzy if it is a point in terms of what a web
browser is capable of delivering (that point is implied by the requirements
of the script).
Post by Peter Michaux
[snip]
Post by Richard Cornford
Third, that the single question should be asked prior to
establishing the context in which "worthy of
consideration" should be applied. If, for example, I am
designing a web application for internal use by corporate
I'm interested in pages/scripts for the general/public web
as it is the most extreme situation where there is no control
over what browser the user might be using.
But even then you don't get a single answer. If the required task is to
validate an HTML form prior to its being submitted then there are no
scriptable browsers that could not be accommodated with a
'one-script-fits-all' solution. But if you want dynamic DOM manipulation
then a huge set of browsers are just not capable of delivering on that. Both
possibilities are reasonable candidates to be general/public web scripts,
plus very much else besides.
Post by Peter Michaux
[snip]
Post by Richard Cornford
While to total number of web browser can only go up the
number of bugs can go down, as bugs are only important
when they are bugs in the browsers that still may get
used and bug fixes do happen.
So when scripting for the general web, when do you decide
that a bug is no longer "important"?
At minimum when it is a bug in a browser that can no longer be practically
used.
Post by Peter Michaux
[snip]
Post by Richard Cornford
Post by Peter Michaux
there is a high (1?) probability that there will not be
a feature detection/ testing path or workaround path
that makes its way through all these bugs for a
particular feature.
The observation that it may be the case that all of the
possibilities may not be covered by feature
detection/testing is only significant if there is a better
alternative. In that case it becomes a very solid justification
for using that alternative. But it is the case that the
alternatives available for handling browser differences are
both significantly worse than feature detection/testing.
A potential shortcoming of the best strategy available is
hardly a reason for even considering worse alternatives,
so the situation does not change.
Of course, using the currently best strategy is the best
choice to make.
There are an awful lot of people who think otherwise.
Post by Peter Michaux
A compelling reason to use feature detection is it is
more future proof than browser sniffing
Even object inference, if not handled trivially, is more reliable than UA
string sniffing. UA string sniffing is not only not the best strategy, it is
not even the second best strategy.
Post by Peter Michaux
but at the same time it is important to recognize feature
detection is not perfect and may fail in the future.
True, but feature detection is the only strategy that takes a
reasoned/rational approach to the problem. UA string sniffing starts off
from the basis of having no technical foundation at all, and then being
demonstrably ineffective at discriminating between known (and current) web
browsers. Object inference may start with a baseless assumption (that some
specific set of properties could be identified that would be discriminating
of each and every web browser (A theoretical possibility but not practically
achievable without some sort of browser omniscience)) but at least it would
be difficult to demonstrate some object inferences to be invalid. For
example, use:-

var isWindowsIE5Pluss = (
(typeof clientInformation == 'object')&&
(typeof CollectGarbage == 'function')&&
(typeof ActiveXObject == 'function')&&
(typeof external == 'object')&&
(typeof ScriptEngine == 'function')&&
(typeof showModalDialog == 'object')&&
(
(document.documentElement)&&
(typeof document.documentElement.currentStyle == 'object')&&
(typeof document.documentElement.behaviorUrns == 'object')&&
(typeof document.documentElement.filters == 'object')
)
);

- and it would be pretty hard to demonstrate that the inference that a
browser where the above is true must be Windows IE 5+ was not sound. Which
makes it difficult to see how UA string sniffing gets any credence at all in
comparison to the alternatives.

(Incidentally, there is only one item in that list that I have not observed
in at least one browser that is not Windows IE 5+)
Post by Peter Michaux
[snip]
Post by Richard Cornford
Post by Peter Michaux
If discarding some less popular browsers means that a
path reappears then that would be a practical choice.
But it is a very big 'if'. It would never be possible to
say that a browser that I have never heard of must be 'less
popular' than one I have heard off in a world where the
very latest technology is being shipped with
pre-installed/embedded web browsers that are unidentified.
I can tell you that I don't care in the slightest what
Netscape 3 (or any other sufficiently ancient browser)
What is "sufficiently ancient"?
There was a time when not supporting Netscape 4 was unthinkable. Then there
was a long period when supporting it was disputed on a regular basis. And
inevitably there comes a time when anyone suggesting making any extra effort
to actively support Netscape 4 will be considered as having a novel thought
process. But even then, for a task such a simple form validation the same
code as should be used on IE 7 will work just fine with Netscape 4 (except
some regular expression constructs which may be seen as expedient for some
tasks).
Post by Peter Michaux
Some people think IE 5.5 and FF 1.5 are sufficiently
ancient.
But the number of possible tasks for which any extra effort would b needed
to accommodate either is quite small. And earlier in the week I observed
someone still using IE 5.0, so it is not practical for me to assert that
nobody still used browsers of that vintage.
Post by Peter Michaux
If you disagree how do you justify your position?
My position remains that the first question to be answered is to identify
the purpose that is to be achieved, and that the browser support questions
will have been pretty much answered once that has been done.
Post by Peter Michaux
This is a core disagreement of c.l.js regulars and the
mainstream library writers. I think the mainstream libraries
are too cavalier about discarding browsers like IE 5.x and
it's contemporaries.
Certainly if their aim is to provide truly general tools for web developers.
The tools used should not constrain the possibilities of what could be
achieved prior to anyone deciding what should be achieved.
Post by Peter Michaux
My question "At what point is a browser considered
worthy of consideration?" is one way to start exploring a
justification why IE 5.x should still be considered
important, if it should, and by what measurements of
justification.
IE 5.x is a (or are) scriptable, dynamic web browser(s) that can deliver on
the vast majority of web site requirements at zero additional authoring
effort (at least for those who know how to write cross browser code) and it
is still in use. There is another set of tasks that it can accommodate in
exchange for some additional effort, and there you have a trade-off and a
judgement call. But there is always the degradation path for such
situations, and no matter how bad IE 5.x may be considered to be it is
certainly no worse at executing scripts than IE 7 with scripting disabled.

Richard.
VK
2008-03-09 19:03:00 UTC
Permalink
<the poetry reading before and after snippet>
Post by Richard Cornford
feature detection is the only strategy that takes a
reasoned/rational approach to the problem.
That is a false statement right here. The feature detection _was_ a
promising reliable strategy several years ago, more exactly during the
stagnation period of 2000-2004, and even then its reliability was
mainly based on the fact that nothing was changing from one year to
another so all key players, their features, bugs and defaults remained
the same. So even at that time the "personal trust" of a developer to
his feature detection code was a kind of a hidden fallacy: because
that trust was still based on his prior practical experience and his
knowledge of possible platforms the code will be running. "Either the
boll is red, then take this, or the boll is white, then take that. But
we know for sure that the bole will not explode in our hands while
taking it and that there is not a snake in the bag". Pardon me, and
from one could possibly know that? Only by prior searching the whole
bag or by looking others doing that.
The end of feature detection came when the feature spoofing became a
casual technique of wannabe UA producers. Alas Opera, the oldest
wannabe on the market, became and remains the leader of this process,
but others did not fall too far behind. This way as of now a pure
abstract feature detection is a dead idea. It is as dead as say sites
serving pages as application/xhtml+xml and nothing else. One may post
such pure abstract feature detection based solution here for
"educational purposes" - with the expected criticism of readers of
course. At the same time for any real life commercial solution this
approach is long time abandoned: and - once again - not out of some
native evilness or stubborness of end developers.

P.S. As both the Mr.Cornford post and my reply containing too much of
philosophy, I want to add a small actual sample, the first that came
to my mind copyright free. In my AL (Application Launcher) script
http://www.geocities.com/schools_ring/al.zip
in order to launch local programs from a link on the page (in a
relaxed security environment of course) I am using ActiveXObject for
IE and XPCOM for Gecko. For that I need to know that the current UA
has netscape.security.PrivilegeManager object with necessary methods
in order to enablePrivilege I need. The relevant Gecko code is:

, 'Gecko' : ( (typeof window != 'undefined')
&& (typeof window.netscape != 'undefined')
&& (typeof window.netscape.security != 'undefined')
&& (typeof window.opera != 'object'))

What a hey window.opera does here?! Well, at that time I still cared
for Opera - more out of nostalgic feelings rather than out of any
practical necessity. So guess what: Opera had netscape object, it had
netscape.security and enablePrivilege in it: but all this was nothing
but spoofing bogus with enablePrivilege leading to runtime error on
use. How did I know that? By checking and adjusting my script for all
browsers I cared about. How would I know that by thinking
theoretically? Never in my life. How would a pure feature detection
prevent this runtime error? That would just failed miserably. I have
N^n of such practical samples but sapienti sat... hopefully...
Richard Cornford
2008-03-10 01:03:56 UTC
Permalink
Post by VK
<the poetry reading before and after snippet>
Post by Richard Cornford
feature detection is the only strategy that takes a
reasoned/rational approach to the problem.
That is a false statement right here.
Judgements of what is or is not reasoned/ration are not significant
when they originate with someone who cannot even do joined up logic.
Post by VK
The feature detection _was_ a promising reliable strategy
several years ago, more exactly during the stagnation
period of 2000-2004,
As you do not (and never have) understood what feature detection is it
would be better for you not to be pontificating on the subject.
Post by VK
and even then its reliability was mainly based on the
fact that nothing was changing from one year to
another ...
<snip>

Nonsense, Feature detection is the best strategy available precisely
because it can anticipate/accommodate changes in browser environments
over time. While UA string sniffing and object inference can never
anticipate changes.


<snip>
Post by VK
P.S. As both the Mr.Cornford post and my reply containing
too much of philosophy, I want to add a small actual sample,
A sample of what you think is feature detection? Good, because that
will illustrate the extent to which you do not understand what feature
detection is.

<snip>
Post by VK
I am using ActiveXObject for IE and XPCOM for Gecko.
Or at least that is what you think you are doing.
Post by VK
For that I need to know that the current UA
has netscape.security.PrivilegeManager object with
necessary methods
If you are going to use it then that is something you would be well
advised to determine. however, at no point in your script do you
directly test for the existence of a - PrivilegeManager -, nor that
any - PrivilegeManager - that does exist has the method you employ on
it.
Post by VK
in order to enablePrivilege I need. The relevant Gecko
, 'Gecko' : ( (typeof window != 'undefined')
&& (typeof window.netscape != 'undefined')
&& (typeof window.netscape.security != 'undefined')
&& (typeof window.opera != 'object'))
That is an object inference test, not a feature detection test. And as
an object inference test it is not even a particularly good one, as
Netscape 4 will pass that test but will not facilitate the script that
will be executed as a result of that test being passed.
Post by VK
What a hey
What?
Post by VK
window.opera does here?! Well, at that time I still cared
for Opera - more out of nostalgic feelings rather than out
of any practical necessity. So guess what: Opera had
netscape object, it had netscape.security and enablePrivilege
in it: but all this was nothing but spoofing bogus with
enablePrivilege leading to runtime error on use.
How did I know that? By checking and adjusting my script
for all browsers I cared about.
Presumably what the script did in the event of its encountering
Netscape 4 (error-out in this case) did not matter as you did not care
about that browser.
Post by VK
How would I know that by thinking theoretically?
You would not encounter that problem if you had been applying feature
detection theory as you would have tested for the existence of the
global - Components - object you intended to use, not found it, and so
never attempted to execute that branch of the script on such a
browser. Your not understanding a theory is (and never will be) an
indicator that the theory does not work.
Post by VK
Never in my life.
In your case, apparently.
Post by VK
How would a pure feature detection
prevent this runtime error?
Exactly as I have just described.
Post by VK
That would just failed miserably.
On the contrary. A even a somewhat ham fisted application of a feature
detection test would avoid the execution of that branch of the code on
a browser that did not support it (and that is without needing to know
anything else about that browser). But the test you did use is not
capable of discriminating Netscape 4 from Mozilla/Gecko and so
certainly will error-out on some browsers. Your only justification for
that flaw will be to assert that you don't care, while a feature
detection test would have worked without anyone needing to know or
care what any individual browser may or may not support.
Post by VK
I have N^n of such practical samples but sapienti
sat... hopefully...
Any number of examples of your not understanding what you are doing
will make no difference to anything.

If you had (or could have) applied feature detection to this problem
you would not have encountered any issues with opera, and in the event
that opera (or any other browser) ever did implement the features used
by that branch of the script then you would gain increased browser
support for zero extra effort.

Your script makes direct use of:-

netscape.security.PrivilegeManager.enablePrivilege
Components.classes['@mozilla.org/file/local;1'].createInstance
Components.interfaces.nsILocalFile
Components.interfaces.nsIProcess

- plus some more methods of the object involved. If you had tested for
them there would be no question of your script being executed on
browsers that did not provide them, such as Opera.

A primary principle of feature detection is that you devise the tests
used so that they have as near a one-to-one relationship with what you
need to know as possible. The existence of the objects and methods you
use has a considerably closer relationship with you ability to
successfully use them than the existence of some arbitrary set of
unrelated objects.

Richard.
VK
2008-03-10 15:46:26 UTC
Permalink
Post by Richard Cornford
Post by VK
<the poetry reading before and after snippet>
Post by Richard Cornford
feature detection is the only strategy that takes a
reasoned/rational approach to the problem.
That is a false statement right here.
Judgements of what is or is not reasoned/ration are not significant
when they originate with someone who cannot even do joined up logic.
The judgments should normally follow the analysis but do not precede
it. Yet knowing your regular posting style in answering to me it does
not surprise me - though it may surprise outside readers.
Post by Richard Cornford
Post by VK
The feature detection _was_ a promising reliable strategy
several years ago, more exactly during the stagnation
period of 2000-2004,
As you do not (and never have) understood
what feature detection is it
would be better for you not to be pontificating
on the subject.
A hilarious statement taking into account that I got my first project
money for NN2 fallback / NN3 + IE3 solution and never really stopped
since then. Mr.Cornford, I do have full respect to your undoubtedly
profound theoretical knowledge. They still could be much more useful
for everyone - including to yourself - if you would stop pretending to
be the only person in the entire world who really knows how to program
properly and what does any customer really need. With all my respect -
your are not The One, just "one of ones" ;-)
Post by Richard Cornford
Feature detection is the best strategy available precisely
because it can anticipate/accommodate changes in browser
environments over time.
While UA string sniffing and object inference can never
anticipate changes.
Another regular discussion trick in this NG remains the "entity
fading". As soon as things gets too hot, one needs to say that the
opponent doesn't understand or misinterprets the entity (term,
definition) so whatever is he saying is a waste of time: while the
opposite side has the only right - yet undisclosed - understanding of
the entity, and in application to this understanding the argumentation
is just right.

Because starting from this point forward all your further comments do
nothing but exploring this trick, it is wasteful to continue until you
define your exact definition of the "feature detection". Socrates,
this master of dialog, implied that any discussion is only leading to
the truth if all involved terms and definitions are commonly agreed
between the participants. So what is exactly "the feature detection"
by Mr.Cornford? Please, it must be a definition and not a philosophic
tract thus within a paragraph / many two paragraphs.

For my humble mind "the feature detection" is
the process of determining if the current environment supports the
entity X so the task Y can be accomplished: where the theoretical
possibility of the presence of entity X is known in advance at the
moment of the development.

This way say the existence of window.netscape and
window.netscape.security and
windows.netscape.security.privilegeManager is known from XUL
documentation and the task is to find out at the runtime if the
current environment provides such object with enablePrivilege method
so the script could request the needed privilege. At the same time
say checking for window.foo.bar object to use its makeTheWorldBetter
method while looking as a feature detection is really a b.s. because
it doesn't conform with the second part of the definition given above.

I hope I was clear in my definition and I hope you can be the same in
yours: because so far by reading your comments to P.S. section I
didn't get a slightest clue what "the feature detection" is for you.
Richard Cornford
2008-03-10 22:51:59 UTC
Permalink
Post by VK
Post by Richard Cornford
Post by VK
<the poetry reading before and after snippet>
Post by Richard Cornford
feature detection is the only strategy that takes a
reasoned/rational approach to the problem.
That is a false statement right here.
Judgements of what is or is not reasoned/ration are not
significant when they originate with someone who cannot
even do joined up logic.
The judgments should normally follow the analysis but do
not precede it.
We are long past the point of being absolutely certain that you cannot do
reasoning or logic, and your not being rational remains the most credible
explanation for the extent of those deficiencies.
Post by VK
Yet knowing your regular posting style in answering to me
You mean freely stating that you are the fool you demonstrate yourself to
be?
Post by VK
it does not surprise me - though it may surprise
outside readers.
Post by Richard Cornford
Post by VK
The feature detection _was_ a promising reliable strategy
several years ago, more exactly during the stagnation
period of 2000-2004,
As you do not (and never have) understood
what feature detection is it
would be better for you not to be pontificating
on the subject.
A hilarious statement
So even though you posted a series of statement that you asserted related to
feature detection but would have been 100% false if they were applied to
feature detection you are now disputing the conclusion that you have no
understanding even of what feature detection is?
Post by VK
taking into account that I got my first project money for
NN2 fallback / NN3 + IE3 solution and never really stopped
since then.
That is what you say, and keep repeating, but you are forgetting that we
have seen the code you write. We know (and it is a matter of public record)
that you screw up the simplest aspects of programming, and don't even know
you are doing it so you post your garbage here and leave it to others to
point out that they don't work. Remember that rounding function? The one you
were still asserting what superior to the alternative even after it had been
pointed out that it did not even get the number of decimal places in its
output correct. If there really are people out there fool enough to give you
money for what you think of as programming then there really is one born
every minute.
Post by VK
Mr.Cornford, I do have full respect to your undoubtedly
profound theoretical knowledge.
Bullshit.
Post by VK
They still could be much more useful for everyone - including
to yourself - if you would stop pretending to be the only
person in the entire world who really knows how to program
properly and what does any customer really need. With all my
respect - your are not The One, just "one of ones" ;-)
Well I have precisely zero respect for you in any sense at all. I think you
are a monumental fool and staggeringly stupid. With your only saving grace
being the suspicion that the cause is mental illness on your part, and so
more of a symptom than something you have any control over.
Post by VK
Post by Richard Cornford
Feature detection is the best strategy available precisely
because it can anticipate/accommodate changes in browser
environments over time.
While UA string sniffing and object inference can never
anticipate changes.
Another regular discussion trick in this NG remains the
"entity fading". As soon as things gets too hot, one
needs to say that the opponent doesn't understand or
misinterprets the entity
How could you tell when not understanding things is the norm with you?
Post by VK
(term,
No, that is you personally. Whatever you say is a waste of time. Not least
because you have squandered your credibility so completely in the past that
even if you did happen to say something worthwhile (even a stopped clock
tells the corr5ect time at least once a day) nobody who knew you would pay
any attention.
Post by VK
while the opposite side has the only right - yet undisclosed
- understanding of the entity,
Are you suggesting that nobody has ever explained what feature detection is
on this group? Don't be an idiot, we have been discussing that subject since
the end of the last century. This year alone has seen a couple of 200+ post
threads almost entirely dedicated to the details of the subject.
Post by VK
and in application to this understanding the argumentation
is just right.
Certainly when someone demonstrates that they do not understand what
something is anything they then say about it can reasonably be disregarded.
Post by VK
Because starting from this point forward all your further
comments do nothing but exploring this trick,
My comments explain what it was about what you posted that demonstrated that
you did not understand what feature detection was, and so why it was total
nonsense in relation to its subject.
Post by VK
it is wasteful to continue until you define your exact
definition of the "feature detection".
If all of the discussions of the subject, the FAQ article, and all the code
demonstrating its use, over the past half decade have gone striate over your
that it would also be a waste of time to reiterate anything that you have
flailed to comprehend the first time.
Post by VK
Socrates, this master of dialog, implied that any discussion
is only leading to the truth if all involved terms and
definitions are commonly agreed between the participants.
Have you noticed that in this thread there are people talking about feature
detection? Indeed many people, even people with divergent opinions and
positions on the subject. We have been having a (reasonably) reasoned
discussion about feature detection because we do know what feature detection
is.

Now if you are just saying that you don't understand what is being discussed
here then yes, that is what you are. But you have nothing to contribute to
the discussion so the fact that you want to make some noise about a subject
that you do not understand (and apparently given years you have had to learn
to understand it, will probably never understand) is of no interest to me.
Post by VK
So what is exactly "the feature detection"
by Mr.Cornford? Please, it must be a definition and not
a philosophic tract thus within a paragraph / many two
paragraphs.
If you haven't recognised it when you have seen it in the past, and cannot
research the subject on your own, then it would be a waste of effort to
reiterate it here.
Post by VK
For my humble mind "the feature detection" is the process of
determining if the current environment supports the entity
X so the task Y can be accomplished: where the theoretical
possibility of the presence of entity X is known in advance
at the moment of the development.
That was a waste of everyone's time.
Post by VK
This way say the existence of window.netscape and
window.netscape.security and
windows.netscape.security.privilegeManager is known from
XUL documentation and the task is to find out at the
runtime if the current environment provides such object
with enablePrivilege method so the script could request
the needed privilege.
Don't be silly, enabling a privilege is never an end in itself. A privilege
is useless unless there is something that you want to do with that privilege
once you have it.
Post by VK
At the same time say checking for window.foo.bar object to
use its makeTheWorldBetter method while looking as a feature
detection is really a b.s. because it doesn't conform with
the second part of the definition given above.
You have descended into incoherent babble again.
Post by VK
I hope I was clear in my definition
Your 'definition' was clearly useless, but after that you started gibbering
incoherently again.
Post by VK
and I hope you can be the same in yours: because so far
by reading your comments to P.S. section I didn't get
a slightest clue what "the feature detection" is for you.
And apparently it also went straight over your head in the preceding 10,000
odd posts on the subject this century.

(Just in case you are wondering; I have asked you laterally hundreds of
questions over the past few years and you almost never answer any of them.
If you feel entitle to demand answers from me to questions you ask you
should try first answering the questions I ask you (hint: they are the
sentences that end in question marks).)

Richard.
VK
2008-03-12 20:06:56 UTC
Permalink
Post by Richard Cornford
Post by VK
They still could be much more useful for everyone - including
to yourself - if you would stop pretending to be the only
person in the entire world who really knows how to program
properly and what does any customer really need. With all my
respect - your are not The One, just "one of ones" ;-)
Well I have precisely zero respect for you in any sense at all.
Well, that it is rather too global as a public statement. Do you know
me stealing money, cheating on people or something? You cannot be sure
I don't do it, of course, but you cannot assert it neither. Same way
your good knowledge of Javascript doesn't exclude the possibility of
you being a serial killer or a children molester ;-)
This way let's us narrow the respect/disrespect field by the Web
development alone. Thusly you have zero respect to my demonstrated,
claimed or presumed programming skills. That is fine as it goes, I
feel that I will survive over it. Irrelevant to the topic though.

<quote>
For my humble mind "the feature detection" is
the process of determining if the current environment supports the
entity X so the task Y can be accomplished: where the theoretical
possibility of the presence of entity X is known in advance at the
moment of the development.
</quote>
Post by Richard Cornford
Post by VK
So what is exactly "the feature detection"
by Mr.Cornford? Please, it must be a definition and not
a philosophic tract thus within a paragraph / many two
paragraphs.
<snip>

You have mastered to waste so much space without giving a single
logical statement for the question above. If you cannot define for
yourself what "feature detection" is (except abstract references to
"previous discussions", "Internet search" etc.) - if that, then why
are you trying to discuss a matter you are even not able to define?
And if you are able to do it then do it: enough of a-la "let's make
the world a better place" blah-blah.
Richard Cornford
2008-03-12 23:11:33 UTC
Permalink
<snip>
Post by VK
Post by Richard Cornford
Well I have precisely zero respect for you in any sense
at all.
Well, that it is rather too global as a public statement.
That is not a global statement. You personally are the subject of that
statement and the amount of respect I have for you is zero.
Post by VK
Do you know me stealing money, cheating on people or
something?
Yes (or at least you have claimed as much on this group), you even seem
proud of taking money off people for what you regard as 'programming'.
Post by VK
You cannot be sure I don't do it, of course, but you
cannot assert it neither.
I don't need to when you assert as much yourself so frequently.
Post by VK
Same way your good knowledge of Javascript doesn't exclude
the possibility of you being a serial killer or a
children molester ;-)
This way let's us narrow the respect/disrespect field by
the Web development alone.
So that is still zero then.
Post by VK
Thusly you have zero respect to my demonstrated,
claimed
Precisely because of what you demonstrate here, and so relentlessly.
Post by VK
or presumed programming skills.
We have seen your code, so there is no "presumed" here.
Post by VK
That is fine as it goes, I
feel that I will survive over it.
You certainly will never learn any better.
Post by VK
Irrelevant to the topic though.
<quote>
For my humble mind "the feature detection" is
the process of determining if the current environment
where the theoretical possibility of the presence of
entity X is known in advance at the moment of the
development.
</quote>
That is still a waste of everyone's time. Because you don't do joined-up
logic you won't see how that shares the common characteristic of the code
you post to this group of having such a huge yawning chasm in the middle as
to be utterly useless for anything.
Post by VK
Post by Richard Cornford
Post by VK
So what is exactly "the feature detection"
by Mr.Cornford? Please, it must be a definition and not
a philosophic tract thus within a paragraph / many two
paragraphs.
<snip>
You have mastered to waste so much space without giving a
single logical statement for the question above.
Stating that it was a waste of time was sufficient.
Post by VK
If you cannot define for yourself what "feature detection" is
I can define it. I am not going to waste my time attempting to do so to you.
If you have not understood the concept from all of the previously extensive
discussion of the subject on this group you probably never would understand
it. And although I did not expect that spelling it out in as many words
would be enough for you to get the idea, if you will not answer any of the
questions that I ask you (and you haven't) then you have no right to demand
any answers from me on any subject.
Post by VK
(except abstract references to "previous discussions",
"Internet search" etc.) - if that, then why are you
trying to discuss a matter you are even not able to define?
As I pointed out previously, the discussion of feature detection has been
going on between people who do understand the concept. I don't have to try
to discuss it, I only have to join in. And there is nothing to discuss with
you because you are not someone who lets not understating a subject prevent
them blowing off a lot of hot air on about that subject (or rather whatever
fantasy you hold in place of that subject). You cannot be taken seriously so
it your opinions don't matter at all.
Post by VK
And if you are able to do it then do it: enough of a-la
"let's make the world a better place" blah-blah.
The questions that I asked you were the sentences that ended in question
marks. If you want me to answer your questions try answering some of those
first.

Richard.
VK
2008-03-14 17:30:16 UTC
Permalink
<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.
Peter Michaux
2008-03-14 20:47:12 UTC
Permalink
Post by Richard Cornford
<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.
Did Richard not write the following?

<URL: http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>

That should pretty much explain it for you.

Peter
VK
2008-03-15 07:37:46 UTC
Permalink
Post by Peter Michaux
Post by Richard Cornford
<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.
Did Richard not write the following?
<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
That should pretty much explain it for you.
Peter
Are you being the herald of His Majesty? :-)

I have read the linked resource and in the particular of
"A Strategy That Works: Object/Feature Detecting."
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdFD

I am reminding that this whole branch of conversation, intensively
filled with personal insults - which is a regular brand style of
Mr.Cornford I have used to over last years - all this branch started
from Mr.Cornford's claims that I have no idea what "feature detection"
is and whatever I am doing is not the feature detection. The I gave my
definition of feature detection and I proposed to Mr.Cornford to
provide his own to find where my possible misunderstanding may reside.
My definition - and I remind - was
<quote>
For my humble mind "the feature detection" is
the process of determining if the current environment supports the
entity X so the task Y can be accomplished: where the theoretical
possibility of the presence of entity X is known in advance at the
moment of the development.
</quote>
On the go of the next several posts Mr.Cornford failed to provide any
adequate definition of the topic of question. If he thinks that a
strict definition of a technical term can be anyhow compensated by
personal insults and by demonstration of personal writing skill in
English then it is sorry mistake, I have to say.

Now by looking the jibbering.com resource the closest to what one may
call a definition would be:
<quote>
Feature detecting seeks to match an attempt to execute as script (or a
part of a script) with the execution environment by seeking to test
features of that environment where the results of the test have a
direct one-to-one relationship with the features that need to be
supported in the environment for the code to successfully execute. It
is the direct one-to-one relationship in the implemented tests that
avoids the need to identify the specific browser because whatever
browser it is it either will support all of the required features or
it will not. That would mean testing the feature itself (to ensure
that it exists on the browser) and possibly aspects of the behaviour
of that feature.
</quote>

It is much more clumsy as a definition comparing to mine: yet by
squeezing out all unnecessary wording it is exactly the same of what I
initially said. If anyone thinks that not then please correct me.
NB: "and possibly aspects of the behaviour of that feature" at the end
of the definition is a bogus to skip, of course. It is not nice of
Mr.Cornford to try to protect the definition by making it so
ridiculously ambivalent. Either one does an abstract feature detection
or one tests the feature behavior across certain amount of UAs. Either
we are making a feature detection or we are making browser sniffing.
Either possible, but let's do not define the feature detection as the
browser sniffing, or vice versa, or all together in one pack, OK?

Now back to the sample I have provided:
in order to accomplish a particular task I need
window.netscape.security.privilegeManager object to use its
enablePrivilege method.

Respectively before to accomplish this task I am checking the
existence of "window", "window.netscape", "window.netscape.security"
and "window.netscape.security.privilegeManager". It is possible that
everything is here including "enablePrivilege" method but at the same
time it is all spoofing bogus: such environment is one of versions of
Opera, so I additionally check for (typeof window.opera != 'object').
No feature detection can possibly help in this and in N^n of similar
situations. My script works not out of some theoretical
considerations, however well reasoned they would be. My script works
because it was deployed on all environments I do care about, tested
and adjusted if needed. If it also works for some other untested
(currently non-interesting = non-payable to me) environments then so
the better. If not then screw them for now.
Thomas 'PointedEars' Lahn
2008-03-15 09:30:50 UTC
Permalink
Post by VK
Post by Peter Michaux
Post by Richard Cornford
<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.
Did Richard not write the following?
<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
That should pretty much explain it for you.
[...]
Are you being the herald of His Majesty? :-)
He is just another person who explains to you that you are wrong. How many
people explaining to you will it take for you to see that and why you are wrong?
Post by VK
My definition - and I remind - was
<quote>
For my humble mind "the feature detection" is
the process of determining if the current environment supports the
entity X so the task Y can be accomplished: where the theoretical
possibility of the presence of entity X is known in advance at the
moment of the development.
</quote>
[...]
[Referring to the explanation of feature detection in the FAQ Notes]
It is much more clumsy as a definition comparing to mine: yet by
squeezing out all unnecessary wording it is exactly the same of what I
initially said. If anyone thinks that not then please correct me.
From supports(X) ---> accomplish(Y) does not follow X = Y. But X = Y is a
requirement for feature detection. If you test for a feature and
subsequently make use of another feature, however related they may seem, you
have either failed to do the correct test or to use the correct feature.
Then it is not a reliable test anymore but mere inference which is known to
be error-prone.


HTH

PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
VK
2008-03-15 10:15:05 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
From supports(X) ---> accomplish(Y) does not follow X = Y. But X = Y is a
1) check if window.netscape.security.privilegeManager object exists
2) if TRUE on step (1) then check if enablePrivilege method exists in
the above object.
3) if TRUE on step (2) then use the above method in expectation of
documented results for netscape.security package.

It is my own "feature detection" definition re-phrased in the formal
algorithm form for a particular task. Please compare is any doubts.

Sounds very logical: yet a complete failure approach, not used
anywhere except occasional theoretical passages in c.l.j. The
commercial value of a program written this way is below $0.

More sample of the kind:

1) check if DOM element has .style property
2) if TRUE on step (1) then set style.position to 'absolute';
3) if success on step (2) then assign valid .style.left
and .style.top.values
4) if success on step (3) then stay happy that the element in question
is absolutely located somewhere.

Result: your script is just failed. Opera 8.x does provide style
features for <SVG> elements but it does disregard them. No matter what
values are, the position remains static with the SVG element remaining
in the default document flaw. The required workaround is to use styled
DIV container with SVG element in it. No workaround of this kind
needed for other UAs with SVG support neither for Opera 9.0 or newer.

P.S. The feature detection as it is is a unrealizable bogus idea some
people are baby sitting with for years. The only practically usable
way is to deploy and test your program on all platforms of your
current commercial interest. It means that an updated list of such
platforms has to be always in mind. If someone's mind is clear of such
limits then the practicality of his advises equals to the commercial
value of her/his solutions, -$0.
Thomas 'PointedEars' Lahn
2008-03-15 14:06:58 UTC
Permalink
Post by VK
Post by Thomas 'PointedEars' Lahn
From supports(X) ---> accomplish(Y) does not follow X = Y. But X = Y is a
I would appreciate it if you did not trim parts of the quote if that would
mean destroying its the meaning, especially not in the midst of the
Post by VK
Post by Thomas 'PointedEars' Lahn
requirement for feature detection. If you test for a feature and
subsequently make use of another feature, however related they may seem, you
have either failed to do the correct test or to use the correct feature.
Then it is not a reliable test anymore but mere inference which is known to
be error-prone.
1) check if window.netscape.security.privilegeManager object exists
2) if TRUE on step (1) then check if enablePrivilege method exists
in the above object.
3) if TRUE on step (2) then use the above method in expectation
of documented results for netscape.security package.
If you did that in order to call the enablePrivilege() method there would
have been no problem.
Post by VK
It is my own "feature detection" definition re-phrased in the formal
algorithm form for a particular task.
Unfortunately you appear not to be able to live up to your definitions, as
flawed as they still are.
Post by VK
Please compare is any doubts.
BTDT. You proposed

| , 'Gecko' : ( (typeof window != 'undefined')
| && (typeof window.netscape != 'undefined')
| && (typeof window.netscape.security != 'undefined')
| && (typeof window.opera != 'object'))

instead and argued that it was necessary to add the test for window.opera
because Opera also supported `netscape' (which is a host-defined of the
Global Object not of Window objects, BTW).

Meaning that you were _not_ feature-testing but you were trying to tell user
agents apart for no good reason. Instead, the fact that Opera also supports
the `netscape' property should have indicated to you that the `netscape'
property is not suitable to tell user agents apart.
Post by VK
Sounds very logical: yet a complete failure approach, not used anywhere
except occasional theoretical passages in c.l.j.
Do you really consider a wrong approach to be practical?
Post by VK
The commercial value of a program written this way is below $0.
True if you write it, not living up to your own definitions, as flawed as
they are.
Post by VK
1) check if DOM element has .style property
2) if TRUE on step (1) then set style.position to 'absolute';
The next correct step in *detecting* a feature would have been to determine
whether the `style' property refers to an object that has the `position'
property instead of inferring that from the mere existence of the `style'
property. (That is ignoring that the existence of a property of a host
object cannot fully reliably be tested for, however `typeof' tests have
sufficed to date.)

Detection means that you want to find something, and you are using a
specific device to find exactly that something. If you do not detect it,
then your detection device should be good enough so that you can be pretty
sure that this something is not there. Your definition of (feature)
detection instead corresponds to the man who wants to know where the water
is and goes off with a Y-shaped twig instead of following wild animals to
their watering place or using a hygrometer.
Post by VK
3) if success on step (2) then assign valid .style.left and
.style.top.values
Further error-prone inference. From the existence of a (style.)position
property does not follow the existence and viability of a (style.)left or
(style.)top property.
Post by VK
4) if success on step (3) then stay happy that the element in question is
absolutely located somewhere.
Another fallacy. It is entirely possible that nothing happens here.
Post by VK
Result: your script is just failed.
That is gibberish.
Post by VK
Opera 8.x does provide style features for <SVG> elements but it does
disregard them. No matter what values are, the position remains static
with the SVG element remaining in the default document flaw. The required
workaround is to use styled DIV container with SVG element in it.
I happen to have Opera 8.0.7561 installed, too. It simply does not support
the `style' property for `svg' elements, which is not surprising though.
Post by VK
No workaround of this kind needed for other UAs with SVG support neither for
Opera 9.0 or newer.
So other UAs implement a proprietary feature. That proves nothing but your
inexperience.
Post by VK
P.S. The feature detection as it is is a unrealizable bogus idea some
people are baby sitting with for years. The only practically usable way
is to deploy and test your program on all platforms of your current
commercial interest. It means that an updated list of such platforms has
to be always in mind. If someone's mind is clear of such limits then the
practicality of his advises equals to the commercial value of her/his
solutions, -$0.
That is utter nonsense, as your list updated today could very well be
obsolete tomorrow.

As it has often been said, and what you fail to recognize is, that feature
detection is sometimes not sufficient, especially not to work around UA's
bugs. But it is much better, because much more reliable, to start with
feature detection than with UA or object inference.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
VK
2008-03-15 10:17:09 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
From supports(X) ---> accomplish(Y) does not follow X = Y. But X = Y is a
1) check if window.netscape.security.privilegeManager object exists
2) if TRUE on step (1) then check if enablePrivilege method exists in
the above object.
3) if TRUE on step (2) then use the above method in expectation of
documented results for netscape.security package.

It is my own "feature detection" definition re-phrased in the formal
algorithm form for a particular task. Please compare is any doubts.

Sounds very logical: yet a complete failure approach, not used
anywhere except occasional theoretical passages in c.l.j. The
commercial value of a program written this way is below $0.

More sample of the kind:

1) check if DOM element has .style property
2) if TRUE on step (1) then set style.position to 'absolute';
3) if success on step (2) then assign valid .style.left
and .style.top.values
4) if success on step (3) then stay happy that the element in question
is absolutely located somewhere.

Result: your script is just failed. Opera 8.x does provide style
features for <SVG> elements but it does disregard them. No matter what
values are, the position remains static with the SVG element remaining
in the default document flaw. The required workaround is to use styled
DIV container with SVG element in it. No workaround of this kind
needed for other UAs with SVG support neither for Opera 9.0 or newer.

P.S. The feature detection as it is is a unrealizable bogus idea some
people are baby sitting with for years. The only practically usable
way is to deploy and test your program on all platforms of your
current commercial interest. It means that an updated list of such
platforms has to be always in mind. If someone's mind is clear of such
limits then the practicality of his advises equals to the commercial
value of her/his solutions, -$0.
VK
2008-03-15 11:26:12 UTC
Permalink
On Mar 15, 1:17 pm, VK <***@yahoo.com> wrote:

(sorry for the occasional double post)
Post by VK
1) check if DOM element has .style property
2) if TRUE on step (1) then set style.position to 'absolute';
3) if success on step (2) then assign valid .style.left
and .style.top.values
4) if success on step (3) then stay happy that the element in question
is absolutely located somewhere.
Result: your script is just failed. Opera 8.x does provide style
features for <SVG> elements but it does disregard them. No matter what
values are, the position remains static with the SVG element remaining
in the default document flaw. The required workaround is to use styled
DIV container with SVG element in it. No workaround of this kind
needed for other UAs with SVG support neither for Opera 9.0 or newer.
More sample of the kind:

1) Check for all necessary DOM tree manupulation methods:
document.createElement, elmReference.appendChild etc.
2) Create a element, append necessary sub-elements to it, append
element to canvas.
Be failed miserably it it's a VML shape: on IE sub-elements of a VML
shape (supposed to affect to the shape presentation) are silently
ignored is added over DOM methods. The workaround is to use
insertAdjacentHTML for the IE branch.

By these two samples we are getting closer to the question frequently
posed here by some theoretists and amateurs: why serious commercial
solutions are checking the current UA/OS first and the methods
themselves only after that? If someone needs method A of object B then
check for B and A, why does he care if it's IE, Firefox, Opera,
Windows XP, MacOS etc.? Sounds very logical if the personal practical
experience is narrow. With time one inevitably comes to the
understanding that the real feature detection is a two-dimensional
system, and not a single-dimensional one as one might initially think.
It is not so important if a particular feature is presented or not:
the most crucial to know what platform your script is currently
running. This is the coordinate X. Only then we can check for
coordinate Y: if the required feature is presented. Only with these
two coordinates we can take a reliable decision: i) use the feature as
officially documented, ii) use the feature over a workaround, iii) do
not use it at all, presented or not.
With even more experience in hands one will realize one day that the
coord X above automatically maps the coord Y so the "manual
calculation" of Y is not necessary and only slows down the program.
This way the full path for a program that got some popularity is:
Stage 1) fully conceptual feature detection
Stage 2) forced workarounds for UA X on platform X
Stage 3) forced UA-specific workarounds flooding the code making it
hard to maintain and to expand
Stage 4) Instead of per-method testing inside the program the whole
code is reorganized for several feature testing free branches. Atop of
the program a UA/platform testing block is added to provide the
initial branching.
Stage 5) Depending on the market conditions extra branches are being
added or older branches are being removed: with relevant updates in
the initial branching block.
Of course this path is for someone who is indeed passing all stages
from the initial idealism to the discovery of the rules of the real
life. This way all stages are normally passed only once in the career.
After that one just starts from the Stage 4 right away.
Post by VK
P.S. The feature detection as it is is a unrealizable bogus idea some
people are baby sitting with for years. The only practically usable
way is to deploy and test your program on all platforms of your
current commercial interest. It means that an updated list of such
platforms has to be always in mind. If someone's mind is clear of such
limits then the practicality of his advises equals to the commercial
value of her/his solutions, -$0.
Just to repeat myself.
Richard Cornford
2008-03-16 03:22:45 UTC
Permalink
VK wrote:
<snip>
Post by VK
document.createElement, elmReference.appendChild etc.
2) Create a element, append necessary sub-elements to it, append
element to canvas.
VML has its own namespace, so there is no reason to expect that it could be
created with the createElement method of an HTML document (as that method
will only create elements with the HTML namespace). You should expect to be
using a createElementNS method for such an action, and testing for the
existence of such a method in IE will not reveal one.

There is little point in stating how difficult it may be to determine
whether an action was ineffective (in some sense) without there being some
grounds for expecting it to be effective in the first place.
Post by VK
on IE sub-elements of a VML shape (supposed to affect to
the shape presentation) are silently ignored is added
over DOM methods. The workaround is to use
insertAdjacentHTML for the IE branch.
Is there a non-IE branch in which it is worthwhile attempting to create a
VML element?
Post by VK
By these two samples we are getting closer to the question
Ah, you are going to pontificate again.
Post by VK
why serious commercial solutions are checking the current
UA/OS first and the methods themselves only after that?
They are not. In general browser scripting if you see browser sniffing or
object inference then everything beyond that point is invariably assumed.
Post by VK
If someone needs method A of object B then check for B
and A, why does he care if it's IE, Firefox, Opera,
Windows XP, MacOS etc.? Sounds very logical if the
personal practical experience is narrow.
It sounds very logical regardless of practical experience. It is a strategy
where the tests to be made can be deduced from understanding the code that
is to be guarded by those tests.
Post by VK
With time one inevitably comes to the
understanding that the real feature detection is a
two-dimensional system,
Bullshit (unless you are talking exclusively about yourself and using
"understanding" as a label for your 'unusual' mental processes).
Post by VK
and not a single-dimensional one as one might initially
think. It is not so important if a particular feature is
presented or not: the most crucial to know what platform
your script is currently running.
As there is no reliable method for determining which "platform" a script is
currently running in that would be an unfortunate situation if it were true.
Fortunately it is not. A significant motivation behind the use of feature
detection is to avoid any necessity to know which "platform" a script is
execution in, in order to avoid the consequences of there being no
effective/reliable/rational means of determining that information.
Post by VK
This is the coordinate X. Only then we can check for
coordinate Y: if the required feature is presented.
No, you can test for the existence and behaviour of features without knowing
which environment is executing a script, and when those features are not
found you can be absolutely certain that any attempt to use them will be
between ineffective and error producing.
Post by VK
Only with these two coordinates we can take a reliable
decision: i) use the feature as officially documented,
ii) use the feature over a workaround, iii) do not use
it at all, presented or not.
This is pure fiction on your part. As fictional as your previous declaration
that feature detection as only effective "during the stagnation period of
2000-2004". And this is why you have nothing to contribute to this debate;
you will happily make any nonsense up off the top of your head and as a
result have no credibility at all.
Post by VK
With even more experience in hands one will realize one day
that the coord X above automatically maps the coord Y so the
"manual calculation" of Y is not necessary and only slows
down the program.
Stage 1) fully conceptual feature detection
Stage 2) forced workarounds for UA X on platform X
Stage 3) forced UA-specific workarounds flooding the code making it
hard to maintain and to expand
Stage 4) Instead of per-method testing inside the program the whole
code is reorganized for several feature testing free branches.
Atop of the program a UA/platform testing block is added to
provide the initial branching.
Stage 5) Depending on the market conditions extra branches are being
added or older branches are being removed: with relevant updates in
the initial branching block.
This is precisely the type of thinking that prevent you form being able to
effectively program anything, and then keeps you from being able to see why
the code you do write doesn't work. That combined with your not actually
caring about the outcome.
Post by VK
Of course this path is for someone who is indeed passing all stages
from the initial idealism to the discovery of the rules of the real
life. This way all stages are normally passed only once in the career.
After that one just starts from the Stage 4 right away.
Post by VK
P.S. The feature detection as it is is a unrealizable bogus
idea some people are baby sitting with for years.
So this time it is an "unrealizable bogus idea" while last week it was
"promising reliable strategy several years ago, more exactly during the
stagnation period of 2000-2004, and even then its reliability was mainly
based on the fact that nothing was changing from one year to another".
Presumably you mean this week's absolute statements from you about what
feature detection is to be taken as seriously as last week's?
Post by VK
Post by VK
The only practically usable way is to deploy and test your
program on all platforms of your current commercial interest.
Not all 'commercial interests' lead to an exclusive set of known web
browsers. For some you can only come to that point by saying that you will
ignore (pretend the non-existence of) anything you have not heard of. You,
after all, have said that often enough.
Post by VK
Post by VK
It means that an updated list of such
platforms has to be always in mind.
A list of web browsers?
Post by VK
Post by VK
If someone's mind is clear of
such limits then the practicality of his advises equals
to the commercial value of her/his solutions, -$0.
It has been the case over the years that nobody who has learnt the concepts
of feature detection and the practicalities/limitations of browser sniffing
has been left with the belief that browser sniffing is the only approach
that should be used or the better approach to use.

The ability to determine which web browser, and/or which version of which
web browser, is in use is predicated upon one of two possible strategies.
User Agent string based browser detection or object inference testing.

User Agent string based browser detection is ineffective and irrational
because it has no technical basis (the specification for what a User Agent
header (and so the corresponding string exposed to javascript) says no more
than that it is an arbitrary sequence of zero or more characters that does
not even need to be consistent over time, and then only in "unconditionally
conforming" HTTP 1.1 user agents ("conditionally conforming" user agents are
not even required to send a User Agent header). Thus the specification does
not even imply that the User Agent header could be treated as a source of
information) and web browsers are known to use user Agent headers that are
indistinguishable from the User Agent headers of other browsers (making any
effective discrimination based upon User Agent strings impossible).

Object inference based browser detection has frequently been demonstrated to
be faulty, by thousands of occurrences of things like:-

var isIE = document.all;

- but even when non-trivially approached it suffers from an implied need to
know a great deal about all web browsers in order to find a set of objects
that would be uniquely discriminating of each and every browsers. It would
never be possible to honestly assert that any unknown browser did not posses
precisely the set of object that any given test had used to infer that a
browser was a specific different web browser.

If the approaches uses in identifying web browsers and/or their versions are
technically baseless, ineffective at that task and irrational then any
browser scripting strategy that is based upon them will itself be
technically baseless, ineffective and irrational.

Feature detection entirely avoids any issues following from not being able
to effectively discriminate between web browsers/web browser versions by not
being interested in that question. Feature detection is rational in that the
tests to be used can be deduced from an analysis of the code that is to be
executed. And feature detection has been demonstrated not only to work in
the vast majority of situations but also to be capable of accommodating
changes in web browsers in a way that can avoid much of the ongoing
maintenance inherent in alternative approaches. An example of the latter was
seen when Opera switched from their non-dynamic Opera 6 to the first version
of Opera 7, with its dynamic W3C standard DOM. Feature detection scripts
that had previously observed that Opera 6 did not offer the dynamic DOM
features, and so had not attempted to use them, suddenly found themselves in
Opera 7, having the features they required and being fully functional at
zero additional authoring effort. While similar scripts that used object
inference or UA string sniffing needed active modification before they could
operate in Opera 7. (Given that a very large proportion of software
authoring costs go into ongoing maintenance this fact alone speaks for the
commercial worth of feature detection).

The worst that can be said of feature detection is that there are a few
circumstances where no effective test is available. But as the alternative
are inherently ineffective/irrational that is nowhere near a big enough
issue to dismiss feature detection as a strategy, and not at all a reason
for using the alternatives in its place. And in reality a large proportion
of the situations where people assert feature detection to be inapplicable
the failure is in their analysis of the issue that they are trying to
address. On the rare occasions that these proposed situations are rendered
concrete (with a genuine test case and the precise environments where the
supposed issues are observed) it has been shown that often an appropriate
feature detection test can be devised, or that the issue can be designed out
of the system.

Richard.
VK
2008-03-18 17:33:07 UTC
Permalink
Post by Richard Cornford
Post by VK
document.createElement, elmReference.appendChild etc.
2) Create a element, append necessary sub-elements to it, append
element to canvas.
VML has its own namespace, so there is no reason to expect that it could be
created with the createElement method of an HTML document (as that method
will only create elements with the HTML namespace). You should expect to be
using a createElementNS method for such an action, and testing for the
existence of such a method in IE will not reveal one.
Because you don't need one: document.createElement covers all needs in
IE - but not on rivals.
Post by Richard Cornford
There is little point in stating how difficult it may be to determine
whether an action was ineffective (in some sense) without there being some
grounds for expecting it to be effective in the first place.
Why not? IE approach is completely different from W3C - in IE HTML has
its own namespace and it may have any amount of extra namespaces.
Respectively document.createElement works for everything, one just
need to add the namespace first and then use the right namespace
prefix in document.createElement. By W3C HTML doesn't have namespaces
of any kind at all, only XHTML and XML do: respectively they had to
invent a set of "namespaced" DOM methods.
Post by Richard Cornford
Post by VK
on IE sub-elements of a VML shape (supposed to affect to
the shape presentation) are silently ignored is added
over DOM methods. The workaround is to use
insertAdjacentHTML for the IE branch.
Is there a non-IE branch in which it is worthwhile attempting
to create a VML element?
There are SVG branch and VML branch. I am talking about the last one.
The SVG branch has a bunch of its own OS and UA specific fixes and
workarounds.
Post by Richard Cornford
Post by VK
By these two samples we are getting closer to the question
Ah, you are going to pontificate again.
Post by VK
why serious commercial solutions are checking the current
UA/OS first and the methods themselves only after that?
They are not. In general browser scripting if you see browser sniffing or
object inference then everything beyond that point is invariably assumed.
In an advanced script, right. "Stage 4" right away as I said later.
Post by Richard Cornford
Post by VK
If someone needs method A of object B then check for B
and A, why does he care if it's IE, Firefox, Opera,
Windows XP, MacOS etc.? Sounds very logical if the
personal practical experience is narrow.
It sounds very logical regardless of practical experience. It is a strategy
where the tests to be made can be deduced from understanding the code that
is to be guarded by those tests.
It guards nothing in the majority of cases: it just pollutes the
script.
Post by Richard Cornford
Post by VK
With time one inevitably comes to the
understanding that the real feature detection is a
two-dimensional system,
Bullshit (unless you are talking exclusively about yourself and using
"understanding" as a label for your 'unusual' mental processes).
Post by VK
and not a single-dimensional one as one might initially
think. It is not so important if a particular feature is
presented or not: the most crucial to know what platform
your script is currently running.
As there is no reliable method for determining which "platform" a script is
currently running in that would be an unfortunate situation if it were true.
Fortunately it is not.
In your private academical universe maybe not. I am not currently
describing "Cornford's worlds", I am explaining how are the things
being done on a serious practical level.
Post by Richard Cornford
A significant motivation behind the use of feature
detection is to avoid any necessity to know which "platform" a script is
execution in, in order to avoid the consequences of there being no
effective/reliable/rational means of determining that information.
And again: there is no way to avoid this necessity - at least if
someone wants to have his programs used and paid for.
Post by Richard Cornford
Post by VK
This is the coordinate X. Only then we can check for
coordinate Y: if the required feature is presented.
No, you can test for the existence and behaviour of features without knowing
which environment is executing a script
You cannot do it: so why keep repeating the non-sense over and over
again? Object X has property Y, one can set/read this property, but it
leads to zero effect or unpredictable effect on some - but not all -
particular browsers and/or OS. What browsers/OS - one cannot know
without prior studying. Feature detection itself is out of use here.
Post by Richard Cornford
Post by VK
Only with these two coordinates we can take a reliable
decision: i) use the feature as officially documented,
ii) use the feature over a workaround, iii) do not use
it at all, presented or not.
This is pure fiction on your part.
No, this is how the things are being done: again, outside of your
pocket universe.
Post by Richard Cornford
Post by VK
With even more experience in hands one will realize one day
that the coord X above automatically maps the coord Y so the
"manual calculation" of Y is not necessary and only slows
down the program.
Stage 1) fully conceptual feature detection
Stage 2) forced workarounds for UA X on platform X
Stage 3) forced UA-specific workarounds flooding the code making it
hard to maintain and to expand
Stage 4) Instead of per-method testing inside the program the whole
code is reorganized for several feature testing free branches.
Atop of the program a UA/platform testing block is added to
provide the initial branching.
Stage 5) Depending on the market conditions extra branches are being
added or older branches are being removed: with relevant updates in
the initial branching block.
This is precisely the type of thinking that prevent you form being able to
effectively program anything,
This is exactly the type of thinking that lets me monetarily enjoy the
results of my work year after year. Your type of thinking just leading
so far to unrealizable programming paradigms claimed by you as the
only one being proper. It also lead to the situation when the most
prevailing trends and the most used scripts are always the most
"improper", "wrong", "ugly" etc. by some c.l.j. regulars.
Post by Richard Cornford
Post by VK
Of course this path is for someone who is indeed passing all stages
from the initial idealism to the discovery of the rules of the real
life. This way all stages are normally passed only once in the career.
After that one just starts from the Stage 4 right away.
Post by VK
P.S. The feature detection as it is is a unrealizable bogus
idea some people are baby sitting with for years.
So this time it is an "unrealizable bogus idea" while last week it was
"promising reliable strategy several years ago, more exactly during the
stagnation period of 2000-2004, and even then its reliability was mainly
based on the fact that nothing was changing from one year to another".
Presumably you mean this week's absolute statements from you about what
feature detection is to be taken as seriously as last week's?
No, I just giving up to get out of you any clear definition of the
"feature detection". Do you agree with mine, do you have your own, do
you agree with the quote from your previous writings? During the whole
thread you just like a snake on the grill, really. You don't explain
what "feature detection" is for you, you don't know how to solve the
situations where the "feature detection" is out of help, you don't
have a list of browsers to check against (because the feature
detection in your _proper_ yet undisclosed understanding doesn't need
it), you want to check not only features but their behaviors as
well... Are you not tired yourself of yourself? Just be a man and
finally strictly define the feature detection as you understand it.
Richard Cornford
2008-03-24 17:41:30 UTC
Permalink
Post by VK
Post by Richard Cornford
Post by VK
document.createElement, elmReference.appendChild etc.
2) Create a element, append necessary sub-elements to it, append
element to canvas.
VML has its own namespace, so there is no reason to expect that
it could be created with the createElement method of an HTML
document (as that method will only create elements with the
HTML namespace). You should expect to be using a createElementNS
method for such an action, and testing for the existence of such
a method in IE will not reveal one.
Because you don't need one: document.createElement covers all
needs in IE - but not on rivals.
Isn't the crux of your compliant above that - cerateElement - creates an
Element with the specified name but that element is not a VML element
(in the sense of having any VML related presentation and behaviour)?
That sounds a lot more like IE is creating an HTML-like element with a
non-HTML name (and so no specified presentation/behaviour associated
with it). It certainly is odd to make the complaint about what IE does
and then assert that it "covers all needs in IE".
Post by VK
Post by Richard Cornford
There is little point in stating how difficult it may be to
determine whether an action was ineffective (in some sense)
without there being some grounds for expecting it to be
effective in the first place.
Why not?
Because in most cases when there are no grounds for expecting something
to work it does not work.
Post by VK
IE approach is completely different from W3C - in IE HTML has
its own namespace and it may have any amount of extra namespaces.
Respectively document.createElement works for everything, one just
need to add the namespace first and then use the right namespace
prefix in document.createElement.
Self evidently that is not the case.

<snip>
Post by VK
Post by Richard Cornford
Post by VK
By these two samples we are getting closer to the question
Ah, you are going to pontificate again.
Post by VK
why serious commercial solutions are checking the current
UA/OS first and the methods themselves only after that?
They are not. In general browser scripting if you see browser
sniffing or object inference then everything beyond that point
is invariably assumed.
In an advanced script, right.
No, the general browser script is and aggregation of copy-and-paste
hacks written by someone who could not explain why they re doing 80% of
the things that they are doing, and is wrong in their explanation of 10%
of what is left.
Post by VK
"Stage 4" right away as I said later.
No, just the result of authors who don't know any better.
Post by VK
Post by Richard Cornford
Post by VK
If someone needs method A of object B then check for B
and A, why does he care if it's IE, Firefox, Opera,
Windows XP, MacOS etc.? Sounds very logical if the
personal practical experience is narrow.
It sounds very logical regardless of practical experience. It
is a strategy where the tests to be made can be deduced from
understanding the code that is to be guarded by those tests.
It guards nothing in the majority of cases: it just pollutes the
script.
You are not really in a position to make any statements about the
majority of cases of feature detection, as you cannot recognise it when
you see it.
Post by VK
Post by Richard Cornford
Post by VK
With time one inevitably comes to the
understanding that the real feature detection is a
two-dimensional system,
Bullshit (unless you are talking exclusively about yourself and using
"understanding" as a label for your 'unusual' mental processes).
Post by VK
and not a single-dimensional one as one might initially
think. It is not so important if a particular feature is
presented or not: the most crucial to know what platform
your script is currently running.
As there is no reliable method for determining which "platform"
a script is currently running in that would be an unfortunate
situation if it were true. Fortunately it is not.
In your private academical universe maybe not.
My "private academical universe" is a place where I program web browsers
for a living, exclusively and as a specialist, and the demands for those
services far exceeds the time I can devote to them. Further more, I work
as a programmer for a software house, where I am surrounded by
programmers and the two layers of management above me are
ex-programmers. If I genuinely were operating on some hopelessly
inefficient basis of non-practical self-delusion somebody would notice
pretty quickly and I would be out of a job. But instead I get to design
the client-side architecture for multi-million pound web applications.

Remember that you have only ever been able to fool people who don't know
any better into thinking that you know what you are talking about, as
soon as any real programmer is shown the code you write they see you for
the incompetent half-wit you are.
Post by VK
I am not currently describing "Cornford's worlds", I am
explaining how are the things being done on a serious
practical level.
No you are not. You are, at best, describing what people do when they
don't know any better.
Post by VK
Post by Richard Cornford
A significant motivation behind the use of feature
detection is to avoid any necessity to know which "platform"
a script is execution in, in order to avoid the consequences
of there being no effective/reliable/rational means of
determining that information.
And again: there is no way to avoid this necessity
As the thing that you assert as necessary is impossible there would be a
huge practical problem if it were necessary.
Post by VK
- at least if someone wants to have his programs used
and paid for.
It is clearly the case that people can get things paid for despite their
being objectively poor. After all, you keep asserting that people pay
you for the code you write, and that is so poor that you would be
unemployable in any serious software authoring context.
Post by VK
Post by Richard Cornford
Post by VK
This is the coordinate X. Only then we can check for
coordinate Y: if the required feature is presented.
No, you can test for the existence and behaviour of features
without knowing which environment is executing a script
You cannot do it: so why keep repeating the non-sense over
and over again?
It has been done, by many others in addition to me, and so must be
something that can be done.
Post by VK
Object X has property Y, one can set/read this property,
but it leads to zero effect or unpredictable effect on
some - but not all - particular browsers and/or OS. What
browsers/OS - one cannot know without prior studying.
Studying web browsers can tell you no more than what the browsers that
are studied may or may not do.
Post by VK
Feature detection itself is out of use here.
Post by Richard Cornford
Post by VK
Only with these two coordinates we can take a reliable
decision: i) use the feature as officially documented,
ii) use the feature over a workaround, iii) do not use
it at all, presented or not.
This is pure fiction on your part.
No, this is how the things are being done: again, outside
of your pocket universe.
Things are being done badly on millions of web sites worldwide; there is
no real doubt about that. But that is not a reason for doing things
badly when they can be done better (though it may act as an excuse for
doing things badly for those who could do no better).

<snip>
Post by VK
Post by Richard Cornford
This is precisely the type of thinking that prevent you form
being able to effectively program anything,
On what basis do you assert that I cannot effectively program anything?
I can post links to dozens of examples of you creating code that does
not work, your not being able to see either that is does not work or
understand why it does not work when that fact is pointed out to you,
and your needing someone else to fix your half-ass efforts. Can you do
the same?
Post by VK
This is exactly the type of thinking that lets me monetarily
enjoy the results of my work year after year. Your type of
thinking just leading so far to unrealizable programming
paradigms claimed by you as the only one being proper.
But a very long way from being claimed only by me. And indeed
considerably pre-dating my involvement with browser scripting.
Post by VK
It also lead to the situation when the most prevailing
trends and the most used scripts are always the most
"improper", "wrong", "ugly" etc. by some c.l.j. regulars.
What is a "most prevailing trend"?
Post by VK
Post by Richard Cornford
Post by VK
Of course this path is for someone who is indeed passing all
stages from the initial idealism to the discovery of the rules
of the real life. This way all stages are normally passed
only once in the career. After that one just starts from the
Stage 4 right away.
Post by VK
P.S. The feature detection as it is is a unrealizable bogus
idea some people are baby sitting with for years.
So this time it is an "unrealizable bogus idea" while last week
it was "promising reliable strategy several years ago, more
exactly during the stagnation period of 2000-2004, and even then
its reliability was mainly based on the fact that nothing was
changing from one year to another". Presumably you mean this
week's absolute statements from you about what feature detection
is to be taken as seriously as last week's?
No, I just giving up to get out of you any clear definition of the
"feature detection". Do you agree with mine,
You have not posted a clear definition of anything, and because you
cannot do joined-up logic it is unlikely that you ever will.
Post by VK
do you have your own, do you agree with the quote from your
previous writings? During the whole thread you just like a snake
on the grill, really. You don't explain what "feature detection"
is for you,
Didn't I make it sufficiently clear that as you refuse to answer the
direct questions that I ask you I see no obligation on may part to
answer any of your requests for information.
Post by VK
you don't know how to solve the situations where the
"feature detection" is out of help,
You originally asserted:-

"What a hey window.opera does here?! Well, at that time I still cared
for Opera - more out of nostalgic feelings rather than out of any
practical necessity. So guess what: Opera had netscape object, it had
netscape.security and enablePrivilege in it: but all this was nothing
but spoofing bogus with enablePrivilege leading to runtime error on use.
How did I know that? By checking and adjusting my script for all
browsers I cared about. How would I know that by thinking theoretically?
Never in my life. How would a pure feature detection prevent this
runtime error? That would just failed miserably."

- and I have already shown how feature detection satisfactorily
addresses that issue. The others you have not yet rendered concrete
(with a test case example) so there is no starting point for any
analysis.
Post by VK
you don't have a list of browsers to check against (because
the feature detection in your _proper_ yet undisclosed
understanding doesn't need it), you want to check not only
features but their behaviors as well... Are you not tired
yourself of yourself? Just be a man and finally strictly
define the feature detection as you understand it.
If you want a strict definition from me you could try answering the
questions that I asked you first.

Richard.
VK
2008-03-26 15:12:12 UTC
Permalink
Post by Richard Cornford
Post by VK
Post by Richard Cornford
Post by VK
document.createElement, elmReference.appendChild etc.
2) Create a element, append necessary sub-elements to it, append
element to canvas.
VML has its own namespace, so there is no reason to expect that
it could be created with the createElement method of an HTML
document (as that method will only create elements with the
HTML namespace). You should expect to be using a createElementNS
method for such an action, and testing for the existence of such
a method in IE will not reveal one.
Because you don't need one: document.createElement covers all
needs in IE - but not on rivals.
Isn't the crux of your compliant above that - cerateElement - creates an
Element with the specified name but that element is not a VML element
(in the sense of having any VML related presentation and behaviour)?
That sounds a lot more like IE is creating an HTML-like element with a
non-HTML name (and so no specified presentation/behaviour associated
with it). It certainly is odd to make the complaint about what IE does
and then assert that it "covers all needs in IE".
It is not a discussion over VML programming or IE's namespace
mechanics. If you want we can start a new thread for that where I'll
be glad to explain the details. For a quick idea you may look at
document.namespaces.add method at MSDN.

My point was that either we have createElementNS or not, appending
children would fail on some browsers (Opera 8.x or IE) and there is no
way to say it in advance without knowing exactly what browser are we
dealing with. appendChild itself works just fine and there is not any
errors to detect.
Post by Richard Cornford
Post by VK
Post by Richard Cornford
Post by VK
By these two samples we are getting closer to the question
Ah, you are going to pontificate again.
Post by VK
why serious commercial solutions are checking the current
UA/OS first and the methods themselves only after that?
They are not. In general browser scripting if you see browser
sniffing or object inference then everything beyond that point
is invariably assumed.
In an advanced script, right.
No, the general browser script is and aggregation of copy-and-paste
hacks written by someone who could not explain why they re doing 80% of
the things that they are doing, and is wrong in their explanation of 10%
of what is left.
Post by VK
"Stage 4" right away as I said later.
No, just the result of authors who don't know any better.
So sake of it go to
http://dev.rubyonrails.org/browser/spinoffs/prototype/tags/rel_1-6-0-2/CHANGELOG
and get your so proud nose into the changelog. This is about how any
changelog of an intensively used program looks like. And the WayBack
Machine http://www.archive.org/index.php will let you to see how did
it started from the very beginning. Do you think all these "IE, Opera,
Firefox on MacOS, etc., etc." was right away in here just to make you
upset?
I am not anyhow involved in Prototype.js project. But I do share the
position that the program "works" only if I saw it working on this
exact browser under this exact OS, anything else is a theoretical
crap. And "works" means that it didn't expose any bugs on this exact
browser under this exact OS until the very release. After the release
inevitable bugs and fixes will come because no one labs can predict
all circumstances. This is why I am always highly suspicious about a
program that did not get yet at least a dozen of known bugs fixed.
Because it means either of two things:
1) no one is using this program
2) the most nasty bugs are still not found.

<snip>
Post by Richard Cornford
Didn't I make it sufficiently clear that as you refuse to answer the
direct questions that I ask you I see no obligation on may part to
answer any of your requests for information.
I refuse to answer on questions about feature detection until the
opponent clearly explains what is feature detection to him. After the
definitions are set we can argue what is wrong or what is right. If
you cannot - or refusing - to define feature detection yourself until
some side question are answered by myself then I am afraid that there
is no ground for further negotiations.

Richard Cornford
2008-03-16 03:22:55 UTC
Permalink
Post by VK
Post by Peter Michaux
Post by Richard Cornford
<snip>
All I want from you is the definition of the "feature detection".
You either can give it or you have no idea what are you talking
about. I am not answering your questions until I see that.
Did Richard not write the following?
<URL:http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>
That should pretty much explain it for you.
Peter
Are you being the herald of His Majesty? :-)
I have read the linked resource and in the particular of
"A Strategy That Works: Object/Feature Detecting."
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdFD
I am reminding that this whole branch of conversation,
intensively filled with personal insults - which is a
regular brand style of Mr.Cornford I have used to over
last years - all this branch started from Mr.Cornford's
claims that I have no idea what "feature detection" is
This branch of the thread did not start with my pointing out that you
clearly had no idea what "featured detection" is. It started with your
responding to my saying that:-

| feature detection is the only strategy that takes a reasoned/rational
| approach to the problem.

- with the statement "That is a false statement right here", followed by a
lot of your pontificating about why 'feature detection' was "promising
reliable strategy several years ago" with its reliability "mainly based on
the fact that nothing was changing from one year to another", and followed
by an example of code that, in context, looked like it was supposed to be
about feature detection, even though it was pretty clearly an 'object
inference' test (and an unreliable one at that).

I did ask you if you actually had intended that posted code to be an example
of 'feature detection', but the simple yes or no answer you could have given
has not yet appeared.

It is neither too difficult, nor at all unreasonable, to conclude that if
someone posts a mass of text that they assert to be about '"feature
detection" but is actually pure bullshit when applied to feature detection,
then that individual does not understand what feature detection is. It may
also be reasonable to ask questions to determine whether what that
individual appears to be saying is what they intended to be saying, but no
grater clarification results if those questions are never answered.
Post by VK
and whatever I am doing is not the feature detection.
The code you posted was not feature detection, or even close to it.
Post by VK
The I gave my definition of feature detection
A definition that had no relationship with the code you had previously
posted as an apparent example of 'feature detection'.
Post by VK
and I proposed to Mr.Cornford to provide his own to find
where my possible misunderstanding may reside.
The misunderstanding resides in your mind, as usual.
Post by VK
My definition - and I remind - was
<quote>
For my humble mind "the feature detection" is
the process of determining if the current environment
where the theoretical possibility of the presence of
entity X is known in advance at the moment of the
development.
</quote>
And it remains a waste of everyone's time. Not being able to do joined-up
logic yourself you will not be able to see how far that assertion falls
short of being something that can be usefully applied.
Post by VK
On the go of the next several posts Mr.Cornford failed
to provide any adequate definition of the topic of question.
But I did not fail to indicate where you should look in order to acquire an
understanding of the subject. You just decided not to bother looking.
Post by VK
If he thinks that a
strict definition of a technical term
It is not a strict definition of anything. The only stated relationship
between "entity X" and "task Y" is that implied by the word "so", which is
so vague as to be utterly useless.
Post by VK
can be anyhow compensated by personal insults and
by demonstration of personal writing skill in
English then it is sorry mistake, I have to say.
Now by looking the jibbering.com resource the closest
It is not a definition, it is an introductory description.
Post by VK
<quote>
Feature detecting seeks to match an attempt to execute as
script (or a part of a script) with the execution
environment by seeking to test features of that environment
where the results of the test have a direct one-to-one
relationship with the features that need to be supported
in the environment for the code to successfully execute. It
is the direct one-to-one relationship in the implemented
tests that avoids the need to identify the specific browser
because whatever browser it is it either will support all
of the required features or it will not. That would mean
testing the feature itself (to ensure that it exists on
the browser) and possibly aspects of the behaviour of that
feature.
</quote>
It is not a definition, it is an introductory description.
Post by VK
yet by squeezing out all unnecessary wording it is exactly
the same of what I initially said.
At minimum that statement makes very strong assertions about the
relationship between the subjects of the tests and the reasons for the
tests. You likely do see that as "unnecessary wording", but only because the
concept has gone far over your head.
Post by VK
If anyone thinks that not then please correct me.
To what end? You never pay any attention to corrections you are given.
Post by VK
NB: "and possibly aspects of the behaviour of that feature"
at the end of the definition is a bogus to skip, of course.
So you did not see how it is both possible to test the actual behaviour of
the environment and why doing so may be necessary from the examples given? I
cannot say that surprises me.
Post by VK
It is not nice of Mr.Cornford to try to protect the
definition by making it so ridiculously ambivalent.
It is not a definition, but it would have not been a satisfactory document
without at least one example of purely behaviour related testing.
Post by VK
Either one does an abstract feature detection or one
tests the feature behavior across certain amount of UAs.
Either? And what do "UAs" have to do with anything?
Post by VK
Either we are making a feature detection or we are
making browser sniffing.
Yes, browser sniffing is not feature detection, in the same way as object
inference is not feature detection.
Post by VK
Either possible,
Browser sniffing and feature detection? Being possible is not the issue, but
rather their relative effectiveness and possible claims to be a
reasoned/rational approach to the problems of browser scripting.
Post by VK
but let's do not define the feature detection as the
browser sniffing, or vice versa, or all together in one
pack, OK?
You have started gibbering again.
When you say "sample" and "provided" do you mean the code you posted, or
your proposed, but never coded, application of your "definition"?
Post by VK
in order to accomplish a particular task I need
window.netscape.security.privilegeManager object
to use its enablePrivilege method.
And as I have already said; that a totally unrealistic example of a 'task'
because acquiring a privilege is never an end in itself. Any actual task
that is to be achieved will require at least one "entity X" in addition to
window.netscape.security.privilegeManager.enablePrivilege.

This exposed one of the logical holes in your "definition" because "task Y"
may require the window.netscape.security.privilegeManager.enablePrivilege to
exist, and so imply that it be tested for (so satisfying your "so"
relationship), but if the task also required
"Components.interfaces.nsILocalFile" you have nothing to imply that that
should also be the subject of testing. And that is quite important because
the whole justification for your testing for - window.opera - in your posted
example followed from your failure to do anything about verifying that the
environment did have - Components -, - Components.interfaces -,
Components.interfaces.nsILocalFile -, etc. Because if you had been testing
for the features that had a direct relationship with the "task Y" that you
intended to attempt you would not have found them on Opera browsers and so
would not have to worry about whether any browser on which you did not find
them was actually Opera or not.

And while you are fixating on the security.privilegeManager object you are
falling to notice that if you remove the - window.opera - test from your
code the exception thrown is:-

| Reference to undefined variable: Components

Which had nothing to do with any capabilities of the
security.privilegeManager object, but everything to do with trying to employ
an object in an environment where it doesn't exist. Just executing the -
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect'); -
line on Opera (at least 7.5 and 8.5) does not throw an exception.
Post by VK
Respectively before to accomplish this task I am checking the
existence of "window", "window.netscape", "window.netscape.security"
and "window.netscape.security.privilegeManager".
But your posted 'example' clearly did not test for
window.netscape.security.privilegeManager, nor
window.netscape.security.privilegeManager.enablePrivilege.
Post by VK
It is possible that everything is here including
"enablePrivilege" method but at the same time it is
What is "spoofing bogus" supposed to mean?
Post by VK
such environment is one of versions of Opera, so I
additionally check for (typeof window.opera != 'object').
Ah, so we are talking bout the code you posted, the code in which you never
did check for the existence of window.netscape.security.privilegeManager,
etc.
Post by VK
No feature detection can possibly help in this
On the contrary, feature detection would have entity solved you proposed
issue that necessitated testing for - window.opera - in the code you posted.
The task you were trying to perform was well beyond the task of acquiring a
privilege and necessitated that the environment provide the extensive set of
other objects employed by the code. Opera browsers do not provide those
objects so testing for them prior to entering the branch where they were
used would mean that no opera browser would enter that branch and so no
code that attempted to use those non existent objects would ever be
executed.
Post by VK
and in N^n of similar situations.
For you situations, where your inability to analyse directly results in
issues that you cannot effectively cope with, that must be a daily
occurrence. but your personal limitations have no baring on anyone else.
Post by VK
My script works not out of some theoretical
considerations,
Your posted script didn't work. It was going to error-out on every browser
that had a - window.netscape.security - object and was not Opera, but also
did not provide any of the remaining features required by the branch of code
that was going to be executed as a result of the test. Your justification
for that was (and probably will remain) that you do not care about any of
those browsers. But not caring when something does not work is not the same
as having something that does work.
Post by VK
however well reasoned they would be.
You don't reason, else you might have seen what when an exception says
"Reference to undefined variable: Components" it is much more reasonable to
test the environment for the existence of the - Components - than to infer
its non-existence from the presence of a - window.opera - object.
Post by VK
My script works because it was deployed on all environments I do
care about,
There you go, you do not care that what you are doing will error-out in
environments that you do not care about.
Post by VK
tested and adjusted if needed. If it also works for some
other untested (currently non-interesting = non-payable to me)
environments then so the better. If not then screw them for now.
Strange as the idea may seem to you there are people who are interested in
doing the best job they can, rather than creating structures consisting of
aggregations of dubious hacks and then saying "screw then" when the
consequences emerge.

Richard.
Eric B. Bednarz
2008-03-10 01:52:11 UTC
Permalink
VK <***@yahoo.com> writes:

[> Richard Cornford wrote:]
Post by Richard Cornford
feature detection is the only strategy that takes a
reasoned/rational approach to the problem.
That is a false statement right here. […]
The end of feature detection came
That might depend on your definition of ‘feature’, and ‘detection’.
when the feature spoofing became a
casual technique of wannabe UA producers.
You mean when M$ started claiming to be Mozilla compatible?

Since you fancy wandering off-topic, seeing server-side code like

| if (strstr($_SERVER['HTTP_ACCEPT'], 'application/xhtml+xml'))

deployed on the web doesn't mean that content negotiation on a http
server is impossible, it just means a half-wit can't reverse engineer it
during lunch break, ‘detecting’ a ‘feature’.

(notably, there isn't *any* kind of inherently *save* client-side
scripting, I’ve seen desktop ‘firewalls’ allowing removal of element
nodes and bit-bucketing insertion after the fact, in savvy UAs,
resulting in blank document parts; you cannot detect *that* in any way I
am aware of, but that doesn’t mean you don’t have to do your best
either)
P.S. As both the Mr.Cornford post and my reply containing too much of
philosophy,
I didn’t see any philosophy in either of them, but I noticed some other
differences. :-)
--
||| hexadecimal EBB
o-o decimal 3771
--oOo--( )--oOo-- octal 7273
205 goodbye binary 111010111011
Matt Kruse
2008-03-03 03:06:06 UTC
Permalink
Post by Peter Michaux
[snip]
Post by Peter Michaux
At what point is a browser considered worthy of
consideration?
The ability to ask a question often gives the false impression that the
question should (or could) be answered.
I think this question _must_ be answered. When developing any web
site, don't you have to decide which browsers you will actively try to
support, and which browsers you don't care about?
Post by Peter Michaux
You question "At what point is a browser considered worthy of
consideration?" implies three things that are dubious assumptions.
I disagree. I think you are inserting your own assumptions.
Post by Peter Michaux
First that there exists a comprehensive list of all web browsers (so pick the top
of the range handsets from each of the big mobile phone manufacturers and
tell me which web browser ships with each? I know that Opera, Safari and
NetFront will be in that list, but I am also pretty sure that there will be
at lest one browser in there that I never heard off at all (and probably
more)).
I don't think this is implied at all. One does not need a
comprehensive list of all browsers in order to decide which browsers
must be supported, or which features must be available in any browser
that will be able to use the web site.
Post by Peter Michaux
Second, that there is a "point" that can be determined in some way.
If you are to support one subset and not support another - for
whatever reasons - then that point must exist. And you must be able to
determine where it is.
Post by Peter Michaux
Third, that the single question should be asked prior to establishing the
context in which "worthy of consideration" should be applied. If, for
example, I am designing a web application for internal use by corporate
users I may well find myself in a position to know a grate deal about the
browsers/OSs in use and so find it very easy to say that every browser that
is not in a very short list is not 'worthy of consideration' (thus avoiding
needed to know the names of the unworthy contenders).
I think you are assuming that you must know every browser you that you
actively choose not to support.

Rather, I see it as a decision to support a specific subset of all
browsers, and any that do not fall into that group are thereby not
supported. You may be able to list some of those browser by name, and
not even know that some others exist.

Unless the goal of a project is to properly support all web browsers
in existence and all browsers that will ever exist in the future, then
the developer _IS_ making a decision about where to draw the line and
how to choose which browsers should be supported and which should not.

The point of Peter's post, I think, was to figure out where that line
is drawn (surely in different places for different situations) and
maybe to discuss the thinking process a person should go through when
deciding where to draw the line.

Matt Kruse
Richard Cornford
2008-03-09 16:58:03 UTC
Permalink
Post by Matt Kruse
Post by Peter Michaux
[snip]
Post by Peter Michaux
At what point is a browser considered worthy of
consideration?
The ability to ask a question often gives the false
impression that the question should (or could) be
answered.
I think this question _must_ be answered.
Even if that question "must be answered" it would still be a mistake to ask
the question prior to knowing precisely what context the answer was going to
apply to.
Post by Matt Kruse
When developing any web site, don't you have to decide
which browsers you will actively try to support, and
which browsers you don't care about?
No you don't. You only need to decide (and once you know what you will be
doing it may no longer be a decision, but rather a direct consequence of
those other decisions) which features those browsers would need to provide
before they could actively support the script.

It is also inevitably the case that whenever a browser is unknown to you it
is impossible to categorise it as something that you will "actively try to
support" or as something that "you don't care about". While if the interest
is only in which features the browser supports then knowing the specifics of
an unknown browser is no longer a consideration because that browser either
does or does not support the relevant features independently of your knowing
whether it does.
Post by Matt Kruse
Post by Peter Michaux
You question "At what point is a browser considered
worthy of consideration?" implies three things that are
dubious assumptions.
I disagree. I think you are inserting your own assumptions.
Possibly. I am certainly assuming that the question is asking for a list of
browsers as an answer.
Post by Matt Kruse
Post by Peter Michaux
First that there exists a comprehensive list of all web
browsers ...
<snip>
Post by Matt Kruse
I don't think this is implied at all. One does not need a
comprehensive list of all browsers in order to decide which
browsers must be supported,
The question is not in terms of which browsers must be supported. That
question is pretty easy to answer; If the context is an intranet then the
browsers in use on that internet _must_ be supported, and on the internet
not supporting the most common browsers would be pretty reckless.
Post by Matt Kruse
or which features must be available in any browser
that will be able to use the web site.
Post by Peter Michaux
Second, that there is a "point" that can be determined in some way.
If you are to support one subset and not support another
- for whatever reasons - then that point must exist.
You start that with an 'if'. But even the existence of a "point" does not
itself result in an ability to determine either what that point it or where
any given subject is in relation to that point.
Post by Matt Kruse
And you must be able to determine where it is.
Why must I? If the "point" is in terms of necessary features employed by the
script then I can determine precisely what that point it, but cannot
determine where any unknown browsers lie in relation to that point. But if
the point is in relation to browser popularity or usage then the point isn't
determined but rather relatively arbitrarily chosen, and it is impossible to
know were even common browsers lie in relation to that point.
Post by Matt Kruse
Post by Peter Michaux
Third, that the single question should be asked prior to
establishing the context in which "worthy of consideration"
should be applied. If, for example, I am designing a web
application for internal use by corporate users I may well
find myself in a position to know a grate deal about the
browsers/OSs in use and so find it very easy to say that
every browser that is not in a very short list is not
'worthy of consideration' (thus avoiding needed to know the
names of the unworthy contenders).
I think you are assuming that you must know every browser you
that you actively choose not to support.
I am saying that you will need to know the name of each and every browser
that you want to make any direct assertions about (be those assertions of
'worthiness' or 'unworthiness').
Post by Matt Kruse
Rather, I see it as a decision to support a specific subset of all
browsers,
And a subset determined by features of browsers, and so avoiding the need to
name any members of that subset.
Post by Matt Kruse
and any that do not fall into that group are thereby not
supported.
Inevitably. But you still cannot list either the browsers that are to be
supported or the browsers that are not. So anyone asking for such a list
will be disappointed (or mislead if you provide them with a list).
Post by Matt Kruse
You may be able to list some of those browser by name, and
not even know that some others exist.
Absolutely. So in practice you can get the job done without ever providing
any lists of specific browsers, and that is a good thing because listing
unknown browsers cannot be practical.
Post by Matt Kruse
Unless the goal of a project is to properly support all web
browsers in existence and all browsers that will ever exist
in the future, then the developer _IS_ making a decision about
where to draw the line and how to choose which browsers should
be supported and which should not.
So you end up agreeing with me that creating a list is not practical, but is
also unnecessary, and that the first step is determining what the purpose of
the wed-site/application/script is (where the answer to that question pretty
much decides which subset of browser features are necessary in actively
supporting browsers)?
Post by Matt Kruse
The point of Peter's post, I think, was to figure out where
that line is drawn (surely in different places for different
situations)
Which is why the question should not be answered prior to deciding what the
precise context is (and becomes pretty trivial after that has been done).
Post by Matt Kruse
and maybe to discuss the thinking process a person should
go through when deciding where to draw the line.
Yes, and that thinking process then should not be fixated on the creation of
lists of web browsers.

Richard.
Matt Kruse
2008-03-09 18:52:50 UTC
Permalink
Post by Richard Cornford
Even if that question "must be answered" it would still be a mistake to ask
the question prior to knowing precisely what context the answer was going to
apply to.
There is a tendency for many regulars here to throw up their hands and
say how futile it is to discuss anything without knowing the context.

I think there is value in exploring questions without knowing the
context, and then looking at where the answers would be different
depending on different contexts. You can't get an exhaustive answer
that would apply to _every_ situation, but you can probably hit many
likely contexts just by thinking about the problem.

"I want to do X".

"I see two ways to do it. You can do it this way, which would work
great in context A, and this way which would work in context B, but I
don't see any way to make it work for both."
Post by Richard Cornford
Post by Matt Kruse
When developing any web site, don't you have to decide
which browsers you will actively try to support, and
which browsers you don't care about?
No you don't. You only need to decide (and once you know what you will be
doing it may no longer be a decision, but rather a direct consequence of
those other decisions) which features those browsers would need to provide
before they could actively support the script.
Chicken and the egg.

There are (at least) two ways to think about this:

a) I know what features I will require in order for my script to work
correctly. I will test for those features and any browser that has
them will be supported. All others will gracefully degrade.

b) I know that my app must run in browsers X, Y, and Z because those
are used by our clients, or on our intranet, or by the majority of our
customers, etc. I know that whatever I write should work at least
there. So I will adjust my feature requirements as necessary and even
change my script functionality if necessary in order to run properly
in those browsers.

If you don't have a list of browsers where your script must run
correctly, then you can just take route (a) and test for the features
you want to use.

If you must support a certain subset of browsers, then your feature
requirements must be flexible and you must design accordingly. If your
revised feature requirements also happen to be available in browsers
you don't know about, then you have the side benefit of your script
working on more browsers than you require it to.

If it's a requirement that NN4 be "supported" then the available
features in your toolbox are severely limited, and you may not be able
to even provide the same functionality. At which point you may have a
discussion with those making the requirements to have a "partial
support" version and a "full support" version, where NN4 can have some
added functionality and more recent browsers will get all the bells
and whistles.

Of course, part of starting with a list of browsers that must be
supported is also accepting that the final answer may be that the
requested functionality simply cannot be accomplished for all required
browsers.

Creating a list of known "unsupported" browsers may be possible and
useful. If a set of required features is known, and a common browsers
is known which does not support those features, then you can list that
browser as "unsupported" so that people wondering if it will work
won't have to test it themselves.

Also, if support for a specific browser like IE5.5 is known not to be
necessary, then you can use features that may not be applicable to a
script where the goal is to run in as many browsers as possible.
Whereas before you may have branched to catch some IE5.5 quirk and try
to support it, now you can just avoid that. Less coding and testing
may be necessary. So there may be great benefit in explicitly listing
browsers that are NOT supported.
Post by Richard Cornford
So you end up agreeing with me that creating a list is not practical, but is
also unnecessary, and that the first step is determining what the purpose of
the wed-site/application/script is (where the answer to that question pretty
much decides which subset of browser features are necessary in actively
supporting browsers)?
Again, just to make sure the point is clear - sometimes you start with
a list of required features, and sometimes you start with a list of
required browsers. It just depends.

Matt Kruse
dhtml
2008-03-15 19:46:01 UTC
Permalink
Post by Matt Kruse
Post by Richard Cornford
Even if that question "must be answered" it would still be a mistake to ask
the question prior to knowing precisely what context the answer was going to
apply to.
There is a tendency for many regulars here to throw up their hands and
say how futile it is to discuss anything without knowing the context.
The idea of Patterns is "encapsulate the parts that vary." This come
from the task of "solving a problem in a context."

SO - it makes sense from that mentality to ask, "What is the
context?".

Considering the problem: "[something] doesn't work in [browser]."
That, to me, is a constraint; it's part of the context and it is not
the problem itself. In many cases, these browser bugs/issues can be
avoided by a different approach, which can only be discovered by
examining the original real Problem in question.
Post by Matt Kruse
I think there is value in exploring questions without knowing the
context, and then looking at where the answers would be different
depending on different contexts. You can't get an exhaustive answer
that would apply to _every_ situation, but you can probably hit many
likely contexts just by thinking about the problem.
"I want to do X".
"I see two ways to do it. You can do it this way, which would work
great in context A, and this way which would work in context B, but I
don't see any way to make it work for both."
This is getting more theoretical.

There is a term called "Speculative Generality" which means,
basically, adding in functionality for features which seem likely. In
some cases, experience with a particular Domain or Paradigm will make
these guesses more accurate. With TDD, the speculative generality
comes at a cost of writing a test. Thorough tests that cover all paths
and possibilities requires more commitment to the API. Basically it
comes down to this: If it is painful to test, then "Do I really need
this solution?"

Now the other approach is to code a solution for - A -, then, if/when
- B - becomes a problem that was not addressed in the solution to - A
-, then that aspect is the part that varies.
Post by Matt Kruse
If you don't have a list of browsers where your script must run
correctly, then you can just take route (a) and test for the features
you want to use.
But then you still need an environment to test in. The application's
user acceptance test will, ultimately, be run against a set of web
browsers that the client is concerned with. These very browsers can
also be used for the unit tests.

The client may not be concerned with future compatibility. Such
concerns are for the developer. Browser detection seems to cause
problems here. Browser detection also causes maintenance problems.
Consider:-

if(isIE) {
statement;
}

As I have noticed, browsers change, and so this code will change
accordingly. The problem is that as it is refactored, do you retest
for previous versions of IE, OR do you expect/assert failure?
Post by Matt Kruse
Again, just to make sure the point is clear - sometimes you start with
a list of required features, and sometimes you start with a list of
required browsers. It just depends.
The client does not care about feature support. Developers either care
about internal quality of the code or they do not. Sacrificing
internal quality may provide immediate short term results, but will
ultimately lead to a decrease in code output and a reduction in code
quality.

When I am asked "How long can you complete [task]" in?" I always look
first at the code. If the code has poor internal quality, then the
time to complete [task] can be considerably longer.

I have one more point about this:
Public web pages are acceptance tests for browser vendors.

Garrett
Post by Matt Kruse
Matt Kruse
David Mark
2008-02-26 05:25:58 UTC
Permalink
<snip>> Is there a property of document in IceBrowser that leads
to its parent window?  ...
<snip>
The only value of the IceBrowser 5 document that refers to its parent window
is its - __parent__ - property.
If I read that right, then this would get a reference to the window:

var win = myDocNode.__parent__;

Is that right?

Thanks for the info! Apparently I need a third branch for my
function.

BTW, is IceBrowser primarily used in mobile devices? All I know about
it is that it is known to spoof IE (at least some versions anyway.)
Richard Cornford
2008-02-26 23:08:38 UTC
Permalink
Post by David Mark
<snip>> Is there a property of document in IceBrowser
that leads to its parent window? ...
<snip>
The only value of the IceBrowser 5 document that refers
to its parent window is its - __parent__ - property.
If I read that right, then this would get a reference
var win = myDocNode.__parent__;
Is that right?
Yes, that it right.

<snip>
Post by David Mark
BTW, is IceBrowser primarily used in mobile devices?
All I know about it is that it is known to spoof IE
(at least some versions anyway.)
IceBrowsr certainly has been embedded in mobile devices. It was also sold as
a Java web browser component for embedding in any Java application.

Richard.
Randy Webb
2008-02-25 00:23:33 UTC
Permalink
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Thomas 'PointedEars' Lahn
Post by Peter Michaux
Post by Bob
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.
You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?
Your continuously missing the point, and making just more fallacious
arguments (here again: shifting the burden of proof), is becoming tiresome.
http://en.wikipedia.org/wiki/List_of_fallacies
You say they exist, someone else says they don't and asks you to prove
your argument. You don't and constantly whine about "shifting the burden
of proof". It is simple to prove what you say, just name a browser
without the window object being the global object. But no, you choose to
constantly whine about it and wonder why your credibility is at the
level it is.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Richard Cornford
2008-02-22 09:54:26 UTC
Permalink
Post by Bob
Is there anyway to access the global object from inside a
function other than doing a "var _global = this;" before
declaring the function?
In javascript the value of the - this - keyword is determined by how a
function is called. If the function is not called as a method of an object
the value of the - this - keyword defaults to a reference to the global
object. As a result, from any context you can get a reference to the global
object using:-

function x(){
...
var localGlobalRef = function(){return this;}();
...
}

This is 100% reliable in ECMAScript 3rd Ed. implementations, and quite
useful, but it looks like ES 4 will not be back-compatible with ES 3 in this
regard. Still, not being back-compatible with ES 3 may (fingers crossed) be
enough to kill ES 4 in its cradle so maybe that is not worth worrying about.

Richard.
Bob
2008-02-22 12:46:54 UTC
Permalink
Interesting. Is there anyway to distinguish ES3 from ES4, and if ES4 is
present then return the global property?

Thanks very much
Post by Richard Cornford
Post by Bob
Is there anyway to access the global object from inside a
function other than doing a "var _global = this;" before
declaring the function?
In javascript the value of the - this - keyword is determined by how a
function is called. If the function is not called as a method of an object
the value of the - this - keyword defaults to a reference to the global
object. As a result, from any context you can get a reference to the global
object using:-
function x(){
...
var localGlobalRef = function(){return this;}();
...
}
This is 100% reliable in ECMAScript 3rd Ed. implementations, and quite
useful, but it looks like ES 4 will not be back-compatible with ES 3 in this
regard. Still, not being back-compatible with ES 3 may (fingers crossed) be
enough to kill ES 4 in its cradle so maybe that is not worth worrying about.
Richard.
Richard Cornford
2008-02-22 13:43:49 UTC
Permalink
Post by Bob
Interesting. Is there anyway to distinguish ES3
from ES4,
Until ES 4 is finished and there is a specification to read that is an
impossible question to answer definitively.
Post by Bob
and if ES4 is
present then return the global property?
<snip>

It certainly should be possible to determine whether a system contains a
property of the global object that has the name 'global' and refers to an
object. So long as you know that you did not put it there it might be
reasonable to assume that the object it refers to is the global object.
Starting with a typeof test might be a good idea. You could do something
like, for example:-

var localGlobalRef = (
(
(typeof global == 'object')&&
(global)
)||
(function(){return this;}())
);

- but I can see good reasons for not wanting to.

Richard.
AKS
2008-02-22 13:29:13 UTC
Permalink
Post by Richard Cornford
but it looks like ES 4 will not be back-compatible with ES 3 in this
regard. Still, not being back-compatible with ES 3 may (fingers crossed) be
enough to kill ES 4 in its cradle so maybe that is not worth worrying about.
Will be this compatible with ES4?

var localGlobalRef = (function () { return this; }).call(null);
Richard Cornford
2008-02-22 13:59:47 UTC
Permalink
Post by AKS
Post by Richard Cornford
but it looks like ES 4 will not be back-compatible with
ES 3 in this regard. Still, not being back-compatible with
ES 3 may (fingers crossed) be enough to kill ES 4 in its
cradle so maybe that is not worth worrying about.
Will be this compatible with ES4?
var localGlobalRef = (function () { return this; }).call(null);
I cannot imagine any circumstances where it would seem reasonable to use -
null - as the first argument to - call - or - apply -. But the last couple
of day's discussion on the ES 4 mailing list says ES 4 will absolutely not
be compatible with ES 3 in this regard. They regard the ES 3 behaviour to be
a bug (and a security vulnerability) and are not going to reproduce it in ES
4.

Given that I cannot imagine circumstances where using - null - as the first
argument would make any sense at all I do not consider this incompatibility
as significant. While the other incompatibility will impact on the third
most common means of getting a reference to the global object, and a
technique which has been being proposed (and so presumably being used by at
least some) for half a decade to my certain knowledge.

Richard.
AKS
2008-02-22 15:48:16 UTC
Permalink
... I cannot imagine circumstances where using - null - as the first
argument would make any sense at all I do not consider this incompatibility
as significant.
Thanks for detailed response!
Continue reading on narkive:
Loading...