typeof for feature testing host methods

[Peter Michaux]

On Dec 16, 10:24 pm, "Richard Cornford" <[email protected]>
wrote:

<VK >> null>

Oh... 220mm mortars of 2005th series... A heavily outdated armor but
still spooky noisy.

What can I say for everything: loosers are searching for theoretical
failures cases and fighting with any kind of libraries - winners are
leaving them next week for Javascript-paid 3 days of Tahoe snow. ;-)

P.S. What bugs me on the background is that with all human/hours put
so far into document.getElementById detection and other useless doings
one could write a robust wrapper for WebServices (Gecko/IE) or
something else what no one else provide so to be grabbed hot right
from one's hands. It is not my damn business of course what other
people are doing at their spare time, just bugs me a bit.

The discussion about document.getElementById has simply been a vehicle
for a more important discussion about feature detection techniques and
which features should be detected and which can be assumed.

[snip]

 

[Peter Michaux]

David Mark said the following on 12/16/2007 8:42 AM:
[snip]

"used to identify a woman by her maiden family name"

But, I searched for isHostMethod and


It is ~160 posts deep now, I will try to sit down tonight and tomorrow
and read through it. I didn't follow it in depth (not even sure why I
read this one).

The original function David posted was

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

I don't use ActiveX so I can't even comment on it. Needless to say, I
don't have to worry about that part of it.

From what I've been reading, you may use it and not even know it. The
anchor to news resources example was a surprise to me.

Anybody that overwrites host methods deserves what they get. The only
time that can be an issue is if you are using third party libraries though.

And mashups (where there is third party code but it isn't really a
library.)

And injecting code into a legacy page where there isn't time to read
the thousands of lines like

eval("obj."+propName+";");

 

[Peter Michaux]

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas Lahn seems particularly concerned about these
problems (and he is preparing to tell I am wrong or that I have
missed the point.)
Yes, I am. *eg*
Another reason for concern is that even though the host may
provide a callable document.getElementById but that when writing
just "if (document.getElementById)" it isn't the [[Call]]
property the [[Get]] property that is used. David Mark seems to
think this is a problem with some (all?) ActiveX objects. All
host objects are required to implement [[Get]] so IE is not
ECMAScript compliant if it does not.
You miss the point. (See? ;-)) Host objects need to implement
[[Get]],
They don't.
Yes, they do. That is explicitly stated by the Specification, as I
pointed out in the part that you snipped.

Read the first paragraph of 8.6.2. The internal properties are not part
of the language

True:

| 8.6.2 Internal Properties and Methods
|
| Internal properties and methods are not part of the language. They are
| defined by this specification purely for expository purposes. An
| implementation of ECMAScript must behave as if it produced and operated
| upon internal properties in the manner described here.

However, ...

and are not required.

... that, in its absolute, is wrong.

What is required is the implementation behaves as though the internal
properties are used.

You misunderstand. By the Specification's stating that they are "not part
of the language" it is meant that they are not available for code written
in/for implementations. You won't be able to call O[[Get]](), for example.

Therefore, the Specification says below that:

| Every object (including host objects) must implement the [[Prototype]]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| and [[Class]] properties and the [[Get]], [[Put]], [[CanPut]],
| [[HasProperty]], [[Delete]], and [[DefaultValue]] methods.
|
| [...] Host objects may implement these methods in any manner unless
^^^ ^^^^^^^^^^^^^
| specified otherwise; [...]

The bottom line is: Host objects may implement these methods in any manner.
But they *do* need to implement them.

I think the specification is contradictory. Section 8.6.2 starts by
stressing the internal methods are "purely for expository purposes"
and that an "implementation of ECMAScript must behave as if it
produced and operate on internal properties..." then they are
*clearly* implying that the internals of the implementation can be
coded any way the implementor wishes to. Then to later say that "Every
object (including host objects) must implement [certain internal
methods]" is a contradiction. My interpretation is that the spec
writers intended to write "Every object (including host objects) must
behave as though it implements [certain internal properties and
methods]". That is consistent with the beginning of 8.6.2.

