469,281 Members | 2,450 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,281 developers. It's quick & easy.

button.disabled - firefox vs IE difference


Hi, say we have the code below on a button:

<input type="button" class="btn" value="Continue" onclick="if
(myform.p_name.value=='') alert('You must enter a name for the folder');
else { this.disabled=true; submit();}">

Not all the validation can be performed client-side so the button may be
pressed and then server validation is performed - this may result in a
request to the user to hit the back button and correct some data
entered.

Now this isn't the best UI design, I know. But nonetheless we have to
stick with this for a qhile and I have noticed a difference in the way
Fireforx and IE handles the button disbaling. On IE, when you go back to
the page, the button is enabled again whereas in Firefox it remains grey
and disabled.

Can anyone suggest a way in which we can automatically re-enable the
button when the user presses the back button? Is there some code we can
put into the onload perhaps which will go through all buttons on the
form and enable them?

Appreciate your suggestions.

--

jeremy
Mar 24 '06 #1
26 21018
Jeremy wrote:
<input type="button" class="btn" value="Continue" onclick="if
(myform.p_name.value=='') alert('You must enter a name for the folder');
else { this.disabled=true; submit();}">
This is nonsense, see below.
Not all the validation can be performed client-side so the button may be
pressed and then server validation is performed - this may result in a
request to the user to hit the back button and correct some data
entered.
And what would be wrong with this? Your application should be able to
handle that anyway.
Now this isn't the best UI design, I know. But nonetheless we have to
stick with this for a qhile
Not at all.
and I have noticed a difference in the way Fireforx and IE handles the
button disbaling. On IE, when you go back to the page, the button is
enabled again whereas in Firefox it remains grey and disabled.

Can anyone suggest a way in which we can automatically re-enable the
button when the user presses the back button? Is there some code we can
put into the onload perhaps which will go through all buttons on the
form and enable them?


No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without client-side
script support.

2. Use the `onsubmit' event handler of the `form' element, and do the form
validation there, by calling a validation function instead of this
badly maintainable spaghetti code. Return `true' to the handler if you
want the form to be submitted, `false' otherwise. Numerous examples of
this have been posted here before. Please do a minimum of research
before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has been
received from that client before, unless the server-side session timed
out, or was actively ended.
PointedEars
Mar 24 '06 #2
In article <12****************@PointedEars.de>, Thomas 'PointedEars'
Lahn says...
No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without client-side
script support.

2. Use the `onsubmit' event handler of the `form' element, and do the form
validation there, by calling a validation function instead of this
badly maintainable spaghetti code. Return `true' to the handler if you
want the form to be submitted, `false' otherwise. Numerous examples of
this have been posted here before. Please do a minimum of research
before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has been
received from that client before, unless the server-side session timed
out, or was actively ended.

Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.

In the short term, as a hack fix (I make no bones about this), it would
meet my needs to be able to simply re-enable the button when the page is
redisplayed after a user has pressed the back button. I think from your
statement above " No. You /have to/ reconsider your design instead. " I
am right in understanding that you are saying that it is not a case of
it not being desirable but a case of it not being possible - is that so?

Thanks again

--

jeremy
Mar 24 '06 #3
While I'm of the opinion that you could rewrite your validation the way
he suggested in the time it takes to post here, I'll be nice and answer
the question as asked ;)

Your best bet is to enable the buttons by name, one after another, in a
simple onload script. If you're doing something quick and dirty, you
might as well. It will work, its just not the prettiest code or the
most efficient way to do it. You do need to name your button and form,
though, or referencing will be a real pain.

Something along the lines of:

<head>
<script>
function mewantbuttons() {
theform.continuebtn.disabled = false;
theform.otherbtns.disabled = false;
}
</script>
</head>
<body onload="mewantbuttons()">
<form NAME="theform">
<input NAME="continuebtn" type="button" class="btn" value="Continue"
onclick="if
(myform.p_name.value=='') alert('You must enter a name for the
folder');
else { this.disabled=true; submit();}">
</form>

----
That said, I agree with Thomas's assessment. It will take you very
little time to write your javascript cleanly to act onsubmit.
Also, I tend to avoid javascript validation myself. If the threat is
that they'd have to re-enter data, I have the server validation give
them their data back pre-filled in the form. The back button won't
always give them their data back, so you shouldn't rely on it.

Mar 24 '06 #4
Jeremy wrote:
[...] Thomas 'PointedEars' Lahn says...
No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without
client-side script support.

2. Use the `onsubmit' event handler of the `form' element, and do the
form validation there, by calling a validation function instead of
this badly maintainable spaghetti code. Return `true' to the handler
if you want the form to be submitted, `false' otherwise. Numerous
examples of this have been posted here before. Please do a minimum
of research before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has
been received from that client before, unless the server-side session
timed out, or was actively ended.
Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.


It is not a question of the browser that is used. That the form would be
usable without client-side script support is a positive side effect of
proper design (using `onsubmit' instead of `onclick'). And who knows --
one member of your closed group might want to access the application with a
mobile device you do not know about yet that does not support client-side
scripting, or simply has it disabled because of some unnerving "features"
"provided" by a number of incompetent people on the Web.
[...] I think from your statement above " No. You /have to/ reconsider
your design instead. " I am right in understanding that you are saying
that it is not a case of it not being desirable but a case of it not
being possible - is that so?


Exactly.
PointedEars
Mar 24 '06 #5
Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:
Jeremy wrote:
[...] Thomas 'PointedEars' Lahn says...
No. You /have to/ reconsider your design instead. Especially:

1. Use a submit button, i.e. input[type="submit"], input[type="image"],
or button[type="submit"] (where the latter two are not backwards
compatible). This way users will be able to submit without
client-side script support.

2. Use the `onsubmit' event handler of the `form' element, and do the
form validation there, by calling a validation function instead of
this badly maintainable spaghetti code. Return `true' to the handler
if you want the form to be submitted, `false' otherwise. Numerous
examples of this have been posted here before. Please do a minimum
of research before you post here; it is a _news_group.

3. Use server-side sessions, so you can detect server-side if data has
been received from that client before, unless the server-side session
timed out, or was actively ended. Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.


It is not a question of the browser that is used.


Do you continue to fail to comprehend what an IntrAnet is? Obviously you
do and keep trying to force everything into a square box when it's round.
That the form would be usable without client-side script support is a
positive side effect of proper design (using `onsubmit' instead of
`onclick'). And who knows -- one member of your closed group might
want to access the application with a mobile device you do not know
about yet that does not support client-side scripting, or simply has
it disabled because of some unnerving "features" "provided" by a number
of incompetent people on the Web.


Can you still not read plain English Thomas?

Let me quote it back to you, you quoted it yourself:

<quote>
The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.
</quote>
[...] I think from your statement above " No. You /have to/ reconsider
your design instead. " I am right in understanding that you are saying
that it is not a case of it not being desirable but a case of it not
being possible - is that so?


Exactly.


Exactly? Sure, Exactly Wrong.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 24 '06 #6
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:
Jeremy wrote:
Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.


It is not a question of the browser that is used.


Do you continue to fail to comprehend what an IntrAnet is?


You have yet to understand what an Intranet is, and that it does
not restrict its users to one user agent, especially not in the
mid-term. Probably you have never used an Intranet before. I have.
PointedEars
Mar 24 '06 #7
*Turns the fire hoses on.* Would be nice to do without the flames...

Randy, the problem here isn't that he doesn't understand, it's that he
has a different philosophical approach. Thomas is looking at it from
the perspective of the future and the unknown. Jeremy can't know if his
closed environment is about to have the doors opened to mobile devices,
or perhaps someone with a visual impairment gets hired to the team, and
the javascript doesn't work for his screen reader, or any other such
scenario. He also can't know if someone on the team has circumvented
him and got permission from "upstairs" to connect his latest
nonstandard toy. If that happens, all this time he's spent developing
QnD solutions (now, and each subsequent time) is wasted. Taking this
opportunity to do it right also makes maintenance in the future much
faster and simple.

I agree with Thomas's thinking on this, just because you believe your
environment is controlled, doesn't mean it really is, or that it will
stay that way. It's called being a conscientious programmer.

Mar 24 '06 #8
Merennulli wrote:
[...]
<head>
<script>
function mewantbuttons() {
theform.continuebtn.disabled = false;
theform.otherbtns.disabled = false;
}
</script>
</head>
<body onload="mewantbuttons()">
<form NAME="theform">
<input NAME="continuebtn" type="button" class="btn" value="Continue"
onclick="if
(myform.p_name.value=='') alert('You must enter a name for the
folder');
else { this.disabled=true; submit();}">
</form>
[...]


Unfortunately(?), your code (even if it was Valid) is not going to do what
it is intended to do. mewantbuttons() will not be called when the Back
feature is used because the `onload' code will not be called then. Not
even if you use Cache-Control in an attempt to prevent caching of the
resource (which is not recommended, though).

We discussed this before; there is no better solution than to drop the idea
of disabling the buttons completely, and to handle the problem on the
server.
Regards,
PointedEars
Mar 25 '06 #9
Thomas 'PointedEars' Lahn said the following on 3/24/2006 1:04 PM:
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 3/24/2006 12:26 PM:
Jeremy wrote:
Thanks. I don't doubt the validity of the points you are making here. I
however am in the best position to be able to determine whether or not
it is feasible at this stage to rewrite the way we handle certain bits
of coding. The application is available to a closed group of users over
whom we can exercise some control over what browsers are used.
It is not a question of the browser that is used. Do you continue to fail to comprehend what an IntrAnet is?


You have yet to understand what an Intranet is, and that it does
not restrict its users to one user agent, especially not in the
mid-term.


Thank you for my daily laugh today Thomas.

What is, or is not, allowed on an intranet can be *very* controlled and
in most environments it is. The fact that you fail to realize that is
indication of your lack of comprehension of what I wrote.
Probably you have never used an Intranet before.
Really? I help manage an Intranet that is larger than your feeble mind
could possibly comprehend. And you know what? I can tell you *precisely*
what UA's are on it and what is and is not allowed on it.
I have.


Logging on at school to do your homework does not count.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 25 '06 #10
Jeremy wrote:
Hi, say we have the code below on a button:

<input type="button" class="btn" value="Continue" onclick="if
(myform.p_name.value=='') alert('You must enter a name for the folder');
else { this.disabled=true; submit();}">

Not all the validation can be performed client-side so the button may be
pressed and then server validation is performed - this may result in a
request to the user to hit the back button and correct some data
entered.

Now this isn't the best UI design, I know. But nonetheless we have to
stick with this for a qhile and I have noticed a difference in the way
Fireforx and IE handles the button disbaling. On IE, when you go back to
the page, the button is enabled again whereas in Firefox it remains grey
and disabled.

Can anyone suggest a way in which we can automatically re-enable the
button when the user presses the back button? Is there some code we can
put into the onload perhaps which will go through all buttons on the
form and enable them?

Appreciate your suggestions.


Sory for the stupid question, but why are you disabling that button in
the first place ? If the user happens to click it again while the next
page is loading, the server validation will fail again.

To the point - since onload will not fire, how about a timer event to
enable the button few seconds after page has been re-rendered (i.e. Back
button pressed) ? Btw. you can save your user pressing the Back button
by sending "Location" in HTTP response header on failed server validation.

Roman
Mar 25 '06 #11
Roman wrote:
Sory for the stupid question, but why are you disabling that button in
the first place ? If the user happens to click it again while the next
page is loading, the server validation will fail again.
I think this was an approach to reduce server load.
To the point - since onload will not fire, how about a timer event to ^^^^^^^^^^^^^^^^^^^^ enable the button few seconds after page has been re-rendered (i.e. Back
button pressed) ?
Because it cannot be detected if this event occurred.
Btw. you can save your user pressing the Back button by sending
"Location" in HTTP response header on failed server validation.


True. Therefore, it is better if the form is generated by a server-side
application. Redirection should be done so that this application can
recognize which input content was wrong or missing, and includes
information into the generated resource about those fields (marking
them in some way.) This allows for easier maintenance of the validator.

The best approach is to use the same application that is used for generating
the form, for server-side validation of the submitted data, so that in a
sense the form submits its data to its own document resource. No further
redirection would be necessary then, and maintenance would be a child's
play.
PointedEars
Mar 25 '06 #12
Merennulli said the following on 3/24/2006 3:14 PM:
*Turns the fire hoses on.* Would be nice to do without the flames...
OK but it wasn't a flame as I would call one.
Randy, the problem here isn't that he doesn't understand, it's that he
has a different philosophical approach.
Thomas has a Theoretical Approach, mine is a Realistic Approach. The
difference is huge.
Thomas is looking at it from the perspective of the future and the unknown.
I disagree with that.
Jeremy can't know if his closed environment is about to have the doors
opened to mobile devices, or perhaps someone with a visual impairment
gets hired to the team, and the javascript doesn't work for his screen
reader, or any other such scenario.
Sure you can. I know, precisely, what devices are and are not allowed on
the Intranet I work on. If I don't, then I can't have security and
considering that our Intranet deals with 10,000+ peoples personal
information a day then security is paramount.

Just out of curiosity though. Do you use CSS in your pages? And, do you
test it without the CSS?

He also can't know if someone on the team has circumvented
him and got permission from "upstairs" to connect his latest
nonstandard toy.
That is one concern that I don't have to deal with. Call it a luxury if
you want. Even my CEO knows how I can behave when somebody does
something that they shouldn't do on the Intranet. And, the person who
"gives permission upstairs" will take a bounce downstairs faster than
you can read this. It has happened and it will probably happen again.
If that happens, all this time he's spent developing
QnD solutions (now, and each subsequent time) is wasted. Taking this
opportunity to do it right also makes maintenance in the future much
faster and simple.

I agree with Thomas's thinking on this, just because you believe your
environment is controlled, doesn't mean it really is, or that it will
stay that way. It's called being a conscientious programmer.


I disagree but we are all entitled to our opinions.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 26 '06 #13
Thomas,
You're right, I didn't think that through all the way. I guess he could
do it onunload, so while the user is going forward it fires, preparing
it for when they come back. This is why I like doing server side code,
you can tie down the interface to controlled points.

Randy,
That's more than a luxury, it borders on being a fantasy world. I've
worked in several IT environments, three of which where I was the
decision maker on application deployment and where the environment was
supposed to be controlled. I have friends in dozens of other IT
environments. No matter how draconian the management structure, I've
never seen or heard of one (other than yours) be able to maintain
absolute control over what will be allowed on the network. Yes, they
can require everything go through checkpoints, but when I've been in
that situation, it mean that we had to support the pet hardware of
influential individuals, it never meant that everyone met our stated
standards or support level. Real security problems such as personal
wireless hubs, yes, that can be barred, but I've never been in a
position that allowed me to tell the president his PDA can't be used to
access our intranet over the existing wireless network.

I hope you don't take offense, but it sounds like even your level of
control is a self deception and part of a BOFH mentality. You even
state "It has happened and it will probably happen again." While you're
referring to the fact that your control of the network is supported, it
also demonstrates that your environment is subject to these unexpected
devices. You're justified in not supporting the devices, since you have
support above you to penalize offenders, but how long before the bubble
bursts and whoever is "bouncing" people downstairs on your behalf isn't
there anymore? Even a CIO can't fire a CEO for naively undermining the
IT infrastructure.

I do use CSS in nearly everything I've done since 2002, including
intranet apps, and I do test for lack of support for CSS, Javascript,
and text only (not inclusive, since both lynx and links currently
support limited Javascript). That sort of testing should be second
nature to any web developer, it shouldn't be a burdon to be dumped at
the first available opportunity.

Even those who stick with our "controlled" environment to the letter
have found ways of breaking my predecessor's pages. He created a notice
mailing form in Visual Studio using grid layout, and didn't lock the
format down with CSS, so people who upped their browser font size were
unable to click in fields where the label ran right over the top of
them. There is no substitute for planning your pages out so they
degrade gracefully.

Mar 28 '06 #14
Merennulli wrote:
Thomas,
You're right, I didn't think that through all the way. I guess he could
do it onunload, so while the user is going forward it fires, preparing
it for when they come back. This is why I like doing server side code,
you can tie down the interface to controlled points.


Not understood. I have never mentioned `onunload' regarding this, I
recommended `onsubmit' (instead of `onclick'). `onunload' code is executed
when one navigates away from the document or the window is closed. That
does not help here because you cannot re-enable the controls later if the
Back feature is used. There is no event to handle this, at least no
interoperable one that I know of.

Please reply to the posting you are referring to, and quote the minimum
of that. NetNews is thread-based, a public discussion displayed as a
tree structure; therefore, your current posting style, originating from
bulletin boards, is not wanted here.

<URL:http://jibbering.com/faq/faq_notes/pots1.html>
PointedEars
Mar 29 '06 #15
Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:
Please reply to the posting you are referring to, and quote the minimum
of that.
Yes, please do.
NetNews is thread-based, a public discussion displayed as a tree structure;
Only if the UA you are using supports tree structures.
therefore, your current posting style, originating from bulletin boards,
is not wanted here.
The current posting style is not wanted, but where or what software they
use is irrelevant as long as they follow the requested norms of posting
here. To say that people who post from "bulletin boards" (GoogleGroups
is *not* a "bulletin board" though) is complete rubbish. This is an open
group and *anybody* is allowed to post here. So please stop telling
people that garbage.
<URL:http://jibbering.com/faq/faq_notes/pots1.html>


Nothing in that document says that "bulletin board posters" are not
wanted here.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 29 '06 #16
Randy Webb <Hi************@aol.com> writes:
Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:
NetNews is thread-based, a public discussion displayed as a tree structure;


Only if the UA you are using supports tree structures.


I'm also unfa,miliar with the name "NetNews". I first thought this was
referring to some web based Usenet gateway.
therefore, your current posting style, originating from bulletin boards,
is not wanted here.


The current posting style is not wanted, but where or what software
they use is irrelevant as long as they follow the requested norms of
posting here.


He didn't say otherwise, but just gave his opinion about the cause of
the style. I would probably have vagered on it being caused by Google
Groups hiding the "reply with quote" button instead of making it the
default.
To say that people who post from "bulletin boards"
(GoogleGroups is *not* a "bulletin board" though) is complete
rubbish. This is an open group and *anybody* is allowed to post
here. So please stop telling people that garbage.


Reread. He didn't.
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Mar 29 '06 #17
Lasse Reichstein Nielsen said the following on 3/29/2006 12:50 AM:
Randy Webb <Hi************@aol.com> writes:
Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:

NetNews is thread-based, a public discussion displayed as a tree structure;

Only if the UA you are using supports tree structures.


I'm also unfa,miliar with the name "NetNews". I first thought this was
referring to some web based Usenet gateway.
therefore, your current posting style, originating from bulletin boards,
is not wanted here.

The current posting style is not wanted, but where or what software
they use is irrelevant as long as they follow the requested norms of
posting here.


He didn't say otherwise, but just gave his opinion about the cause of
the style. I would probably have vagered on it being caused by Google
Groups hiding the "reply with quote" button instead of making it the
default.


Yes, that is the major flaw with Google Groups. If they changed the way
it quotes the only way you could tell it came from Google would be the
headers. But as it is, just seeing a post without being quoted is a
pretty good indication of Google Groups posting.
To say that people who post from "bulletin boards"
(GoogleGroups is *not* a "bulletin board" though) is complete
rubbish. This is an open group and *anybody* is allowed to post
here. So please stop telling people that garbage.


Reread. He didn't.


I had to read it three more times and two cups of coffee to read it a
different way. The first four times I read it I got the implication that
posting from a "bulletin board" is unwanted. I can see where it implies
the posting style and how Google might cause that behavior. He should
have been a little clearer in what he said though.

But for now, he can have the benefit of the doubt on it.

And, this quote is all over Usenet and could have been given or referred to:

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.
<URL: http://www.safalra.com/special/googlegroupsreply/ >

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 29 '06 #18
Lasse Reichstein Nielsen wrote:
Randy Webb <Hi************@aol.com> writes:
Thomas 'PointedEars' Lahn said the following on 3/28/2006 11:17 PM:
NetNews is thread-based, a public discussion displayed as a tree
structure; Only if the UA you are using supports tree structures.


AFAIK "displayed" does not necessarily mean "depicted". The tree structure
is created by Message-ID headers of postings, and References headers of
followups to contain them.
I'm also unfa,miliar with the name "NetNews". I first thought this
was referring to some web based Usenet gateway.


Not at all. NetNews (network news) is the UUCP/NNTP-based communication
medium, with Usenet, including this newsgroup, being a subset of it. It
would be equally correct, but not equally sufficient, to say that Usenet
is thread-based.

<URL:http://en.wikipedia.org/wiki/Usenet>

HTH

Regards,
(F'up2) PointedEars
Mar 29 '06 #19
Thomas 'PointedEars' Lahn wrote:
Not understood. I have never mentioned `onunload' regarding this, I
recommended `onsubmit' (instead of `onclick'). `onunload' code is executed
when one navigates away from the document or the window is closed. That
does not help here because you cannot re-enable the controls later if the
Back feature is used. There is no event to handle this, at least no
interoperable one that I know of.
As I said: "so while the user is going forward it fires, preparing it
for when they come back."
My purpose in mentioning an "onunload" alternative is clear, even
without reading your prior post. Onunload fires as the page is being
exited, so changes it makes would only affect the cached version of the
page. When you hit the back button, you pull up the cached version of
the page (hence the lack of onload), which you already altered as you
left the page. It's not using the back button as an event, it's
preparing the page for when you go back to it.
Please reply to the posting you are referring to, and quote the minimum
of that. NetNews is thread-based, a public discussion displayed as a
tree structure; therefore, your current posting style, originating from
bulletin boards, is not wanted here.


My style of response comes from the fact that I made the apparently
false assumption that everyone here could follow a conversation without
everything repeated any time someone speaks.

There is no policy statement here of how I should post. I quote when
I'm responding to something specific, and I will respond without quotes
when I'm responding to larger sections that require you to have read
the previous post(s) in entirety. These off topic tirades are "not
wanted" as well.

And yes, as Randy suggested, I'm viewing this through Google Groups,
which displays previous posts right above responses, but any decent
mail or news client can sort by topic. I've been on mailing lists and
newsgroups for 8 years, and your insistence on your posting style is
your own preference, not the ubiquitous or official style of a
particular format.

Randy, thank you for your later response that took into account the
interface I'm using and requested I accommodate the structure of your
interface rather than dismissing my response as "not wanted". Needless
abrasiveness such as that "not wanted" is what kills online user
groups.

Mar 31 '06 #20
Merennulli wrote:
Thomas 'PointedEars' Lahn wrote:
Not understood. I have never mentioned `onunload' regarding this, I
recommended `onsubmit' (instead of `onclick'). `onunload' code is
executed when one navigates away from the document or the window is
closed. That does not help here because you cannot re-enable the
controls later if the Back feature is used. There is no event to
handle this, at least no interoperable one that I know of.
As I said: "so while the user is going forward it fires, preparing it
for when they come back."
My purpose in mentioning an "onunload" alternative is clear, even
without reading your prior post. Onunload fires as the page is being
exited, [...]


.... or the window is closed. However, one cannot expect that full DOM
access is still possible at this point, so this approach is flawed.
There is no policy statement here of how I should post. [...]
There is. <URL:http://jibbering.com/faq/#FAQ2_3>
[...] rather than dismissing my response as "not wanted". Needless
abrasiveness such as that "not wanted" is what kills online user
groups.


It is of course not your response that is not wanted on Usenet,
and I never said that; it was merely your _posting style_.
PointedEars
Mar 31 '06 #21
Merennulli said the following on 3/31/2006 5:48 PM:

<snip>
Randy, thank you for your later response that took into account the
interface I'm using and requested I accommodate the structure of your
interface rather than dismissing my response as "not wanted".
I did not say your reply was "not wanted". It is the style of posting
that Google Groups encourages that is not wanted here. The lack of quoting.
Needless abrasiveness such as that "not wanted" is what kills online user
groups.


No, what kills "online user groups" is people who want help that won't
follow the accepted conventions of those user groups.

Question: What's the worst thing to happen to Usenet in the last 15 years?
Answer: Google Groups

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Apr 1 '06 #22
> > There is no policy statement here of how I should post. [...]

There is. <URL:http://jibbering.com/faq/#FAQ2_3>


Under the heading "comp.lang.javascript tips".

Sorry, but tips != policy.

Further, it even suggests using Google Groups to read replies. Had you
read your own source, we wouldn't be having this discussion.

I'm done arguing this.

Apr 3 '06 #23
VK

Randy Webb wrote:
Question: What's the worst thing to happen to Usenet in the last 15 years?
Answer: Google Groups


<http://groups.google.com/group/comp.archives/browse_frm/thread/fdc8cfcfde8518e1/ad173ff36141539f?lnk=st&q=%22World+Wide+Web%22&rnu m=13&hl=en#ad173ff36141539f>

Now the task: by using "World Wide Web" search string (plus date range)
get me this thread out of your most beloved newsreader.

It is a blessure that DejaNews came to the idea. And it is another
blessure that Google took it over. I agree that new owner could be
possibly more generous and more interface caring. But at the dark
after-bubble period it could be as well thrown to the trash as soon as
the owner went under. I know a lot of cases of this kind happened with
rather useful databases and codes at 2000-2001.

Yes Google is pushing for non-quoting posting because they (as DejaNews
before) structure the data by threads and topics, not by individual
messages. But this push is rather soft: no prohibitions, just two extra
click - easy to bypass.

Apr 3 '06 #24
VK said the following on 4/3/2006 2:45 PM:
Randy Webb wrote:
Question: What's the worst thing to happen to Usenet in the last 15 years?
Answer: Google Groups
<http://groups.google.com/group/comp.archives/browse_frm/thread/fdc8cfcfde8518e1/ad173ff36141539f?lnk=st&q=%22World+Wide+Web%22&rnu m=13&hl=en#ad173ff36141539f>

Now the task: by using "World Wide Web" search string (plus date range)
get me this thread out of your most beloved newsreader.


You missed the total point of what I meant by not quoting fully (and in
context) what I said.
Yes Google is pushing for non-quoting posting


<snip>

And that is *precisely* the problem with Google Groups now and what
makes it the worst thing to happen to Usenet in 15 years. It is so
widespread (Google Groups) that newbes think its the way it should be
when it isn't.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Apr 4 '06 #25
VK

Randy Webb wrote:
VK said the following on 4/3/2006 2:45 PM:
Yes Google is pushing for non-quoting posting
And that is *precisely* the problem with Google Groups now and what
makes it the worst thing to happen to Usenet in 15 years. It is so
widespread (Google Groups) that newbes think its the way it should be
when it isn't.


The question is why is Google doing it? I dare to guess it is not
because of some anti-Usenet conspiracy. The infospace pullution is one
of biggest problems of Internet. It is so often hard to find some
really iseful info because it is being burried in the "noise" which is
difficult/impossible to filter out even by the best search engines. In
this aspect quoting definitely adds more "infonoise".

X wrote:
I have a problem A
-----
Y wrote: I have a problem A

Here is solution B
-----
X wrote:
I have a problem A

Here is solution B

<snip>
A have a question about your solution.
-----
Y wrote:
I have a problem A

Here is solution B

<snip>
A have a question about your solution.

Here is my answer.

etc.

It is easy to predict that the search engine will get a hard time to
get the *right* post on request "problem A solution". At the same time
getting the right *thread* will ensure that (after some extra reading)
the right post will be found.

Just don't shoot - first listen! ;-) I am not calling for "drop the
quoting". But IMHO the traditional Usenet quoting rules should be
changed to the most fat-free variant.

Apr 5 '06 #26
VK said the following on 4/5/2006 7:39 AM:
Randy Webb wrote:
VK said the following on 4/3/2006 2:45 PM:
Yes Google is pushing for non-quoting posting And that is *precisely* the problem with Google Groups now and what
makes it the worst thing to happen to Usenet in 15 years. It is so
widespread (Google Groups) that newbes think its the way it should be
when it isn't.


The question is why is Google doing it? I dare to guess it is not
because of some anti-Usenet conspiracy. The infospace pullution is one
of biggest problems of Internet. It is so often hard to find some
really iseful info because it is being burried in the "noise" which is
difficult/impossible to filter out even by the best search engines. In
this aspect quoting definitely adds more "infonoise".


If Google wants to minimize the space it needs to store data, then they
can start there own forum. But, they are trying to change a very long
standing procedure in Usenet for there own benefit. The ends don't
justify the means.
X wrote:
I have a problem A
-----
Y wrote:
I have a problem A Here is solution B
-----
X wrote:
I have a problem A

Here is solution B

<snip>
A have a question about your solution.
-----
Y wrote:
I have a problem A
Here is solution B

<snip>
A have a question about your solution.

Here is my answer.

etc.

It is easy to predict that the search engine will get a hard time to
get the *right* post on request "problem A solution". At the same time
getting the right *thread* will ensure that (after some extra reading)
the right post will be found.


No, it will find the right post. Google particularly. It doesn't return
individual hits for the same thread, it returns one hit to that thread
(test it).
Just don't shoot - first listen! ;-) I am not calling for "drop the
quoting". But IMHO the traditional Usenet quoting rules should be
changed to the most fat-free variant.
Now, take the reverse side. The people that are in the best position to
actually give good answers don't use Google Groups to post. And they
have become accustomed to quoting, for very good reasons. If a post
isn't quoted, then I have two choices:

1) Ignore the thread
2) Go find the thread and read the entire thread to get an idea about
the conversation.

If the "experts" (I use that term loosely) continue to ignore threads
then Usenet goes to hell. You end up with a bunch of crap answers. And
Usenet is not for the benefit of Google, it is for the benefit of its
users. And the users benefit the most from quoting.

Let me give the flip side of your example though:

X wrote:
I have a problem A
-----
Y wrote:
Here is solution B
-----
X wrote:
A have a question about your solution.
-----
Y wrote:
Here is my answer.

Now, let's assume that each of those four posts are made on different
days. And, that each post is 40 lines long. If I want to know what the
answer was for, I now have to read four posts instead of one to find
out. How is that more efficient than reading this?
Y wrote:
I have a problem A
Here is solution B

<snip>
A have a question about your solution.

Here is my answer.


--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Apr 5 '06 #27

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by bart plessers | last post: by
7 posts views Thread by John Smith | last post: by
1 post views Thread by Phil_Cam | last post: by
11 posts views Thread by Joey | last post: by
1 post views Thread by CARIGAR | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.