Updated FAQ

[Garrett Smith]

* Remove entry for window.status
(G Smith, despite mild objection)
* modified and cleaned up the DC meta tags
(Thomas)

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 24 Nov 2009 21:47:05, Garrett Smith

* Remove entry for window.status
(G Smith, despite mild objection)

I don't recall any *mild* objection.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 24 Nov 2009 21:47:05, Garrett Smith


I don't recall any *mild* objection.

Peter Michaux:
| I'd leave it in the FAQ if the answer is still correct. It may not get
| asked *because* it is in the FAQ.
|
| I know people that still want to manipulate the user's browser in
| inappropriate ways.
| ...

Sounds like a mild objection to me.

You had a lot to say about that entry. You started out mentioning
problems you were experiencing when trying to set window.status.

You went on to say that it was a useful feature for the user, when it
worked consistently. I know you felt strongly on this, however, there
are options for displaying notifications to users. The user is more
likely to pay closer attention to a message displayed right near the
object the user clicked than to a status bar message. So even where the
status bar is displayed and scriptible, it is a poor option with easy
workarounds.

You also had a lot to write about the numbering as well. Thomas
explained the rationale for using meaningful fragment identifiers.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 25 Nov 2009 19:33:45, Garrett Smith

Peter Michaux:
| I'd leave it in the FAQ if the answer is still correct. It may not get
| asked *because* it is in the FAQ.
|
| I know people that still want to manipulate the user's browser in
| inappropriate ways.
| ...

Sounds like a mild objection to me.

You had a lot to say about that entry. You started out mentioning
problems you were experiencing when trying to set window.status.

No. T told you how useful it could be, although not with all browsers.
For me, it is never difficult to set. The coding is easy; in some
browsers the status line responds, in others it does not.

You went on to say that it was a useful feature for the user, when it
worked consistently. I know you felt strongly on this,

Then you were dishonest in writing "mild objection", whether that be
intended to be singular or plural.

however, there are options for displaying notifications to users. The
user is more likely to pay closer attention to a message displayed
right near the object the user clicked than to a status bar message. So
even where the status bar is displayed and scriptible, it is a poor
option with easy workarounds.

And I told you how mistaken you were.

You do not seem, for instance, to understand that the author is at least
as important as the users - without an author, there could be no users.
Code that helps an author is of benefit to the users, even if removed
before publication.

You do not seem to understand the difference between an unexpected
warning, which needs to attract the reader's attention of the reader
(author or otherwise), and an expected, continuously changing,
indication of the general situation.

You do not seem to understand that the author may be the actual or prime
user, with the page being published (if at all) only as a public proof
of assertions that the author wants to make, or on the grounds that the
benefit might as well be available to others.

It appears that the only situation you can envisage is that of the hack
coder, employed by commerce or government to produce pages for /hoi
polloi/ to use in direct or indirect support of transactions.

You also had a lot to write about the numbering as well. Thomas
explained the rationale for using meaningful fragment identifiers.

He is a fool, among other things.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 25 Nov 2009 19:33:45, Garrett Smith


No.

You wrote:
| AFAICS, IE allows, FF does not, Opera allows ; Safari & Chrome don't
| have a bar. But I may have changed settings from default.

and:
| It can be a positive advantage that the status is being shown on a bar
| at the foot; of late I have frequently had Opera doing a full scan
| with <URL:http://www.merlyn.demon.co.uk/linxchek>, taking about a
| minute, with its progress/status bar peeping out from some completely
| different task

It sounds like compatibility problems to me. Did I misconstrue?

T told you how useful it could be, although not with all browsers.

For me, it is never difficult to set. The coding is easy; in some
browsers the status line responds, in others it does not.


Then you were dishonest in writing "mild objection", whether that be
intended to be singular or plural.

The valid parts of your argument were considered and the objections you
raised did not seem strong.

And I told you how mistaken you were.

Would you like to restate your argument?

You do not seem, for instance, to understand that the author is at least
as important as the users - without an author, there could be no users.
Code that helps an author is of benefit to the users, even if removed
before publication.

You're right; I don't really understand that. Is this about the argument
of using the status bar for developer log info?

You do not seem to understand the difference between an unexpected
warning, which needs to attract the reader's attention of the reader
(author or otherwise), and an expected, continuously changing,
indication of the general situation.

you totally lost me.

You do not seem to understand that the author may be the actual or prime
user, with the page being published (if at all) only as a public proof
of assertions that the author wants to make, or on the grounds that the
benefit might as well be available to others.

What does this have to do with the status bar?

