Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #12419 > unrolled thread

on*= Clauses: When to return

Back to article view | Back to comp.lang.javascript

Contents

  on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-05 11:20 -0800
    Re: on*= Clauses: When to return "Mel Smith" <med_cutout_syntel@aol.com> - 2012-03-05 14:03 -0700
      Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-05 15:11 -0800
        Re: on*= Clauses: When to return "Evertjan." <exjxw.hannivoort@interxnl.net> - 2012-03-06 12:15 +0000
        Re: on*= Clauses: When to return Dr J R Stockton <reply1210@merlyn.demon.co.uk> - 2012-03-06 19:06 +0000
    Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 17:13 -0700
      Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-12 19:58 -0700
        Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 20:20 -0700
          Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-12 22:15 -0700
            Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-12 22:29 -0700
              Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-13 08:56 -0700
                Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 10:42 -0700
                  Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-13 12:53 -0700
                    Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 15:18 -0700
                      Re: on*= Clauses: When to return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-14 00:17 +0100
                      Re: on*= Clauses: When to return Gene Wirchenko <genew@ocis.net> - 2012-03-13 19:48 -0700
                        Re: on*= Clauses: When to return David Mark <dmark.cinsoft@gmail.com> - 2012-03-13 20:55 -0700
          Re: on*= Clauses: When to return Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-03-13 23:10 +0100

#12419 — on*= Clauses: When to return

Dear JavaScripters:

     In my working with on* clauses, one confusion I had was when to
return and when not to.  For example, with onblur, the return is
needed, as in:
          <input name=Sample onblur="return SampleTest();">
but this is not the case for every on* clause.

     I have not been able to find this documented anywhere.  I would
appreciate a good pointer.

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#12420

Gene said:

> return and when not to.  For example, with onblur, the return is
> needed, as in:
>          <input name=Sample onblur="return SampleTest();">

    I don't see anywhere in my 'Bible' that the onblur requires a return 
(either true or false).

    (But perhaps *you* need a return for you own requirements ?? )

-Mel

[toc] | [prev] | [next] | [standalone]

#12421

On Mon, 5 Mar 2012 14:03:42 -0700, "Mel Smith"
<med_cutout_syntel@aol.com> wrote:

>Gene said:
>
>> return and when not to.  For example, with onblur, the return is
>> needed, as in:
>>          <input name=Sample onblur="return SampleTest();">
>
>    I don't see anywhere in my 'Bible' that the onblur requires a return 
>(either true or false).
>
>    (But perhaps *you* need a return for you own requirements ?? )

     How can I tell is the problem.  I am fine with ignoring return
values if I do not need them.  I would like to know if they are
available, and if they are, what they mean.  That data is sadly
lacking where I have been looking.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12429

Gene Wirchenko wrote on 06 mrt 2012 in comp.lang.javascript:

> On Mon, 5 Mar 2012 14:03:42 -0700, "Mel Smith"
> <med_cutout_syntel@aol.com> wrote:
> 
>>Gene said:
>>
>>> return and when not to.  For example, with onblur, the return is
>>> needed, as in:
>>>          <input name=Sample onblur="return SampleTest();">
>>
>>    I don't see anywhere in my 'Bible' that the onblur requires a
>>    return 
>>(either true or false).
>>
>>    (But perhaps *you* need a return for you own requirements ?? )
> 
>      How can I tell is the problem.  I am fine with ignoring return
> values if I do not need them.

Wrong conclusion. 
Return values do not ask you if you need them.

> I would like to know if they are
> available, and if they are, what they mean.  That data is sadly
> lacking where I have been looking.

Effectively there always is a return value.
[unless the javascript gives an error, perhaps?]
If there is no return value then true is defaultly assumed.

ONLY a return false acts the prohibit the normal html-action.

Since losing focus has no default html-action, 
the onblurr return value is not used.
[same for onfocus]  

With onclick and onsubmit, however, 
have prohitable default actions:

<a href='..' onclick='return false'>click me and nothing happens</a>

<form onsubmit='return false'>
<input type='submit' value='click me and no submission will be done'>
</form>


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

[toc] | [prev] | [next] | [standalone]

#12457

