Accessing the global object

15 views
Skip to first unread message

Bob

unread,
Feb 21, 2008, 8:10:09 PM2/21/08
to
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

unread,
Feb 21, 2008, 8:19:26 PM2/21/08
to
"Bob" <nob...@nowhere.com> writes:

> 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/

Peter Michaux

unread,
Feb 21, 2008, 8:35:33 PM2/21/08
to
On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
> 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

Richard Cornford

unread,
Feb 22, 2008, 4:54:26 AM2/22/08
to

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

unread,
Feb 22, 2008, 7:46:54 AM2/22/08
to
Interesting. Is there anyway to distinguish ES3 from ES4, and if ES4 is
present then return the global property?

Thanks very much


"Richard Cornford" <Ric...@litotes.demon.co.uk> wrote in message
news:fpm64j$f9j$1$8300...@news.demon.co.uk...

AKS

unread,
Feb 22, 2008, 8:29:13 AM2/22/08
to
On Feb 22, 2:54 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> 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

unread,
Feb 22, 2008, 8:43:49 AM2/22/08
to
Bob wrote:
> 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.

> 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.


Richard Cornford

unread,
Feb 22, 2008, 8:59:47 AM2/22/08
to
AKS wrote:

> On Feb 22, 2:54 pm, Richard Cornford wrote:
>
>> 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

unread,
Feb 22, 2008, 10:48:16 AM2/22/08
to
On Feb 22, 6:59 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> ... 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!

Thomas 'PointedEars' Lahn

unread,
Feb 23, 2008, 8:33:48 PM2/23/08
to
Joost Diepenmaat wrote:
> "Bob" <nob...@nowhere.com> writes:
>> 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.

> 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

Thomas 'PointedEars' Lahn

unread,
Feb 23, 2008, 8:37:30 PM2/23/08
to
Peter Michaux wrote:
> On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
>> 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.

> I think your idea of creating your own "_global" is better.

See <47C0C97C...@PointedEars.de>, among others.

> 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.

> 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

unread,
Feb 23, 2008, 10:29:32 PM2/23/08
to
On Feb 23, 5:37 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Peter Michaux wrote:
> > On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
> >> 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.


> > I think your idea of creating your own "_global" is better.
>

> See <47C0C97C.5010...@PointedEars.de>, among others.


>
> > 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.
>
> > 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

unread,
Feb 24, 2008, 6:20:38 AM2/24/08
to
Peter Michaux wrote:

> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
>>>> 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.

>>> 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.
>>
>>> 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

unread,
Feb 24, 2008, 1:18:00 PM2/24/08
to
On Feb 24, 3:20 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> Peter Michaux wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Peter Michaux wrote:
> >>> On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
> >>>> 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.


> >>> 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.
>
> >>> 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

unread,
Feb 24, 2008, 1:36:25 PM2/24/08
to
Peter Michaux wrote:
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> Peter Michaux wrote:
>>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>>> Peter Michaux wrote:
>>>>> On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
>>>>>> 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.

>>>>> 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.

> 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.

Peter Michaux

unread,
Feb 24, 2008, 2:06:54 PM2/24/08
to
On Feb 24, 10:36 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>

wrote:
> Peter Michaux wrote:
> > [...] Thomas 'PointedEars' Lahn [...] wrote:
> >> Peter Michaux wrote:
> >>> [...] Thomas 'PointedEars' Lahn [...] wrote:
> >>>> Peter Michaux wrote:
> >>>>> On Feb 21, 5:10 pm, "Bob" <nob...@nowhere.com> wrote:
> >>>>>> 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

unread,
Feb 24, 2008, 5:04:17 PM2/24/08
to

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$8300...@news.demon.co.uk>

Peter Michaux

unread,
Feb 24, 2008, 6:31:28 PM2/24/08
to
On Feb 24, 2:04 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>

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

unread,
Feb 24, 2008, 6:49:01 PM2/24/08
to

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.

> 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.

Peter Michaux

unread,
Feb 24, 2008, 6:53:30 PM2/24/08
to
On Feb 24, 3:49 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>

The overwhelming majority of JavaScript hosts are web browsers. Simple
as that.

Peter

Randy Webb

unread,
Feb 24, 2008, 7:23:33 PM2/24/08
to
Thomas 'PointedEars' Lahn said the following on 2/24/2008 5:04 PM:

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/

Thomas 'PointedEars' Lahn

unread,
Feb 24, 2008, 8:09:42 PM2/24/08
to
>>> [...]