They need to behave as though the implement [[Get]].
That is a matter of interpretation.

No. Read the third sentence of 8.6.2.

Read 8.6.2 yourself, again. And this time you should read the most recent
revision.

I have 3rd ed December 1999.


[snip]

Maybe you should stop constraining the use of ECMAScript applications to
browsers.

I program for browsers and the code under discussion is for browsers.

However, it will break in any UA that has a script engine that
does not implement try..catch.

That is an engine that is non-compliant with ES3 or even trying to be
compliant with ES3. I'm not programming for those. Those go down the
degradation path. This is not a substantial loss given the proportion
of users with browsers that do not have try-catch. If you are
programming for implementations that are not ES3 compliant or at least
trying to be ES3 compliant then there is no use quoting from the ES3
spec.

Whether that UA is "old" is irrelevant.

If it is old, unpopular, and unlikely to regain popularity then it is
relevant.

Exception handling was among the newest language features that were
implemented. It can not be expected to be supported.

I think it can be expected to be supported. This is another "where to
draw the line" issues. In rare cases the try-catch will cause one
syntax error and the page will fall back to plain HTML. That is a
sufficiently good user experience for rare users with browsers that
don't comply with an 8 year old standard.

[snip]

 

[David Mark]

David Mark said the following on 12/16/2007 8:42 AM:



Do you test it for any use of appendChild or only in the one place that
it is known to have a problem? And, is there a counterpart in other
browsers?

I test before appending children to script or style elements, as well
as in generic routines that append children to any element. For
elements other than script or style, there are additional rules to
follow to ensure that the resulting markup is valid.

AFAIK, there is no counterpart for canHaveChildren in other browsers.
AFAIK, other browsers don't need it as badly as invalid append
operations fail silently rather than throwing exceptions.

In any event, the feature testing for adding script snippets is
convoluted, but does seem to work for most (if not all) cases.

[snip]

It is ~160 posts deep now, I will try to sit down tonight and tomorrow
and read through it. I didn't follow it in depth (not even sure why I
read this one).

I wasn't referring just to the current topics of discussion. Future
topics are proposed on the project site.

I don't use ActiveX so I can't even comment on it. Needless to say, I
don't have to worry about that part of it.

My point is that you can't always know when you are using an ActiveX
object. MS changes the rules with each release. Did you know that
some anchor elements are implemented as ActiveX objects in IE7? Doing
something as innocuous as testing the href property of a random link
can throw an error.

Anybody that overwrites host methods deserves what they get. The only
time that can be an issue is if you are using third party libraries though.

I agree. I do not test for such foolishness. On a similar note, I
don't care for libraries that fill in missing methods either (even in
the rare event that the substitute implementation is perfect.) They
assume that they will never be used in the same page as a script that
makes inferences based on the presence of host methods.

That I totally agree with when it comes to testing procedures. Not so
much for generic functions though.

I don't follow you there. Either you use a generic feature testing
function or you have to duplicate the same code endlessly.

 

[David Mark]

Peter Michaux said the following on 12/16/2007 8:10 PM:

<snip>

The original function David posted was

var reFeaturedMethod = new RegExp('^function|object$', 'i');

var isFeaturedMethod = function(o, m) {
var t = typeof(o[m]);
return !!((reFeaturedMethod.test(t) && o[m]) || t == 'unknown');
};

I found it shortly after posting.

From what I've been reading, you may use it and not even know it. The
anchor to news resources example was a surprise to me.

<URL:http://groups.google.com/group/comp.lang.javascript/browse_frm/thread...>

Let me clarify it a little better. I don't use var something = new
ActiveX('anything') in web page code. I use it on our intranet, it is
used in the process.wsf file that generates the group FAQ, and I use it
on my personal computer. But, for web work, I don't use it unless there
is a hidden use of it.

Still ignorant for MS to make a protocol an ActiveX component. Might
explain why the links don't work for me in IE.

