New FAQ Version for review
Randy Webb
<URL: http://jibbering.com/faq/newfaq/>
The changes/modifications to date are:
2.3 Corrected "span" to "spam".
2.3 Updated with a note about not posting copyrighted material.
2.3 Removed paragraph about Google Groups.
2.3 Para 5 Added note about code being executable as transmitted.
2.4 Made an LI list of the answers.
2.7 Updated with a reference to the MS group for JScript.
3.1 Updated to include Fifth Edition.
3.2 (WSH) added to the .wsh newsgroup reference.
3.2 Added links to the MS Debugger and Documentation.
3.2 Updated to refer to microsoft.public.scripting.wsh rather than
Google Groups
4.4 Updated with new links on cookies.
4.6 Updated to refer to 4.7 Wording questionable?
4.9 Retitled "How do I find the size of the browser canvas area?"
4.13 Slightly reworded.
4.20 Updated to refer to the delay in setTimeout and setInterval
4.43 Updated to reflect the new location of the JS Console in Opera
5.1 Updated to request draft proposal for an FAQ Entry.
There are probably some changes I failed to notate when doing it. I
still have 24 more FAQENTRY requests to sort through and then the
discussions on the FAQ since Bart has been posting a section a day.
I think that 3.2 is getting sufficiently lengthy enough that it might
benefit from being moved to a page of it's own.
Thoughts and comments are welcome.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Richard Cornford
> There is an updated version of the FAQ at:
> <URL: http://jibbering.com/faq/newfaq/>
>
> The changes/modifications to date are:
> 4.9 Retitled "How do I find the size of the browser canvas area?"
I take it you did not buy Lee's justification that the question that
actually is frequently asked is about "window" size, even if the
information required, and the answers given, actually relate to client
area size?
> 4.13 Slightly reworded.
<snip>
I never thought that there was anything wrong with the wording of 4.13
as it was, but while you are enumerating situations where just reading -
contrl.value - is problematic don't <IINPUT type="file"> elements
qualify?
Richard.
Randy Webb
> Randy Webb wrote:
>> There is an updated version of the FAQ at:
>> <URL: http://jibbering.com/faq/newfaq/>
>>
>> The changes/modifications to date are:
> <snip>
>> 4.9 Retitled "How do I find the size of the browser canvas area?"
>
> I take it you did not buy Lee's justification that the question that
> actually is frequently asked is about "window" size, even if the
> information required, and the answers given, actually relate to client
> area size?
I can buy that justification, it is just a misleading title is all. It
is now reworded again:
"How do I find the size of the window/browser canvas area?"
With this note:
While it is often asked about window size, what is more relevant is the
"canvas area" of the browser.
>> 4.13 Slightly reworded.
> <snip>
>
> I never thought that there was anything wrong with the wording of 4.13
> as it was,
The wording, as it was, implied there was One exception, then it says
there is another exception. It was just misleading to me is all and if
it gets to where the way it is now is misleading, it can be changed back.
> but while you are enumerating situations where just reading -
> contrl.value - is problematic don't <IINPUT type="file"> elements
> qualify?
Sure it does, and there is now a small snippet there. I was going to
find a section of <URL:
http://www.jibbering.com/faq/faq_notes/form_access.html> that dealt with
File Inputs but it doesn't appear anywhere in that document.
I am pretty sure the wording of Third Exception leaves a lot to be
desired and is open to be changed again.
RobG
> There is an updated version of the FAQ at:
> <URL: http://jibbering.com/faq/newfaq/>
> Thoughts and comments are welcome.
Can you update the CSS? The current FAQ looks very, very dated. The
format of the "Javascript Best Practices" page is pretty good[1],
perhaps that (or something similar) can be adopted without too much
effort?
Maybe Matt would volunteer, if not, I'm happy to do it.
1. The text is set too small and the dashed borders are kitsch ;-),
otherwise it's simple, clean and reasonably modern.
--
Rob
Randy Webb
> Randy Webb wrote:
>> There is an updated version of the FAQ at:
>> <URL: http://jibbering.com/faq/newfaq/>
> [...]
>> Thoughts and comments are welcome.
>
> Can you update the CSS?
Sure can, its a work in progress :)
> The current FAQ looks very, very dated. The format of the "Javascript
> Best Practices" page is pretty good[1], perhaps that (or something
> similar) can be adopted without too much effort?
It would just be a matter of creating a file call faq.css and uploading it.
> Maybe Matt would volunteer, if not, I'm happy to do it.
Save the index.html and faq.css files locally, modify them and email
them to clj...@ctvea.net and I can upload it and get it reviewed.
<URL: http://jibbering.com/faq/newfaq/index.html>
<URL: http://jibbering.com/faq/newfaq/faq.css>
Randy Webb
There is a new upload there that reflects some changes based on Richards
thoughts, Evertjan's comma and a section 4.44 entitle "What is AJAX?"
Any thoughts, comments or corrections appreciated.
Bart Van der Donck
> Randy Webb said the following on 11/26/2006 5:39 PM:
> > There is an updated version of the FAQ at:
> > <URL: http://jibbering.com/faq/newfaq/>
>
> There is a new upload there that reflects some changes based on Richards
> thoughts, Evertjan's comma and a section 4.44 entitle "What is AJAX?"
>
> Any thoughts, comments or corrections appreciated.
Thanks for the good work !
--
Bart
Richard Cornford
> Richard Cornford said the following on 11/26/2006 6:51 PM:
>> Randy Webb wrote:
<snip>
>> I never thought that there was anything wrong with the
>> wording of 4.13 as it was,
>
> The wording, as it was, implied there was One exception,
> then it says there is another exception.
No it did not. It gave two examples of exceptions form an indefinite
set.
Richard.
Randy Webb
> Randy Webb wrote:
>> Richard Cornford said the following on 11/26/2006 6:51 PM:
>>> Randy Webb wrote:
> <snip>
>>> I never thought that there was anything wrong with the
>>> wording of 4.13 as it was,
>> The wording, as it was, implied there was One exception,
>> then it says there is another exception.
> <snip>
>
> No it did not.
Yes it did.
> It gave two examples of exceptions form an indefinite set.
The set of form elements and the ways of accessing them is not an
indefinite set, nor are the problems associated with it. So a subset of
a fixed set can't be an indefinite set.
Martin Honnen
> Randy Webb said the following on 11/26/2006 5:39 PM:
>> There is an updated version of the FAQ at:
>> <URL: http://jibbering.com/faq/newfaq/>
>
> There is a new upload there that reflects some changes based on Richards
> thoughts, Evertjan's comma and a section 4.44 entitle "What is AJAX?"
Nit on spelling in the AJAX explanation, the object is named
"XMLHttpRequest" and not "XMLHTTPRequest".
You could also add links to the Mozilla documentation
<http://developer.mozilla.org/en/docs/XMLHttpRequest>
and the IE documentation of the object
<http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/objects/obj_xmlhttprequest.asp>
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/xmlsdk/html/63409298-0516-437d-b5af-68368157eae3.asp>
--
Martin Honnen
http://JavaScript.FAQTs.com/
Randy Webb
Is it worth using the non-framed URL for the MSDN articles? It makes it
even longer for the FAQ:
I tried this one:
<URL:
http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_xmlhttprequest.asp>
And it takes you to the page but then MS automatically puts it back in
the frameset with the tree view :\
Martin Honnen
> Is it worth using the non-framed URL for the MSDN articles?
Hard to answer in general, I prefer having the toc tree on the left to
be able to navigate easily to e.g. objects/properties/methods. But I am
usually sitting in front of a desktop system with a large enough monitor
not to be hurt by frames taking up space. A laptop user might have other
preferences.
Dr J R Stockton
Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>There is an updated version of the FAQ at:
><URL: http://jibbering.com/faq/newfaq/>
It (unlike 8.1) lacks a clear statement as to who maintains it.
Also, it's not clear what the present status of the FAQ Notes is.
Are they still maintained?
Are they abandonware, (c) RC?
Are they detached parts of the FAQ, similarly maintained, (c)
newsgroup?
IMHO, each Note should be annotated with the name of its author, its
maintainer if different, and its date; the link to the index page should
be dejargonised and repeated at the top, and the Notes index page should
enlarge a little on such matters. The final link at the top of Notes
Index, to zipped Notes & FAQ, needs consideration.
<FAQENTRY>FAQ section 1, or thereabouts, should contain a link to each
individual Note, as a list.
</FAQENTRY>
If they are not now maintained, the FAQ should make that clear.
>4.20 Updated to refer to the delay in setTimeout and setInterval
The added sentence includes "generally". ISTM that, for the common case
where the requested delay is a multiple of the tick interval, IE6 in
WinXP does not do that; and if IE6 (so, probably, IE7?) does not do it,
can "generally" be right?
The delay is not *caused* by the difference.
"The delay ... may exceed ... (browsers differ)."
TIDY checker reports missing <li> in 4.29. Probably four are missing
(see issue 8.1, 4.29).
2.1 : Subject now ungrammatical.
4.12 Subject : but parseInt('09') does not give an error. It gives, as
it should, a Number of value 0.
"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 ."
N.B. When an entry's Subject is a question, the entry's body should
*always* explicitly answer that question. It should usually, but should
not only, present a solution to any implied problem. If necessary,
change the Subject.
4.16 How do I trim whitespace ...
String "aaa zzz" contains trimmable whitespace; but the entry ignores
that case. ASCII should read Unicode.
Count : "enviroment" 3, "environment" 1.
>I think that 3.2 is getting sufficiently lengthy enough that it might
>benefit from being moved to a page of it's own.
Can one have confidence in an author who, seemingly having lived for
many years in a nominally English-speaking country, and in spite of
frequently-presented examples in this newsgroup, still apparently
believes "it's" to be a genitive? Also FAQ 4.44.
It's a good idea to read the newsgroup and its old FAQ. See below.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
<URL:http://www.jibbering.com/faq/> Old RC FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
RobG
Randy Webb wrote:
> RobG said the following on 11/27/2006 12:20 AM:
> > Randy Webb wrote:
> >> There is an updated version of the FAQ at:
> >> <URL: http://jibbering.com/faq/newfaq/>
> > [...]
> >> Thoughts and comments are welcome.
> >
> > Can you update the CSS?
>
> Save the index.html and faq.css files locally, modify them and email
OK, done that.
Mac users (Safari users in particular) should change their monospace
font to Monaco 14pt, the default Courier (new) 13pt is way too small on
all browsers and monitors.
--
Rob
Peter Michaux
> There is an updated version of the FAQ at:
> <URL: http://jibbering.com/faq/newfaq/>
<snip>
> Thoughts and comments are welcome.
Below are a few.
Peter
------------
There seem to be two leading spaces at the start of each code example.
------------
In section 4.9
> When using IE6 with in CSS1Compat mode (with a Formal DOCTYPE)
Would this be clearer as the following?
When using IE6 with in CSS1Compat mode (i.e. with a Formal DOCTYPE)
------------
In section 4.13
> In HTML documents, named forms may be referred to as named properties of the document.forms collection
It seems to me that named forms are also available as properties of the
document object.
------------
In section 4.15
> Using the DOM and Microsoft's innerHTML extension
This could be interpreted as innerHTML is only available in IE. Could
"Microsoft's" be replaced with "the non-standard but widely
implemented"
The code example in this section seems to be for browsers without
function literals. To which browsers does this cater? Does this example
deserve updating?
------------
In Section 4.18
The last sentance in section 4.18 could be moved to 4.44
------------
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]
------------
Could sections 4.25 and 4.39 should be close together or merged?
------------
In Section 4.31
Could a mention of preloading images be added. Something like
(new Image()).src = "http://example.com/maui.gif"
If the image is served with correct headers when this JavaScript runs
then the first time the roll over is used it won't be slow, at least in
some browsers.
Perhaps mentioning that sliding images can be used instead like RobG (I
believe) mentioned within the last weeks.
------------
In Section 4.34
> Mozilla, Safari, and the Windows version of IE (and Opera 7.6+)
I think Opera deserves to be outside of parentheses. Something like
this with the correct version numbers. (I'll research the correct
numbers if someone doesnt know off the top of their more knowing head.)
Something more like this...
Mozilla (NN6+, Firefox, Ice Weasle etc), Opera 7.6+, Safari, the
Windows version of IE versions 5+, and some other browsers
------------
In Section 4.39
> There are two equivalent ways to access properties
I suggest the removal of the word equivalent
------------
In Section 4.43
The Firebug extension in Firefox is so valuable I think it is worth a
mention. Firebug is just going to version 1.0
------------
In Section 4.44
Ajax only has one capital letter. It may be an acronym but Ajax was
also a Greek God or something.
http://www.adaptivepath.com/publications/essays/archives/000385.php
Randy Webb
Check your email for an alternative email address. After checking it
from some other email addresses I don't think ctvea.net likes the file
attachments. It wouldn't even let me send myself an attachment. What a
service that is there!
RobG
Randy Webb wrote:
[...]
> Check your email for an alternative email address. After checking it
> from some other email addresses I don't think ctvea.net likes the file
> attachments. It wouldn't even let me send myself an attachment. What a
> service that is there!
Thanks, done that. I may not have properly attached the files.
--
Rob
Randy Webb
I am not sure it was you. I tried sending myself an email with an
attachment and the email went through but without the attachment. I have
to call them and find out what happened and why.
Randy Webb
> Randy Webb wrote:
>> There is an updated version of the FAQ at:
>> <URL: http://jibbering.com/faq/newfaq/>
>
> <snip>
>
>> Thoughts and comments are welcome.
>
> Below are a few.
>
> Peter
>
> ------------
>
> There seem to be two leading spaces at the start of each code example.
Fixed. I am not sure how it happened but the file that processes the XML
file was adding a leading space. The original has that leading space
added but I don't see it in the FAQ itself so not sure what is going on
with that one.
> ------------
>
> In section 4.9
>
>> When using IE6 with in CSS1Compat mode (with a Formal DOCTYPE)
>
> Would this be clearer as the following?
>
> When using IE6 with in CSS1Compat mode (i.e. with a Formal DOCTYPE)
Not sure but it is added.
> ------------
>
> In section 4.13
>
>> In HTML documents, named forms may be referred to as named properties of the document.forms collection
>
> It seems to me that named forms are also available as properties of the
> document object.
They are. But the FAQ was stressing using the FORMS collection.
> ------------
>
> In section 4.15
>
>> Using the DOM and Microsoft's innerHTML extension
>
> This could be interpreted as innerHTML is only available in IE. Could
> "Microsoft's" be replaced with "the non-standard but widely
> implemented"
Not sure why it was worded that way in the past, sure there was a reason
but it's modified. If there was a good reason that is still there now, I
am sure we will hear about it :)
> The code example in this section seems to be for browsers without
> function literals. To which browsers does this cater? Does this example
> deserve updating?
What do you propose updating it to? And, what is wrong with what is
there now?
> ------------
>
> In Section 4.18
>
> The last sentance in section 4.18 could be moved to 4.44
I'm not too sure that sentence should appear at all except in 4.44 so I
moved the last sentence, along with the link, to 4.44 as an alternative
to the XMLHttpRequest Object.
> ------------
>
> In Section 4.22
>
> The function name "Random" is capitalized which is usually reserved for
> constructor functions. Perhaps this should be lower case
Almost except that it uses Math.random() in the code. IIRC it was
capitalized to prevent confusion with Math.random()
> The featured code in the yellow box doesn't answer the section's title
> question. The actual answer is added like an after thought.
True :\
>> 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]
Modified.
> ------------
>
> 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.
> ------------
>
> In Section 4.31
>
> Could a mention of preloading images be added.
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.
> Something like
> (new Image()).src = "http://example.com/maui.gif"
>
> If the image is served with correct headers when this JavaScript runs
> then the first time the roll over is used it won't be slow, at least in
> some browsers.
>
> Perhaps mentioning that sliding images can be used instead like RobG (I
> believe) mentioned within the last weeks.
> ------------
>
> In Section 4.34
>
>> Mozilla, Safari, and the Windows version of IE (and Opera 7.6+)
>
> I think Opera deserves to be outside of parentheses. Something like
> this with the correct version numbers. (I'll research the correct
> numbers if someone doesnt know off the top of their more knowing head.)
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.
> Something more like this...
>
> Mozilla (NN6+, Firefox, Ice Weasle etc), Opera 7.6+, Safari, the
> Windows version of IE versions 5+, and some other browsers
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.
Section 4.38:
I added a link to <URL: http://www.ajaxtoolbox.com> and removed the link
to Laurents Java page. In this thread:
Laurent recommended against using it so it's removed.
> ------------
>
> In Section 4.39
>
>> There are two equivalent ways to access properties
>
> I suggest the removal of the word equivalent
Done. They have never been equivalent and never will :)
> ------------
>
> In Section 4.43
>
> The Firebug extension in Firefox is so valuable I think it is worth a
> mention. Firebug is just going to version 1.0
>
> http://www.getfirebug.com/
Added. It probably needs to be reworded but it is there.
> ------------
>
> In Section 4.44
>
> Ajax only has one capital letter. It may be an acronym but Ajax was
> also a Greek God or something.
>
> http://www.adaptivepath.com/publications/essays/archives/000385.php
Ajax has been so many things nobody is sure anymore :) But, it is changed.
Thank you.
Randy Webb
> In comp.lang.javascript message <37qdnY_T3df...@telcove.net>,
> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>> There is an updated version of the FAQ at:
>> <URL: http://jibbering.com/faq/newfaq/>
>
> It (unlike 8.1) lacks a clear statement as to who maintains it.
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.
> Also, it's not clear what the present status of the FAQ Notes is.
> Are they still maintained?
What has indicated that they aren't?
> Are they abandonware, (c) RC?
> Are they detached parts of the FAQ, similarly maintained, (c)
> newsgroup?
<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.
> IMHO, each Note should be annotated with the name of its author, its
> maintainer if different, and its date;
The date, perhaps. But Author and Maintainer? The FAQ is for
information, not personal glorification.
> the link to the index page should be dejargonised and repeated at the top,
> and the Notes index page should enlarge a little on such matters.
What is so "jargonized" about the link and what is a proposed re-wording?
> The final link at the top of Notes Index, to zipped Notes & FAQ, needs
> consideration.
> <FAQENTRY>FAQ section 1, or thereabouts, should contain a link to each
> individual Note, as a list.
> </FAQENTRY>
Why? There is already a TOC to the Notes.
> If they are not now maintained, the FAQ should make that clear.
I have seen nothing to indicate they aren't maintained.
>
>
>> 4.20 Updated to refer to the delay in setTimeout and setInterval
>
> The added sentence includes "generally". ISTM that, for the common case
> where the requested delay is a multiple of the tick interval, IE6 in
> WinXP does not do that; and if IE6 (so, probably, IE7?) does not do it,
> can "generally" be right?
>
> The delay is not *caused* by the difference.
>
> "The delay ... may exceed ... (browsers differ)."
>
>
> TIDY checker reports missing <li> in 4.29. Probably four are missing
> (see issue 8.1, 4.29).
Fixed the LI issue. It was the result of an errant search/replace.
>
> 2.1 : Subject now ungrammatical.
Whatever.
>
> 4.12 Subject : but parseInt('09') does not give an error. It gives, as
> it should, a Number of value 0.
> "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.
> N.B. When an entry's Subject is a question, the entry's body should
> *always* explicitly answer that question. It should usually, but should
> not only, present a solution to any implied problem. If necessary,
> change the Subject.
There is nothing wrong with the Subject though.
> 4.16 How do I trim whitespace ...
>
> String "aaa zzz" contains trimmable whitespace; but the entry ignores
> that case. ASCII should read Unicode.
Proposed alternative?
>
> Count : "enviroment" 3, "environment" 1.
>
>
>> I think that 3.2 is getting sufficiently lengthy enough that it might
>> benefit from being moved to a page of it's own.
>
> Can one have confidence in an author who, seemingly having lived for
> many years in a nominally English-speaking country, and in spite of
> frequently-presented examples in this newsgroup, still apparently
> believes "it's" to be a genitive? Also FAQ 4.44.
Mea bouws doun befoor yer majisty an beags fer fergiveness fer mi
transgreshuns.
NGFY
Peter Michaux
> > The code example in this section seems to be for browsers without
> > function literals. To which browsers does this cater? Does this example
> > deserve updating?
>
> 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.
:)
> > ------------
> >
> > In Section 4.22
> >
> > The function name "Random" is capitalized which is usually reserved for
> > constructor functions. Perhaps this should be lower case
>
> 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.
> > ------------
> >
> > In Section 4.31
> >
> > Could a mention of preloading images be added.
>
> 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.
> >> Mozilla, Safari, and the Windows version of IE (and Opera 7.6+)
> >
> > I think Opera deserves to be outside of parentheses. Something like
> > this with the correct version numbers. (I'll research the correct
> > numbers if someone doesnt know off the top of their more knowing head.)
>
> 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.
>
> > Something more like this...
> >
> > Mozilla (NN6+, Firefox, Ice Weasle etc), Opera 7.6+, Safari, the
> > Windows version of IE versions 5+, and some other browsers
>
> 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
> Hi Randy,
>
>>> The code example in this section seems to be for browsers without
>>> function literals. To which browsers does this cater? Does this example
>>> deserve updating?
>> 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
Ahhh, the semicolons... :)
<snip>
> 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"
}
>>> ------------
>>>
>>> In Section 4.22
>>>
>>> The function name "Random" is capitalized which is usually reserved for
>>> constructor functions. Perhaps this should be lower case
>> 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.
It is so widely known that there isn't really any benefit in changing
it. Maybe randomNumber(x).
<snip>
>>> ------------
>>>
>>> In Section 4.31
>>>
>>> Could a mention of preloading images be added.
>> 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.
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?"
>>>> Mozilla, Safari, and the Windows version of IE (and Opera 7.6+)
>>> I think Opera deserves to be outside of parentheses. Something like
>>> this with the correct version numbers. (I'll research the correct
>>> numbers if someone doesnt know off the top of their more knowing head.)
>> 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.
>>
>>> Something more like this...
>>>
>>> Mozilla (NN6+, Firefox, Ice Weasle etc), Opera 7.6+, Safari, the
>>> Windows version of IE versions 5+, and some other browsers
>> 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.
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
<ekftep$16q$1$8302...@news.demon.co.uk>, Mon, 27 Nov 2006 23:36:42,
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,
But, you being a Failed FAQ writer, it ill behoves you to criticise one
who is at least trying.
Dr J R Stockton
>Dr J R Stockton said the following on 11/28/2006 7:43 AM:
>> In comp.lang.javascript message <37qdnY_T3df...@telcove.net>,
>> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>>> There is an updated version of the FAQ at:
>>> <URL: http://jibbering.com/faq/newfaq/>
>> It (unlike 8.1) lacks a clear statement as to who maintains it.
>
>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.
>
>> Also, it's not clear what the present status of the FAQ Notes is.
>> Are they still maintained?
>
>What has indicated that they aren't?
What has indicated that they are?
>> Are they abandonware, (c) RC?
>> Are they detached parts of the FAQ, similarly maintained, (c)
>> newsgroup?
>
><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.
>
>> IMHO, each Note should be annotated with the name of its author, its
>> maintainer if different, and its date;
>
>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.
>> the link to the index page should be dejargonised and repeated at the
>>top, and the Notes index page should enlarge a little on such
>>matters.
>
>What is so "jargonized" about the link and what is a proposed re-wording?
>
>> The final link at the top of Notes Index, to zipped Notes & FAQ,
>>needs consideration.
>> <FAQENTRY>FAQ section 1, or thereabouts, should contain a link to each
>> individual Note, as a list.
>> </FAQENTRY>
>
>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.
>> If they are not now maintained, the FAQ should make that clear.
>
>I have seen nothing to indicate they aren't maintained.
I have seen nothing to indicate that they are.
>> 2.1 : Subject now ungrammatical.
>
>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.
>> 4.12 Subject : but parseInt('09') does not give an error. It gives,
>>as
>> it should, a Number of value 0.
>> "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. It
gives Number 0, as is right and proper. The newsgroup regulars are in
general agreement, ISTM, that unary + is good.
>> N.B. When an entry's Subject is a question, the entry's body should
>> *always* explicitly answer that question. It should usually, but should
>> not only, present a solution to any implied problem. If necessary,
>> change the Subject.
>
>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.
>> 4.16 How do I trim whitespace ...
>> String "aaa zzz" contains trimmable whitespace; but the entry
>>ignores
>> that case. ASCII should read Unicode.
>
>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.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt> RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ.
Dr J R Stockton
Wed, 29 Nov 2006 04:06:09, Randy Webb <HikksNo...@aol.com> wrote:
>
>> 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.
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.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borland.com ; but first read
Guidelines <URL:http://www.borland.com/newsgroups/guide.html> ff. with care.
Richard Cornford
> Richard Cornford wrote:
>>Randy Webb wrote:
>>> Richard Cornford said the following on 11/26/2006 6:51 PM:
>>>> Randy Webb wrote:
>><snip>
>>>> I never thought that there was anything wrong with the
>>>> wording of 4.13 as it was,
>>>
>>> The wording, as it was, implied there was One exception,
>>> then it says there is another exception.
>><snip>
>>
>> No it did not. It gave two examples of exceptions form an
>> indefinite set.
>
> 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
> Dr J R Stockton wrote:
<snip>
>> By "One exception ..." ... "Another exception ..." you
>
> 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
> In comp.lang.javascript message <pvCdnc-RhZk...@telcove.net>,
> Wed, 29 Nov 2006 04:06:09, Randy Webb <HikksNo...@aol.com> wrote:
>>> 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.
>
> 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
> In comp.lang.javascript message
> <ekftep$16q$1$8302...@news.demon.co.uk>, Mon, 27 Nov 2006 23:36:42,
> Richard Cornford <Ric...@litotes.demon.co.uk> wrote:
>> Randy Webb wrote:
>>> Richard Cornford said the following on 11/26/2006 6:51 PM:
>>>> Randy Webb wrote:
>> <snip>
>>>> I never thought that there was anything wrong with the
>>>> wording of 4.13 as it was,
>>>
>>> The wording, as it was, implied there was One exception,
>>> then it says there is another exception.
>> <snip>
>>
>> No it did not. It gave two examples of exceptions form an indefinite
>> set.
>
> 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
> In comp.lang.javascript message <H6idnd1cWKr...@telcove.net>,
> Wed, 29 Nov 2006 00:19:38, Randy Webb <HikksNo...@aol.com> wrote:
>> Dr J R Stockton said the following on 11/28/2006 7:43 AM:
>>> In comp.lang.javascript message <37qdnY_T3df...@telcove.net>,
>>> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>>>> There is an updated version of the FAQ at:
>>>> <URL: http://jibbering.com/faq/newfaq/>
>>> It (unlike 8.1) lacks a clear statement as to who maintains it.
>>
>> 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.
>>
>>> Also, it's not clear what the present status of the FAQ Notes is.
>>> Are they still maintained?
>>
>> What has indicated that they aren't?
>
> 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.
<snip>
>>> IMHO, each Note should be annotated with the name of its author, its
>>> maintainer if different, and its date;
>>
>> 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.
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.
>>> The final link at the top of Notes Index, to zipped Notes & FAQ,
>>> needs consideration.
>>> <FAQENTRY>FAQ section 1, or thereabouts, should contain a link to each
>>> individual Note, as a list.
>>> </FAQENTRY>
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.
>> 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 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.
>>> 4.12 Subject : but parseInt('09') does not give an error. It gives, as
>>> it should, a Number of value 0.
>>> "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. 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?
>>> N.B. When an entry's Subject is a question, the entry's body should
>>> *always* explicitly answer that question. It should usually, but should
>>> not only, present a solution to any implied problem. If necessary,
>>> change the Subject.
>>
>> There is nothing wrong with the Subject though.
>
> Eh? "*The* Subject"? That is a general remark, applying to all entries
> in S.4.
No it wasn't, but believe what you want.
>>> 4.16 How do I trim whitespace ...
>>> String "aaa zzz" contains trimmable whitespace; but the entry ignores
>>> that case. ASCII should read Unicode.
>>
>> 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.
Once again, you want something changed but you don't want to propose an
alternative?
Michael Winter
> Wed, 29 Nov 2006 00:19:38, Randy Webb <HikksNo...@aol.com> wrote:
>> 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.
> 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
<1164763720....@j72g2000cwa.googlegroups.com>, Tue, 28 Nov 2006
17:28:40, Peter Michaux <peterm...@gmail.com> wrote:
>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".
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
Randy Webb
> Randy Webb wrote:
>
>> 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 said "Three exceptions are".
>
> 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
> In comp.lang.javascript message
> <1164763720....@j72g2000cwa.googlegroups.com>, Tue, 28 Nov 2006
> 17:28:40, Peter Michaux <peterm...@gmail.com> wrote:
>
>> 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 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".
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
> It is a change (in falsely-dated 9.0) from 8.1.
With regards to the date, I am not changing the date on it every time I
update it.
The date that was put on it was a tentative date for trying to get it
updated to the point where it could be moved to replace the current FAQ.
If/When it gets moved, the date will be corrected. Until then, the date
there is irrelevant, is it not?
Dr J R Stockton
>Dr J R Stockton said the following on 11/29/2006 6:51 PM:
>> 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.
Then explain it. Don't attempt to demonstrate superiority by obscurity.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.
Dr J R Stockton
>Dr J R Stockton wrote:
>
>> 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.
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
<_dDbh.9408$k74....@text.news.blueyonder.co.uk>, Thu, 30 Nov 2006
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <H6idnd1cWKr...@telcove.net>,
>>Wed, 29 Nov 2006 00:19:38, Randy Webb <HikksNo...@aol.com> wrote:
>>> 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.
>> 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.
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
> In comp.lang.javascript message <7amdnQXDOcL...@telcove.net>,
> Thu, 30 Nov 2006 01:00:41, Randy Webb <HikksNo...@aol.com> wrote:
>> Dr J R Stockton said the following on 11/29/2006 6:51 PM:
>
>>> 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.
>
> 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
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".
Jim Ley
<HikksNo...@aol.com> wrote:
>Dr J R Stockton said the following on 11/30/2006 3:29 PM:
>
>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.
<div id="chicken">false</div>
...
Jim.
VK
Randy Webb wrote:
> I think that 3.2 is getting sufficiently lengthy enough that it might
> benefit from being moved to a page of it's own.
>
<http://www.jibbering.com/faq/#FAQ3_2>
I see no immediate need to move links onto a separate page, but I would
suggest to group links by logical sections and place them in some
"usability order". Say Netscape 4 documentation doesn't need to be the
second link from the top, right after "check it first".
<vk> ... </vk> marks my comments.
Javascript FAQ site, please check first:-
<http://javascript.faqts.com>
<vk>Does it really has to be the very first resource
for someone willing to learn JavaScript? That seems
more like a resource for advanced users
doing advanced scripting. IMHO anyway.</vk>
1. Browser producers documentation
Mozilla JavaScript 1.5 reference:-
<http://developer.mozilla.org/en/docs/JavaScript>
Mozilla DOM Reference:-
<http://www.mozilla.org/docs/dom/domref>
<vk>"Online Gecko DOM Reference" is confusing
in context of "Mozilla JavaScript 1.5 reference":
as if these are two different organizations.
"Mozilla" is more recognizable for a novice,
so should be preferred over "Gecko".</vk>
Download:-
<http://www.mozilla.org/docs/dom/domref.zip>
(817Kb, HTML format)
<vk>Size and format should be indicated for all downloads.</vk>
Microsoft JScript 5.6 reference and related resources:-
<http://msdn.microsoft.com/library/en-us/script56/html/1e9b3876-3d38-4fd8-8596-1bbfe2330aa9.asp>
<vk>The title is uniformed with the Mozilla resource above</vk>
<vk>Important!
The current link doesn't work for Internet Explorer: it randomly
reports "Page not found" and stays there or "Page not found" and
then 5 sec delay redirection to the correct location. The first
one
is simply bad, the second is very confusing for a novice.
The link was updated.</vk>
Download:
<http://www.microsoft.com/downloads/details.aspx?familyid=01592C48-207D-4BE1-8A76-1C4099D7BBB9>
(2.8Mb, Microsoft Windows .chm help file)
Microsoft DOM reference:-
<http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_entry.asp>
<vk>The title is uniformed with the Mozilla resource above</vk>
Opera JavaScript and DOM documentation:-
<http://www.opera.com/docs/specs/#ecmascript>
<http://www.opera.com/docs/specs/js/>
iCab InScript documentation:-
<http://www.muchsoft.com/inscript/>
<vk>Watch the corrected case for UA and script names</vk>
Safari Developer FAQ:-
<http://developer.apple.com/internet/safari/faq.html>
<vk>Added for your considerations</vk>
2. Standards and specifications
The official ECMAScript specification:-
<http://www.ecma-international.org/publications/standards/Ecma-262.htm>
Other versions of the ECMAScript specification:-
<http://www.mozilla.org/js/language/>
DOM Level 1 ECMAScript language binding
<http://www.w3.org/TR/REC-DOM-Level-1/ecma-script-language-binding.html>
DOM Level 2 ECMAScript language binding
<http://www.w3.org/TR/DOM-Level-2-HTML/ecma-script-binding.html>
<vk>Both items above re-named properly, also W3C typo corrected:
the relevant language is called "ECMAScript", not "ECMA script",
it is typed properly only in the 2nd document.</vk>
3. Other ECMAScript implementations
FESI - a free implementation of ECMAScript in Java:-
<http://www.lugrin.ch/fesi/index.html>
Whitebeam Apache Module - Server Side Javascript in Apache;-
<http://www.whitebeam.org>
Digital Mars DMD Script, console and MS Active Script implementation of
ECMAScript, claimed to be faster than other implementations:-
<http://www.digitalmars.com/dscript/>
4. Developer resources:-
Source code and tutorials:-
<http://www.w3schools.com/>
<vk>"DHTML" term is obsolete, moreover say XSLT is not "DHTML"</vk>
Frequently asked questions about source code obfuscation:-
<http://jibbering.com/faq/obfuscate.html>
<vk>It is already covered in FAQ 4.1, so I see no need
to repeat the same but in more words. I could be
safely removed and referenced instead in actual posts.</vk>
Sites discussing Active Server Pages:-
<http://www.15seconds.com/>
<http://www.4guysfromrolla.com/>
<http://www.aspfaq.com/>
<vk>The majority of ASP pages
being programmed in VBScript, not JScript.
This way a generic ASP sites are irrelevant
to ECMAScript. If they contain some JScript
specific sections then link them directly.
Respectively the link should be renamed to
something like "JScript in ASP".</vk>
Sites focused on using Scripting to automate Windows:-
<http://www.windows-script.com/>
<http://cwashington.netreach.net/>
<vk>Again: VBScript or JScript scripting?
Same considerations as for the item above</vk>
Microsoft's Windows Scripting Host (WSH) Newsgroup:-
<microsoft.public.scripting.wsh>
<vk>Again: VBScript or JScript scripting?
Same considerations as for the item above</vk>
Manipulating times, dates and the lastModified date and time in
javascript:-
<http://www.merlyn.demon.co.uk/js-dates.htm>
5. Developer tools
Venkman - Mozilla Visual JS debugger:-
<http://www.mozilla.org/projects/venkman/>
Microsoft Script Debugger Download:
<http://msdn.microsoft.com/downloads/list/webdev.asp>
<vk>This link is not valid and never was. I'm not
sure how did it slip in here. Simply remove it.
It could be replaced by two new items below:</vk>
Microsoft Script Debugger:-
<http://en.wikipedia.org/wiki/Microsoft_Script_Debugger>
Microsoft Visual Studio Express (free version):-
<http://msdn.microsoft.com/vstudio/express/vwd/>
6. Legacy resources
Netscape JavaScript 1.3 reference:-
http://docs.sun.com/source/816-6408-10/contents.htm
<vk>was: "Index of Netscape 4 JavaScript docs online
(These documents are no longer available form Netscape
but are still reproduced by Sun Microsystems, Inc.)"
The title is corrected and shortened.</vk>
Index of Archived Netscape 4 JavaScript docs online and for download:-
http://devedge-temp.mozilla.org/library/manuals/2000/javascript/1.3/reference/
<vk>I see no download links in there (?) Otherwise it is exactly what
the
above item is. IMHO only one should stay: and I suggest this one.
As there is not enough confusion between Java and JavaScript: why
add more by referencing JavaScript docs from sun.com?</vk>
Archived documentation for MSIE 3.x:-
http://members.tripod.com/~housten/download/
7. Browser download links
<vk>Suggested section to add</vk>
Randy Webb
I remember :) And that is why I replied to myself and corrected myself.
That wasn't the specific flaw that I had in mind though. If the browser
doesn't support getElementById then trying to use it results in a
visible JS error. If the element doesn't exist then trying to access
document.getElementById('incorrectID').property then it results in a JS
error.
I think what you are referring to is not knowing for sure that setting
the .innerHTML actually changes the .innerHTML of an element and any
code that uses .innerHTML is subject to that flaw :\
Dr J R Stockton
>Dr J R Stockton said the following on 11/29/2006 6:23 PM:
>
>> It is a change (in falsely-dated 9.0) from 8.1.
>
>With regards to the date, I am not changing the date on it every time I
>update it.
>
>The date that was put on it was a tentative date for trying to get it
>updated to the point where it could be moved to replace the current FAQ.
>If/When it gets moved, the date will be corrected. Until then, the date
>there is irrelevant, is it not?
No. If one looks again at NEWFAQ on the Web, one wants to know whether
there are any changes from last time. For those who feel no need to
look more than once a day - non-addicts - the date of editing would
serve nicely, since most people know the current date and most
interested know roughly when they last looked at the Web copy.
Changing the number would also serve.
Technical documents, of any form, should bear the identity of the
responsible person or organisation, and an indication of their age, to
an appropriate degree of accuracy.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6.
Web <URL:http://www.merlyn.demon.co.uk/> - w. FAQish topics, links, acronyms
PAS EXE etc : <URL:http://www.merlyn.demon.co.uk/programs/> - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.
Dr J R Stockton
Thu, 30 Nov 2006 16:50:36, Randy Webb <HikksNo...@aol.com> wrote:
>Dr J R Stockton said the following on 11/30/2006 6:29 AM:
>> In comp.lang.javascript message
>> <1164763720....@j72g2000cwa.googlegroups.com>, Tue, 28 Nov 2006
>> 17:28:40, Peter Michaux <peterm...@gmail.com> wrote:
>>
>>> In Section 4.22
>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
Completely adequate.
I'd insert "use" after the semi-colon, on aesthetic grounds.
Actually, the result is an integer, rather than a general Number, so I'd
put "random integer".
The upper limit is really Ceil(x-1) or Ceil(x)-1.
One should never want to write Random(0) or Random(1) in code; but in an
algorithm calls with those parameters may occur (well, at least the
second case occurs) and the return value is OK.
Random does not give good results for x < 0 (example : Random(-2)
matches -Random(2)-1 EXCEPT that it gives zero once per 2^K times where
K is probably 32, 53, or 64. So in a full description I'd include
(x>=0).
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
John G Harris
<HikksNo...@aol.com> writes
<snip>
>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
<snip>
Would you be willing to add 'inclusive', as in
gives a random number in the range from 0 to x-1 inclusive;
Then there is no doubt about the meaning.
Also, 'random number' should be 'random integer' to match the question.
John
--
John Harris
Randy Webb
> In comp.lang.javascript message <ptadnR_4qLP...@telcove.net>,
> Thu, 30 Nov 2006 16:59:44, Randy Webb <HikksNo...@aol.com> wrote:
>> Dr J R Stockton said the following on 11/29/2006 6:23 PM:
>>
>>> It is a change (in falsely-dated 9.0) from 8.1.
>>
>> With regards to the date, I am not changing the date on it every time
>> I update it.
>>
>> The date that was put on it was a tentative date for trying to get it
>> updated to the point where it could be moved to replace the current FAQ.
>> If/When it gets moved, the date will be corrected. Until then, the
>> date there is irrelevant, is it not?
>
>
> No. If one looks again at NEWFAQ on the Web, one wants to know whether
> there are any changes from last time. For those who feel no need to
> look more than once a day - non-addicts - the date of editing would
> serve nicely, since most people know the current date and most
> interested know roughly when they last looked at the Web copy.
OK, I will start changing it when I modify and upload it.
> Changing the number would also serve.
Would it be better then to re-number it to 8.2 or so and when it becomes
a final draft to go live with then change it to 9.0?
> Technical documents, of any form, should bear the identity of the
> responsible person or organisation, and an indication of their age, to
> an appropriate degree of accuracy.
Valid Point.
Randy Webb
> In comp.lang.javascript message <ptadnR34qLO...@telcove.net>,
> Thu, 30 Nov 2006 16:50:36, Randy Webb <HikksNo...@aol.com> wrote:
>> Dr J R Stockton said the following on 11/30/2006 6:29 AM:
>>> In comp.lang.javascript message
>>> <1164763720....@j72g2000cwa.googlegroups.com>, Tue, 28 Nov 2006
>>> 17:28:40, Peter Michaux <peterm...@gmail.com> wrote:
>>>
>>>> In Section 4.22
>
>> 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
>
> Completely adequate.
>
> I'd insert "use" after the semi-colon, on aesthetic grounds.
Added.
> Actually, the result is an integer, rather than a general Number, so I'd
> put "random integer".
Changed
> The upper limit is really Ceil(x-1) or Ceil(x)-1.
>
> One should never want to write Random(0) or Random(1) in code; but in an
> algorithm calls with those parameters may occur (well, at least the
> second case occurs) and the return value is OK.
Not sure I would agree with the return value being OK since this code:
<script type="text/javascript">
function Random(x) { return Math.floor(x*Math.random()) }
for (i=0;i<1000;i++) document.write(Random(1))
</script>
Prints out 1,000 zeros.
Yes, that is "OK" in that there are no errors but the return value is
pretty useless.
> Random does not give good results for x < 0 (example : Random(-2)
> matches -Random(2)-1 EXCEPT that it gives zero once per 2^K times where
> K is probably 32, 53, or 64. So in a full description I'd include
> (x>=0).
Since x=1 gives such useless results I added "where N>2".
Modified proposed entry:
How do I generate a random integer from 1 to N?
function Random(x) { return Math.floor(x*Math.random()) }
gives a random integer in the range from 0 to x-1 ; use
Random(N)+1 for 1 to N where N>2.
Do you have a page/anchor, or know of one, that deals with random
numbers where X<2 that I could add a link reference to the entry?
Randy Webb
> In article <ptadnR34qLO...@telcove.net>, Randy Webb
> <HikksNo...@aol.com> writes
>
> <snip>
>> 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
> <snip>
>
> Would you be willing to add 'inclusive', as in
>
> gives a random number in the range from 0 to x-1 inclusive;
Done.
> Then there is no doubt about the meaning.
>
> Also, 'random number' should be 'random integer' to match the question.
Done, JRS pointed it out also.
See my reply to John Stockton for a proposed modified entry there. The
proposed entry doesn't have inclusive in it but it is added in my local
copy to be uploaded.
Randy Webb
<snip>
> Modified proposed entry:
>
> How do I generate a random integer from 1 to N?
>
> function Random(x) { return Math.floor(x*Math.random()) }
> gives a random integer in the range from 0 to x-1 ; use
> Random(N)+1 for 1 to N where N>2.
Modified to say from "0 to x-1 inclusive".
Randy Webb
> Randy Webb wrote:
>> I think that 3.2 is getting sufficiently lengthy enough that it might
>> benefit from being moved to a page of it's own.
>>
>> Thoughts and comments are welcome.
>
> <http://www.jibbering.com/faq/#FAQ3_2>
>
> I see no immediate need to move links onto a separate page, but I would
> suggest to group links by logical sections and place them in some
> "usability order".
Yes, I tried making it an OL list and the file that creates the HTML
balked on it. When I have time I have to go through the process.wsf file
and find where it is balking and try to correct it. Making it an OL
would, as JRS suggested, make it easier to reference the links.
As for re-ordering them, absolutely. It would make it easier to keep the
separated and put like links together. As for what order, I will work on
that this weekend and try to get a new update posted.
Dr J R Stockton
>Dr J R Stockton said the following on 11/30/2006 3:29 PM:
>> In comp.lang.javascript message <7amdnQXDOcL...@telcove.net>,
>>Thu, 30 Nov 2006 01:00:41, Randy Webb <HikksNo...@aol.com> wrote:
>>> Dr J R Stockton said the following on 11/29/2006 6:51 PM:
>>
>>>> However, the code cited above lacks one advantage of DynWrite : it
>>>>
>>>> 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.
>> 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
That is the important difference. Don't confuse "way to go" with "final
solution.
It is IMPORTANT, for efficient work, that detailed code is not repeated
where it could be better put into a loop or a function. And if the
details are hidden away in a function the calling code is less
cluttered.
However long or short the meat of the section is, provided that it
exceeds about a third of a line and is used repeatedly, putting it into
a function is better. We see frequently in what is posted in the group
that the naive do not think of that.
>and lacks any feature detection at all. Your claim was that my code
>"was longer", and it is, for the reason of feature detection.
No. Your document.getElementById(ID).innerHTML = HTML; is longer
than my DineRite(ID, HTML). Feature detection makes it even longer
every time that it is written - so write it once.
>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.
And yours suffers the flaw that if a naive site writer copies it (and
the FAQ is aimed at naive users), then someone reading without
getElementById will have something not working without any indication.
Remember that in general the reader does not know exactly what to
expect.
With my short version the reader will at least know that the page is
incompatible with his browser.
function DineRite(ID, HTML) {
if (document &&
document.getElementById &&
document.getElementById(ID) &&
document.getElementById(ID).innerHTML)
{
document.getElementById(ID).innerHTML = HTML; else alert("OOps")
}
}
will show the writer how to give a warning.
In FAQ code, it is much better to put alerts where they might be wanted
(the FAQ reader can easily take them out) than to leave them out (the
FAQ reader may not see where they might be advisable).
If getElementById is not available, ISTM likely to be better to detect
it at the start of the page, and plan subsequent operation accordingly,
avoiding the circumstances leading to the DineRite call.
Feature detection is easy if it is a question of whether a method
exists, easy enough if it is a question of whether a method works
correctly AND one knows how it fails, and not at all easy (until one
knows how) for such as whether RegExp look-ahead works. I hope that the
relevant Notes section goes far enough.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
For news:borland.*, use their server newsgroups.borland.com ; but first read
Guidelines <URL:http://www.borland.com/newsgroups/guide.html> ff. with care.
VK
Dr J R Stockton wrote:
> than my DineRite(ID, HTML). Feature detection makes it even longer
> every time that it is written - so write it once.
May ask what browsers these "innerHTML support checks" are targeted to?
By the intensity of the discussion side readers may decide that this is
some crucial problem of the modern web-development :-): while this
problem is not practically relevant for several years already. If there
is a known web browser without innerHTML support produced over the last
say three years I'd like to know it.
If the aim is to cover NN3/IE3 as well (so excluding if(property in
object) boolean check) it could be:
<body onload="
for (var p in document.body) {
if (p == 'innerHTML') {
alert('has innerHTML');
}
}
">
But again: for what *current* purpose? And if getElementById and
innerHTML can be missing, why a bunch of other things are presumed as
"given no matter what"? Like Array constructor, Image, src attribute
support for script tag etc?
Randy Webb
<snip>
> Feature detection is easy if it is a question of whether a method
> exists, easy enough if it is a question of whether a method works
> correctly AND one knows how it fails, and not at all easy (until one
> knows how) for such as whether RegExp look-ahead works.
Feature detection is "easy enough"? OK, I want to know if createTextNode
works correctly in the browser. I know, quite well, how it fails in one
very widely used browser (IE). Yet, there is no feature detection test
to find out if it works correctly or not even though I know exactly how
it's going to fail (fatal error to the script). See the thread from the
last two days entitled "createTextNode and IE7" that was started by me
and you can see the issue. So no, feature detection is not always "easy
enough".
VK
Randy Webb wrote:
> Feature detection is "easy enough"? OK, I want to know if createTextNode
> works correctly in the browser. I know, quite well, how it fails in one
> very widely used browser (IE). Yet, there is no feature detection test
> to find out if it works correctly or not even though I know exactly how
> it's going to fail (fatal error to the script).
Purely in-script feature detection driven code is not possible in some
or many circumstances. That could be always possible only if all UA
producers either 1) don't implement a feature at all or 2) do implement
it uniformely strictly by publically available specs. Every time the
2nd happens I'm getting all nervious: because it's too good to be true
and usually means some especially big hidden sh** to explode :-) Lucky
it happens on expremely rare basis :-)
Is it bad? It *is*. Can we do something besides carefully studying each
UA of our interests? Not too much.
See also my recent discussion over SVG at
<http://groups.google.com/group/mozilla.dev.tech.svg/browse_frm/thread/92f3c6f392886f26>
Randy Webb
> Dr J R Stockton wrote:
>> No. Your document.getElementById(ID).innerHTML = HTML; is longer
>> than my DineRite(ID, HTML). Feature detection makes it even longer
>> every time that it is written - so write it once.
>
> May ask what browsers these "innerHTML support checks" are targeted to?
Any browser that doesn't support innerHTML <g>
The part of the post he quoted I was referring to the body of the
function of DynWrite and John, in his typically pedantic childish way,
chose to pedant that I hadn't wrapped it in a function call. Most of
that conversation was based on a philosophical issue of feature
detection but JRS totally missed it.
If DynWrite gets changed, it will be, almost verbatim:
function DynWrite(elemID,elemContent){
document.getElementById(elemID).innerHTML = elemContent;
}
Unless someone has a viable reason why it would be faulty in a modern
context.
Randy Webb
> Randy Webb wrote:
>> Feature detection is "easy enough"? OK, I want to know if createTextNode
>> works correctly in the browser. I know, quite well, how it fails in one
>> very widely used browser (IE). Yet, there is no feature detection test
>> to find out if it works correctly or not even though I know exactly how
>> it's going to fail (fatal error to the script).
>
> Purely in-script feature detection driven code is not possible in some
> or many circumstances.
Don't let John know that, he said it was "easy enough" and I know,
firsthand, better than that.
> That could be always possible only if all UA producers either 1)
> don't implement a feature at all or 2) do implement it uniformely
> strictly by publically available specs.
Or 3) implements it but barely and not in accordance with the specs.
Michael Winter
[snip]
> 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.
Agreed. Perhaps "Why doesn't parseInt('09') return what I expect?" would
be a better question.
[snip]
> I don't recall anyone asking why it gives 9; that question is valid,
> but not frequent.
Most people that encounter the issue have probably only tested in an
environment that chooses octal for leading zeros. To omit the return
value of 9 might suggest that such a value is in error.
> Nevertheless, if a FAQ description says what parseInt does, it should
> certainly include both what ECMA requires or permits and what browsers
> actually do.
An edit of the current entry:
The parseInt function decides what base the number is by
looking at the number. It assumes that any number beginning
with '0x' or '0X' is hexadecimal, but it has a choice with a
leading zero: the number can either be octal or decimal.
Assuming octal, the string '09' will be converted to 0 (octal
digits are 0-7); assuming decimal, '09' will be converted to 9
(the leading zero is ignored).
To force use of a particular radix, add a second parameter:
parseInt("09",10)
The Notes article would be a better location for more detail, if desired.
[MLW:]
>> 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.
Recommendations can be ignored when there is sufficient reason. They are
not requirements and there's no need to abandon judgement; the eval
function is evil, but not always.
> As a general rule for the majority of commercial applications, it
> holds
Which is why it's a good general recommendation. Someone with special
needs should have the sense to overlook it when they know better,
especially if the rationale for the recommendation is clear.
> - with a doubt whether there are any cases where unary plus cannot be
> used *and* parseInt needs an explicit base 10.
The radix need not be 10. For example, colour codes (#rrggbb) can begin
with a zero, but should be interpreted as hexadecimal. Using unary plus
would evaluate to NaN.
[snip]
[MLW:]
>> parseInt(value, /^\s*0\d/.test(value) ? 8 : 0);
[snip]
> That may need developing to allow for signed numbers. /^\s*[-+]?0\d/
> might suffice.
Quite. Sorry.
[snip]
Mike
Dr J R Stockton
>
>Would it be better then to re-number it to 8.2 or so and when it
>becomes a final draft to go live with then change it to 9.0?
Since it was said that the First Complete RW Version would be released
as 9.0 on 2006-12-01, I think I have to answer a definite Don't Know.
On second thoughts, no. The numbering sequence must increase
monotonically; consecutive releases of the same number are appropriate
only where the change is truly cosmetic (e.g. more tasteful shades of
similar colours done in the CSS).
But, starting from where I think we may be, I suggest using 10.0 for the
number of the first release for which you are fully responsible, with a
target date of Before 2007 and an actual date of whatever it is.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Dr J R Stockton
Fri, 1 Dec 2006 16:36:29, Randy Webb <HikksNo...@aol.com> wrote:
>Dr J R Stockton said the following on 12/1/2006 6:12 AM:
>> One should never want to write Random(0) or Random(1) in code; but
>>in an
>> algorithm calls with those parameters may occur (well, at least the
>> second case occurs) and the return value is OK.
If I were rewriting that, I think I'd omit the reference to Random(0).
One can choose an element from a set of 1 or more elements, but not from
an empty set.
>Not sure I would agree with the return value being OK since this code:
>
><script type="text/javascript">
>function Random(x) { return Math.floor(x*Math.random()) }
>
>for (i=0;i<1000;i++) document.write(Random(1))
></script>
>
>Prints out 1,000 zeros.
>
>Yes, that is "OK" in that there are no errors but the return value is
>pretty useless.
That's right. Each of those zeroes could have been chosen, at
equi-probable random, from a set of digits holding a single zero.
Remember that N factorial is generally considered as the product of all
integers from 1 to N, but 1!=1 then involves no multiplication and 0!=1
involves no integers. A broader definition is that (for N>=0) N! is "1
times all the integers from 1 or 2 to N in turn".
>> Random does not give good results for x < 0 (example : Random(-2)
>> matches -Random(2)-1 EXCEPT that it gives zero once per 2^K times where
>> K is probably 32, 53, or 64. So in a full description I'd include
>> (x>=0).
>
>Since x=1 gives such useless results I added "where N>2".
NO. In an algorithm similar to shuffling, where a sequence of N is
used, it may be desirable to include N=1 rather than to add code to
exclude it. There, "similar to" does not include "the same as".
The limits of validity given in a description of an algorithm should
include all cases in which it is correct, without regard to any
judgement of utility; otherwise, a reader may waste time/effort by
assuming that it is not valid outside the stated limits.
There is no need for " where N>2"
>Do you have a page/anchor, or know of one, that deals with random
>numbers where X<2 that I could add a link reference to the entry?
Offhand, no. In the cases I've looked at today, the coding has been
able to avoid using Random(1) without extra code.
It's always wise to allow extreme cases as a limit of non-extreme cases.
In Algol, IIRC, arrays are dynamically sized when the block containing
the declaration is executed. Ignoring syntax errors,
procedure X(N) ;
var A : array [1:N] ; J : integer ;
begin for J = 1 step 1 to N do A[J] := 0 ; end;
will work for integer N > 0; but the declaration will fail for N=0,
though the loop would execute perfectly, zero times. A corresponding
Javascript can handle an array of no elements.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.com/CompLangPascalDelphiMisc-MiniFAQ.htm> clpdmFAQ;
<URL:http://www.borland.com/newsgroups/guide.html> news:borland.* Guidelines
Randy Webb
<snip>
> An edit of the current entry:
>
> The parseInt function decides what base the number is by
> looking at the number. It assumes that any number beginning
> with '0x' or '0X' is hexadecimal, but it has a choice with a
> leading zero: the number can either be octal or decimal.
> Assuming octal, the string '09' will be converted to 0 (octal
> digits are 0-7); assuming decimal, '09' will be converted to 9
> (the leading zero is ignored).
> To force use of a particular radix, add a second parameter:
> parseInt("09",10)
>
> The Notes article would be a better location for more detail, if desired.
Changed.
Dr J R Stockton
Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>There is an updated version of the FAQ at:
><URL: http://jibbering.com/faq/newfaq/>
Re "comp.lang.javascript FAQ - 8.2 - 2006-12-01", collected at about
2006-12-02 20:15+-15 GMT.
Ugh!
The FAQ is fundamentally a plain-text document.
Contrary to both good manners and Disability legislation, you have
chosen to present it using YOUR choice of font face and size, whereas my
browser default is set to what suits me best. BTW, the Public Library
browsers default to much the same as mine.
You foist on me a SANS-SERIF font of REDUCED size.
I grant that it's often said that sans-serif is more legible on computer
screens; but, on a reasonably modern CRT screen (1998-2004, then
2004-date) I find that not to be so. It is MY computer; and in plain
running text you should not mess with MY fonts.
With my normal window width, 640 px - half-screen, there are too many
words per line for comfortable reading (consequence of both font face
and size). However, because the dirty pink code boxes are in Courier
(you correctly set monospace) and have whitespace on their left, some of
them extend to the right of the viewport.
The longest line in the pink box in 4.26 brings the right edge of the
box in alignment with the right margin of the text, near enough, with my
preferred viewport width. If others see similarly, I suggest that you
keep code lines below about 63 characters, where practical. (With
smaller body padding, I get 69 characters OK on my pages).
W3's HTML validator sneers : "This Page Is Tentatively Valid HTML 4.01
Transitional" and "No Character Encoding Found! Falling back to UTF-8."
Jim may be able to fix that at the server, or you in the page. Otherwise
it's happy.
W3's CSS validator claimed one error; but I don't see that its message
matches your CSS. It warns about specifying color without specifying
background-color; but you do seem to have set global background white.
AFAICS, the only useful part of the CSS is that which colours and
borders the boxes. The index should use <li> not <H5> and is the only
other part that looks wrong without CSS.
--
(c) John Stockton, Surrey, UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Why does NASA JSC think Dunfermline is in England?
It's learned recently that Gibraltar is not.
Dr J R Stockton
<7Lich.10536$k74....@text.news.blueyonder.co.uk>, Sat, 2 Dec 2006
>Dr J R Stockton wrote:
>An edit of the current entry:
>
> The parseInt function decides what base the number is by
> looking at the number. It assumes that any number beginning
> with '0x' or '0X' is hexadecimal, but it has a choice with a
> leading zero: the number can either be octal or decimal.
Good, but maybe slightly improvable without significant expansion. The
function has no choice; the choice was made by its authors. Maybe :
"... hexadecimal; otherwise, a string with a leading zero may be read as
either octal or decimal."
The input to parseInt should be referred to as a string or String; it is
not a number.
In fact, as "number" is used to mean "decimal digit" and "integer" and
"real number", it's probably best to use it as little as possible (and
to save "Number" for the meaning in Javascript).
> Assuming octal, the string '09' will be converted to 0 (octal
> digits are 0-7); assuming decimal, '09' will be converted to 9
> (the leading zero is ignored).
> To force use of a particular radix, add a second parameter:
> parseInt("09",10)
>
>The Notes article would be a better location for more detail, if desired.
>> As a general rule for the majority of commercial applications, it
>> holds
>
>Which is why it's a good general recommendation. Someone with special
>needs should have the sense to overlook it when they know better,
>especially if the rationale for the recommendation is clear.
That is why it's better to have, instead of "should be passed", "should
(usually/normally/generally) be passed".
>> - with a doubt whether there are any cases where unary plus cannot be
>> used *and* parseInt needs an explicit base 10.
>
>The radix need not be 10. For example, colour codes (#rrggbb) can begin
>with a zero, but should be interpreted as hexadecimal. Using unary plus
>would evaluate to NaN.
Agreed; but note the *and*. Unary + can never be used if parseInt would
need an explicit base other than 10. In that case unary + cannot be
used but parseInt needs an explicit base 16.
But Hue = parseInt(ColourCode.replace(/#/, "0X")) // *could* be used
Hue = parseInt(ColourCode.substr(1), 16) // shorter
Reading a ColourCode #abc to decimal can be done by
Hue = parseInt(ColourCode.replace(/#(\w)(\w)(\w)/, "0X$1$1$2$2$3$3"))
FAQ 8.2 - 2006-12-01 - 4.12 omits the useful point that any invalid
character terminates the number (which is why parseInt is useful when
reading properties given as a string matching /^\d+px$/).
If "To force use of base 10 add a second parameter parseInt("09",10)"
were changed to "To force use of a particular base, add a second
parameter parseInt("09", base)". That's only a little longer, answers
the case of base 10, and generalises it.
--
Dr J R Stockton
Fri, 1 Dec 2006 20:18:20, Randy Webb <HikksNo...@aol.com> wrote:
>The part of the post he quoted I was referring to the body of the
>function of DynWrite and John, in his typically pedantic childish way,
>chose to pedant that I hadn't wrapped it in a function call. Most of
>that conversation was based on a philosophical issue of feature
>detection but JRS totally missed it.
No; at that time I had nothing to add about feature detection, so I
added nothing about it. Instead, I addressed what you had omitted.
Proper modularisation of code is IMPORTANT, and a FAQ should never set a
bad example.
>If DynWrite gets changed, it will be, almost verbatim:
>
>function DynWrite(elemID,elemContent){
>document.getElementById(elemID).innerHTML = elemContent;
>}
There'd be something to be said for changing the function identifier
slightly, to make it easier to refer to both the new and the old.
IMHO, where space permits, every token-separator-comma should be
followed by whitespace; and every statement-terminator-semicolon & many
for-parentheses-semicolons should be surrounded by whitespace. The
Javascript engine will not care, but the script will be more legible.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
Dr J R Stockton
Fri, 1 Dec 2006 20:04:11, Randy Webb <HikksNo...@aol.com> wrote:
>Dr J R Stockton said the following on 12/1/2006 4:32 PM:
>
><snip>
>
>> Feature detection is easy if it is a question of whether a method
>>exists, easy enough if it is a question of whether a method works
>>correctly AND one knows how it fails, and not at all easy (until one
>>knows how) for such as whether RegExp look-ahead works.
>
>Feature detection is "easy enough"? OK, I want to know if
>createTextNode works correctly in the browser. I know, quite well, how
>it fails in one very widely used browser (IE). Yet, there is no feature
>detection test to find out if it works correctly or not even though I
>know exactly how it's going to fail (fatal error to the script). See
>the thread from the last two days entitled "createTextNode and IE7"
>that was started by me and you can see the issue. So no, feature
>detection is not always "easy enough".
That confirms once more that a FAQ writer really does need to be able to
read English. Thomas would not have doubted.
You have responded to the first four words without considering the
influence of the following "if". The sentence refers to three cases,
indicated by "if ...", "if ...", and "for ...". It does not imply that
only three cases are possible.
In IE4, the code testRe = new RegExp("a??") was, I think, a
fatal script error. But if window.onerror had been set to a function
just returning true, then the code was a no-op. Thus *that* error can,
in IE4, be caught and so detected.
It was implied that one can do similarly with "all" browsers. Perhaps
one can do similarly for "createTextNode ... (fatal error to the
script)"?
For that technique, search the javascript newsgroups, for some while
back, for "window.onerror" (AFAIR, it occurs infrequently) or see
<URL:http://www.merlyn.demon.co.uk/js-valid.htm#RFT>.
The singular of "criteria" is "criterion".
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 IE 6
<URL:http://www.jibbering.com/faq/> Old RC FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
Jim Ley
<repl...@merlyn.demon.co.uk> wrote:
>W3's HTML validator sneers : "This Page Is Tentatively Valid HTML 4.01
>Transitional" and "No Character Encoding Found! Falling back to UTF-8."
>Jim may be able to fix that at the server, or you in the page. Otherwise
>it's happy.
This is 'cos it's in newfaq, once index.html was in faq/ it would've
just magically worked.
>W3's CSS validator claimed one error; but I don't see that its message
>matches your CSS. It warns about specifying color without specifying
>background-color; but you do seem to have set global background white.
CSS "validator" rightly believes that the background colour needs to
be set anywhere the foreground is set (in case a user stylesheet
overrides the background of that element.
It's not a realistic worry though, indeed almost certainly bogus.
I agree about the 90% as default size btw.
Jim.
Randy Webb
The entire .css file there is one that RobG did that I put up and forgot
to post the change to get feedback on it. It is now back to where it
started as far as CSS is concerned.
RobG
> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
> >There is an updated version of the FAQ at:
> ><URL: http://jibbering.com/faq/newfaq/>
>
> Re "comp.lang.javascript FAQ - 8.2 - 2006-12-01", collected at about
> 2006-12-02 20:15+-15 GMT.
>
> Ugh!
Pretty much what I think every time I visit the current FAQ.
> The FAQ is fundamentally a plain-text document.
And it remains so. The different appearance, other than sections of
lists that were changed to ul and li elements, was achieved with small
modifications to the existing CSS.
>
> Contrary to both good manners and Disability legislation, you have
> chosen to present it using YOUR choice of font face and size, whereas my
> browser default is set to what suits me best. BTW, the Public Library
> browsers default to much the same as mine.
Don't blame Randy, it was my suggestion. My intention was to give the
FAQ a more contemporary appearance, one that does not look like it came
from 1995.
The choice of sans-serif font is in keeping with the vast majority of
web sites. If you don't like sans-serif fonts, by all means make your
position known but to claim specifying such in a CSS file is "bad
manners" is absurd. It is no more bad manners than the default setting
of browsers that "enforce" a serif font.
The claim that the suggestion of a sans-serif font in a CSS file is
contrary to legislation is news to me - please explain.
>
> You foist on me a SANS-SERIF font of REDUCED size.
It is also common to reduce the size of the default font, many sites
set 80% or even 75%. Users are used to seeing fonts of that size and
often set their default font expecting a reduced size in the page (the
default font for Mozilla browsers is 16pt, when most printed fonts are
10 to 12pt). I chose 90% as a happy medium - fonts will still present
larger than in the vast majority of web pages.
What do others think?
> I grant that it's often said that sans-serif is more legible on computer
> screens; but, on a reasonably modern CRT screen (1998-2004, then
> 2004-date) I find that not to be so. It is MY computer; and in plain
> running text you should not mess with MY fonts.
OK, so you vote against sans-serif fonts.
Note that you are free to use whatever font you like through your
default CSS file, you also have the ability to set a minimum font size.
>
> With my normal window width, 640 px - half-screen, there are too many
> words per line for comfortable reading (consequence of both font face
> and size).
I think only a very few users are surfing the web with a window set to
320px. Are you seriously suggesting the FAQ be optimised for that?
> However, because the dirty pink code boxes are in Courier
> (you correctly set monospace) and have whitespace on their left, some of
> them extend to the right of the viewport.
The "dirty pink" is a compromise. The original yellow is
uncomfortable, I was looking for something easier to look at. The
styles were tested on a number of computers, screens, browsers and
operating systems, the differences in appearance were dramatic - what
looks a gaudy puce on one screen is a bland maroon on another.
Please suggest alternative colours.
>
> The longest line in the pink box in 4.26 brings the right edge of the
> box in alignment with the right margin of the text, near enough, with my
> preferred viewport width. If others see similarly, I suggest that you
> keep code lines below about 63 characters, where practical. (With
> smaller body padding, I get 69 characters OK on my pages).
4.37 has a longer line, your (apparently preferred) larger fonts will
exacerbate the situation. It is a convention to indent blocks of
quoted or special text (such as code examples) and therefore it is
appropriate to do so in the FAQ. The overrun is a consequence of your
narrow window width; I think it is unreasonable to expect the FAQ to be
tailored to suit that at the expense of a more conventional layout.
--
Rob
John G Harris
Stockton <repl...@merlyn.demon.co.uk> writes
<snip>
>But since then, in over a year, he has produced absolutely nothing,
<snip>
Isn't it time that the mistakes in js-other concerning identifiers and
semicolons were corrected ?
John
--
John Harris
Randy Webb
> Dr J R Stockton wrote:
>> In comp.lang.javascript message <37qdnY_T3df...@telcove.net>,
>> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>>> There is an updated version of the FAQ at:
>>> <URL: http://jibbering.com/faq/newfaq/>
>> Re "comp.lang.javascript FAQ - 8.2 - 2006-12-01", collected at about
>> 2006-12-02 20:15+-15 GMT.
>>
>> Ugh!
>
> Pretty much what I think every time I visit the current FAQ.
>
>> The FAQ is fundamentally a plain-text document.
>
> And it remains so. The different appearance, other than sections of
> lists that were changed to ul and li elements, was achieved with small
> modifications to the existing CSS.
What was being seen was your CSS with the current FAQ layout. I know you
changed some of the layout but I can't do that - for now - with the way
the FAQ is generated. It is coded in an .xml file
(http://jibbering.com/faq/newfaq/index.sml) which is then processed by
http://jibbering.com/faq/newfaq/process.wsf) which creates the HTML file
on the fly. The XML file is so that the daily/weekly postings of the FAQ
and snippets could be easily done in text by reading the XML file. To
changes the layout means changing the process.wsf file to create it that
way. I tried making 3.2 an LI and it didn't work. I have to figure out
where a case: "LI" goes in the process.wsf file to create the lists out
of the links (or anywhere else).
Meaning, for now, you are stuck with the HTML itself until I can change
it. You can only modify what is there now with different definitions.
Dr J R Stockton
<1165152144.0...@80g2000cwy.googlegroups.com>, Sun, 3 Dec 2006
05:22:24, RobG <rg...@iinet.net.au> wrote:
>Dr J R Stockton wrote:
>> In comp.lang.javascript message <37qdnY_T3df...@telcove.net>,
>> Sun, 26 Nov 2006 17:39:09, Randy Webb <HikksNo...@aol.com> wrote:
>> >There is an updated version of the FAQ at:
>> ><URL: http://jibbering.com/faq/newfaq/>
>>
>> Re "comp.lang.javascript FAQ - 8.2 - 2006-12-01", collected at about
>> 2006-12-02 20:15+-15 GMT.
>>
>> Ugh!
>
>Pretty much what I think every time I visit the current FAQ.
>
>> The FAQ is fundamentally a plain-text document.
>
>And it remains so.
That's implied by "is".
> The different appearance, other than sections of
>lists that were changed to ul and li elements, was achieved with small
>modifications to the existing CSS.
The FAQ as seen, to all who have not overridden what it sets, is the
result of both the HTML and the CSS that are served from jibbering. The
history is unimportant, except where it shows that a change is a
mistake.
>> Contrary to both good manners and Disability legislation, you have
>> chosen to present it using YOUR choice of font face and size, whereas my
>> browser default is set to what suits me best. BTW, the Public Library
>> browsers default to much the same as mine.
>
>Don't blame Randy, it was my suggestion. My intention was to give the
>FAQ a more contemporary appearance, one that does not look like it came
>from 1995.
Randy is responsible for the FAQ, and that responsibility includes
accepting good ideas and rejecting bad ones.
<URL:http://www.merlyn.demon.co.uk/quotings.htm#Alfonso>
>The choice of sans-serif font is in keeping with the vast majority of
>web sites.
One should do what is right, not just follow the fashion set by others.
> If you don't like sans-serif fonts, by all means make your
>position known but to claim specifying such in a CSS file is "bad
>manners" is absurd. It is no more bad manners than the default setting
>of browsers that "enforce" a serif font.
A browser MUST have a default font, if it is to work "out of the box". A
Web page and/or CSS file do not need to change that setting.
>The claim that the suggestion of a sans-serif font in a CSS file is
>contrary to legislation is news to me - please explain.
Enforcing a setting for ordinary text other than that preferred by the
user is contrary certainly to the spirit of disability discrimination
legislation. Granted the legislation may not actually apply - but
should one ignore the visually disabled just because the law applies
only to other sites or to other countries?
>OK, so you vote against sans-serif fonts.
No: against overriding my settings.
>Note that you are free to use whatever font you like through your
>default CSS file, you also have the ability to set a minimum font size.
At many client sites, the individual users cannot personalise
preferences. They should not need to do so.
And I don't want to make a CSS file that will improve what I see for the
FAQ page and thereby alter what I see on my own pages or degrade what I
see on other pages - often, I have several pages from different sources
open at once, for reference.
>> With my normal window width, 640 px - half-screen, there are too many
>> words per line for comfortable reading (consequence of both font face
>> and size).
>
>I think only a very few users are surfing the web with a window set to
>320px. Are you seriously suggesting the FAQ be optimised for that?
No. 640 px is half screen. The screen is 1280 * 1024 and my normal
window width is 640 wide * 85% high (just changed from 90%). Most sites
I view are satisfactory at that (especially commercial ones where that
width cuts off half of the advertising).
>> However, because the dirty pink code boxes are in Courier
>> (you correctly set monospace) and have whitespace on their left, some of
>> them extend to the right of the viewport.
>
>The "dirty pink" is a compromise. The original yellow is
>uncomfortable, I was looking for something easier to look at. The
>styles were tested on a number of computers, screens, browsers and
>operating systems, the differences in appearance were dramatic - what
>looks a gaudy puce on one screen is a bland maroon on another.
>
>Please suggest alternative colours.
I was happy enough with the previous colours. ISTM that one should
avoid, for routine purposes, colours near the edge of the visual
spectrum - or at least putting together colours at opposite ends of the
spectrum. But the "dirty pink" was a description, not a condemnation.
>> The longest line in the pink box in 4.26 brings the right edge of the
>> box in alignment with the right margin of the text, near enough, with my
>> preferred viewport width. If others see similarly, I suggest that you
>> keep code lines below about 63 characters, where practical. (With
>> smaller body padding, I get 69 characters OK on my pages).
>
>4.37 has a longer line, your (apparently preferred) larger fonts will
>exacerbate the situation.
I chose to refer to 4.26 because its longest line was just satisfactory
here; others are manifestly longer.
My font-size complaint referred to the proportional font. Even in the
FAQ as it is, I think I'd prefer code blocks to use a slightly narrower
(but not shorter) font.
Browser defaults IMHO should enable code lines of 72 characters and text
lines of about 12 words to occupy about the same width. For that, my
IE4 was fine; but in my IE6 it is necessary to use
pre { font-size: smaller }
> It is a convention to indent blocks of
>quoted or special text (such as code examples) and therefore it is
>appropriate to do so in the FAQ.
Code examples are not indented in the FAQ, except by about 1 em at the
edge of the boxes and for structure; the code boxes more-or-less align
on the left with the ordinary paragraphs.
> The overrun is a consequence of your
>narrow window width; I think it is unreasonable to expect the FAQ to be
>tailored to suit that at the expense of a more conventional layout.
But there is no need to have such wide body padding - and no need to
indent paragraphs more than minor headers more than major headers.
If I increase the window width, then (a) I can no longer see all of the
code that I'm working on & reading the FAQ for (my normal editor window
is about 620 px wide); and (b) because the text of the paragraphs is 90%
and the sans-serif font has narrow characters, there are too many words
on the line for comfortable reading.
Section 2.3 (plain text only) is now most readable with my window
reduced to 80% width, which reduces the text lines by a larger factor.
That changes characters/line by about as much as two Ctrl-Mousewheel
steps.
IMHO, the FAQ should be submitted to
news:comp.infosystems.www.authoring.html and maybe
news:comp.infosystems.www.authoring.stylesheets for discussion as a
document.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Dr J R Stockton
<RJ82e4B8...@jgharris.demon.co.uk.nospam.invalid>, Sun, 3 Dec 2006
Perhaps. But first you have to tell me what they, in your opinion, are,
and I have to agree with you or at least believe you.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Randy Webb
> In comp.lang.javascript message <g8Cdnd8dM_2...@telcove.net>,
> Fri, 1 Dec 2006 20:04:11, Randy Webb <HikksNo...@aol.com> wrote:
>> Dr J R Stockton said the following on 12/1/2006 4:32 PM:
>>
>> <snip>
>>
>>> Feature detection is easy if it is a question of whether a method
>>> exists, easy enough if it is a question of whether a method works
>>> correctly AND one knows how it fails, and not at all easy (until one
>>> knows how) for such as whether RegExp look-ahead works.
>> Feature detection is "easy enough"? OK, I want to know if
>> createTextNode works correctly in the browser. I know, quite well, how
>> it fails in one very widely used browser (IE). Yet, there is no feature
>> detection test to find out if it works correctly or not even though I
>> know exactly how it's going to fail (fatal error to the script). See
>> the thread from the last two days entitled "createTextNode and IE7"
>> that was started by me and you can see the issue. So no, feature
>> detection is not always "easy enough".
>
>
> That confirms once more that a FAQ writer really does need to be able to
> read English.
I don't have a problem reading, writing, and/or typing English. It is
you who needs to learn to comprehend what you yourself write.
> Thomas would not have doubted.
GFY
> You have responded to the first four words without considering the
> influence of the following "if".
You are making an ignorant assumption, but that is normal for you.
> The sentence refers to three cases, indicated by "if ...", "if ...",
> and "for ...". It does not imply that only three cases are possible.
I didn't say that it did say/imply anything. I said it was a false
statement and then gave you a scenario to prove me wrong. You have
failed to do that yet and until you do, your statement is still false.
And no amount of dodging the issue will change that.
> In IE4, the code testRe = new RegExp("a??") was, I think, a
> fatal script error. But if window.onerror had been set to a function
> just returning true, then the code was a no-op. Thus *that* error can,
> in IE4, be caught and so detected.
So you suggest I kill all error reporting in a page via a library type
function simply to pacify your desire to be right?
> It was implied that one can do similarly with "all" browsers. Perhaps
> one can do similarly for "createTextNode ... (fatal error to the
> script)"?
Probably. But in a library type function the ability to hijack
window.onerror isn't an appealing solution. I would prefer an approach
that uses pure feature detection to detect it. I think my best solution
though is to create a variable, set it to false, and then in an IE
conditional set it to true. That doesn't feature detect for what I want
but it gets close enough as the only browser that I know of that doesn't
use createTextNode properly is IE.
RobG
> In comp.lang.javascript message
> <1165152144.0...@80g2000cwy.googlegroups.com>, Sun, 3 Dec 2006
> 05:22:24, RobG <rg...@iinet.net.au> wrote:
> >Don't blame Randy, it was my suggestion. My intention was to give the
> >FAQ a more contemporary appearance, one that does not look like it came
> >from 1995.
>
> Randy is responsible for the FAQ, and that responsibility includes
> accepting good ideas and rejecting bad ones.
The intention was to put it up and let people comment, I guess you've
had your say.
>
> >The choice of sans-serif font is in keeping with the vast majority of
> >web sites.
>
> One should do what is right, not just follow the fashion set by others.
As you noted, there is a good body of evidence that sans-serif fonts
are easier to read on computer screens for most web users, disabled or
not. I believe that's the reason that the vast majority of web sites
use them. The transition to sans-serif fonts has been slow and
deliberate over a number of years, I don't think it has been done
purely for the sake of fashion.
[...]
> >The claim that the suggestion of a sans-serif font in a CSS file is
> >contrary to legislation is news to me - please explain.
>
> Enforcing a setting for ordinary text other than that preferred by the
> user is contrary certainly to the spirit of disability discrimination
> legislation.
There is no such enforcement, CSS is but a suggestion. If the
intention is to make the page more accessible and easier to read using
CSS (which is specifically designed to be able to be over-ridden by
those who wish to do so for whatever reason), how is that contrary to
the spirit of disability legislation? I think you are exaggerating the
issue.
[...]
> IMHO, the FAQ should be submitted to
> news:comp.infosystems.www.authoring.html and maybe
> news:comp.infosystems.www.authoring.stylesheets for discussion as a
> document.
A good suggestion, however I'd prefer if some of the more knowledgeable
regulars here would pass their eye over it first. There are some ciwah
and ciwas lurkers here who may like to comment once the new page is
ready.
--
Rob
Randy Webb
<snip>
> IMHO, the FAQ should be submitted to
> news:comp.infosystems.www.authoring.html and maybe
> news:comp.infosystems.www.authoring.stylesheets for discussion as a
> document.
There is nothing stopping you from posting to ciwah or ciwas and
discussing the FAQ "as a document". So feel free to do so.
As for me doing it, don't plan on it.
Randy Webb
> Dr J R Stockton wrote:
>> In comp.lang.javascript message
>> <1165152144.0...@80g2000cwy.googlegroups.com>, Sun, 3 Dec 2006
>> 05:22:24, RobG <rg...@iinet.net.au> wrote:
> [...]
>>> Don't blame Randy, it was my suggestion. My intention was to give the
>>> FAQ a more contemporary appearance, one that does not look like it came
>> >from 1995.
>>
>> Randy is responsible for the FAQ, and that responsibility includes
>> accepting good ideas and rejecting bad ones.
>
> The intention was to put it up and let people comment, I guess you've
> had your say.
And it has been duly noted.
> [...]
>> IMHO, the FAQ should be submitted to
>> news:comp.infosystems.www.authoring.html and maybe
>> news:comp.infosystems.www.authoring.stylesheets for discussion as a
>> document.
>
> A good suggestion, however I'd prefer if some of the more knowledgeable
> regulars here would pass their eye over it first. There are some ciwah
> and ciwas lurkers here who may like to comment once the new page is
> ready.
If it were a static HTML document then it is simple to modify part of it
be some other element. Take 3.2, if it is a static document then you can
simple re-code it to be an Ordered List and everything is fine. Changing
it under the current system isn't so trivial though. From my experience
the conversations in ciwah and ciwas tend to follow the same pattern as
clj where it isn't a constructive conversation but it becomes a
philosophical debate for the ages.
FWIW, 10.0 will probably be a static HTML file.
Dr J R Stockton
>Dr J R Stockton said the following on 12/2/2006 4:45 PM:
>> In IE4, the code testRe = new RegExp("a??") was, I think, a
>> fatal script error. But if window.onerror had been set to a function
>> just returning true, then the code was a no-op. Thus *that* error can,
>> in IE4, be caught and so detected.
>
>So you suggest I kill all error reporting in a page via a library type
>function simply to pacify your desire to be right?
No. Just all error reporting from *immediately* before the test
statement to *immediately* after it.
The article of mine which you partly quoted ends with "For that
technique, search the javascript newsgroups, for some while back, for
"window.onerror" (AFAIR, it occurs infrequently) or see
<URL:http://www.merlyn.demon.co.uk/js-valid.htm#RFT>." The essence of
the code there was copied from a News article posted by, IIRC, a
reliable person.
If you had looked at that URL you would have seen how an error-handler
is saved and restored - but surely that is a well-known technique in
various high-level languages?
>> It was implied that one can do similarly with "all" browsers. Perhaps
>> one can do similarly for "createTextNode ... (fatal error to the
>> script)"?
>
>Probably. But in a library type function the ability to hijack
>window.onerror isn't an appealing solution.
It would not be if it could not be restored immediately.
> I would prefer an approach that uses pure feature detection to detect
>it. I think my best solution though is to create a variable, set it to
>false, and then in an IE conditional set it to true. That doesn't
>feature detect for what I want but it gets close enough as the only
>browser that I know of that doesn't use createTextNode properly is IE.
If IE (with conditionals) is in fact the only failing browser, then your
method should work, AFAICS.
You will be announcing here, clearly, the posting to the "standard" URL
of each completed version of the FAQ, with its correct date and a number
higher than used ever before?
John G Harris
Stockton <repl...@merlyn.demon.co.uk> writes
>In comp.lang.javascript message <RJ82e4B8...@jgharris.demon.co.uk.
>nospam.invalid>, Sun, 3 Dec 2006 13:42:20, John G Harris
><jo...@nospam.demon.co.uk> wrote:
>>In article <HD1MTuBf...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>>Stockton <repl...@merlyn.demon.co.uk> writes
>>
>> <snip>
>>>But since then, in over a year, he has produced absolutely nothing,
>> <snip>
>>
>>Isn't it time that the mistakes in js-other concerning identifiers and
>>semicolons were corrected ?
>
>Perhaps. But first you have to tell me what they, in your opinion,
>are, and I have to agree with you or at least believe you.
It will improve your understanding if you read the identifier and
semicolon sections again and spot the problems yourself.
John
--
John Harris
Peter Michaux
Peter Michaux wrote:
>
> 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.
I haven't been keeping up on this thread but is this info not going to
be included in the FAQ?
Thanks,
Peter
Randy Webb
It is in section 4.34 and probably getting moved to 4.44
John G Harris
>In comp.lang.javascript message
><RJ82e4B8...@jgharris.demon.co.uk.nospam.invalid>, Sun, 3 Dec 2006
>13:42:20, John G Harris <jo...@nospam.demon.co.uk> wrote:
>>In article <HD1MTuBf...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>>Stockton <repl...@merlyn.demon.co.uk> writes
>>
>> <snip>
>>>But since then, in over a year, he has produced absolutely nothing,
>> <snip>
>>
>>Isn't it time that the mistakes in js-other concerning identifiers and
>>semicolons were corrected ?
>
>Perhaps. But first you have to tell me what they, in your opinion,
>are, and I have to agree with you or at least believe you.
Here is what I would have written. You'll notice that some of my
assertions differ from some of yours.
===========================================================
Identifiers
Identifiers give names to variables, functions, and
properties so that the compiler knows which one you're
talking about.
With some restrictions, an identifier is any combination of
letters, digits, '_', and '$' characters. Unicode letters
and a few obscure Unicode symbols are allowed. Identifiers
are case sensitive.
One restriction is that an identifier does not start with a
decimal digit, ('0' to '9'). The other restriction is that
an identifier is not one of the javascript keywords, (while,
var, in, ...), nor one of the words reserved for future use,
(class, goto, ...), nor one of the words null, true, false.
It is best not to use '$' as it makes identifiers difficult
to read and is there for use by programs that write
javascript programs.
Variables
It is better to declare each variable explicitly, as in
var x;
If this is done inside a function then x becomes a local
variable, different from any global variable and any
local variable named x in other functions. It is also
different from the local variable named x in a recursive
call of the same function.
===========================================================
Semicolons
Some statements end with a semicolon, ';'; some end with a
close curly brackets, '}'; all other statements end with a
nested, simpler, statement. Here is an example that shows
all three cases :
if (x==0)
{ y = 0; z = 1; }
The 'if' statement ends with a block statement, { ... }.
The block statement ends with a close curly brackets. Each
of the two statements inside the block statement ends with
a semicolon.
A 'var' declaration is classified as a statement. It ends
with a semicolon.
A 'function' declaration is not classified as a statement,
though it looks much the same. It ends with a close curly
brackets.
In some cases you need not write the semicolons yourself.
In effect, the compiler will write them for you. One case
is when the semicolon is at the end of the line *and* the
beginning of the next line cannot possibly be part of the
same statement. The other case is when the semicolon is
followed by a close curly brackets. (Ignore comments when
applying these rules). Thus the example can be written as :
if (x==0)
{ y = 0
z = 1 }
In return for being able to leave out some of the
semicolons you must be careful where you put your line
endings. In particular, if a function returns a value then
the expression giving the value must start on the same line
as the 'return' keyword.
The semicolons inside a 'for' condition, (... ; ... ; ...),
cannot be omitted.
The full rules are given in ECMA 262.
===========================================================
John
--
John Harris
Dr J R Stockton
<M$6uxqAZu...@jgharris.demon.co.uk.nospam.invalid>, Sun, 10 Dec 2006
>In article <FHTMyXUb...@invalid.uk.co.demon.merlyn.invalid>, Dr J
>R Stockton <repl...@merlyn.demon.co.uk> writes
>>In comp.lang.javascript message
>><RJ82e4B8...@jgharris.demon.co.uk.nospam.invalid>, Sun, 3 Dec
>>2006 13:42:20, John G Harris <jo...@nospam.demon.co.uk> wrote:
>>>In article <HD1MTuBf...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>>>Stockton <repl...@merlyn.demon.co.uk> writes
>>>
>>> <snip>
>>>>But since then, in over a year, he has produced absolutely nothing,
>>> <snip>
>>>
>>>Isn't it time that the mistakes in js-other concerning identifiers and
>>>semicolons were corrected ?
>>
>>Perhaps. But first you have to tell me what they, in your opinion,
>>are, and I have to agree with you or at least believe you.
>
>Here is what I would have written. You'll notice that some of my
>assertions differ from some of yours.
You're writing a simplified manual; I'm writing remarks aimed at those
who have already read as much manual or specification as they want to
(want != need).
For example, you're saying what can be used as an identifier; I'm
indicating what should be used : 'it' is a perfectly good identifier to
the parser; but it's not a good choice for a programmer/coder, as it's
difficult to search a set of pages for 'it' without getting swamped by
instances in strings, comment, and HTML-marked text.
>===========================================================
> Identifiers
>
>Identifiers give names to variables, functions, and
>properties so that the compiler knows which one you're
I'd not think "compiler" appropriate, "parser" seems better.
--
John G Harris
Stockton <repl...@merlyn.demon.co.uk> writes
>In comp.lang.javascript message <M$6uxqAZu...@jgharris.demon.co.uk.
<snip>
>>Identifiers give names to variables, functions, and
>>properties so that the compiler knows which one you're
Given that you understand this, I'm surprised you didn't notice the
mistake in
"Every identifier used within a function
should be declared as a var" ... .
>I'd not think "compiler" appropriate, "parser" seems better.
A parser just builds parse trees. In other languages, finding out the
meaning of each identifier is done somewhere else in the compiler, with
the parse trees as input.
As it happens, "compiler" is wrong for javascript. Finding out what an
identifier refers to is done at run-time, inside the program.
John
--
John Harris
Evertjan.
> As it happens, "compiler" is wrong for javascript. Finding out what an
> identifier refers to is done at run-time, inside the program.
"Interpreter" is the name.
Well not quite.
In the old days, a compiler made a machine language [well not quite]
programme from the source code, that could be executed independently.
In the old days, an interpreter ran a source script while(!!!) it was
executing the script. A function could not be called if it was not defined
higher up in the script.
Nowadays, a script is first scanned by the "interpreter" at runtime(!!!),
before the real execution of some intermediate code, that is made in the
first scan by a process akin to compiling, starts.
At least, that is what I deduct from what they tell me!
Should we coin "javascript execution engine"?
I prefer "interpreter" or perhaps simply "javascript engine".
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Dr J R Stockton
<X+Y27zLK...@jgharris.demon.co.uk.nospam.invalid>, Mon, 11 Dec 2006
>In article <eSyh9pf3...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>Stockton <repl...@merlyn.demon.co.uk> writes
>>In comp.lang.javascript message <M$6uxqAZu...@jgharris.demon.co.uk.
>>nospam.invalid>, Sun, 10 Dec 2006 13:28:57, John G Harris
>><jo...@nospam.demon.co.uk> wrote:
>
> <snip>
>>>Identifiers give names to variables, functions, and
>>>properties so that the compiler knows which one you're
>
>Given that you understand this, I'm surprised you didn't notice the
>mistake in
> "Every identifier used within a function
> should be declared as a var" ... .
Eschew selective or inadequate quoting, ESPECIALLY when you're not
quoting the previous News article.
And remember that you were there reading a recommendation for the use of
the language, not a requirement of the language (likewise, the regulars
here agree on the benefit of indentation to show structure and of some
other non-essential whitespace; but the javascript engine does not need
it).
>>I'd not think "compiler" appropriate, "parser" seems better.
>
>A parser just builds parse trees. In other languages, finding out the
>meaning of each identifier is done somewhere else in the compiler, with
>the parse trees as input.
Maybe "interpreter" or "javascript engine" for your text, then.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
John G Harris
<exjxw.ha...@interxnl.net> writes
I vote for javascript engine. Then no-one gets confused by what
interpreters do or don't do in other languages.
Question : Is your program running in a computer simulated by the
engine, or is the engine running with your program as data ?
If the latter, then you never make programming errors because your
program never runs :-)
John
--
John Harris
Evertjan.
> I vote for javascript engine. Then no-one gets confused by what
> interpreters do or don't do in other languages.
>
> Question : Is your program running in a computer simulated by the
> engine, or is the engine running with your program as data ?
if it was simulated, there would be no effect.
> If the latter, then you never make programming errors because your
> program never runs :-)
No, script programmes run "on" an engine.
"Water boils in a kettel,
so the water does not boil,
the kettel does"???
;-} ;-}
John G Harris
Stockton <repl...@merlyn.demon.co.uk> writes
>In comp.lang.javascript message <X+Y27zLK...@jgharris.demon.co.uk.
>nospam.invalid>, Mon, 11 Dec 2006 20:27:54, John G Harris
><jo...@nospam.demon.co.uk> wrote:
>>In article <eSyh9pf3...@invalid.uk.co.demon.merlyn.invalid>, Dr J R
>>Stockton <repl...@merlyn.demon.co.uk> writes
>>>In comp.lang.javascript message <M$6uxqAZu...@jgharris.demon.co.uk.
>>>nospam.invalid>, Sun, 10 Dec 2006 13:28:57, John G Harris
>>><jo...@nospam.demon.co.uk> wrote:
>>
>> <snip>
>>>>Identifiers give names to variables, functions, and
>>>>properties so that the compiler knows which one you're
>>
>>Given that you understand this, I'm surprised you didn't notice the
>>mistake in
>> "Every identifier used within a function
>> should be declared as a var" ... .
>
>Eschew selective or inadequate quoting, ESPECIALLY when you're not
>quoting the previous News article.
Cast your gaze upon the word "identifier" in the quoted text (which came
from <URL:http://www.merlyn.demon.co.uk/js-other.htm>).
John
--
John Harris