In comp.lang.javascript message <1vhal7hqn0kphr4enfge9pt5n8bcldcrbd@4ax.
com>, Mon, 5 Mar 2012 15:11:23, Gene Wirchenko <genew@ocis.net> posted:

>     How can I tell is the problem.  I am fine with ignoring return
>values if I do not need them.  I would like to know if they are
>available, and if they are, what they mean.  That data is sadly
>lacking where I have been looking.

It seems clear enough in the first 3 pages of chapter 15 "Events and
Event Handling" of 3rd Edition Flanagan (see FAQ) - and it's probable
(a) right, (b) easily found in later editions.  Easily found in Goodman
2nd Edn too.

The answer should, I think, be in <http://www.w3.org/DOM/DOMTR>.  Or
<https://developer.mozilla.org/en/Gecko_DOM_Reference/Introduction#What_
is_the_DOM.3F>.

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
 Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
 Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[toc] | [prev] | [next] | [standalone]

#12625

On Mar 5, 3:20 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> Dear JavaScripters:
>
>      In my working with on* clauses, one confusion I had was when to
> return and when not to.  For example, with onblur, the return is
> needed, as in:
>           <input name=Sample onblur="return SampleTest();">

What makes you think that's needed? And for what?

[toc] | [prev] | [next] | [standalone]

#12632

On Mon, 12 Mar 2012 17:13:06 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 5, 3:20 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> Dear JavaScripters:
>>
>>      In my working with on* clauses, one confusion I had was when to
>> return and when not to.  For example, with onblur, the return is
>> needed, as in:
>>           <input name=Sample onblur="return SampleTest();">
>
>What makes you think that's needed? And for what?

     I want to know when it is required, and when it is not.  I have
seen it used without differentiation as to when it is required.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12634

On Mar 12, 10:58 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 12 Mar 2012 17:13:06 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 5, 3:20 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> Dear JavaScripters:
>
> >>      In my working with on* clauses, one confusion I had was when to
> >> return and when not to.  For example, with onblur, the return is
> >> needed, as in:
> >>           <input name=Sample onblur="return SampleTest();">
>
> >What makes you think that's needed? And for what?
>
>      I want to know when it is required, and when it is not.  I have
> seen it used without differentiation as to when it is required.

Returning false prevents the default behavior for *some* events. When
and why would you want to prevent a blur? ISTM that you can't any more
than you can prevent the focus behavior. Those events are fired after
the behavior has occurred.

[toc] | [prev] | [next] | [standalone]

#12637

On Mon, 12 Mar 2012 20:20:18 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 12, 10:58 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Mon, 12 Mar 2012 17:13:06 -0700 (PDT), David Mark
>>
>> <dmark.cins...@gmail.com> wrote:
>> >On Mar 5, 3:20 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> >> Dear JavaScripters:
>>
>> >>      In my working with on* clauses, one confusion I had was when to
>> >> return and when not to.  For example, with onblur, the return is
>> >> needed, as in:
>> >>           <input name=Sample onblur="return SampleTest();">
>>
>> >What makes you think that's needed? And for what?
>>
>>      I want to know when it is required, and when it is not.  I have
>> seen it used without differentiation as to when it is required.
>
>Returning false prevents the default behavior for *some* events. When

     My problem in this area is that I do not know which ones those
are, and I have not run across any docs that say.

>and why would you want to prevent a blur? ISTM that you can't any more

     I want something to happen as a result of the blur: the
validation.

>than you can prevent the focus behavior. Those events are fired after
>the behavior has occurred.

     With some clever code for the error case, I make it as if the
blur did not happen.  The focus gets set back to the erroneous
control.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12638

On Mar 13, 1:15 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 12 Mar 2012 20:20:18 -0700 (PDT), David Mark
>
>
>
>
>
>
>
>
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 12, 10:58 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> On Mon, 12 Mar 2012 17:13:06 -0700 (PDT), David Mark
>
> >> <dmark.cins...@gmail.com> wrote:
> >> >On Mar 5, 3:20 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> >> Dear JavaScripters:
>
> >> >>      In my working with on* clauses, one confusion I had was when to
> >> >> return and when not to.  For example, with onblur, the return is
> >> >> needed, as in:
> >> >>           <input name=Sample onblur="return SampleTest();">
>
> >> >What makes you think that's needed? And for what?
>
> >>      I want to know when it is required, and when it is not.  I have
> >> seen it used without differentiation as to when it is required.
>
> >Returning false prevents the default behavior for *some* events. When
>
>      My problem in this area is that I do not know which ones those
> are, and I have not run across any docs that say.