Exactly. For some unknown reason MS implements some element objects
(e.g. news links) as ActiveX objects. This wasn't the case in IE6,
but is in IE7. Nobody knows if this will be the case in future
versions of IE. They may decide to implement the document object that
way (imagine the ramifications of that.) This is why a generic
testing function makes sense.

[snip]

And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".

Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)

The result of all this is that much of the Web has turned into an
inaccessible wasteland. Thanks to script errors around every corner,
I often disable scripting. And of course, many sites refuse to do
anything but tell me "your browser does not support scripting" (if
that.)

I recently tried to tell one of the Google Code developers that a very
simple page of theirs didn't work without script. They came up with
several ridiculous ways that you could possibly make it work
(including manually typing long-winded URI's into the address box.)
After failing to convince them that this was ridiculous, I mentioned
that you couldn't even navigate to the page in question without script
(due to the use of pseudo-links.) Their response was the usual tired
"argument" asking where my way-cool code repository site was.
Informed that they were clearly not qualified to develop Websites or
even engage in rational discussions on the subject, they deleted my
membership in the group. See no evil, hear no evil, etc.

 

[Dr J R Stockton]

Dr J R Stockton said the following on 12/16/2007 6:19 PM:

Please buy you some common sense as it is obvious you possess none.

See <http://www.chambersharrap.co.uk/chambers/features/chref/chref.py/ma
in?query=criteria&title=21st&sourceid=Mozilla-search>.

 

[Peter Michaux]

[snip]

And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".

Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)

Using the hash to make bookmark friendly URLs can be a very good user
experience, in my opinion. Technically there is a flaw that in some
browsers the page may reload. This is actually the case in some
versions of Safari. However I think the idea of using the hash this
way is great in a page like <URL: http://maps.yahoo.com> when dragging
the map around.

 

[David Mark]

[snip]

And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".

Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)

Using the hash to make bookmark friendly URLs can be a very good user

I disagree. It isn't what the hash is for and requires constant
polling of the window's location to keep navigation in sync.

experience, in my opinion. Technically there is a flaw that in some
browsers the page may reload. This is actually the case in some
versions of Safari. However I think the idea of using the hash this
way is great in a page like <URL:http://maps.yahoo.com> when dragging
the map around.

The state of a map image on a page isn't really a bookmark. It seems
counter-intuitive to use a bookmark to persist it. There are
certainly other options, especially for an Ajax app.

 

[David Mark]

Peter Michaux said the following on 12/18/2007 12:30 AM:







That was one of the issues that I spent a lot of time dealing with at
work was the ability for a user to return to where they were in a .js
file driven system. What we ended up with was a hidden form in every
.html file that kept track of what .js files were loaded, what data was
in what forms, any information needed to return it back to the state it
was in when the user wanted to bookmark it. There is a link in the upper
right corner of each page that is a "Bookmark" link that a user clicks

Right. You created your own interface, which makes more sense than
trying to force the browser's navigation system to handle persistence
within the pages.

on that submits the hidden form to the server. The server then saves the
information into a database and returns a page to the user with a URL
with a hash that is associated with the database entry. Since 99% of
what is done on the Intranet is time critical, no DB entry is left for
more than 30 days. It gets purged. On average, with 100,000+ terminals,
the DB has around 500,000 entries in it.

The #1 complaint the first thirty days after we implemented it? "That is
too much trouble".

Complaint from whom? The DB admins?

The #1 request after six months of using the system? "Can you do that
for websites as well?". Now, we are working on the same type of system
to run as part of the proxy system to insert the hidden form into any
website page for Favorites use.

And, Favorites is one of the sticking issues with converting the entire
company website to a .js file driven system. How well the proxy system
works will give me a pretty fair indication of well it will potentially
work on the website.

As for AJAX, I think the future of it depends on whether people keep
crutching it or finally realize that in order for it to work and give
the benefits that it can give. And in order to take maximum advantage of
the benefits you have to redesign and rethink the entire website
strategy from the ground up rather than trying to integrate the two
together. It is either an AJAX site or it isn't, there is no in between
with it.