It appears that the only situation you can envisage is that of the hack
coder, employed by commerce or government to produce pages for /hoi
polloi/ to use in direct or indirect support of transactions.

This sounds like you're telling me what *my* observations or thoughts
are. Where are you getting this? I've provided alternatives to each
situation where you though status bar was useful.

1) debug info - use a console; an input if unavailable.
2) provide notification to use; update an element on the page.

He is a fool, among other things.

<hot button>
What you dislike about Thomas may be something that you see in yourself.
</hot button>

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 30 Nov 2009 00:24:58, Garrett Smith

You wrote:
| AFAICS, IE allows, FF does not, Opera allows ; Safari & Chrome don't
| have a bar. But I may have changed settings from default.

and:
| It can be a positive advantage that the status is being shown on a bar
| at the foot; of late I have frequently had Opera doing a full scan
| with <URL:http://www.merlyn.demon.co.uk/linxchek>, taking about a
| minute, with its progress/status bar peeping out from some completely
| different task

It sounds like compatibility problems to me. Did I misconstrue?

Yes. There is no need for something useful to work in all browsers,
provided only that an alternative is provided. One should not deprive
Opera users, oneself included of a feature, just because some other
browser lacks the feature.

T told you how useful it could be, although not with all browsers.

If you did, that was unnecessary.

The valid parts of your argument were considered and the objections you
raised did not seem strong.

In the English language, which you should learn, strength and validity
of an objection are independent concepts.

Would you like to restate your argument?

No. You can re-read the relevant thread(s).

You're right; I don't really understand that. Is this about the
argument of using the status bar for developer log info?

you totally lost me.

Then you are not sufficiently intelligent for the task.

What does this have to do with the status bar?

If a feature is useful to an author, it helps him in his work. That
means that the work becomes quicker or better than it otherwise would.
That becomes of benefit to the users, independently of whether any or
every user can see the feature on operation.

This sounds like you're telling me what *my* observations or thoughts
are. Where are you getting this? I've provided alternatives to each
situation where you though status bar was useful.

NO: I'm telling you what they seem to be. That is what "It appears
that" means.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 30 Nov 2009 00:24:58, Garrett Smith
[snip]

Would you like to restate your argument?

No. You can re-read the relevant thread(s).

OK, I've read your arguments.

AIUI, you have a way of using the status bar that you are comfy with.

Does not mean the status bar needs to be in the FAQ?

No.

In the general sense, and in the big picture of the FAQ, your comfy way
of outputting messages to yourself is not important.

The status bar is an inferior means of outputting/logging data. The
status bar is a poor place to convey critical information to the user,
as the status bar may be hidden or may be ignored by the user.

The status bar is a proprietary window feature that is not cross browser
compatible.

It is not asked about very often. It is not something to recommend.

Removing that entry reduces the length of the FAQ.

[snip]

 

[David Mark]

In comp.lang.javascript message <[email protected]
september.org>, Mon, 30 Nov 2009 00:24:58, Garrett Smith

Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Wed, 25 Nov 2009 19:33:45, Garrett Smith
<[email protected]> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Tue, 24 Nov 2009 21:47:05, Garrett Smith
<[email protected]> posted:
* Remove entry for window.status

[snip]

however, there are options for displaying notifications to users. The
user is more likely to pay closer attention to a message displayed
right near the object the user clicked than to a status bar message.So
even where the status bar is displayed and scriptible, it is a poor
option with easy workarounds.
 And I told you how mistaken you were.
Would you like to restate your argument?

No.  You can re-read the relevant thread(s).

OK, I've read your arguments.

AIUI, you have a way of using the status bar that you are comfy with.

It's easy to use. Doesn't mean that it is something useful though.

Does not mean the status bar needs to be in the FAQ?

Not as such.

No.

In the general sense, and in the big picture of the FAQ, your comfy way
of outputting messages to yourself is not important.

The idea is that there should be some entry. That entry may detail
your objections to using it and also mention how it can be done for
completeness.

The status bar is an inferior means of outputting/logging data.

Put that in too.

The
status bar is a poor place to convey critical information to the user,
as the status bar may be hidden or may be ignored by the user.

There you go.

The status bar is a proprietary window feature that is not cross browser
compatible.
Right.


It is not asked about very often.

Who conducted that study?

It is not something to recommend.

Right, but neither is it something to ignore because it is not
recommended. The FAQ is not the Good Parts.

Removing that entry reduces the length of the FAQ.

