New FAQ Version for review

[Peter Michaux]

Hi Randy,

What do you propose updating it to? And, what is wrong with what is
there now?

It doesn't have semicolons at the ends of all the lines. I can't take
it! :S

Well maybe nothing wrong with it at all. In fact, it may work in more
browsers than with function literals. However it looks old and no one
bothers programming that way anymore, do they? Using the Function
constructor is leading in the direction of using eval where it is not
necessary.

I have no clue but I would guess that since the Function constructor
takes string arguments that it would parse the strings at run time and
be slower during execution than using a function literal which would be
parsed during compile time.

I don't know if the goal is to have getRef in the global space or not.
I doubt a closure is appropriate to this FAQ question so to keep it
looking simple for the FAQ maybe just this

var getRef,
dynWrite;

if (document.getElementById) {
getRef = function(id) {return document.getElementById(id);} ;
} else if (document.all) {
getRef = function(id) {return document.all(id);};
}

if (getRef) {
dynWrite = function(id, s) {getRef(id).innerHTML=s; return true;};
} else {
dynWrite = function() {return false;};
}

(Can't help it, I have to remove those uppercase function names.)

I know the repetition in defining getRef could be removed but perhaps
at the cost of clarity.

Given IE 5 has getElementById isn't it time to stop all of this
document.all stuff anyway and shove those browsers down the degredation
path with NS 4 like the current example has done. In which case the
entire example becomes

var dynWrite;
if (document.getElementById) {
dynWrite = function(id, s) {document.getElementById(id).innerHTML=s;
return true;}
} else {
dynWrite = function(){return false;}
}

This example still displays feature detection but assumes innerHTML
which is not in the character of c.l.j.

// first call to dynWrite initializes it
var dynWrite = function(id, s) {
var el;
if (document.getElementById &&
el = document.getElementById(id) &&
el.innerHTML) {
dynWrite = function(id, s) {
document.getElementById(id).innerHTML=s;
return true;
}
} else {
dynWrite = function() {return false;};
}
return dynWrite(id, s);
};

Ok maybe I've gone off the deep end but if c.l.j. regulars are going to
go on about feature detection then maybe this is the necessary version.

Almost except that it uses Math.random() in the code. IIRC it was
capitalized to prevent confusion with Math.random()

If lower case "random" is out then how about "chaos" or the more boring
"rand" for the function name? I really think that upper case function
names should be reserved for constructors. But hey, that's just me.

Could sections 4.25 and 4.39 should be close together or merged?

They are closely related but different. One deals with forms with []
characters in the name while the other deals with Bracket Notation in
general. Of which I have never agreed with terming it "illegal
characters" as [] are perfectly valid in HTML attributes. The problem
comes when trying to access them via script. But, it was agreed to the
wording with regards to being illegal.

The problem with merging them is historical links in the archives. Right
now I want to try to update what is there and get it live. Then it will
be time to try to go through this again with another layout/format after
there is an updated FAQ on-line.

Ok. I do think they should be close so I'll try to remember this one so
I can bring it up again and make sure the nice faq volunteer isn't
bored.

I have always thought it should mention it. The word "preload" nor
"pre-load" appear in the FAQ anywhere and typically when people ask
about that entry they are generally wanting to know how to preload
images. Whenever a preload entry has come up someone always beckons
about "It might not work in browser KYJ so don't do it".

The last line in that entry implies that headers are the only way to
overcome that problem and I have never seen a browser where preloading
them using new Image() didn't do the trick.

Personally, I think the whole entry needs to be retitled and re-written
as a "How do I preload images" entry along with the notes/links about
headers.

I imagine this will be revisited later.

I moved the code line there to a box of it's own. Even in the old
version it starts at the end of the paragraph.


Updated, as you have it. If you can find version numbers for the first
level of each browser that supports it I can add the version numbers to it.

Randy, I'm not worth trusting for information yet, am I? I'm still just
the new kid.

I just downloaded four versions of NN6 and the first version to support
my test XHR test was 6.2

The Apple website says Safari 1.2 is the first with XHR

If someone took the time to determine Opera 7.6 was the first Opera
with XHR I believe them.

I don't know a thing about Ice Weasle except the name is hilarious and
I might not be able to stop laughing if I was using it. Especially if I
could see the Ice Weasle logo.

Perhaps the following would be appropriate

Mozilla (Netscape Navigator 6.2+, Firefox), Opera 7.6+, Safari 1.2+,
the Windows version of Internet Explorer 5+, and some other browsers.


Peter

 

[Randy Webb]

Peter Michaux said the following on 11/29/2006 3:10 AM:

Hi Randy,


It doesn't have semicolons at the ends of all the lines. I can't take
it! :S

Ahhh, the semicolons...

Given IE 5 has getElementById isn't it time to stop all of this
document.all stuff anyway and shove those browsers down the degredation
path with NS 4 like the current example has done. In which case the
entire example becomes

If IE4 support is dropped then the entire entry answer becomes
document.getElementById(yourElementId).innerHTML = newHTML;

Does it not? And I didn't think IE4 needed to be covered even when NN4
was dropped and definitely don't think it should be included now. People
using IE4 now can't use 90% of the web anyway so not a lot in the FAQ is
of much use to them for any reason other than historical reasons.

Ok maybe I've gone off the deep end but if c.l.j. regulars are going to
go on about feature detection then maybe this is the necessary version.

if (document &&
document.getElementById &&
document.getElementById('someElement') &&
document.getElementById('someElement').innerHTML)
{
document.getElementById(someElement').innerHTML = "some HTML here"
}

If lower case "random" is out then how about "chaos" or the more boring
"rand" for the function name? I really think that upper case function
names should be reserved for constructors. But hey, that's just me.

It is so widely known that there isn't really any benefit in changing
it. Maybe randomNumber(x).

I imagine this will be revisited later.

Absolutely. Preloading seems to come up pretty often. Either directly or
indirectly but I don't recall seeing any one post and ask "Why are my
rollovers so slow?"

Randy, I'm not worth trusting for information yet, am I? I'm still just
the new kid.

If you are downloading and installing browsers then why would anybody
have a reason not to believe you until you give them a reason? I tend to
give people some benefit unless they are posting questions that can be
answered in 30 seconds in the archives, then I get my typically ranting
attitude.

I just downloaded four versions of NN6 and the first version to support
my test XHR test was 6.2

The Apple website says Safari 1.2 is the first with XHR

If someone took the time to determine Opera 7.6 was the first Opera
with XHR I believe them.

I don't know a thing about Ice Weasle except the name is hilarious and
I might not be able to stop laughing if I was using it. Especially if I
could see the Ice Weasle logo.

<URL: http://www.gnu.org/software/gnuzilla/>

He's kinda cute actually.....

Perhaps the following would be appropriate

Mozilla (Netscape Navigator 6.2+, Firefox), Opera 7.6+, Safari 1.2+,
the Windows version of Internet Explorer 5+, and some other browsers.

I left the name Ice Weasel in it because it's a Debian browser which is
a different OS but it's based on Mozilla. From what I have read about it
though, it is simply Firefox for the Debian Package with a different
name/logo.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/28/2006 7:43 AM:

It is added back but it didn't make a hill of beans to me so I removed
it. But, it's back in there now.


What has indicated that they aren't?

What has indicated that they are?

<shrug>

Do you have a proposed Notes page to add? If so, URL to it and it will
get reviewed, uploaded, and a link added to the Notes page.


The date, perhaps. But Author and Maintainer? The FAQ is for
information, not personal glorification.

An author should be prepared to put his name to his work, and to receive
comment both favourable and unfavourable.

What is so "jargonized" about the link and what is a proposed re-wording?


Why? There is already a TOC to the Notes.

Because we do not all have continuous access to the Net/Web, but those
of us who have sensibly chosen our News access method do, when using our
computers, have permanent access to the FAQ as posted to News.

I have seen nothing to indicate they aren't maintained.

I have seen nothing to indicate that they are.

Whatever.

Even the weakest knowledge of English grammar should suffice to tell
that the change is to an error. The plural noun requires a plural verb
form here. It is a change (in falsely-dated 9.0) from 8.1.

I won't have this argument with you again. It has been had in the past
and when it was had you simply ducked around the argument.

I don't recall arguing about whether parseInt("09") gives an error. It
gives Number 0, as is right and proper. The newsgroup regulars are in
general agreement, ISTM, that unary + is good.

There is nothing wrong with the Subject though.

Eh? "*The* Subject"? That is a general remark, applying to all entries
in S.4.

The present Subject of 4.12 is wrong in that no error is given (though
the result may not match what was wanted). For a complete response to
the "Why" one must state that the first character which cannot be part
of the number causes termination, so that "09" is treated as "0" which
is then read /* in octal */ and yields Number 0.

Proposed alternative?

If you cannot write, at full speed, a .Replace() using a RegExp to
reduce multiple embedded whitespace to a single space, then see any
tutorial on RegExps. The non-RegExp part of 4.16 is no longer worth
keeping.

BTW, the FAQ lacks a general RegExps section. Such a section should not
be long, but should refer to their great utility and provide a couple of
links. You should know where to look for a longer treatment.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

If IE4 support is dropped then the entire entry answer becomes
document.getElementById(yourElementId).innerHTML = newHTML;

Does it not? And I didn't think IE4 needed to be covered even when NN4
was dropped and definitely don't think it should be included now.
People using IE4 now can't use 90% of the web anyway so not a lot in
the FAQ is of much use to them for any reason other than historical
reasons.

Well, 99% of the Web is rubbish, blatantly commercial, or both. But, of
the rest, over 95% of what I wanted to see was accessible to IE4.

Those who write pages for use by impoverished organisations, maybe in
the Third World, may still want to support older systems.

And one must not fall into the same trap as a certain computer supplier,
whose Web site (including order-placing part) was only accessible to
those with computers too new to need replacing.

However, the code cited above lacks one advantage of DynWrite : it is,
wherever used, longer.

function DineRite(ID, HTML) {
document.getElementById(ID).innerHTML = HTML }

is the way to go, so that in the code one sees the job each time and not
the mechanism.

 

[Richard Cornford]

We cannot expect a Merkin to be able to understand English.

That would you depend on what you mean by "Murkin". My dictionary says;
"a hairpiece for the pubic area. [Origin uncertain]". If I had been
aware of their existence I would not have expected them to understand
English.

I do expect citizens of the United States to understand English. I may
yet be disappointed but those I have conversed with to date don't seem
to have any serious difficulty doing so.

By "One exception ..." ... "Another exception ..." you

Mike Winter wrote the wording for that version of that entry.

clearly suggested that at least one other exception was
possible or likely or certain.

Randy asserts that there are exactly three exceptions -
which is egg-on-his-face if anyone demonstrates another,

Any attempt to list all risks becoming extended. I seem to recall some
early Opera versions asking the user for permission to allow scripts to
access <input type="password"> fields (I don't know why as if
cross-domain scripting is properly excluded that should not be a
security issue).

But, you being a Failed FAQ writer, it ill behoves you to
criticise one who is at least trying.

<snip>

I was not criticising Randy. I was hoping he might ask for a second
opinion on his interpretation, as I suspect that the first 5 people he
asked would reveal a majority in favour of my interpretation.

Richard.

 

[Randy Webb]

Richard Cornford said the following on 11/29/2006 8:01 PM:

Dr J R Stockton wrote:


Mike Winter wrote the wording for that version of that entry.

The wording just seemed odd to me was all. Might have just been me
<shrug>. With a third exception being file inputs, would it be better to
change it to something like this:

Some exceptions would be:

Or, is the list sufficient enough to move it a Notes section?

 

[Randy Webb]

Dr J R Stockton said the following on 11/29/2006 6:51 PM:

In comp.lang.javascript message <[email protected]>,


Well, 99% of the Web is rubbish, blatantly commercial, or both. But, of
the rest, over 95% of what I wanted to see was accessible to IE4.

I said nothing about your personal browsing habits. I said they can't
use 90% of the web.

Those who write pages for use by impoverished organisations, maybe in
the Third World, may still want to support older systems.

Then let them search the archives or ask how to support an older system.
By that reasoning, the FAQ entry should cover NN4 as well......

However, the code cited above lacks one advantage of DynWrite : it is,
wherever used, longer.

function DineRite(ID, HTML) {
document.getElementById(ID).innerHTML = HTML }

is the way to go, so that in the code one sees the job each time and not
the mechanism.

That one is shorter but it suffers a flaw that my code dosen't.

 

[Randy Webb]

Dr J R Stockton said the following on 11/28/2006 3:01 PM:

In comp.lang.javascript message


We cannot expect a Merkin to be able to understand English.

By "One exception ..." ... "Another exception ..." you clearly suggested
that at least one other exception was possible or likely or certain.
Randy asserts that there are exactly three exceptions - which is
egg-on-his-face if anyone demonstrates another,

No. The entry doesn't say "The only three exceptions are.." It said
"Three exceptions are". I thought you would realize that but evidently
your hatred of anything American is clouding your judgement.

But, you being a Failed FAQ writer, it ill behoves you to criticise one
who is at least trying.

Richard is far from a "Failed FAQ writer". To date, Richard has written
approximately 10 kazillion times as much in the FAQ as you have. All I
have seen you do is post about once a week requesting something be added
yet I have seen only one or two posts where you actually offer any kind
of proposed entry. It is typically you just whining about nothing
getting done. Well, not a lot can get done when either Richard or myself
has to spend time weeding through your non-productive FAQ requests in
order to get something done. Maybe you should check the post from Peter
and use it as a guideline to future requests.

 

[Randy Webb]

Dr J R Stockton said the following on 11/29/2006 6:23 PM:

In comp.lang.javascript message <[email protected]>,


What has indicated that they are?

You are one of the most evasive people I have ever tried to have a
conversation with. The Notes section is maintained. There is nothing to
indicate they aren't. If you have some solid reasonable reason for
thinking they aren't then please state it. If you intend to continue to
be evasive about it then please drop it.

An author should be prepared to put his name to his work, and to receive
comment both favourable and unfavourable.

You don't need an author's name to comment about code. The only reason
for wanting a name is to critique the person. Second, any code in the
FAQ or Notes can't easily be changed by the person writing it. If there
is a problem with code in either the FAQ or the Notes then only three
people - to the best of my knowledge - have the ability and access to
change it. Directing comments to the author becomes moot. In short - I
am not inclined to go through and comment who wrote what code in the FAQ
or the Notes pages.

I won't comment on the wisdom of putting an FAQENTRY marker in a
conversation that is being conducted in a thread directly addressing
updating the FAQ and especially when the conversation is being conducted
with the person that would be reacting to that FAQENTRY request.

Because we do not all have continuous access to the Net/Web, but those
of us who have sensibly chosen our News access method do, when using our
computers, have permanent access to the FAQ as posted to News.

I am not going to change the TOC to the Notes to satisfy your wants and
desires based on you not being connected at all times. If you want "easy
access" to the Notes then do it the same way you have access to the FAQ.
Download the .zip file, unzip it, and you have total 100% access to them.

I don't recall arguing about whether parseInt("09") gives an error. It
gives Number 0, as is right and proper. The newsgroup regulars are in
general agreement, ISTM, that unary + is good.

Then what is your proposed re-wording of the Subject of 4.12?

Eh? "*The* Subject"? That is a general remark, applying to all entries
in S.4.

No it wasn't, but believe what you want.

If you cannot write, at full speed, a .Replace() using a RegExp to
reduce multiple embedded whitespace to a single space, then see any
tutorial on RegExps. The non-RegExp part of 4.16 is no longer worth
keeping.

Once again, you want something changed but you don't want to propose an
alternative?

 

[Dr J R Stockton]

In comp.lang.javascript message

In Section 4.22

The function name "Random" is capitalized which is usually reserved for
constructor functions. Perhaps this should be lower case

The featured code in the yellow box doesn't answer the section's title
question. The actual answer is added like an after thought.

gives a random number in the range 0..(x-1); Random(N)+1 for [1..N]

The range notation is not consistent in this sentence. I suggest the
use standard range notation: [1, N] and [1, N) or [1, N-1]

"Random" was chosen so as to be reminiscent of, but visually and
computationally distinct from, the "random" in
with (Math) X = random() ;
and to match the corresponding function in other languages.

The code shoes the recommended function, the basic one which is commonly
needed. The "actual answer" is not an afterthought; it is the
completion of the response.

One should not expect the target FAQ audience to know the "standard
range notation"; but the Subject could be changed to include "1 to N"
and the text similarly.

The argument of the function is given as "x" because it does not need to
be integer; in the text N is used, as non-integer is rare.

Query - Random(N) is often used where a return value of N would be
unacceptable. AIUI, some versions of Opera would sometimes return 1.0
from Math.random(). Does that occur often enough nowadays to justify
including the "%1" fix?

Ajax only has one capital letter. It may be an acronym but Ajax was
also a Greek God or something.

Ajax was a Greek Hero of the Trojan Wars. Or two heroes, to be more
accurate; there was also a Lesser Ajax. For that name, the form "Ajax"
is correct in English.

But "AJAX is shorthand for Asynchronous Javascript and XML" - it is,
like OTAN, an acronym and should be capitalised. ^ So, I think, should
that "and".

 

[Michael Winter]

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/28/2006 7:43 AM:

[snip]

I won't have this argument with you again. It has been had in the
past and when it was had you simply ducked around the argument.

I don't recall arguing about whether parseInt("09") gives an error.

That wasn't the argument.

It gives Number 0, as is right and proper.

No, it /may/ return zero. It may also return 9, which is correct, too.
Opera, for instance, returns the latter.

The argument began from (what I believe to be) the sensible conclusion
that the second, base argument should be passed to the function. Your
counterargument was that such an action prevents users from entering
hexadecimal numbers of the form 0xHH, which would otherwise receive
treatment as base-16 numbers.

A reasonable response, which I don't think was made, is that the rules
can be more rigorously defined than in ECMA-262 by testing the number
using a regular expression and varying the second argument based on the
results of that test:

parseInt(value, /^\s*0\d/.test(value) ? 8 : 0);

where value is some string. This allows for the same flexibility less
the ambiguity of step 11.

If octal is to be ignored and only decimal or hexadecimal is to be
accepted, then swap 8 for 10.

There are, of course, other approaches, including more explicit tests
using a regular expression, or getting unequivocal indication from the
user via other form controls.

[snip]

Mike


A lot seems to have happened whilst I've been absent...

 

[Elegie]

But, you being a Failed FAQ writer, it ill behoves you to criticise one
who is at least trying.

Your considering only recent events, by which Richard Cornford seemingly
did not update the FAQ entries, without even slightly taking into
account the tremendous work he has done in the past, makes this "Failed"
attribute extremely ungrateful and offensive.

As an occasional reader of this list, I have been very satisfied with
his work so far, with the FAQ document itself as well as with the FAQ
notes he has created and developed, which gather some of the best
javascript articles I have read on public data sources.

His not having the time or the will to maintain it anymore will not
change this: he was not paid for what appears to be a difficult and
time-consuming task, and yet successfully managed to bring invaluable
profit to C.L.J participants.

Randy, I thank you for being the next maintainer, and wish you good luck
with this tough quest.


<QUOTE FROM="FAQ">
The majority of regular posters here do so voluntarily in their free
time. They have good days and bad days just like everyone else.
</QUOTE>

Today's one of my bad day, probably. However... while it is in a way
motivating to see how passionate people have become about the FAQ, I
feel sad to notice that this FAQ subject is kind of able to so easily
dismiss good relationships and respect in participants' discussions.


Kind regards.

 

[Michael Winter]

Dr J R Stockton said the following on 11/28/2006 3:01 PM:
[snip]

Randy asserts that there are exactly three exceptions - which is
egg-on-his-face if anyone demonstrates another,

No. The entry doesn't say "The only three exceptions are.."

True, but to me (and apparently others), the word "only" merely adds
emphasis to what's otherwise a definite statement: "The three exceptions
are...". "The three" - it implies that there are no others.

It said "Three exceptions are".

It currently includes a preceding "the".

Something odd, though: you appear to argue, and I would agree, that
"Three exceptions are..." means "Here are three; there could be more".
Why doesn't that apply to my "One exception is..."?

So much over a couple of words...

Mike

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/29/2006 6:51 PM:

That one is shorter but it suffers a flaw that my code dosen't.

Then explain it. Don't attempt to demonstrate superiority by obscurity.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,

Your considering only recent events, by which Richard Cornford
seemingly did not update the FAQ entries, without even slightly taking
into account the tremendous work he has done in the past, makes this
"Failed" attribute extremely ungrateful and offensive.

It was intended to be so.

I don't recall how many versions he did produce, or at what intervals,
before his last one of 2005-11-05. IIRC, his final version was not
greatly different from the last version edited by Jim Ley, though he had
made some changes. His work up till then was satisfactory, but is past
history.

It is not clear whether he has been editing or adding to the Notes,
since they are undated.

But since then, in over a year, he has produced absolutely nothing, in
spite of there having been a continual flow of suggestions, of which at
least some were good. He has not even produced, AFAIK, a resignation.
That at least would have been constructive.

 

[Dr J R Stockton]

In comp.lang.javascript message

In comp.lang.javascript message <[email protected]>,

Dr J R Stockton said the following on 11/28/2006 7:43 AM:

[snip]

"4.12 Why does K = parseInt('09') set K to 0?
Function parseInt(S, B) accepts two arguments, string S and base
B; the first character (leading whitespace excepted) in S which
in that position cannot be part of a base-B number terminates
number reading.
If B is not given : S with leading "0x" or "0X" is read as
Hexadecimal, else S with leading "0" is read as Octal, otherwise
S is read as Decimal. Generally, it is better to use unary + : K
= +S ."
I won't have this argument with you again. It has been had in the
past and when it was had you simply ducked around the argument.

I don't recall arguing about whether parseInt("09") gives an error.

That wasn't the argument.

Precisely. Rem acu tetigisti. The previous discussion was just about
what parseInt *returns*. The first point of this one is that the
existing Subject line of 4.12 is badly chosen, since a correct answer to
it must start by saying that parseInt('09') does not give an error, but
returns 0 or 9.

To get a good FAQ entry, one must choose a well-asked question.
Convention is that a FAQ contributor can compose a question which
reflects what the questioners ought to have asked.


If the first code executed in a page is A then an error is given,
since A is undefined. Math.random(), sometimes, in some Opera, returns
(we are told) 1.0 - that number is in error, but no error is reported.
But parseInt never gives an error AFAICS; all it can do is return a
Number which is not that hoped for or expected or needed - but which
AFAIK is always compatible with ECMA.

No, it /may/ return zero. It may also return 9, which is correct, too.
Opera, for instance, returns the latter.

But under the Subject of the existing FAQ it probably does not return 9,
since an error is asserted by the Subject; and, under my suggested
Subject, above it certainly gives 0. I don't recall anyone asking why
it gives 9; that question is valid, but not frequent.

Nevertheless, if a FAQ description says what parseInt does, it should
certainly include both what ECMA requires or permits and what browsers
actually do.

The argument began from (what I believe to be) the sensible conclusion
that the second, base argument should be passed to the function. Your
counterargument was that such an action prevents users from entering
hexadecimal numbers of the form 0xHH, which would otherwise receive
treatment as base-16 numbers.

I disagree with your conclusion (as a FAQ recommendation) because it is
not always valid. As a general rule for the majority of commercial
applications, it holds - with a doubt whether there are any cases where
unary plus cannot be used *and* parseInt needs an explicit base 10.

Aside: parseInt needs explaining; but unary + needs recommending.

But the FAQ should not confine itself to commercial usage; without the
technical world, there would be much less commercial world, no
javascript, and so no FAQ.

A reasonable response, which I don't think was made, is that the rules
can be more rigorously defined than in ECMA-262 by testing the number
using a regular expression and varying the second argument based on the
results of that test:

parseInt(value, /^\s*0\d/.test(value) ? 8 : 0);

where value is some string. This allows for the same flexibility less
the ambiguity of step 11.

That may need developing to allow for signed numbers. /^\s*[-+]?0\d/
might suffice. Using (value, 8*/^\s*[-+]?0\d/.test(value) would be
cruel.

If octal is to be ignored and only decimal or hexadecimal is to be
accepted, then swap 8 for 10.

There are, of course, other approaches, including more explicit tests
using a regular expression, or getting unequivocal indication from the
user via other form controls.

ISTM that the latter is often best; the other controls can if
appropriate allow for parseInt(S) or parseInt(S, 0) to be used with the
user taking responsibility for providing a good string. After all,
no-one in their right mind would actually provide "09" and want it to be
treated as octal Zero, terminator 9.

It's a good idea to read the newsgroup and its old FAQ. See below.

 

[Randy Webb]

Michael Winter said the following on 11/30/2006 12:41 PM:

Dr J R Stockton said the following on 11/28/2006 3:01 PM:
[snip]

Randy asserts that there are exactly three exceptions - which is
egg-on-his-face if anyone demonstrates another,

No. The entry doesn't say "The only three exceptions are.."

True, but to me (and apparently others), the word "only" merely adds
emphasis to what's otherwise a definite statement: "The three exceptions
are...". "The three" - it implies that there are no others.

I can see that.

It currently includes a preceding "the".

Fair enough

Something odd, though: you appear to argue, and I would agree, that
"Three exceptions are..." means "Here are three; there could be more".
Why doesn't that apply to my "One exception is..."?

I guess it does

 

[Randy Webb]

Dr J R Stockton said the following on 11/30/2006 6:29 AM:

In comp.lang.javascript message

In Section 4.22

The function name "Random" is capitalized which is usually reserved for
constructor functions. Perhaps this should be lower case

The featured code in the yellow box doesn't answer the section's title
question. The actual answer is added like an after thought.

gives a random number in the range 0..(x-1); Random(N)+1 for [1..N]

The range notation is not consistent in this sentence. I suggest the
use standard range notation: [1, N] and [1, N) or [1, N-1]

"Random" was chosen so as to be reminiscent of, but visually and
computationally distinct from, the "random" in
with (Math) X = random() ;
and to match the corresponding function in other languages.

The code shoes the recommended function, the basic one which is commonly
needed. The "actual answer" is not an afterthought; it is the
completion of the response.

One should not expect the target FAQ audience to know the "standard
range notation"; but the Subject could be changed to include "1 to N"
and the text similarly.

Changed to this:

Question: How do I generate a random integer from 1 to N?

function Random(x) { return Math.floor(x*Math.random()) }
gives a random number in the range from 0 to x-1;
Random(N)+1 for 1 to N

The argument of the function is given as "x" because it does not need to
be integer; in the text N is used, as non-integer is rare.
Query - Random(N) is often used where a return value of N would be
unacceptable. AIUI, some versions of Opera would sometimes return 1.0
from Math.random(). Does that occur often enough nowadays to justify
including the "%1" fix?

Most Opera users use it by choice and seem to be pretty predictable
about updating it so I wouldn't think that Opera6 (IIRC it was 6) is
much of an issue anymore.

Ajax was a Greek Hero of the Trojan Wars. Or two heroes, to be more
accurate; there was also a Lesser Ajax. For that name, the form "Ajax"
is correct in English.

But "AJAX is shorthand for Asynchronous Javascript and XML" - it is,
like OTAN, an acronym and should be capitalised. ^ So, I think, should
that "and".

Corrected to read AJAX and with the "And" capitalized. I have always
referred to it, personally, as AJAX because it is an acronym. But, most
of the references/resources I checked it against refer to it as "Ajax"
<shrug>

 

[Randy Webb]

Dr J R Stockton said the following on 11/30/2006 3:29 PM:

In comp.lang.javascript message <[email protected]>,


Then explain it. Don't attempt to demonstrate superiority by obscurity.

Practice what you preach.

The only difference between your code and mine is that yours is wrapped
in a function and lacks any feature detection at all. Your claim was
that my code "was longer", and it is, for the reason of feature detection.

function DineRite(ID, HTML){
if (document &&
document.getElementById &&
document.getElementById(ID) &&
document.getElementById(ID).innerHTML)
{
document.getElementById(ID).innerHTML = HTML;
}
}

If the browser doesn't support getElementById, if the element doesn't
exist, or the browser doesn't support innerHTML then your version throws
an error. That is the flaw that your code suffers from that the code I
posted doesn't suffer from.

That brings up the question of what browser doesn't support it and the
only ones I know of are IE4, NN4 and previous browsers. Which kind of
makes it a moot point but the FAQ, as well as regulars here, stresses
using feature detection.

 

[Randy Webb]

Randy Webb said the following on 11/30/2006 8:58 PM:

Dr J R Stockton said the following on 11/30/2006 3:29 PM:


Practice what you preach.

The only difference between your code and mine is that yours is wrapped
in a function and lacks any feature detection at all. Your claim was
that my code "was longer", and it is, for the reason of feature detection.

function DineRite(ID, HTML){
if (document &&
document.getElementById &&
document.getElementById(ID) &&
document.getElementById(ID).innerHTML)
{
document.getElementById(ID).innerHTML = HTML;
}
}

If the browser doesn't support getElementById, if the element doesn't
exist, or the browser doesn't support innerHTML then your version throws
an error.

That is not entirely true as non-support for innerHTML but support for
the rest won't throw an error, it simply doesn't update the page. So a
semi-proper rewording might be "If the browser doesn't support gEBI or
the element doesn't exist then an error occurs".