If you want to eliminate all traditional page navigation (which seems
like a silly idea) then that is true. However, Ajax enhancements
(e.g. form validation, auto-suggestion, etc.) can be added easily
enough to standard sites.

 

[Peter Michaux]

[snip]

And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)

Using the hash to make bookmark friendly URLs can be a very good user

I disagree. It isn't what the hash is for

What is it for officially?

and requires constant
polling of the window's location to keep navigation in sync.

Yes it does. That is not so bad as it is an isolated bit of code with
a handler. I actually thought it was an appealing bit of code. It
would be better if there was a window.location.onchange handler,
however.

The state of a map image on a page isn't really a bookmark. It seems
counter-intuitive to use a bookmark to persist it.

It is great to be able to email someone a map at the right location.

There are
certainly other options, especially for an Ajax app.

I know that there can be a "get permalink" link but that really does
the same thing and could easily be missed by a user.

Having the URL represent the state of the page at any time seems very
intuitive to me.

Peter

 

[David Mark]

[snip]
And that is part of the problem with the current state of AJAX
applications. Just dumping code in and hoping it works just to be able
to say "Yeah, its an AJAX site. We know it is crap, it doesn't work
right in half the world, and it is grossly inefficient, but, IT'S AJAX!!".
Thanks to widespread abuse by incompetent developers, Ajax may be the
worst thing that ever happened to the Web. I particularly dislike
sites that use Ajax/innerHTML for page navigation. When the
developers of such sites find out that they broke the browser
navigation buttons, rather than seeing that they made a mistake, they
add bogus hashes and timers to compensate. Then they find out that
their inline scripts don't work, requiring additional insane
workarounds (as you are well aware.)
Using the hash to make bookmark friendly URLs can be a very good user

I disagree. It isn't what the hash is for

What is it for officially?

For navigating to bookmark anchors. These represent static locations
within documents, not scripted user customizations or states of Flash
movies.

Yes it does. That is not so bad as it is an isolated bit of code with
a handler. I actually thought it was an appealing bit of code. It
would be better if there was a window.location.onchange handler,
however.



It is great to be able to email someone a map at the right location.

Use the query portion of the URI, leaving the hash open to point to a
bookmark within the customized view of the document.

I know that there can be a "get permalink" link but that really does
the same thing and could easily be missed by a user.

I don't see what permalinks have to do with it, except that they
typically redirect to locations with hashes.

Having the URL represent the state of the page at any time seems very
intuitive to me.

Query yes, hash no.

 

[Peter Michaux]

As for AJAX, I think the future of it depends on whether people keep
crutching it or finally realize that in order for it to work and give
the benefits that it can give. And in order to take maximum advantage of
the benefits you have to redesign and rethink the entire website
strategy from the ground up rather than trying to integrate the two
together. It is either an AJAX site or it isn't, there is no in between
with it.

I think this is why Gmail uses a gateway script. They test the
browsers features to see if it can use the full-featured version of
Gmail. If the browser can't the user is sent to a primative version of
Gmail. Rather than worrying that each page in the site degrades
gracefully, the entire site degrades gracefully. (Disclaimer: I'm
writing about the concept of graceful site degradation with Gmail as
an example and not about the quality of the JavaScript used by Gmail.)

 

[Peter Michaux]

David Mark said the following on 12/18/2007 9:07 AM:

Auto-suggestion was something I looked at when Google first did it and
found it very annoying so I lost interest in it.

Yeah but I only know how to spell this much

"anna ko"

 

[David Mark]

I think this is why Gmail uses a gateway script. They test the
browsers features to see if it can use the full-featured version of
Gmail. If the browser can't the user is sent to a primative version of
Gmail. Rather than worrying that each page in the site degrades
gracefully, the entire site degrades gracefully. (Disclaimer: I'm
writing about the concept of graceful site degradation with Gmail as
an example and not about the quality of the JavaScript used by Gmail.)

