New FAQ Version for review

[Randy Webb]

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

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]

In comp.lang.javascript message

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.



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

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]

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

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.

 

[Dr J R Stockton]

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

Dr J R Stockton said the following on 12/1/2006 4:32 PM:



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

 

[Dr J R Stockton]

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

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.

 

[Jim Ley]

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]

Jim Ley said the following on 12/3/2006 5:12 AM:

This is 'cos it's in newfaq, once index.html was in faq/ it would've
just magically worked.


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.

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]

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


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.

 

[John G Harris]

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

 

[Randy Webb]

RobG said the following on 12/3/2006 8:22 AM:

Pretty much what I think every time I visit the current FAQ.


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]

In comp.lang.javascript message

Pretty much what I think every time I visit the current FAQ.


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.

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

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

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.

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.

 

[Dr J R Stockton]

In comp.lang.javascript message

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

 

[Randy Webb]

Dr J R Stockton said the following on 12/2/2006 4:45 PM:

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



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
<[email protected]>, Sun, 3 Dec 2006


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.

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.

[...]

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.

 

[Randy Webb]

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

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]

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

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]

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

Dr J R Stockton said the following on 12/2/2006 4:45 PM:

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?

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]

In comp.lang.javascript message <[email protected].
nospam.invalid>, Sun, 3 Dec 2006 13:42:20, John G Harris


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

 

[Peter Michaux]

Hi Randy,

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]

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

Hi Randy,



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