New FAQ Version for review

[RobG]

Re: New FAQ Version for review

Dr J R Stockton wrote:

In comp.lang.javas cript message
<1165152144.066 950.248660@80g2 000cwy.googlegr oups.com>, Sun, 3 Dec 2006
05:22:24, RobG <rgqld@iinet.ne t.auwrote:

[...]

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.infos ystems.www.authoring.html and maybe
news:comp.infos ystems.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]

Re: New FAQ Version for review

Dr J R Stockton said the following on 12/3/2006 5:52 PM:

<snip>

IMHO, the FAQ should be submitted to
news:comp.infos ystems.www.authoring.html and maybe
news:comp.infos ystems.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
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Randy Webb]

Re: New FAQ Version for review

RobG said the following on 12/4/2006 9:10 AM:

Dr J R Stockton wrote:

>In comp.lang.javas cript message
><1165152144.06 6950.248660@80g 2000cwy.googleg roups.com>, Sun, 3 Dec 2006
>05:22:24, RobG <rgqld@iinet.ne t.auwrote:

[...]

>>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.infos ystems.www.authoring.html and maybe
> news:comp.infos ystems.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.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Dr J R Stockton]

Re: New FAQ Version for review

In comp.lang.javas cript message <qeOdnSUyOJkT R-7Y4p2dnA@telcov e.net>,
Mon, 4 Dec 2006 03:22:02, Randy Webb <HikksNotAtHome @aol.comwrote:

>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.demo n.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 "createText Node ... (fatal error to the
>script)"?

>
>Probably. But in a library type function the ability to hijack
>window.onerr or 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?

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 IE 6
<URL:http://www.jibbering.c om/faq/ Old RC FAQ of news:comp.lang. javascript
<URL:http://www.merlyn.demo n.co.uk/js-index.htmjscr maths, dates, sources.
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/jscr/&c, FAQ items, links.

[John G Harris]

Re: New FAQ Version for review

In article <FHTMyXUbZ1cFFw +d@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
Stockton <reply0648@merl yn.demon.co.ukw rites

>In comp.lang.javas cript message <RJ82e4B8QtcFFw dO@jgharris.dem on.co.uk.
>nospam.invalid >, Sun, 3 Dec 2006 13:42:20, John G Harris
><john@nospam.d emon.co.ukwrote :

>>In article <HD1MTuBfF0bFFw XR@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
>>Stockton <reply0648@merl yn.demon.co.ukw rites
>>
> <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]

Re: New FAQ Version for review

Hi Randy,

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]

Re: New FAQ Version for review

Peter Michaux said the following on 12/6/2006 4:14 PM:

Hi Randy,
>
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?
>

It is in section 4.34 and probably getting moved to 4.44

--
Randy
Chance Favors The Prepared Mind
comp.lang.javas cript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[John G Harris]

Re: New FAQ Version for review

In article <FHTMyXUbZ1cFFw +d@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
Stockton <reply0648@merl yn.demon.co.ukw rites

>In comp.lang.javas cript message
><RJ82e4B8QtcFF wdO@jgharris.de mon.co.uk.nospa m.invalid>, Sun, 3 Dec 2006
>13:42:20, John G Harris <john@nospam.de mon.co.ukwrote:

>>In article <HD1MTuBfF0bFFw XR@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
>>Stockton <reply0648@merl yn.demon.co.ukw rites
>>
> <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]

Re: New FAQ Version for review

In comp.lang.javas cript message
<M$6uxqAZuAfFFw VN@jgharris.dem on.co.uk.nospam .invalid>, Sun, 10 Dec 2006
13:28:57, John G Harris <john@nospam.de mon.co.ukwrote:

>In article <FHTMyXUbZ1cFFw +d@invalid.uk.c o.demon.merlyn. invalid>, Dr J
>R Stockton <reply0648@merl yn.demon.co.ukw rites