Speaking of Google and graceful degradation (again), I set up an
AdSense account recently and what an adventure that was.

First there was the script error every time I clicked or focused a
form field. As I have debugging turned on, the resulting message
boxes ("style is not an object") made it impossible to complete the
form. So I turned off scripting (should have known better and turned
off debugging instead.) I made it all the way through a lengthy form,
hit submit and was presented with a page that mentioned something
about going forward, but only had a "back" button. (!) Switching to
FIreFox (and starting all over), I found that the "next" button was
generated by script. (!!)

You'd think that Google would at least use competent developers for
pages that are designed to bring in money. I guess they don't have
any.

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:

I think the specification is contradictory. Section 8.6.2 starts by
stressing the internal methods are "purely for expository purposes" and
that an "implementation of ECMAScript must behave as if it produced and
operate on internal properties..." then they are *clearly* implying that
the internals of the implementation can be coded any way the implementor
wishes to. Then to later say that "Every object (including host objects)
must implement [certain internal methods]" is a contradiction. My
interpretation is that the spec writers intended to write "Every object
(including host objects) must behave as though it implements [certain
internal properties and methods]". That is consistent with the beginning
of 8.6.2.

I don't see the contradiction. And to speculate about the intention of the
spec writers is pointless.

They need to behave as though the implement [[Get]].
That is a matter of interpretation.
No. Read the third sentence of 8.6.2.

Read 8.6.2 yourself, again. And this time you should read the most
recent revision.

I have 3rd ed December 1999.

"Final", the most recent revision of ECMA-262 Edition 3, is dated 2000-03-24
CE. It is available as PDF and MSWord 6.0 document from mozilla.org, maybe
for ECMA members via ftp.ecma.ch as mentioned at the end of the
specification, and can probably ordered as printed copy from ECMA, 114 Rue
du Rhône, CH-1204 Geneva, Switzerland (ibid).

I program for browsers and the code under discussion is for browsers.

It should be for all HTML UAs.

That is an engine that is non-compliant with ES3 or even trying to be
compliant with ES3. I'm not programming for those. Those go down the
degradation path. This is not a substantial loss given the proportion of
users with browsers that do not have try-catch. If you are programming
for implementations that are not ES3 compliant or at least trying to be
ES3 compliant then there is no use quoting from the ES3 spec.

I don't agree with your argumentation as it makes assumptions about the
use of HTML UAs that cannot be substantiated because there is never enough
representative evidence. I would like to coin that the Web Statistics Fallacy.

If it is old, unpopular, and unlikely to regain popularity then it is
relevant.

There is no coercive relation between the age of a UA and the features it
supports.

I think it can be expected to be supported. This is another "where to
draw the line" issues. In rare cases the try-catch will cause one syntax
error and the page will fall back to plain HTML.

You fail to provide proof for that assumption because it can never be
substantiated.

That is a sufficiently good user experience for rare users with browsers
that don't comply with an 8 year old standard.

I will not agree with a statement that says throwing error messages at users
that they do not understand and cannot necessarily do anything against that
would be OK. Especially not when that argument is made in favor of a code
library. If you keep arguing like that, you have an active opposer of your
project here, as it would employ and support bad coding practices.


PointedEars

 

[Peter Michaux]

Peter Michaux wrote:
[snip]

I think it can be expected to be supported. This is another "where to
draw the line" issues. In rare cases the try-catch will cause one syntax
error and the page will fall back to plain HTML.

You fail to provide proof for that assumption because it can never be
substantiated.

That is a sufficiently good user experience for rare users with browsers
that don't comply with an 8 year old standard.

I will not agree with a statement that says throwing error messages at users
that they do not understand and cannot necessarily do anything against that
would be OK.

So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?

 

[Thomas 'PointedEars' Lahn]

So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?

I have said where I draw the line: I won't test for `typeof' anymore because
that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
feature tests. Consequently, I draw the line at what JavaScript 1.1 and
JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.


PointedEars

 

[Peter Michaux]