That's the weakest of the arguments presented. Who cares about a
couple of paragraphs? It's a relevant entry, though not quite as
relevant as others. I can't see removing it for space reasons.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 1 Dec 2009 22:41:07, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Mon, 30 Nov 2009 00:24:58, Garrett Smith

Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Wed, 25 Nov 2009 19:33:45, Garrett Smith
<[email protected]> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Tue, 24 Nov 2009 21:47:05, Garrett Smith
<[email protected]> posted:
* Remove entry for window.status

[snip]

however, there are options for displaying notifications to users.
The
user is more likely to pay closer attention to a message displayed
right near the object the user clicked than to a status bar message. So
even where the status bar is displayed and scriptible, it is a poor
option with easy workarounds.
And I told you how mistaken you were.

Would you like to restate your argument?

No. You can re-read the relevant thread(s).

OK, I've read your arguments.

But with manifest prejudice and without intelligent appreciation.

The status bar is an inferior means of outputting/logging data. The
status bar is a poor place to convey critical information to the user,
as the status bar may be hidden or may be ignored by the user.

Why introduce "critical"? - it is necessary and sufficient that the
information should be useful.

The status bar is a proprietary window feature that is not cross
browser compatible.

Agreed. But an intelligent user will have a choice of browsers. It
appears that you are again considering only government/commercial
sales/advertising/ordering sites whose users may be scarcely literate.

From the programmer's point of view, window.status can always be
assigned to, AFAICS; from the system designer's point of view, it may or
may not be displayed.

And consider, for example, how it is used in my <linxchek.htm> : by
calling

function Progress(St) {
Form.ST.value = window.status = "STATUS: " + St }

At a cost of a mere 15 characters, seven probably redundant, most users
are given a choice of places to read the progress information - and the
status bar never scrolls up and down while the document is being read.

It is not asked about very often.

So parts of the FAQ are working. There's no point in writing a FAQ if
you don't believe it will be read.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 1 Dec 2009 22:41:07, Garrett Smith

In comp.lang.javascript message <[email protected]
september.org>, Mon, 30 Nov 2009 00:24:58, Garrett Smith
<[email protected]> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Wed, 25 Nov 2009 19:33:45, Garrett Smith
<[email protected]> posted:
Dr J R Stockton wrote:
In comp.lang.javascript message <[email protected]
september.org>, Tue, 24 Nov 2009 21:47:05, Garrett Smith
<[email protected]> posted:
* Remove entry for window.status [snip]

however, there are options for displaying notifications to users.
The
user is more likely to pay closer attention to a message displayed
right near the object the user clicked than to a status bar message. So
even where the status bar is displayed and scriptible, it is a poor
option with easy workarounds.
And I told you how mistaken you were.

Would you like to restate your argument?
No. You can re-read the relevant thread(s).

OK, I've read your arguments.

But with manifest prejudice and without intelligent appreciation.

Try focusing on your argument.

Why introduce "critical"? - it is necessary and sufficient that the
information should be useful.

Does the message pertain to the page or the browser, or does it pertain
to something on the page?

Agreed. But an intelligent user will have a choice of browsers.

It sounds like your argument is that intelligent people do not use any
machine other than one that they own, have a browser that has a
scriptable status bar. Intelligent user does not use mobile device.

Does this sound like a strong argument to you?

It

appears that you are again considering only government/commercial
sales/advertising/ordering sites whose users may be scarcely literate.

Where are you getting this from?

The status bar is not in close proximity to the thing the user clicked.
Users look before clicking, and when they click, they are looking at the
thing they are clicking on. Putting something in window.status provides
a visual distraction away from where the user is focused.

From the programmer's point of view, window.status can always be
assigned to, AFAICS; from the system designer's point of view, it may or
may not be displayed.

And consider, for example, how it is used in my <linxchek.htm> : by
calling

function Progress(St) {
Form.ST.value = window.status = "STATUS: " + St }

A familiar mix of title case, camel case, and two-letter abbreviations
of upper, lower, and mixed case.

At a cost of a mere 15 characters, seven probably redundant, most users
are given a choice of places to read the progress information

It seems like users with js enabled are presented with a form control
update. And users with visible, scriptable status bar are presented with
concurrent distractions in the status bar.

The consequence of accessing form controls as properties of the form
(nonstandard), is leaving a property of the control on the form object
in some browsers, even after (if) the control is removed from the form.

Removing assignment to window.status would result in better performance.

- and the

status bar never scrolls up and down while the document is being read.

Yes, the status bar does not scroll.

If the entry is added back, some of the problems with window.status must
be mentioned in it.

It is not something that gets asked frequently, judging from what I see
in archive searches.

Setting window.status is not something worth recommending (proprietary,
fickle support).