>>In comp.lang.javas cript message
>><RJ82e4B8QtcF FwdO@jgharris.d emon.co.uk.nosp am.invalid>, Sun, 3 Dec
>>2006 13:42:20, John G Harris <john@nospam.de mon.co.ukwrote:

>>>In article <HD1MTuBfF0bFFw XR@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
>>>Stockton <reply0648@merl yn.demon.co.ukw rites
>>>
>> <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.


--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Delphi 3? Turnpike 6.05
<URL:http://www.merlyn.demo n.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.bancoems.co m/CompLangPascalD elphiMisc-MiniFAQ.htmclpd mFAQ;
<URL:http://www.borland.com/newsgroups/guide.htmlnews: borland.* Guidelines

[John G Harris]

Re: New FAQ Version for review

In article <eSyh9pf3IJfFFw FQ@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
Stockton <reply0649@merl yn.demon.co.ukw rites

>In comp.lang.javas cript message <M$6uxqAZuAfFFw VN@jgharris.dem on.co.uk.
>nospam.invalid >, Sun, 10 Dec 2006 13:28:57, John G Harris
><john@nospam.d emon.co.ukwrote :

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

Re: New FAQ Version for review

John G Harris wrote on 11 dec 2006 in comp.lang.javas cript:

As it happens, "compiler" is wrong for javascript. Finding out what an
identifier refers to is done at run-time, inside the program.

"Interprete r" 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 "interprete r" 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 "interprete r" or perhaps simply "javascript engine".

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Dr J R Stockton]

Re: New FAQ Version for review

In comp.lang.javas cript message
<X+Y27zLK9bfFFw Hz@jgharris.dem on.co.uk.nospam .invalid>, Mon, 11 Dec 2006
20:27:54, John G Harris <john@nospam.de mon.co.ukwrote:

>In article <eSyh9pf3IJfFFw FQ@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
>Stockton <reply0649@merl yn.demon.co.ukw rites

>>In comp.lang.javas cript message <M$6uxqAZuAfFFw VN@jgharris.dem on.co.uk.
>>nospam.invali d>, Sun, 10 Dec 2006 13:28:57, John G Harris
>><john@nospam. demon.co.ukwrot e:

>
<snip>

>>>Identifier s 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 "interprete r" or "javascript engine" for your text, then.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon. co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demo n.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.

[John G Harris]

Re: New FAQ Version for review

In article <Xns9896E1B063F A6eejj99@194.10 9.133.242>, Evertjan.
<exjxw.hannivoo rt@interxnl.net writes

>John G Harris wrote on 11 dec 2006 in comp.lang.javas cript:
>

>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 "interprete r" 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 "interprete r" or perhaps simply "javascript engine".

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

Re: New FAQ Version for review

John G Harris wrote on 12 dec 2006 in comp.lang.javas cript:

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

;-} ;-}


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[John G Harris]

Re: New FAQ Version for review

In article <$yvplqTDpqfFFw TI@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
Stockton <reply0650@merl yn.demon.co.ukw rites

>In comp.lang.javas cript message <X+Y27zLK9bfFFw Hz@jgharris.dem on.co.uk.
>nospam.invalid >, Mon, 11 Dec 2006 20:27:54, John G Harris
><john@nospam.d emon.co.ukwrote :

>>In article <eSyh9pf3IJfFFw FQ@invalid.uk.c o.demon.merlyn. invalid>, Dr J R
>>Stockton <reply0649@merl yn.demon.co.ukw rites

>>>In comp.lang.javas cript message <M$6uxqAZuAfFFw VN@jgharris.dem on.co.uk.
>>>nospam.inval id>, Sun, 10 Dec 2006 13:28:57, John G Harris
>>><john@nospam .demon.co.ukwro te:

>>
> <snip>

>>>>Identifie rs give names to variables, functions, and
>>>>propertie s 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.

<snip>

Cast your gaze upon the word "identifier " in the quoted text (which came
from <URL:http://www.merlyn.demo n.co.uk/js-other.htm>).

John
--
John Harris