The DOM specs on the W3C site surely cover this.

>
> >and why would you want to prevent a blur? ISTM that you can't any more
>
>      I want something to happen as a result of the blur: the
> validation.
>
> >than you can prevent the focus behavior. Those events are fired after
> >the behavior has occurred.
>
>      With some clever code for the error case, I make it as if the
> blur did not happen.  The focus gets set back to the erroneous
> control.

You shouldn't do that even if you could.

[toc] | [prev] | [next] | [standalone]

#12644

On Mon, 12 Mar 2012 22:29:16 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 13, 1:15 am, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Mon, 12 Mar 2012 20:20:18 -0700 (PDT), David Mark
>> <dmark.cins...@gmail.com> wrote:

[snip]

>>      My problem in this area is that I do not know which ones those
>> are, and I have not run across any docs that say.
>
>The DOM specs on the W3C site surely cover this.

     I will have a look.  Half the battle seems to be finding which
docs to read.

>> >and why would you want to prevent a blur? ISTM that you can't any more
>>
>>      I want something to happen as a result of the blur: the
>> validation.
>>
>> >than you can prevent the focus behavior. Those events are fired after
>> >the behavior has occurred.
>>
>>      With some clever code for the error case, I make it as if the
>> blur did not happen.  The focus gets set back to the erroneous
>> control.
>
>You shouldn't do that even if you could.

     I can do it, and I am doing it.  It is required for decent data
entry according to the way that we like it.

     I find silly the idea that DE methods that have worked for years
and years have to be tossed <fanfare> because of the Web.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12649

On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:
> On Mon, 12 Mar 2012 22:29:16 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 13, 1:15 am, Gene Wirchenko <ge...@ocis.net> wrote:
> >> On Mon, 12 Mar 2012 20:20:18 -0700 (PDT), David Mark
> >> <dmark.cins...@gmail.com> wrote:
>
> [snip]
>
> >>      My problem in this area is that I do not know which ones those
> >> are, and I have not run across any docs that say.
>
> >The DOM specs on the W3C site surely cover this.
>
>      I will have a look.  Half the battle seems to be finding which
> docs to read.
>
> >> >and why would you want to prevent a blur? ISTM that you can't any more
>
> >>      I want something to happen as a result of the blur: the
> >> validation.
>
> >> >than you can prevent the focus behavior. Those events are fired after
> >> >the behavior has occurred.
>
> >>      With some clever code for the error case, I make it as if the
> >> blur did not happen.  The focus gets set back to the erroneous
> >> control.
>
> >You shouldn't do that even if you could.
>
>      I can do it, and I am doing it.'

You can't prevent the blur, but you can try to simulate that. Good
luck.

> It is required for decent data
> entry according to the way that we like it.
>
>      I find silly the idea that DE methods that have worked for years
> and years have to be tossed <fanfare> because of the Web.

AFAIK, nobody ever thought that was a good idea in GUI design.

>
> Sincerely,
>
> Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12657

On Tue, 13 Mar 2012 10:42:25 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:

[snip]

>You can't prevent the blur, but you can try to simulate that. Good
>luck.

     No luck.  Already done.  I am coding for use in IE 9 only for
now, and it works reliably.

     Well, I may need a bit of luck later.  I recently found out that
my focus reset does not work in Firefox 10.  I looked at one possible
culprit, but that was not it.  Something for a bit later.

     I have tried to avoid coding using IE 9-isms, but maybe I missed
on something.  Or maybe, it is a bug.  I already found a minor bug in
IE 9's handling of textarea data input.

>> It is required for decent data
>> entry according to the way that we like it.
>>
>>      I find silly the idea that DE methods that have worked for years
>> and years have to be tossed <fanfare> because of the Web.
>
>AFAIK, nobody ever thought that was a good idea in GUI design.

     Which one are you talking about?

     The things that I am referring to are such things as input fields