>>> 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.

Richard Cornford

unread,
Feb 24, 2008, 8:25:42 PM2/24/08
to
Peter Michaux wrote:
<snip>

> 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

unread,
Feb 24, 2008, 10:12:40 PM2/24/08
to
On Feb 24, 8:25 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

Yes, I have heard that it is a bad assumption that
document.defaultView == window.

> (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

unread,
Feb 24, 2008, 10:19:59 PM2/24/08
to
On Feb 24, 7:12 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Feb 24, 8:25 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:

[snip]

> > 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

unread,
Feb 24, 2008, 10:35:18 PM2/24/08
to

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

unread,
Feb 25, 2008, 5:37:05 PM2/25/08
to
David Mark wrote:
<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.

Richard.


Peter Michaux

unread,
Feb 25, 2008, 6:43:09 PM2/25/08
to
On Feb 25, 2:37 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> David Mark wrote:
>
> <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 and I
have never heard of anyone using it. Is it something you use in your
work?

Peter

David Mark

unread,
Feb 26, 2008, 12:25:58 AM2/26/08
to
On Feb 25, 5:37 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

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

unread,
Feb 26, 2008, 6:08:49 PM2/26/08
to
Peter Michaux wrote:

> On Feb 25, 2:37 pm, Richard Cornford wrote:
>> David Mark wrote:
>>
>> <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.

> 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.


Richard Cornford

unread,
Feb 26, 2008, 6:08:38 PM2/26/08
to
David Mark wrote:

> On Feb 25, 5:37 pm, Richard Cornford wrote:
>> David Mark wrote:
>> <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?

Yes, that it right.

<snip>


> 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.


Peter Michaux

unread,
Feb 27, 2008, 12:20:21 AM2/27/08
to
On Feb 26, 3:08 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> Peter Michaux wrote:
> > On Feb 25, 2:37 pm, Richard Cornford wrote:
> >> David Mark wrote:
>
> >> <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

unread,
Feb 27, 2008, 11:12:37 AM2/27/08
to
On Feb 26, 11:20 pm, Peter Michaux <petermich...@gmail.com> wrote:
> 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

unread,
Feb 27, 2008, 3:17:05 PM2/27/08
to
On Feb 27, 11:12 am, Matt Kruse <m...@mattkruse.com> wrote:
> On Feb 26, 11:20 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > 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.)

>
> 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.

>
> 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.

> assumptions must be made. Core language features are assumed to work

Again with the language features.

> 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.

> 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.

>
> No, of course not. Because the second logical conclusion is that we

What was the first one?

> 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.

> 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.

>
> 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.

>
> 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."

> 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.

>
> 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.

>
> 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.

>
> 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.

>
> - 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.

> - 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.

> - 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.

> 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.

> - 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.

>
> 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

unread,
Mar 2, 2008, 11:28:20 AM3/2/08
to
Peter Michaux wrote:

> On Feb 26, 3:08 pm, Richard Cornford wrote:
>> Peter Michaux wrote:
>> > On Feb 25, 2:37 pm, Richard Cornford wrote:
>> >> David Mark wrote:
>>
>> >> <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.

> 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.

> 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).

> 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.

> If the number of browsers increases indefinitely,

The total is unlikely to go down over time.

> 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.

> 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.

> 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

unread,
Mar 2, 2008, 12:53:17 PM3/2/08
to
On Mar 2, 8:28 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>

wrote:
> Peter Michaux wrote:
> > On Feb 26, 3:08 pm, Richard Cornford wrote:
> >> Peter Michaux wrote:
> >> > On Feb 25, 2:37 pm, Richard Cornford wrote:
> >> >> David Mark wrote:
>


>
> 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

>
> Richard.

Thomas 'PointedEars' Lahn

unread,
Mar 2, 2008, 1:34:54 PM3/2/08
to
dhtml wrote:
> On Mar 2, 8:28 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
>> Peter Michaux wrote:
>>> On Feb 26, 3:08 pm, Richard Cornford wrote:
>>>> Peter Michaux wrote:
>>>>> On Feb 25, 2:37 pm, Richard Cornford wrote:
>>>>>> David Mark wrote:
>
>> 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

VK

unread,
Mar 2, 2008, 1:43:07 PM3/2/08
to
On Mar 2, 7:28 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> 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.

Richard Cornford

unread,
Mar 2, 2008, 1:50:49 PM3/2/08
to
dhtml wrote:
> On Mar 2, 8:28 am, Richard Cornford wrote:
<snip - irrelevant attributions>