Having this in the FAQ of suggested "read before posting" is asking
probably a majority of its readers to read something that is probably
not something they care about much, or at all.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 3 Dec 2009 17:51:38, Garrett Smith

Does the message pertain to the page or the browser, or does it pertain
to something on the page?

The message is whatever the coder sees fit to code.

It sounds like your argument is that intelligent people do not use any
machine other than one that they own, have a browser that has a
scriptable status bar. Intelligent user does not use mobile device.

Does this sound like a strong argument to you?

Sorry, I should have written "author" there, which deflates your
"argument". But an intelligent user *will* have a choice of browsers,
although not necessarily always. The IT man at our Public library can
there only use MSIE (council policy; but council intelligence is an
untenable hypothesis); but I understand that he uses Firefox at home. I
can use Firefox there, as I have it on a stick, but that can only read
the Council's site; the council firewall does not pass Firefox (ditto).

It

Where are you getting this from?

From the blinkered, knee-jerk nature of your responses, which never
display breadth of thinking.

The status bar is not in close proximity to the thing the user clicked.
Users look before clicking, and when they click, they are looking at
the thing they are clicking on. Putting something in window.status
provides a visual distraction away from where the user is focused.

You are presuming there that the status bar is *only* updated as an
immediate consequence of a user click. That is a false assumption.

A familiar mix of title case, camel case, and two-letter abbreviations
of upper, lower, and mixed case.

A sufficiently intelligent newsgroup reader will be able to accommodate
that with ease. That is the code as it is, and it suits the primarily-
intended reader.

It seems like users with js enabled are presented with a form control
update.

If JavaScript is not enabled, there will be no progress in that page.
Indeed, in that page, the very button that sets thing going is hidden in
the HTML and enabled by script.

And users with visible, scriptable status bar are presented with
concurrent distractions in the status bar.

No, with an alternative place to read it.

The consequence of accessing form controls as properties of the form
(nonstandard),

Can you justify that parenthesis?

is leaving a property of the control on the form object in some
browsers, even after (if) the control is removed from the form.

Even if true, that hardly seems important. The proportion of form
controls that are removed will, overall, be small, and the putative
existence of such a residual property will be unimportant.

Removing assignment to window.status would result in better performance.

Yes - but tests show that the difference is negligible provided that the
updates do not occur unreasonably quickly.

Having this in the FAQ of suggested "read before posting" is asking
probably a majority of its readers to read something that is probably
not something they care about much, or at all.

However, the presence of sectional Subject lines means that they will be
able to skip such parts of no immediate interest very rapidly. That's
not a significant objection.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Thu, 3 Dec 2009 17:51:38, Garrett Smith


The message is whatever the coder sees fit to code.

Try using document.title.

That will work in more browsers. I don't know the specifics of the
scenario here, but it probably has something to do with your lixcheck thing.

Sorry, I should have written "author" there, which deflates your
"argument".

My "argument"? I read and you wrote:
| But an intelligent user will have a choice of browsers.

I see you posed the argument that intelligent user will have a choice of
browser.

And so the implication that if the user does not have a choice, he must
not be intelligent.

If having knowledge of browsers were a prerequisite to intelligence then
what about before browsers existed?

What if a user decides to use a browser with status bar hidden? The
status bar is mostly a wast of space anyway, right?

But an intelligent user *will* have a choice of browsers,

although not necessarily always. The IT man at our Public library can
there only use MSIE (council policy; but council intelligence is an
untenable hypothesis); but I understand that he uses Firefox at home. I
can use Firefox there, as I have it on a stick, but that can only read
the Council's site; the council firewall does not pass Firefox (ditto).

RIght, so the user may not have control of the browser.

From the blinkered, knee-jerk nature of your responses, which never
display breadth of thinking.

What is your "other" argument?

You are presuming there that the status bar is *only* updated as an
immediate consequence of a user click. That is a false assumption.

No, it is not a false assumption. It is a poor word choice. Recall
earlier in the thread where I used terminology to the effect of "the
objecdt that the user took action on." Was that object the browser, or
was it something in the document?

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Sun, 6 Dec 2009 20:33:58, Garrett Smith

Try using document.title.

Semantically inappropriate. The element document.title is intended for,
and useful as, the title of the document.

My "argument"? I read and you wrote:
| But an intelligent user will have a choice of browsers.

I see you posed the argument that intelligent user will have a choice
of browser.

And so the implication that if the user does not have a choice, he must
not be intelligent.

If having knowledge of browsers were a prerequisite to intelligence
then what about before browsers existed?

Then there were no browser or Web page users. The word "user" is
meaningless without an implicit or explicit indicator of what, and in
this case "Web page" is clearly implied.