that accurately reflect how much data will fit, immediate data cleanup
(e.g. capitalising Postal Codes), validation by data type (e.g.
checking that a value input for a date is a valid date), and
validation by data item (e.g. checking that a new client code does not
already exist).

     Unfortunately, many Web pages do not deal with this very well.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12662

On Mar 13, 3:53 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 13 Mar 2012 10:42:25 -0700 (PDT), David Mark
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:
>
> [snip]
>
> >You can't prevent the blur, but you can try to simulate that. Good
> >luck.
>
>      No luck.  Already done.  I am coding for use in IE 9 only for
> now, and it works reliably.

Okay.

>
>      Well, I may need a bit of luck later.  I recently found out that
> my focus reset does not work in Firefox 10.

I imagine you were braced for that. :)

> I looked at one possible
> culprit, but that was not it.  Something for a bit later.

It's difficult if you don't understand exactly why something works (or
doesn't). Too often in this industry, developers consider anything
that appears to work in a subset of "all browsers" to be correct. In
other words, conflating logic with observation. It leads to nothing
but aggravation when something "breaks" and you don't even know why it
was "working" in the first place. ;)

>
>      I have tried to avoid coding using IE 9-isms, but maybe I missed
> on something.

What ism's would that be?  DirectX?

> Or maybe, it is a bug.  I already found a minor bug in
> IE 9's handling of textarea data input.

I've found a lot of bugs with its debugger (what a piece of junk).

>
> >> It is required for decent data
> >> entry according to the way that we like it.
>
> >>      I find silly the idea that DE methods that have worked for years
> >> and years have to be tossed <fanfare> because of the Web.
>
> >AFAIK, nobody ever thought that was a good idea in GUI design.
>
>      Which one are you talking about?

Stealing the focus, particularly after a tab.

>
>      The things that I am referring to are such things as input fields
> that accurately reflect how much data will fit, immediate data cleanup
> (e.g. capitalising Postal Codes), validation by data type (e.g.
> checking that a value input for a date is a valid date), and
> validation by data item (e.g. checking that a new client code does not
> already exist).

Yes, I am dealing with all of those things in my current project, but
I don't steal the focus to do it.

>
>      Unfortunately, many Web pages do not deal with this very well.

Many Web pages do not deal with anything very well. :(

[toc] | [prev] | [next] | [standalone]

#12664

David Mark wrote:

> Gene Wirchenko wrote:
>> David Mark wrote:
>> >On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:
>>
>> [snip]
>>
>> >You can't prevent the blur, but you can try to simulate that. Good
>> >luck.
>>
>> No luck.  Already done.  I am coding for use in IE 9 only for
>> now, and it works reliably.
> 
> Okay.
> 
>> Well, I may need a bit of luck later.  I recently found out that
>> my focus reset does not work in Firefox 10.
> 
> I imagine you were braced for that. :)

A correct assumption.

>> I looked at one possible
>> culprit, but that was not it.  Something for a bit later.
> 
> It's difficult if you don't understand exactly why something works (or
> doesn't). Too often in this industry, developers consider anything
> that appears to work in a subset of "all browsers" to be correct. In
> other words, conflating logic with observation. It leads to nothing
> but aggravation when something "breaks" and you don't even know why it
> was "working" in the first place. ;)
> […]
>> >> It is required for decent data
>> >> entry according to the way that we like it.
>>
>> >> I find silly the idea that DE methods that have worked for years
>> >> and years have to be tossed <fanfare> because of the Web.
>>
>>> AFAIK, nobody ever thought that was a good idea in GUI design.
>> Which one are you talking about?
> 
> Stealing the focus, particularly after a tab.

JFTR: This is a typical beginner's mistake, and so is the notion that it 
would be appropriate if web code only worked in one (version of) one 
browser.

"Intranet", you say?  Intranets do change, and the more they depend on 
features or behavior of a particular browser or browser version, the more 
expensive is the adoption of another, probably faster and more secure 
browser, as the planned small changes will gradually evolve into a full 
rewrite.  I have been there before.

As for calling focus() on blur, precisely because that is bad UI design, 
working against the user's expectations and making a web form inaccessible, 
the Gecko code contains precautions to prevent trapping the user in a 
control.  It's not a bug, it's a feature.  And if IE does not have it by 
now, it is going to; perhaps in version 10.