>> 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

unread,
Mar 2, 2008, 6:55:33 PM3/2/08
to
On Mar 2, 8:28 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
> Peter Michaux wrote:

[snip]

> 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]

> 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]

> 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]

> 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]

> > 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]

> > 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

Peter Michaux

unread,
Mar 2, 2008, 7:07:03 PM3/2/08
to
On Mar 2, 10:34 am, Thomas 'PointedEars' Lahn <PointedE...@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

Peter Michaux

unread,
Mar 2, 2008, 7:08:45 PM3/2/08
to
On Mar 2, 10:50 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

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

Thomas 'PointedEars' Lahn

unread,
Mar 2, 2008, 7:31:06 PM3/2/08
to
Peter Michaux wrote:
> [...] Thomas 'PointedEars' Lahn [...] wrote:
>> 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.

>> 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.

> 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.

> 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 ;-)

> 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.

Thomas 'PointedEars' Lahn

unread,
Mar 2, 2008, 7:33:51 PM3/2/08
to
Thomas 'PointedEars' Lahn wrote:
> Peter Michaux wrote:
>> [...] Thomas 'PointedEars' Lahn [...] wrote:
>>> 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

unread,
Mar 2, 2008, 10:06:06 PM3/2/08
to
On Mar 2, 10:28 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
> [snip]

> > 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?

> 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.

> 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.

> 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.

> 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

Matt Kruse

unread,
Mar 2, 2008, 10:11:43 PM3/2/08
to
On Mar 2, 6:31 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> 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?

> 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?

> 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?

> > 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.

> > 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

unread,
Mar 6, 2008, 10:57:51 PM3/6/08
to

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

unread,
Mar 7, 2008, 9:17:32 AM3/7/08
to
On Mar 6, 9:57 pm, Peter Michaux <petermich...@gmail.com> wrote:
> 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.

> 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.

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.

> 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.

> 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.

> 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

unread,
Mar 7, 2008, 10:29:16 AM3/7/08
to
On Mar 7, 6:17 am, Matt Kruse <m...@mattkruse.com> wrote:
> On Mar 6, 9:57 pm, Peter Michaux <petermich...@gmail.com> wrote:
>
> > 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.


> > 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.
>
> 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.

> 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.

> 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.

> 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.

> 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.

> 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.
>
> > 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.

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.

> 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

unread,
Mar 9, 2008, 12:58:03 PM3/9/08
to
Matt Kruse wrote:

> On Mar 2, 10:28 am, Richard Cornford wrote:
>> [snip]
>>> 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.

> 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.

>> 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.

>> First that there exists a comprehensive list of all web

>> browsers ...
<snip>


> 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.

> or which features must be available in any browser
> that will be able to use the web site.
>
>> 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.

> 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.

>> 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').

> 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.

> 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).

> 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.

> 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)?

> 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).

> 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.


Richard Cornford

unread,
Mar 9, 2008, 12:58:14 PM3/9/08
to
Peter Michaux wrote:

> On Mar 2, 10:50 am, Richard Cornford wrote:
>> dhtml wrote:
>>> On Mar 2, 8:28 am, Richard Cornford wrote:
>>
>> <snip - irrelevant attributions>>
>>>> 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>

>>> As strange as it may sound, there actually is a
>>> comprehensive list of all web browsers. It's
>>> called WURFL.
>> <snip>
>>
>> Bullshit!
<snip>

> 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.

Richard Cornford

unread,
Mar 9, 2008, 12:58:07 PM3/9/08
to
Peter Michaux wrote:
> On Mar 2, 7:11 pm, Matt Kruse wrote:
>> On Mar 2, 6:31 pm, Thomas 'PointedEars' Lahn wrote:
<snip>

> 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).

> 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.

> 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.

> 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.

> 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.

> 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

unread,
Mar 9, 2008, 12:58:21 PM3/9/08
to
Peter Michaux wrote:

> On Mar 2, 8:28 am, Richard Cornford wrote:
>> Peter Michaux wrote:
> [snip]
>> 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.

> 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.

> [snip]
>> 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).

> [snip]
>
>> 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.

> [snip]
>> 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.

> [snip]
>
>>> 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.

> 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.

> 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+)

> [snip]
>
>>> 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).

> 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.

> 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.

> 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.

> 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.

Matt Kruse

unread,
Mar 9, 2008, 2:52:50 PM3/9/08