Peter Michaux wrote:
[snip]

So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?

I have said where I draw the line: I won't test for `typeof' anymore because
that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
feature tests. Consequently, I draw the line at what JavaScript 1.1 and
JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.

We now know that your scripts will have syntax and runtime errors in
at least some known browsers as you assume some syntax and language
and host features (although you may start testing for all host
features). It seems that you are ok with this and presumably judge
your scripts to be of sufficient quality: perhaps even good and/or
professional quality. Perhaps you are satisfied with your decision
because the standards that must be supported to avoid the errors your
scripts will throw are old enough? Or the UAs known to have problems
are unpopular enough? or old enough? You've stated that UA age and
supported features are not necessarily related (you used the word
"coercive" and I don't quite see how that works but that is ok.) Given
you assume old syntax and features and criticised using try-catch as
it is new syntax, I don't know how you discard age from the decision
making process. How do you justify where you've drawn your line? What
makes this location a better place than where others draw their lines?
Do you believe you have made a better decision in some absolute or
objective sense?

I don't understand is how you can criticize someone for drawing a
different line for assumed/tested syntax/features for syntax/features
that have been standardized and widely implemented for many years and
even supported by legacy browsers released almost eight years ago. My
line and your line are both much further in the past than many other
developer's lines. We are all in a grey area but you seem convinced
you have made a superior choice and have justification to criticize
others almost as though they couldn't possibly have any brains at all
or even have considered the problem thoroughly given where they draw
their lines.

I suppose you could just say "I'm comfortable with my line being drawn
there" but that does not give you justification for criticizing others
who draw lines elsewhere. A more concrete foundation for your
criticism to be built upon would give your criticism more weight. As
it stands, your position can only be subjectively judged as better by
supporting some but not all very old, unpopular browsers or even
judged as worse as your resulting code is bigger.

 

[Thomas 'PointedEars' Lahn]

So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?

I have said where I draw the line: I won't test for `typeof' anymore because
that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
feature tests. Consequently, I draw the line at what JavaScript 1.1 and
JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.

We now know that your scripts will have syntax and runtime errors in
at least some known browsers

Given the conditions described above, that would be Netscape 2.0.

as you assume some syntax and language and host features (although you may
start testing for all host features).

It would appear that you are unable to make the difference between language
syntax features and features provided by the host environment.


PointedEars

 

[Peter Michaux]

Peter Michaux wrote:
So do you limit your syntax to the only the syntax valid in the very
first JavaScript enabled browser?
I have said where I draw the line: I won't test for `typeof' anymore because
that would involve evil[tm] eval() at no advantage -- `typeof' is needed for
feature tests. Consequently, I draw the line at what JavaScript 1.1 and
JScript 1.0 introduce, and what ECMAScript Edition 1 specifies.

We now know that your scripts will have syntax and runtime errors in
at least some known browsers

Given the conditions described above, that would be Netscape 2.0.

as you assume some syntax and language and host features (although you may
start testing for all host features).

It would appear that you are unable to make the difference between language
syntax features and features provided by the host environment.

I'm not sure why you would write that. I think I understand the
difference between language syntax, language features and host
features in the context we have been discussing them.

You've avoided all of my questions[1] about how you justify your
decisions about which syntax and features to assume even though they
will cause your scripts to throw errors. You criticized me for exactly
this[2]. This is the destination of our long conversation and a very
interesting piece of browser script design. Your avoidance can only
indicate your acknowledgment that you do not have an objectively
superior platform from which to make your criticisms of other's
decisions. You have an arbitrarily drawn a line (based on browser age
or unpopularity?) just like everyone else and your line may be
subjectively better or worse than other's lines. Given that you are in
the same boat as those you criticize, it follows that you have been
criticizing yourself quite harshly too.

[1] <URL: http://groups.google.com/group/comp.lang.javascript/msg/0198173dfa45d4fb>
[2] <URL: http://groups.google.com/group/comp.lang.javascript/msg/6895c0517d83bcac>