The more wannabes abuse features, and the more users are complaining about 
that, the more likely is it that vendors will make efforts to prevent that 
kind of abuse.  This can be seen, for example, when comparing the user 
preferences dialogs to restrict certain aspects of web scripting between 
Firefox 1 and Firefox 10: the latter does not even have the former's option 
to prevent scripts from changing the status bar text anymore, as that is 
disallowed by default now.  Likewise for other browsers and versions.

Who writes code on the basis that it is working reliably today, is writing 
code for the trash.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#12676

On Tue, 13 Mar 2012 15:18:19 -0700 (PDT), David Mark
<dmark.cinsoft@gmail.com> wrote:

>On Mar 13, 3:53 pm, Gene Wirchenko <ge...@ocis.net> wrote:
>> On Tue, 13 Mar 2012 10:42:25 -0700 (PDT), David Mark
>>
>> <dmark.cins...@gmail.com> wrote:
>> >On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:
>>
>> [snip]
>>
>> >You can't prevent the blur, but you can try to simulate that. Good
>> >luck.
>>
>>      No luck.  Already done.  I am coding for use in IE 9 only for
>> now, and it works reliably.
>
>Okay.

>>      Well, I may need a bit of luck later.  I recently found out that
>> my focus reset does not work in Firefox 10.
>
>I imagine you were braced for that. :)

    No.  Surprised.  A co-worker tried to break my test page in IE 9
and was unable to.

>> I looked at one possible
>> culprit, but that was not it.  Something for a bit later.
>
>It's difficult if you don't understand exactly why something works (or
>doesn't). Too often in this industry, developers consider anything
>that appears to work in a subset of "all browsers" to be correct. In
>other words, conflating logic with observation. It leads to nothing
>but aggravation when something "breaks" and you don't even know why it
>was "working" in the first place. ;)

     I know.  I am trying very hard to work out why things work as
they do.

>>      I have tried to avoid coding using IE 9-isms, but maybe I missed
>> on something.
>
>What ism's would that be?  DirectX?

     I do not know.  I have not knowingly used any.  tabindex=-1 is
the worst of my knowing kludges.

>> Or maybe, it is a bug.  I already found a minor bug in
>> IE 9's handling of textarea data input.
>
>I've found a lot of bugs with its debugger (what a piece of junk).

     I have found the debugger of very limited use.

>> >> It is required for decent data
>> >> entry according to the way that we like it.
>>
>> >>      I find silly the idea that DE methods that have worked for years
>> >> and years have to be tossed <fanfare> because of the Web.
>>
>> >AFAIK, nobody ever thought that was a good idea in GUI design.
>>
>>      Which one are you talking about?
>
>Stealing the focus, particularly after a tab.

     Whereas I think it silly for a control to lose focus when its
onblur fails.

>>      The things that I am referring to are such things as input fields
>> that accurately reflect how much data will fit, immediate data cleanup
>> (e.g. capitalising Postal Codes), validation by data type (e.g.
>> checking that a value input for a date is a valid date), and
>> validation by data item (e.g. checking that a new client code does not
>> already exist).
>
>Yes, I am dealing with all of those things in my current project, but
>I don't steal the focus to do it.

     I want the focus on the erroneous control, so the error can be
corrected right away.

>>      Unfortunately, many Web pages do not deal with this very well.
>
>Many Web pages do not deal with anything very well. :(

     Yes, one of my instructors had a fair amount to say about that.
His family name?  O'Neil.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#12682

On Mar 13, 10:48 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> On Tue, 13 Mar 2012 15:18:19 -0700 (PDT), David Mark
>
>
>
>
>
>
>
>
>
> <dmark.cins...@gmail.com> wrote:
> >On Mar 13, 3:53 pm, Gene Wirchenko <ge...@ocis.net> wrote:
> >> On Tue, 13 Mar 2012 10:42:25 -0700 (PDT), David Mark
>
> >> <dmark.cins...@gmail.com> wrote:
> >> >On Mar 13, 11:56 am, Gene Wirchenko <ge...@ocis.net> wrote:
>
> >> [snip]
>
> >> >You can't prevent the blur, but you can try to simulate that. Good
> >> >luck.
>
> >>      No luck.  Already done.  I am coding for use in IE 9 only for
> >> now, and it works reliably.
>
> >Okay.
> >>      Well, I may need a bit of luck later.  I recently found out that
> >> my focus reset does not work in Firefox 10.
>
> >I imagine you were braced for that. :)
>
>     No.  Surprised.  A co-worker tried to break my test page in IE 9
> and was unable to.

The observations of your co-worker are not an indicator of anything,
other than your code seems to work in IE 9 in whatever configuration
you use. Programming is about logic, not observation.

>
> >> I looked at one possible
> >> culprit, but that was not it.  Something for a bit later.
>
> >It's difficult if you don't understand exactly why something works (or
> >doesn't). Too often in this industry, developers consider anything
> >that appears to work in a subset of "all browsers" to be correct. In
> >other words, conflating logic with observation. It leads to nothing
> >but aggravation when something "breaks" and you don't even know why it
> >was "working" in the first place. ;)
>
>      I know.  I am trying very hard to work out why things work as
> they do.
>
> >>      I have tried to avoid coding using IE 9-isms, but maybe I missed
> >> on something.
>
> >What ism's would that be?  DirectX?
>
>      I do not know.  I have not knowingly used any.  tabindex=-1 is
> the worst of my knowing kludges.

You shouldn't need to worry about that, unless you did in the static
markup.  I have been doing that for many years without incident and
apparently it is going to be "legalized" (per HTML5) in the near
future.  Still, a try-catch around it is a sound idea as a silent
failure won't hurt anything in this case.

>
> >> Or maybe, it is a bug.  I already found a minor bug in
> >> IE 9's handling of textarea data input.
>
> >I've found a lot of bugs with its debugger (what a piece of junk).
>
>      I have found the debugger of very limited use.
>
> >> >> It is required for decent data
> >> >> entry according to the way that we like it.
>
> >> >>      I find silly the idea that DE methods that have worked for years
> >> >> and years have to be tossed <fanfare> because of the Web.
>
> >> >AFAIK, nobody ever thought that was a good idea in GUI design.
>
> >>      Which one are you talking about?
>
> >Stealing the focus, particularly after a tab.
>
>      Whereas I think it silly for a control to lose focus when its
> onblur fails.
>
> >>      The things that I am referring to are such things as input fields
> >> that accurately reflect how much data will fit, immediate data cleanup
> >> (e.g. capitalising Postal Codes), validation by data type (e.g.
> >> checking that a value input for a date is a valid date), and
> >> validation by data item (e.g. checking that a new client code does not
> >> already exist).
>
> >Yes, I am dealing with all of those things in my current project, but
> >I don't steal the focus to do it.
>
>      I want the focus on the erroneous control, so the error can be
> corrected right away.

Why?  Let them do whatever it is they want to do until the form is to
be submitted.

>
> >>      Unfortunately, many Web pages do not deal with this very well.
>
> >Many Web pages do not deal with anything very well. :(
>
>      Yes, one of my instructors had a fair amount to say about that.
> His family name?  O'Neil.

Don't think I know him, but if he agrees on that point he's okay. ;)

[toc] | [prev] | [next] | [standalone]

#12660

David Mark wrote:

> Gene Wirchenko wrote:
>> David Mark wrote:
>> > Gene Wirchenko wrote:
>> >> Dear JavaScripters:
>> >> 
>> >> In my working with on* clauses, one confusion I had was when to
>> >> return and when not to.  For example, with onblur, the return is
>> >> needed, as in:
>> >> <input name=Sample onblur="return SampleTest();">
>>
>> >What makes you think that's needed? And for what?
>>
>> I want to know when it is required, and when it is not.  I have
>> seen it used without differentiation as to when it is required.
> 
> Returning false prevents the default behavior for *some* events. When
> and why would you want to prevent a blur? ISTM that you can't any more
> than you can prevent the focus behavior. Those events are fired after
> the behavior has occurred.

For some event types, returning `true' does the same thing as returning 
`false' for others.  I had started detailing this at 
<https://developer.mozilla.org/en/DOM_Client_Object_Cross-
Reference/DOM_Events>.  Any good updates are welcome.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web