> > DOM 1 reached recommendation status in 1998 > > Sorry but I don't recall if it's first recommendation included the > "document.getElemen..." > statement in its apearence. If you don't recall, then why not look? http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835 > It was DOM Level 2 that invented e different statement for > the same purpose and reached recommendation status only a month > before 2001. Incorrect, see above. > Eventhough FX didn't hesitate to implement it, but did it maliciously. Firefox implemented the standard ... maliciously. That makes no sense whatsoever. > Same goes with the famous .innerHTML. Firefox implemented innerHTML because lots of websites used it (because Microsoft implemented instead of promoting the standard, and IE was commonly used). I don't see any maliciousness there either. I don't see Firefox's implementation breaking when you edit the inside of tables either. > > It lent itself to write-only code, they didn't consult with anyone > > before implementing it, the standards group (including Microsoft) > came > > up with something better. > > :) Like What? document.getElementById > And what do you understand with "write-only"? That when someone comes along to read the code, it is not obvious where the variable is being declared (since it is generated by being associated with an HTML document, not from within the script itself). This results in code which is hard to edit. > What do you mean with "they didn't consult with anyone"? That they implemented it rather then proposing it to the standards group that they are, and were, a member of. > Do you understand that this acusation is a direct answer to the > question: -Who was, and still is hollding up the web??? I don't really care what it is in answer to. It is packed full of factual errors. > Don't forget that it was only in December 1997 that HTML 4.0 added > support for tables. > Can you imagine? -Tables! Right. Yes. HTML 4.0. Of course. http://www.w3.org/TR/REC-html32#table The whole situation with HTML at the time was a mess. It didn't help that browser vendors ran around implementing , and instead of trying to develop something good. So HTML 3 was scrapped and HTML 3.2 came along to document what they had some up with. > W3C recommended "document.getElement" a month before 2001, while > IE4-was allready three years old and running. Incorrect, see above. > So it was, still is, and allways will be, W3C. That statement is based on a number of false premises. -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From david at dorward.me.uk Thu Apr 17 01:22:54 2008 From: david at dorward.me.uk (David Dorward) Date: Thu, 17 Apr 2008 07:22:54 +0100 Subject: [Javascript] IE onclick problem In-Reply-To: <4806AE6A.6010506@denhaag.org> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> Message-ID: > So I would argue that 'onsubmit="return checkMyForm()"' should read > 'onsubmit="checkMyForm()"' It shouldn't. > since the handler function itself returns a > true or false value to the onsubmit event It doesn't. If you don't use a return statement, nothing is returned. -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From schneegans at internetique.com Thu Apr 17 07:52:00 2008 From: schneegans at internetique.com (Claude Schneegans) Date: Thu, 17 Apr 2008 08:52:00 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <4806AE6A.6010506@denhaag.org> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> Message-ID: <480747F0.6050908@internetique.com> >>since the handler function itself returns a true or false value to the onsubmit event, thereby cancelling or granting the submit event. You're right, there was some confusion on my side. From tedd at sperling.com Thu Apr 17 07:54:04 2008 From: tedd at sperling.com (tedd) Date: Thu, 17 Apr 2008 08:54:04 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <4806AE6A.6010506@denhaag.org> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> Message-ID: At 3:56 AM +0200 4/17/08, J. Lester Novros II wrote: >So I would argue that 'onsubmit="return checkMyForm()"' should read >'onsubmit="checkMyForm()"' since the handler function itself returns a >true or false value to the onsubmit event, thereby cancelling or granting >the submit event. Well -- it doesn't work that way for me. Here's a form where I use it: http://webbytedd.com/c/form-submit/ 'onsubmit=return checkMyForm()" <-- works where 'onsubmit=checkMyForm()" <-- doesn't Or is there something here I'm not understanding? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From java.script at cutterscrossing.com Thu Apr 17 08:06:21 2008 From: java.script at cutterscrossing.com (Cutter (JSRelated)) Date: Thu, 17 Apr 2008 08:06:21 -0500 Subject: [Javascript] IE onclick problem In-Reply-To: References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> Message-ID: <48074B4D.8070406@cutterscrossing.com> There must be something you're misunderstanding. I have hundreds of forms out there with onsubmit="validate()" (before I knew better). The validate function returns true or false, which either cancels the event or allows it depending on that return. Create a quick test case: function checkMyForm(){ return false; // Manually toggle this for your test } Then make a quick test form with onsubmit="checkMyForm()" to see what happens. Don't even worry about logic or other functionality right now, just the quick test case... Steve "Cutter" Blades Adobe Certified Professional Advanced Macromedia ColdFusion MX 7 Developer _____________________________ http://blog.cutterscrossing.com tedd wrote: > At 3:56 AM +0200 4/17/08, J. Lester Novros II wrote: >> So I would argue that 'onsubmit="return checkMyForm()"' should read >> 'onsubmit="checkMyForm()"' since the handler function itself returns a >> true or false value to the onsubmit event, thereby cancelling or granting >> the submit event. > > > Well -- it doesn't work that way for me. > > Here's a form where I use it: > > http://webbytedd.com/c/form-submit/ > > 'onsubmit=return checkMyForm()" <-- works > > where > > 'onsubmit=checkMyForm()" <-- doesn't > > Or is there something here I'm not understanding? > > Cheers, > > tedd > From tedd at sperling.com Thu Apr 17 09:14:41 2008 From: tedd at sperling.com (tedd) Date: Thu, 17 Apr 2008 10:14:41 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <48074B4D.8070406@cutterscrossing.com> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> <48074B4D.8070406@cutterscrossing.com> Message-ID: At 8:06 AM -0500 4/17/08, Cutter (JSRelated) wrote: >There must be something you're misunderstanding. I have hundreds of >forms out there with onsubmit="validate()" (before I knew better). The >validate function returns true or false, which either cancels the event >or allows it depending on that return. > >Create a quick test case: > >function checkMyForm(){ > return false; // Manually toggle this for your test >} > >Then make a quick test form with onsubmit="checkMyForm()" to see what >happens. Don't even worry about logic or other functionality right now, >just the quick test case... Steve: A simple one entry won't demonstrate the problem. Please follow: http://webbytedd.com/ccc/test-onsubmit/index.php Form One uses the onsubmit="return checkForm(this);" where as Form Two uses onsubmit="checkForm(this);" Now, without entering anything click the top Submit button. An alert will ask you to enter something in Anything 1. Enter something and click Submit again. An alert will ask you to enter something in Anything 2. Enter something and click Submit again. At this time the form will process. Now, without entering anything click the bottom Submit button. An alert will ask you to enter something in Anything 1. Enter something and click Submit again. An alert will ask you to enter something in Anything 1. BUT, please note that the form processed before having both fields populated -- not desired. As you can see, the performance of these two are not the same. Now, what am I misunderstanding? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From hassan at webtuitive.com Thu Apr 17 09:42:04 2008 From: hassan at webtuitive.com (Hassan Schroeder) Date: Thu, 17 Apr 2008 07:42:04 -0700 Subject: [Javascript] IE onclick problem In-Reply-To: <48074B4D.8070406@cutterscrossing.com> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <4806AA1B.8020502@internetique.com> <4806AE6A.6010506@denhaag.org> <48074B4D.8070406@cutterscrossing.com> Message-ID: <480761BC.7030005@webtuitive.com> Cutter (JSRelated) wrote: > validate function returns true or false, which either cancels the event > or allows it depending on that return. That's simply wrong. > Create a quick test case: > > function checkMyForm(){ > return false; // Manually toggle this for your test > } > > Then make a quick test form with onsubmit="checkMyForm()" to see what > happens. Yep, easy test case, which demonstrates that the above submits no matter what happens in the function, while onsubmit="return checkMyForm()" does not (when the returned value is false). It is certainly possible to have the function "trap" the event (i.e. cancel bubbling) but your example doesn't do that. -- Hassan Schroeder ----------------------------- hassan at webtuitive.com Webtuitive Design === (+1) 408-621-3445 === http://webtuitive.com dream. code. From hjess at cardomain.com Thu Apr 17 10:40:47 2008 From: hjess at cardomain.com (Howard Jess) Date: Thu, 17 Apr 2008 08:40:47 -0700 Subject: [Javascript] IE onclick problem In-Reply-To: References: Message-ID: <48076F7F.9090100@cardomain.com> > > tedd wrote: >> At 3:56 AM +0200 4/17/08, J. Lester Novros II wrote: >>> So I would argue that 'onsubmit="return checkMyForm()"' should read >>> 'onsubmit="checkMyForm()"' since the handler function itself returns a >>> true or false value to the onsubmit event, thereby cancelling or >>> granting >>> the submit event. >> >> >> Well -- it doesn't work that way for me. >> >> Here's a form where I use it: >> >> http://webbytedd.com/c/form-submit/ >> >> 'onsubmit=return checkMyForm()" <-- works >> >> where >> >> 'onsubmit=checkMyForm()" <-- doesn't >> >> Or is there something here I'm not understanding? >> >> Cheers, >> >> tedd >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript The "onsubmit" property of the form element is defined as a function; therefore, when you assign it a string value in markup (as you must, since HTML attributes can only be strings, in markup), the string is converted to a function: -- hj From fastpaced at yahoo.com Fri Apr 18 11:29:03 2008 From: fastpaced at yahoo.com (Sid D.) Date: Fri, 18 Apr 2008 09:29:03 -0700 (PDT) Subject: [Javascript] free project tracking system Message-ID: <465748.42255.qm@web45706.mail.sp1.yahoo.com> Hello All, We have a web based project tracking system, single project owners can sign up for free. Get your free online installation at http://www.project-tracking-system. You can further create resource logins and client login within the system. Demo details are available at http://www.project-tracking-system/demo.asp best, Sidharth. p.s. please forward this to your friends who can benefit from this. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedd at sperling.com Fri Apr 18 11:53:27 2008 From: tedd at sperling.com (tedd) Date: Fri, 18 Apr 2008 12:53:27 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <48076F7F.9090100@cardomain.com> References: <48076F7F.9090100@cardomain.com> Message-ID: At 8:40 AM -0700 4/17/08, Howard Jess wrote: >And finally, it's *far* better to leave this attribute out of >markup altogether, and do everything in javascript: > > > > > >-- >hj Yes, that is much better. Thanks, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From tedd at sperling.com Fri Apr 18 12:48:47 2008 From: tedd at sperling.com (tedd) Date: Fri, 18 Apr 2008 13:48:47 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <48076F7F.9090100@cardomain.com> References: <48076F7F.9090100@cardomain.com> Message-ID: At 8:40 AM -0700 4/17/08, Howard Jess wrote: >And finally, it's *far* better to leave this attribute out of >markup altogether, and do everything in javascript: > > > > Howard: I spoke too soon -- take a look at this: http://webbytedd.com/ccc/test-onsubmit1/index.php Please note that while not entering the data required in each text box will generate an alert, it will not stop the submit. I provided a demo here: http://webbytedd.com/ccc/test-onsubmit/index.php The proper operation is to prohibit a submit until both text boxes have data. So, how do you do that while remaining unobtrusive? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From david at dorward.me.uk Fri Apr 18 13:50:26 2008 From: david at dorward.me.uk (David Dorward) Date: Fri, 18 Apr 2008 19:50:26 +0100 Subject: [Javascript] IE onclick problem In-Reply-To: References: <48076F7F.9090100@cardomain.com> Message-ID: <6CD5B8B3-5B5B-447B-A52D-1EA9BAC95E7A@dorward.me.uk> On 18 Apr 2008, at 18:48, tedd wrote: >> > > Howard: > > I spoke too soon -- take a look at this: > > http://webbytedd.com/ccc/test-onsubmit1/index.php You have: form.onsubmit = checkForm(form); So you are calling checkForm, with the the form as an argument, and assigning the return value to onsubmit. The return value is going to be false (since the form isn't filled in at load time), but it needs to be a function. form.onsubmit = function (f) { return function () { checkForm(f) }; }(form); Here I generate an anonymous function with one argument, and call it with the form as the argument immediately. The return value (another anonymous function, which calls checkForm when it is run) is assigned to onsubmit. -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From hjess at cardomain.com Fri Apr 18 13:57:42 2008 From: hjess at cardomain.com (Howard Jess) Date: Fri, 18 Apr 2008 11:57:42 -0700 Subject: [Javascript] IE onclick problem In-Reply-To: References: <48076F7F.9090100@cardomain.com> Message-ID: <4808EF26.8090200@cardomain.com> tedd wrote: > At 8:40 AM -0700 4/17/08, Howard Jess wrote: >> And finally, it's *far* better to leave this attribute out of >> markup altogether, and do everything in javascript: >> >> >> >> > > Howard: > > I spoke too soon -- take a look at this: > > http://webbytedd.com/ccc/test-onsubmit1/index.php > > Please note that while not entering the data required in each text box > will generate an alert, it will not stop the submit. > > I provided a demo here: > > http://webbytedd.com/ccc/test-onsubmit/index.php The onsubmit property is a function reference, as I suggested: form.onsubmit = checkMyForm; Your example, which doesn't work, says: window.onload=function() { var form=document.getElementById('a'); if (form) { form.onsubmit = checkForm(form); } } The line you specify invokes the checkForm function, rather than referring to it, and sets the onsubmit property to false; notice that you get the alert prompt on first display of the page, *before* you hit submit. Try: window.onload = function() { var form = document.getElementById('a'); form.onsubmit = function() {return checkForm(form)}; } or if you don't like that, try: window.onload = function() { var form = document.getElementById('a'); function submitter() { return checkForm(form); } form.onsubmit = submitter; } -- Howard Jess | CarDomain Network Software Engineer 1633 Westlake Avenue North, Suite 100, Seattle, WA 98109 hjess at cardomain.com | tel 206.926.2144 | fax 206.926.2299 http://members.cardomain.com/verklempt From tedd at sperling.com Fri Apr 18 17:36:18 2008 From: tedd at sperling.com (tedd) Date: Fri, 18 Apr 2008 18:36:18 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <4808EF26.8090200@cardomain.com> References: <48076F7F.9090100@cardomain.com> <4808EF26.8090200@cardomain.com> Message-ID: At 11:57 AM -0700 4/18/08, Howard Jess wrote: >tedd wrote: >> At 8:40 AM -0700 4/17/08, Howard Jess wrote: >>> And finally, it's *far* better to leave this attribute out of >>> markup altogether, and do everything in javascript: >>> >>> >>> >>> >> >> Howard: >> >> I spoke too soon -- take a look at this: >> > > http://webbytedd.com/ccc/test-onsubmit1/index.php >> >> Please note that while not entering the data required in each text box >> will generate an alert, it will not stop the submit. >> >> I provided a demo here: >> > > http://webbytedd.com/ccc/test-onsubmit/index.php > >The onsubmit property is a function reference, as I suggested: > > form.onsubmit = checkMyForm; > >Your example, which doesn't work, says: > >window.onload=function() { > var form=document.getElementById('a'); > if (form) { > form.onsubmit = checkForm(form); > } >} > >The line you specify invokes the checkForm function, rather than >referring to it, and sets the onsubmit property to false; notice >that you get the alert prompt on first display of the page, *before* >you hit submit. > >Try: > window.onload = function() { > var form = document.getElementById('a'); > form.onsubmit = function() {return checkForm(form)}; > } > >or if you don't like that, try: > window.onload = function() { > var form = document.getElementById('a'); > function submitter() { > return checkForm(form); > } > form.onsubmit = submitter; > } > Okay, I understand both of those. Those are more in keeping with the original post question, which discussed the difference between "return checkForm(this)" and "checkForm(this)" -- the later not working. Thanks, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From tedd at sperling.com Fri Apr 18 18:41:36 2008 From: tedd at sperling.com (tedd) Date: Fri, 18 Apr 2008 19:41:36 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <6CD5B8B3-5B5B-447B-A52D-1EA9BAC95E7A@dorward.me.uk> References: <48076F7F.9090100@cardomain.com> <6CD5B8B3-5B5B-447B-A52D-1EA9BAC95E7A@dorward.me.uk> Message-ID: At 7:50 PM +0100 4/18/08, David Dorward wrote: >On 18 Apr 2008, at 18:48, tedd wrote: >>> >> >> Howard: >> >> I spoke too soon -- take a look at this: >> >> http://webbytedd.com/ccc/test-onsubmit1/index.php > > >You have: > form.onsubmit = checkForm(form); > >So you are calling checkForm, with the the form as an argument, and >assigning the return value to onsubmit. > >The return value is going to be false (since the form isn't filled in >at load time), but it needs to be a function. > > form.onsubmit = function (f) { > return function () { > checkForm(f) > }; > }(form); > >Here I generate an anonymous function with one argument, and call it >with the form as the argument immediately. The return value (another >anonymous function, which calls checkForm when it is run) is assigned >to onsubmit. That still did not seem to work as it should -- unless I screwed up (most likely). But, the code provided by Howard did work. Thanks all. tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From trojani2000 at hotmail.com Fri Apr 18 22:35:06 2008 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Sat, 19 Apr 2008 03:35:06 +0000 Subject: [Javascript] IE onclick problem In-Reply-To: <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> Message-ID: Sorry, but > var capturedReturnValue = myFunction();just won't do! You are asigning the function to the var. It imediately calls the function execution and in casse it was referrenced from some other function as well, might end up in loop execution. I still don't see how to utilize such a claim nor make it work. At least not by asigning a function to the var, because: >if (capturedReturnValue) {... will allways act as TRUE since it's not an empty strig.~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From: david at dorward.me.uk> To: javascript at lists.evolt.org> Date: Thu, 17 Apr 2008 07:09:23 +0100> Subject: Re: [Javascript] IE onclick problem> > > On 17 Apr 2008, at 01:28, Troy III Ajnej wrote:> > Yes,> > but how do you hadle it, -how do you capture the bolean response> > of true or false in case it fails to run> > var capturedReturnValue = myFunction();> > > , or in casse it succeeded, how> > do you check it prior to invoking other instuctions?> > if (capturedReturnValue) {> > }> > -- > David Dorward> http://dorward.me.uk/> http://blog.dorward.me.uk/> > > _______________________________________________> Javascript mailing list> Javascript at lists.evolt.org> http://lists.evolt.org/mailman/listinfo/javascript _________________________________________________________________ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at dorward.me.uk Sat Apr 19 02:31:38 2008 From: david at dorward.me.uk (David Dorward) Date: Sat, 19 Apr 2008 08:31:38 +0100 Subject: [Javascript] IE onclick problem In-Reply-To: References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> Message-ID: <915F0F75-2EA4-434D-8F25-F59E150FA6B8@dorward.me.uk> On 19 Apr 2008, at 04:35, Troy III Ajnej wrote: > Sorry, but > > var capturedReturnValue = myFunction(); > just won't do! You are asigning the function to the var. No, it is the return value of the function. If that was assigning the function it would be: var anotherRefToTheFunction = myFunction; > It imediately calls the function execution and in casse it was > referrenced from some other function as well, might end up > in loop execution. So don't write the script to call it in a recursive fashion. > I still don't see how to utilize such a claim nor make it work. > At least not by asigning a function to the var, because: > >if (capturedReturnValue) {... > will allways act as TRUE since it's not an empty strig. The function can be written to return whatever you like, including on of the many things (not limited to empty strings) that are false values. -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From trojani2000 at hotmail.com Sat Apr 19 04:02:17 2008 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Sat, 19 Apr 2008 09:02:17 +0000 Subject: [Javascript] IE onclick problem In-Reply-To: <915F0F75-2EA4-434D-8F25-F59E150FA6B8@dorward.me.uk> References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> <915F0F75-2EA4-434D-8F25-F59E150FA6B8@dorward.me.uk> Message-ID: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From: david at dorward.me.uk> To: javascript at lists.evolt.org> Date: Sat, 19 Apr 2008 08:31:38 +0100> Subject: Re: [Javascript] IE onclick problem> > > On 19 Apr 2008, at 04:35, Troy III Ajnej wrote:> > Sorry, but> > > var capturedReturnValue = myFunction();> > just won't do! You are asigning the function to the var.> > No, it is the return value of the function. I think my english is not god enough..., you are assigning the function-name (that is: a function call) to the "var capturedReturnValue" So, if you write it as a global 'var', it will simply invoke that function during load time. In casse you declare it inside a function it will call the execution of it, same way. > If that was assigning the > function it would be:> > var anotherRefToTheFunction = myFunction; That, in contrast will assign the function-body to the var. > The function can be written to return whatever you like, including on > of the many things (not limited to empty strings) that are false values. All right, -how do you write it so it will return, !not execute myFunction(), but at least alert you from another function that: myFunction() did execute succesfully without executing it accidentally on-check time or before user-action? > David Dorward> http://dorward.me.uk/> http://blog.dorward.me.uk/> > > _______________________________________________> Javascript mailing list> Javascript at lists.evolt.org> http://lists.evolt.org/mailman/listinfo/javascript _________________________________________________________________ Going green? See the top 12 foods to eat organic. http://green.msn.com/galleries/photos/photos.aspx?gid=164&ocid=T003MSN51N1653A -------------- next part -------------- An HTML attachment was scrubbed... URL: From trojani2000 at hotmail.com Sat Apr 19 04:38:40 2008 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Sat, 19 Apr 2008 09:38:40 +0000 Subject: [Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox In-Reply-To: <3A03F77B-73A7-4C3B-A490-54BE603BC0E3@dorward.me.uk> References: <12fcb13ce6b042c6af170e879873b99c@maila15.webcontrolcenter.com> <47FFDBBC.5040505@internetique.com> <4800C5AD.5060204@webtuitive.com> <4800D690.2040804@internetique.com> <1F71AA0A-C332-4528-A49A-DA1A042D1E77@dorward.me.uk>

<3A03F77B-73A7-4C3B-A490-54BE603BC0E3@dorward.me.uk> Message-ID: > From: david at dorward.me.uk> To: javascript at lists.evolt.org> Date: Thu, 17 Apr 2008 07:20:55 +0100> Subject: Re: [Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox> > > There is a VERY significant difference between "A decade old" which > the above statement uses and "A decade older then > document.getElementById", which your email of 16 April 2008 06:02:07 > BST uses. True!But I think you somehow manage to miss my point. > > > Generating global variables, which might conflict with built ins, >

A set of "reserved words" will never sieze to exist. There will allways be a setof some reserved words, so this is simply an overreaction. If a coder was thateager to name a portion of his text with such a fullish name as "window" or "alert", simply by changing the "window" with "Window" or "alert" with "Alert"would be more than satisfying. -One of the reasons why js is casse sensitive. > > > DOM 1 reached recommendation status in 1998> >> > Sorry but I don't recall if it's first recommendation included the > > "document.getElemen..."> > statement in its apearence.> If you don't recall, then why not look?> http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835 I was being educated.Because I already did a re-check while writting! Please view the: http://www.w3.org/TR/DOM-Level-2-Core/core.html > > It was DOM Level 2 that invented e different statement for> > the same purpose and reached recommendation status only a month > > before 2001.> > Incorrect, see above. Correct all the way! It was a re-invetnion of the wheel. It was "getElementsByTagName" that was proposed in Level 1 not the ID. To be more exact, this link (se below), will navigate you strait to the paragraph of our matter in discussion, http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId same page as the above. Where it explicitely states: "getElementById introduced in DOM Level 2" This, -once again - proves that "document.getElementById" is Level 2, and was ~introduced~ only a month before 2001 respectively. > > Eventhough FX didn't hesitate to implement it, but did it maliciously.> Firefox implemented the standard ... maliciously. That makes no sense > whatsoever. The "it" language var cited above meant "reference by ID", I never said "FX implemented the standard", why do you alter my words? -So it does make sense! > > Same goes with the famous .innerHTML.> > Firefox implemented innerHTML because lots of websites used it > (because Microsoft implemented instead of promoting the standard, and > IE was commonly used). I don't see any maliciousness there either. I > don't see Firefox's implementation breaking when you edit the inside > of tables either. O really! Why did FX implement the NON-STANDARD innerHTML?Why did FX support the NON-STANDARD reference by ID? While providing error mesage:"Element rreferenced by Name/ID use standard getElementById() instead".I'ts obviously malicious! Today this message doesn't turn your Error Console button into red, but it used to.And what about innerHTML, it doesn't even yeld a soft error nor a warnig message! Does it mean that innerHTML has become a standard?!!FX never met a W3C standards and never will. It's a pure demagogy and you know that. > > > It lent itself to write-only code, they didn't consult with anyone> > > before implementing it, the standards group (including Microsoft) > > came> > > up with something better.> >> > :) Like What?> > document.getElementById Let's see... > > And what do you understand with "write-only"? > That when someone comes along to read the code, it is not obvious > where the variable is being declared (since it is generated by being > associated with an HTML document, not from within the script itself). > This results in code which is hard to edit. Nonsense...Complete nonsense. First of, -where do you look before assigning your vars? Or do you arbitrarily try toassing whatever comes to your mind, hopping that it will call the object you are aiming to, by guess or something? "MyElement" is not a variable, it's the actuall object you are referrening to, -and there will be no guess nor any place for confussion.That way you can never go wrong about. On contrast, what makes the element referrencing a real pain is a completely independent naming convention of vars that refer to them. MyElement.width="value" compared to: var anyName = document.getElementById("MyElement").width="value" is actually what makes it almost impossible to edit some one else's document. You'll have to digg in three different places to find out what is the correct id/name of the element referred from this var; where was it declared; find the original name/id of it; find it in HTML; check if there is everything right than go through CSS to find that there was some banal typing error causing your function to fail or to act as not expected. > > What do you mean with "they didn't consult with anyone"?> > That they implemented it rather then proposing it to the standards > group that they are, and were, a member of. I allready pointed out that IE4 was allready out and running for thee long coding years before they even came up with any proposal. Douring the time you are talking about, W3C was bussy cleaning the mess they've created with the GIF format and pattents and were intensely preocupied with PNG developement. They didn't even turn their eyes on the matters we are talking about. > > Do you understand that this acusation is a direct answer to the> > question: -Who was, and still is hollding up the web???> > I don't really care what it is in answer to. It is packed full of > factual errors.> As we can clearly see, the facts are all in the right place. > > Don't forget that it was only in December 1997 that HTML 4.0 added > > support for tables.> > Can you imagine? -Tables!> > Right. Yes. HTML 4.0. Of course. http://www.w3.org/TR/REC-html32#table> > The whole situation with HTML at the time was a mess. It didn't help > that browser vendors ran around implementing , and > instead of trying to develop something good. So HTML 3 was > scrapped and HTML 3.2 came along to document what they had some up with. So, as you see, they were not capable of even dealing with such a fundamental need like tablesat the time, but you expect them to address things like how to manipulate the DOM?! > > W3C recommended "document.getElement" a month before 2001, while> > IE4-was allready three years old and running.> > Incorrect, see above. Correct all the way, as you can see from above too. -They should have used the same policy as they did with other coding practices and embrace what was allready a standard in the coding "world". If itweren't for them taking sides... For more than three years, coders around the world got used to "MyElement" solution with no alternative recommendation. Accusing IE for being non-compliant is a pure demagogy. One can not write you a ticket for exceeding speed-limit yesterday while driving 70mph, simply because today the speed limit for that road is reduced to 60mph by God himself, shortly known as W3C & his felow cancelor FX. > > So it was, still is, and allways will be, W3C. Mean time, while W3C was holding back the web, coders turned to using Flash and other plugin alternativesfilling the vacuume they (W3C) almost puposedly created. In 2001 flash couldn't do anything more fancier than IE4.1 filters could do, -today html and scripting has become a simple tool for hidding url's of flash content from pages that every day more and more rely on third party plugins. There are 30% of pages completely built in flash. Other 40% are hybrids, and all because W3C is still holding back the web... I salute them. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _________________________________________________________________ Going green? See the top 12 foods to eat organic. http://green.msn.com/galleries/photos/photos.aspx?gid=164&ocid=T003MSN51N1653A -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at dorward.me.uk Sat Apr 19 07:04:59 2008 From: david at dorward.me.uk (David Dorward) Date: Sat, 19 Apr 2008 13:04:59 +0100 Subject: [Javascript] IE onclick problem In-Reply-To: References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> <915F0F75-2EA4-434D-8F25-F59E150FA6B8@dorward.me.uk> Message-ID: <62443594-5903-481E-831E-6C24B7F3B38F@dorward.me.uk> On 19 Apr 2008, at 10:02, Troy III Ajnej wrote: > > On 19 Apr 2008, at 04:35, Troy III Ajnej wrote: > > > Sorry, but > > > > var capturedReturnValue = myFunction(); > > > just won't do! You are asigning the function to the var. > > > No, it is the return value of the function. > > I think my english is not god enough..., > you are assigning the function-name (that is: a function call) to > the "var capturedReturnValue" No. var capturedReturnValue = myFunction(); That executes the function and assigns whatever value it returns to capturedReturnValue. var referenceToFunction = myFunction; Without the () to *call* the function it will assign the function to the variable. If you couldn't call functions, JavaScript wouldn't be a usable language. > All right, -how do you write it so it will return, !not execute > myFunction(), > but at least alert you from another function that: myFunction() did > execute > succesfully without executing it accidentally on-check time or > before user-action? If you want to return a function then: function myFunction() { return function () { var something = doSomething(); doSomethingElse(; return something; } } -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From david at dorward.me.uk Sat Apr 19 07:07:00 2008 From: david at dorward.me.uk (David Dorward) Date: Sat, 19 Apr 2008 13:07:00 +0100 Subject: [Javascript] IE onclick problem In-Reply-To: References: <480553F7.4090108@bigskypenguin.com> <480590F8.4070109@internetique.com> <2D037D51-90E1-49A8-BE35-A74E282A391A@dorward.me.uk> <3F82C096-6035-4890-9392-508707E0E270@dorward.me.uk> <915F0F75-2EA4-434D-8F25-F59E150FA6B8@dorward.me.uk> Message-ID: <25782E6B-7186-4780-9AB8-E521FD9B1384@dorward.me.uk> On 19 Apr 2008, at 10:02, Troy III Ajnej wrote: > > On 19 Apr 2008, at 04:35, Troy III Ajnej wrote: > > > Sorry, but > > > > var capturedReturnValue = myFunction(); > > > just won't do! You are asigning the function to the var. > > > No, it is the return value of the function. > > I think my english is not god enough..., > you are assigning the function-name (that is: a function call) to > the "var capturedReturnValue" No. var capturedReturnValue = myFunction(); That executes the function and assigns whatever value it returns to capturedReturnValue. var referenceToFunction = myFunction; Without the () to *call* the function it will assign the function to the variable. If you couldn't call functions, JavaScript wouldn't be a usable language. > All right, -how do you write it so it will return, !not execute > myFunction(), > but at least alert you from another function that: myFunction() did > execute > succesfully without executing it accidentally on-check time or > before user-action? If you want to return a function then: function myFunction() { return function () { var something = doSomething(); doSomethingElse(; return something; } } -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From david at dorward.me.uk Sat Apr 19 07:29:04 2008 From: david at dorward.me.uk (David Dorward) Date: Sat, 19 Apr 2008 13:29:04 +0100 Subject: [Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox In-Reply-To: References: <12fcb13ce6b042c6af170e879873b99c@maila15.webcontrolcenter.com> <47FFDBBC.5040505@internetique.com> <4800C5AD.5060204@webtuitive.com> <4800D690.2040804@internetique.com> <1F71AA0A-C332-4528-A49A-DA1A042D1E77@dorward.me.uk>

<3A03F77B-73A7-4C3B-A490-54BE603BC0E3@dorward.me.uk> Message-ID: <83FCBFD4-7109-42FE-9D16-2E9021F6BD5F@dorward.me.uk> On 19 Apr 2008, at 10:38, Troy III Ajnej wrote: > > > > Generating global variables, which might conflict with built > ins, > >

> >

> > A set of "reserved words" will never sieze to exist. Yes, but having reserved words in JavaScript should not influence any decision made about the HTML. > > http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835 > > I was being educated. > Because I already did a re-check while writting! > Please view the: http://www.w3.org/TR/DOM-Level-2-Core/core.html Existing in DOM level 2 doesn't stop it existing in DOM level 1 as well. > Correct all the way! It was a re-invetnion of the wheel. It was > "getElementsByTagName" > that was proposed in Level 1 not the ID. See the link I provided previously. > http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId > > same page as the above. Where it explicitely states: "getElementById > introduced in DOM Level 2" > This, -once again - proves that "document.getElementById" is Level > 2, and was ~introduced~ only a > month before 2001 respectively. It was made more flexible and introduced into DOM Core Level 2. It already existed in an HTML specific form in DOM HTML Level 1 (I assume that this is because they needed to have some way to define "id" in a generic way for XML: http://www.w3.org/TR/xml-id/ ). See the link I provided before: http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835 . Note the date in it. The W3C do NOT edit old specifications, release them under exactly the same name (they add revision information to the title) and then publish at the same citable (as opposed to "quick link to the latest version") URI. > > > Eventhough FX didn't hesitate to implement it, but did it > maliciously. > > > Firefox implemented the standard ... maliciously. That makes no > sense > > whatsoever. > > The "it" language var cited above meant "reference by ID", I never > said "FX implemented the standard", > why do you alter my words? -So it does make sense! I must have misinterpreted you. How did they implement support for Microsoft's proprietary system _ maliciously_? > > > > Same goes with the famous .innerHTML. > > > > Firefox implemented innerHTML because lots of websites used it > > (because Microsoft implemented instead of promoting the standard, > and > > IE was commonly used). I don't see any maliciousness there either. I > > don't see Firefox's implementation breaking when you edit the inside > > of tables either. > > O really! > Why did FX implement the NON-STANDARD innerHTML? Because Microsoft had massive market share and influence, so many developers who didn't know better used the proprietary system ... and they didn't want to produce a browser that lots of sites simply didn't work with. > Why did FX support the NON-STANDARD reference by ID? While providing > error mesage: > "Element rreferenced by Name/ID use standard getElementById() > instead". It's a warning. There is a standard, which Microsoft was partly responsible for, and a (poor) proprietary system. Warning for use of non-standard constructs is a perfectly standard part of compiler / interpreter design. > I'ts obviously malicious! Promoting a (better) standard over a proprietary system is not malicious. > Today this message doesn't turn your Error Console button into red, > but it used to. > And what about innerHTML, it doesn't even yeld a soft error nor a > warnig message! > Does it mean that innerHTML has become a standard?!! It is being worked on. http://www.w3.org/html/wg/html5/#innerhtml0 > FX never met a W3C standards and never will. It's a pure demagogy > and you know that. Garbage. > > > > It lent itself to write-only code, they didn't consult with > anyone > > > > before implementing it, the standards group (including > Microsoft) > > > came > > > > up with something better. > > > > > > :) Like What? > > > > document.getElementById > > Let's see... > > > > And what do you understand with "write-only"? > > That when someone comes along to read the code, it is not obvious > > where the variable is being declared (since it is generated by being > > associated with an HTML document, not from within the script > itself). > > This results in code which is hard to edit. > > Nonsense... > Complete nonsense. > First of, -where do you look before assigning your vars? Or do you > arbitrarily try to > assing whatever comes to your mind, hopping that it will call the > object you are aiming to, > by guess or something? What does that have to do with reading other people's code? > "MyElement" is not a variable, it's the actuall object you are > referrening to No, it is an variable containing an object reference. > , -and there > will be no guess nor any place for confussion.That way you can never > go wrong about. > On contrast, what makes the element referrencing a real pain is a > completely independent > naming convention of vars that refer to them. There is nothing stopping you assigning the return value of getElementById to a variable with the same or a similar name as the id of the element. > > MyElement.width="value" compared to: > var anyName = document.getElementById("MyElement").width="value" > is actually what makes it almost impossible to edit some one else's > document. Well yes. If you will compare proprietary code to a syntax error, then obviously the former will win. > You'll have to > digg in three different places to find out what is the correct id/ > name of the element referred from > this var; where was it declared; find the original name/id of it; > find it in HTML; check if > there is everything right than go through CSS to find that there was > some banal typing error > causing your function to fail or to act as not expected. Generally speaking, people declare their variables at the top of the function that uses them, it isn't far to look. Then you give them a similar name, and what's the problem? > > > What do you mean with "they didn't consult with anyone"? > > > > That they implemented it rather then proposing it to the standards > > group that they are, and were, a member of. > > I allready pointed out that IE4 was allready out and running for > thee long coding years before > they even came up with any proposal. As pointed out above, you are wrong about that. > Douring the time you are talking about, W3C was bussy cleaning the > mess they've created with the > GIF format and pattents and were intensely preocupied with PNG > developement. They didn't even turn > their eyes on the matters we are talking about. > > > > Do you understand that this acusation is a direct answer to the > > > question: -Who was, and still is hollding up the web??? > > > > I don't really care what it is in answer to. It is packed full of > > factual errors. > > > As we can clearly see, the facts are all in the right place. No, you are still misinterpreting what you are reading. > > > > Don't forget that it was only in December 1997 that HTML 4.0 added > > > support for tables. > > > Can you imagine? -Tables! > > > > Right. Yes. HTML 4.0. Of course. http://www.w3.org/TR/REC-html32#table > > > > The whole situation with HTML at the time was a mess. It didn't help > > that browser vendors ran around implementing , and > > instead of trying to develop something good. So HTML 3 was > > scrapped and HTML 3.2 came along to document what they had some up > with. > > So, as you see, they were not capable of even dealing with such a > fundamental need like tables > at the time, but you expect them to address things like how to > manipulate the DOM?! *headdesk* The HTML 3 drafts had tables in them too: http://www.w3.org/MarkUp/html3/tables.html Their problem was browser vendors implementing proprietary stuff and ignoring standards, you can't blame them for that. How is the W3C supposed to be "holding back the web" if browser vendors are ignoring them? > > > W3C recommended "document.getElement" a month before 2001, while > > > IE4-was allready three years old and running. > > > > Incorrect, see above. > > Correct all the way, as you can see from above too. No, I've pointed you at a 1998 document that defined document.getElementById as it relates to HTML documents. > For more than three years, coders around the world got used to > "MyElement" solution with no alternative > recommendation. Accusing IE for being non-compliant is a pure > demagogy. Incorrect, see 1998 document. > One can not write you a ticket for exceeding speed-limit yesterday > while driving 70mph, simply because > today the speed limit for that road is reduced to 60mph by God > himself, shortly known as W3C & his felow > cancelor FX. Firefox didn't even exist when that specification came out. I suspect Microsoft had more influence over it then any entity that had anything to do with what would become the Firefox codebase. > > > > So it was, still is, and allways will be, W3C. > > Mean time, while W3C was holding back the web, coders turned to > using Flash and other plugin alternatives > filling the vacuume they (W3C) almost puposedly created. I've lost track. Is this the period after Microsoft crushed Netscape, and then dominated the browser market with IE6 which went though half a decade without any development? -- David Dorward http://dorward.me.uk/ http://blog.dorward.me.uk/ From tedd at sperling.com Sat Apr 19 11:14:57 2008 From: tedd at sperling.com (tedd) Date: Sat, 19 Apr 2008 12:14:57 -0400 Subject: [Javascript] IE onclick problem Message-ID: At 11:57 AM -0700 4/18/08, Howard Jess wrote: The line you specify invokes the checkForm function, rather than >referring to it, and sets the onsubmit property to false; notice >that you get the alert prompt on first display of the page, *before* >you hit submit. > >Try: > window.onload = function() { > var form = document.getElementById('a'); > form.onsubmit = function() {return checkForm(form)}; > } > >or if you don't like that, try: > window.onload = function() { > var form = document.getElementById('a'); > function submitter() { > return checkForm(form); > } > form.onsubmit = submitter; > } > Another question -- what if you have two forms? window.onload=function() { var form=document.getElementById('a'); function submitter() { return checkForm(form) } form.onsubmit = submitter; var form=document.getElementById('b'); function submitter() { return checkForm(form) } form.onsubmit = submitter; } Doesn't work for two forms. How can you have an unobtrusive onsubmit function tied to an unique id form on a document that contains several forms -- such that IF its submit button is clicked, then that form is processed (i.e., evaluated for content) while not processing the other forms? Now, I can do this with an in-line: onsubmit="return checkForm(this);" for each form, but how do you do that and be unobtrusive? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com _______________________________________________ Javascript mailing list Javascript at lists.evolt.org http://lists.evolt.org/mailman/listinfo/javascript -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From liorean at gmail.com Sat Apr 19 12:26:48 2008 From: liorean at gmail.com (liorean) Date: Sat, 19 Apr 2008 19:26:48 +0200 Subject: [Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox In-Reply-To: References: <12fcb13ce6b042c6af170e879873b99c@maila15.webcontrolcenter.com> <4800C5AD.5060204@webtuitive.com> <4800D690.2040804@internetique.com> <1F71AA0A-C332-4528-A49A-DA1A042D1E77@dorward.me.uk>

<3A03F77B-73A7-4C3B-A490-54BE603BC0E3@dorward.me.uk> Message-ID: > > From: david at dorward.me.uk > > > > DOM 1 reached recommendation status in 1998 > > > > > > Sorry but I don't recall if it's first recommendation included the > > > "document.getElemen..." > > > statement in its apearence. > > If you don't recall, then why not look? On 19/04/2008, Troy III Ajnej wrote: > http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-36113835 > > I was being educated. > Because I already did a re-check while writting! > Please view the: > http://www.w3.org/TR/DOM-Level-2-Core/core.html > > > It was DOM Level 2 that invented e different statement for > > > the same purpose and reached recommendation status only a month > > > before 2001. > > > > Incorrect, see above. > > Correct all the way! It was a re-invetnion of the wheel. It was > "getElementsByTagName" > that was proposed in Level 1 not the ID. To be more exact, this link (se > below), will > navigate you strait to the paragraph of our matter in discussion, > > http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-getElBId > > same page as the above. Where it explicitely states: "getElementById > introduced in DOM Level 2" > This, -once again - proves that "document.getElementById" is Level 2, and > was ~introduced~ only a > month before 2001 respectively. DOM1Core introduced getElementsByTagName on Document. DOM1HTML introduced getElementById, getElementsByName on HTMLDocument. DOM2Core introduced getElementById on Document. Thus, DOM2Core didn't introduce document.getElementById because in browsers, document was an HTMLDocument, which means they had the DOM1HTML interfaces to go by. > > > Eventhough FX didn't hesitate to implement it, but did it maliciously. > > > Firefox implemented the standard ... maliciously. That makes no sense > > whatsoever. > > The "it" language var cited above meant "reference by ID", I never said "FX > implemented the standard", > why do you alter my words? -So it does make sense! No it's still total gibberish. > > > Same goes with the famous .innerHTML. > > > > Firefox implemented innerHTML because lots of websites used it > > (because Microsoft implemented instead of promoting the standard, and > > IE was commonly used). I don't see any maliciousness there either. I > > don't see Firefox's implementation breaking when you edit the inside > > of tables either. > > O really! > Why did FX implement the NON-STANDARD innerHTML? Because live web content wanted to use the feature, and the W3C DOM had not standardised anything even close to as practical for programmers. > Why did FX support the NON-STANDARD reference by ID? While providing error > mesage: > "Element rreferenced by Name/ID use standard getElementById() instead". > I'ts obviously malicious! Firefox didn't even exist at the time getElementById was standardised. Meanwhile, using ids as variable names were never standard and is a problem that has plagued us for a long time. > Today this message doesn't turn your Error Console button into red, but it > used to. > And what about innerHTML, it doesn't even yeld a soft error nor a warnig > message! > Does it mean that innerHTML has become a standard?!! A de facto standard, even if not a de jure standard. (Yet!) Why try to demonise introduction of features that no standard covers? If there is something you want to be able to do, but there is no standard for it yet, do you think it's reasonable to submit the idea to a standards committee, have it draft and get consensus for the feature, and take it to CR before you try to implement? Heck no! You make a prototype implementation to build a spec proposal from, then you submit that spec, and keep yourself open to changing the interface as the standardisation process goes on. Introducing a feature is only malicious if: - It directly competes with a current standard achieving the same thing. - It breaks significant amounts of live content. (Significant can be as low as fractions of a per cent here, because the web is so massive.) - You don't spec it out publicly, so authors don't know exactly how it works. - You don't make it behave in the most natural way for most given usages. - You don't submit it to a standards body but instead force your competitors to reverse engineer your implementation. - You continually change the way it's implemented. > FX never met a W3C standards and never will. It's a pure demagogy and you > know that. NOBODY has proven full conformance to ANY web standard. Mozilla has a considerable adoption of a considerable amount of web standards, however. Much larger than Microsoft has. As it stands, Mozilla is fairly standards compliant. Various standards are supported to various degrees, and there's bugs in the implementations, sure. To say that it's pure demagogy is patently false though - there is a public bug database which proves Mozilla has a considerable effort poured into meeting the W3C standards. > > > > It lent itself to write-only code, they didn't consult with anyone > > > > before implementing it, the standards group (including Microsoft) > > > came > > > > up with something better. > > > > > > :) Like What? > > > > document.getElementById > > Let's see... > > > > And what do you understand with "write-only"? > > That when someone comes along to read the code, it is not obvious > > where the variable is being declared (since it is generated by being > > associated with an HTML document, not from within the script itself). > > This results in code which is hard to edit. > > Nonsense... > Complete nonsense. > First of, -where do you look before assigning your vars? Or do you > arbitrarily try to > assing whatever comes to your mind, hopping that it will call the object you > are aiming to, > by guess or something? You of course look in all the scripts you have, as well as what objects are implemented on the Window object of each browser. However, having the set of properties that are defined on window change because you use some names or ids on elements within the document, now that lends to write-only code. If the script cannot be authored without explicit knowledge of the document that it's linked or embedded in, then that's bad design of the system. Another example of this is the if-variable-is-not-found-default-to-creating-a-new-global-variable behaviour of JavaScript. > "MyElement" is not a variable, it's the actuall object you are referrening > to, -and there > will be no guess nor any place for confussion.That way you can never go > wrong about. > On contrast, what makes the element referrencing a real pain is a > completely independent > naming convention of vars that refer to them. Elements shouldn't be global variables in the first place. Sure, there are better designs than the one the DOM uses which could have been adopted, but having every named element as a global when the script writer doesn't necessarily know anything about the document is madness. > MyElement.width="value" compared to: > var anyName = > document.getElementById("MyElement").width="value" > is actually what makes it almost impossible to edit some one else's > document. You'll have to > digg in three different places to find out what is the correct id/name of > the element referred from > this var; where was it declared; find the original name/id of it; find it in > HTML; check if > there is everything right than go through CSS to find that there was some > banal typing error > causing your function to fail or to act as not expected. The script source shouldn't depend on the document, and the other way around. That's bad separation of concerns. Hardcoding names of elements is bad software engineering. > > > What do you mean with "they didn't consult with anyone"? > > > > That they implemented it rather then proposing it to the standards > > group that they are, and were, a member of. > > I allready pointed out that IE4 was allready out and running for thee long > coding years before > they even came up with any proposal. Wrong. The first DOM proposal reached FPWD only a month after IE4 was first released - Microsoftian Scott Isaacs was an editor for the early drafts, later replaced by the current Platform Architect for Internet Explorer and HTML WG co-chair Chris Wilson. Granted, it took until 1998-07-20 for the getElementsById method to appear, but Microsoft never proposed document.all or this global variable binding in that WG, from what I could see. > Douring the time you are talking about, W3C was bussy cleaning the mess > they've created with the > GIF format and pattents and were intensely preocupied with PNG developement. > They didn't even turn > their eyes on the matters we are talking about. Are you aware that you're talking about the period when Netscape, Microsoft and loads of other interests were spewing out more proposals than they ever have? Most were rejected of course, but this period was when things really happened in the W3C: HTML/XHTML, CSS and DOM were actively developed and everybody was involved in everything. > > > Do you understand that this acusation is a direct answer to the > > > question: -Who was, and still is hollding up the web??? > > > > I don't really care what it is in answer to. It is packed full of > > factual errors. > > > As we can clearly see, the facts are all in the right place. Yes, but they don't support your argument. > > > Don't forget that it was only in December 1997 that HTML 4.0 added > > > support for tables. > > > Can you imagine? -Tables! > > > > Right. Yes. HTML 4.0. Of course. > http://www.w3.org/TR/REC-html32#table Wasn't that his point? > > The whole situation with HTML at the time was a mess. It didn't help > > that browser vendors ran around implementing , and > > instead of trying to develop something good. So HTML 3 was > > scrapped and HTML 3.2 came along to document what they had some up with. > > So, as you see, they were not capable of even dealing with such a > fundamental need like tables > at the time, but you expect them to address things like how to manipulate > the DOM?! Tables were in HTML 3.2 as well as in the 1995 HTML 3.0 proposals, which Netscape implemented a good chunk of. > > > W3C recommended "document.getElement" a month before 2001, while > > > IE4-was allready three years old and running. > > > > Incorrect, see above. > > Correct all the way, as you can see from above too. -They should have used > the same policy as they > did with other coding practices and embrace what was allready a standard in > the coding "world". If it > weren't for them taking sides... Wrong, as I explained above. DOM1HTML and DOM1Core contained the getElement{sByTagName|ById|sByName} methods in 1998 already. > For more than three years, coders around the world got used to "MyElement" > solution with no alternative > recommendation. Accusing IE for being non-compliant is a pure demagogy. Actually, Microsoft has a better alternative solution in document.all. Netscape and DOM1HTML had the purpose specific collections that IE3 copied from Netscape2/3. Microsoft didn't have to expose elements with names or ids as global variables for backwards compatibility, there was already a precedent of using collections on the Document which they and Netscape both supported, so introducing the global variables for each and every element with name or id was entirely unnecessary. It just broke code... > One can not write you a ticket for exceeding speed-limit yesterday while > driving 70mph, simply because > today the speed limit for that road is reduced to 60mph by God himself, > shortly known as W3C & his felow > cancelor FX. True. Microsoft simply made a bad decision and in the process prevented Netscape from doing corrections to their slightly broken early designs by demanding that everything they both implemented was kept as-is. > > > So it was, still is, and allways will be, W3C. > > Mean time, while W3C was holding back the web, coders turned to using Flash > and other plugin alternatives > filling the vacuume they (W3C) almost puposedly created. In 2001 flash > couldn't do anything more fancier > than IE4.1 filters could do, -today html and scripting has become a simple > tool for hidding url's of flash > content from pages that every day more and more rely on third party > plugins. There are 30% of pages completely > built in flash. Other 40% are hybrids, and all because W3C is still holding > back the web... The W3C wasn't holding back the web by any measure. What held back the web was: 1. Netscape scrapping version 5 thereby giving Microsoft years of calm to marginalise them. 2. Netscape releasing version 6 before it was production quality, thus throwing the last chance they had at using their old-but-not-forgotten, well-liked brand by making it an old-and forgotten-except-by-those-that-dislike-it brand. 3. Microsoft stopping any resemblance of progress in browser space. 4. Total domination of the W3C activities by non-browser-makers. Browser makers are regaining dominance in W3C activities. The HTML5 WG, WebAPI WG, CSS WG, SVG WG and others have been started or in some cases finally woken up and begun pushing technologies that have end-users, live content and browser implementation interoperability as priorities instead of walled garden enterprise specs such as the WS-* space, the mobile forum WAP space etc. And that's not the only part of the web standards world that has been revived. TG1, or TC39, is living and making progress on ECMAScript 4. (And ECMAScript 3.1/3.x). In IETF the HTTP people are working too. And most of all, browsers have actually begun pushing the borders of web technology forwards again. Because on the web, the ultimate decision maker for which technology survives and which dies is the user, and the browser is the gatekeeper. -- David "liorean" Andersson From liorean at gmail.com Sat Apr 19 12:34:28 2008 From: liorean at gmail.com (liorean) Date: Sat, 19 Apr 2008 19:34:28 +0200 Subject: [Javascript] Microsoft proprietary DOM vs Standards (Was: IE work-a-round question (re: checkbox In-Reply-To: References: <12fcb13ce6b042c6af170e879873b99c@maila15.webcontrolcenter.com> <4800D690.2040804@internetique.com> <1F71AA0A-C332-4528-A49A-DA1A042D1E77@dorward.me.uk>

<3A03F77B-73A7-4C3B-A490-54BE603BC0E3@dorward.me.uk> Message-ID: On 19/04/2008, liorean wrote: > Tables were in HTML 3.2 as well as in the 1995 HTML 3.0 proposals, > which Netscape implemented a good chunk of. > > Errr, or course. -- David "liorean" Andersson From davidh126 at writeme.com Sat Apr 19 15:54:42 2008 From: davidh126 at writeme.com (David Hucklesby) Date: Sat, 19 Apr 2008 13:54:42 -0700 Subject: [Javascript] IE onclick problem In-Reply-To: Message-ID: <2008419135442.724425@DAVIDS> On Sat, 19 Apr 2008 12:14:57 -0400, tedd wrote: [...] > > How can you have an unobtrusive onsubmit function tied to an unique id form on a > document that contains several forms -- such that IF its submit button is clicked, then > that form is processed (i.e., evaluated for content) while not processing the other > forms? > > Now, I can do this with an in-line: > > onsubmit="return checkForm(this);" > > for each form, but how do you do that and be unobtrusive? > Use an "addEvent()" function, perhaps? Cordially, David -- From dshaw256 at earthlink.net Sun Apr 20 13:52:58 2008 From: dshaw256 at earthlink.net (Dave Shaw) Date: Sun, 20 Apr 2008 14:52:58 -0400 Subject: [Javascript] Two questions about AJAX Message-ID: <1208717578.4952.9.camel@localhost.localdomain> Hi! Pardon me if this is repetitive. I'm new to AJAX and have a couple of questions to which I have not been able to find answers by searching the 'net. First, must I use a new XMLHttpRequest object for each interaction with my server, or can one such object be reused for multiple interactions? Second, the first time I tried using AJAX I managed to kick off two requests simultaneously, using two XMLHttpRequest objects, two onreadystatechange functions, etc. I was using Internet Explorer 7, and this worked fine. But when I tried the same page using Firefox, one or the other request would complete but the other would fail. I recoded to ensure that the requests would be issued serially. But in general, should I be able to have multiple asynchronous requests outstanding at the same time, or should I ensure that there is only one request pending at a time? Thanks much for the help! Dave Shaw -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwarden at gmail.com Sun Apr 20 14:33:37 2008 From: mwarden at gmail.com (Matt Warden) Date: Sun, 20 Apr 2008 15:33:37 -0400 Subject: [Javascript] Two questions about AJAX In-Reply-To: <1208717578.4952.9.camel@localhost.localdomain> References: <1208717578.4952.9.camel@localhost.localdomain> Message-ID: On Sun, Apr 20, 2008 at 2:52 PM, Dave Shaw wrote: > First, must I use a new XMLHttpRequest object for each interaction with my > server, or can one such object be reused for multiple interactions? You are supposed to use a new object for each interaction. It is abstracting a "request", after all. However, from a purely technical possibility perspective, there are browser differences with whether you can re-use the object or not. See this thread from May 2005 (FYI the sandbox link referred to in the thread is now at http://mattwarden.com/sandbox/ajax.htm): http://lists.evolt.org/archive/Week-of-Mon-20050516/172540.html > Second, the first time I tried using AJAX I managed to kick off two > requests simultaneously, using two XMLHttpRequest objects, two > onreadystatechange functions, etc. I was using Internet Explorer 7, and this > worked fine. But when I tried the same page using Firefox, one or the other > request would complete but the other would fail. I recoded to ensure that > the requests would be issued serially. But in general, should I be able to > have multiple asynchronous requests outstanding at the same time, or should > I ensure that there is only one request pending at a time? You can definitely have 2 outstanding asynchronous requests at one time. A July 05 article presents a method for dealing with any number of outstanding requests at a given time (although the browser typically restricts the number of outstanding requests to the same host, due to a suggestion in the http specification). The idea I put forth in this article is largely irrelevant now, because few people operate with AJAX directly without a library anymore: http://www.devx.com/webdev/Article/28695 -- Matt Warden Cincinnati, OH, USA http://mattwarden.com This email proudly and graciously contributes to entropy. From hjess at cardomain.com Mon Apr 21 10:54:08 2008 From: hjess at cardomain.com (Howard Jess) Date: Mon, 21 Apr 2008 08:54:08 -0700 Subject: [Javascript] IE onclick problem In-Reply-To: References: Message-ID: <480CB8A0.6080302@cardomain.com> > Another question -- what if you have two forms? > > window.onload=function() > { > var form=document.getElementById('a'); > function submitter() > { > return checkForm(form) > } > form.onsubmit = submitter; > var form=document.getElementById('b'); > function submitter() > { > return checkForm(form) > } > form.onsubmit = submitter; > } > > Doesn't work for two forms. I think it's time for you to get and read a good book on JavaScript, where most of your questions will likely be answered; specifically, anonymous functions (lambdas) and closures. I'd suggest Flanagan's _JavaScript_The_Definitive_Guide_. In short, window.onload=function() { var form1 = document.getElementById('a'); var form2 = document.getElementById('b'); form1.onsubmit = function() { return checkform(form1); } form2.onsubmit = function() { return checkform(form2); } } Or, as David Hucklesby implied, use DOM2 events: form1.addEventListener('submit',formcheck,false); form2.addEventListener('submit',formcheck,false); (leaving code for IE and the formcheck function as an exercise for the reader.) -- hj From tedd at sperling.com Mon Apr 21 13:20:26 2008 From: tedd at sperling.com (tedd) Date: Mon, 21 Apr 2008 14:20:26 -0400 Subject: [Javascript] IE onclick problem In-Reply-To: <480CB8A0.6080302@cardomain.com> References: <480CB8A0.6080302@cardomain.com> Message-ID: At 8:54 AM -0700 4/21/08, Howard Jess wrote: >I think it's time for you to get and read a good book on JavaScript, >where most >of your questions will likely be answered; specifically, anonymous functions >(lambdas) and closures. I'd suggest Flanagan's >_JavaScript_The_Definitive_Guide_. > >In short, > > window.onload=function() { > var form1 = document.getElementById('a'); > var form2 = document.getElementById('b'); > form1.onsubmit = function() { > return checkform(form1); > } > form2.onsubmit = function() { > return checkform(form2); > } > } > >Or, as David Hucklesby implied, use DOM2 events: > > form1.addEventListener('submit',formcheck,false); > form2.addEventListener('submit',formcheck,false); Ahhh, you are right of course. I don't know why I didn't see that. Thanks for the education. Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From riegel at clearimageonline.com Mon Apr 21 16:27:24 2008 From: riegel at clearimageonline.com (Terry Riegel) Date: Mon, 21 Apr 2008 17:27:24 -0400 Subject: [Javascript] IE work-a-round question (re: checkboxes) OT In-Reply-To: <034f01c89ce5$5bf8e060$13eaa120$@com> References: <12fcb13ce6b042c6af170e879873b99c@maila15.webcontrolcenter.com> <034f01c89ce5$5bf8e060$13eaa120$@com> Message-ID: <8CE682D7-6598-4E22-A08D-8DEB84000A13@clearimageonline.com> > What puzzles me is why anyone would set out to code to 30% of > browsers and then tweak to fit 70%, seems backwards to me. I can answer why I code for the 30% then make the 70% work. Because it takes less time. For the most part MS is standards compliant. But, If I code to a "more" standards compliant browser (in my case Safari) then my fixes for a "less" compliant browser will take less time then if I did it in reverse. For example if I use a lot of MS only functions then how do I retrofit that to the browser that tries to follow the standard. Or to look at it another way... Why did Quicken require Microsoft's Internet Explorer to run? Because they coded to IE and it was to much work to try to make the other browsers work. But if they had coded for a more standards compliant browser then making IE work would have been a breeze. (BTW this is no longer true of Quicken for the web, but at one time it was true) Just my 2 cents. Terry Riegel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedd at sperling.com Tue Apr 29 13:23:44 2008 From: tedd at sperling.com (tedd) Date: Tue, 29 Apr 2008 14:23:44 -0400 Subject: [Javascript] A better way to do this Message-ID: Hi gang: There has to be a better way to do this: function checkAll( form ) { if(form.checkall.checked) { form.a1.checked = true; form.a2.checked = true; form.a3.checked = true; form.a4.checked = true; form.a5.checked = true; } else { form.a1.checked = false; form.a2.checked = false; form.a3.checked = false; form.a4.checked = false; form.a5.checked = false; } } What say you? Cheers, tedd -- ------- http://sperling.com http://ancientstones.com http://earthstones.com From js0000 at gmail.com Tue Apr 29 13:53:20 2008 From: js0000 at gmail.com (john saylor) Date: Tue, 29 Apr 2008 14:53:20 -0400 Subject: [Javascript] A better way to do this In-Reply-To: References: Message-ID: hi On 4/29/08, tedd wrote: > There has to be a better way to do this: there are [probably more than one] ... put all the form objects into an array and loop through them setting their checked status to form.checkall.checked. -- \js [ http://or8.net/~johns/ ] From mwarden at gmail.com Tue Apr 29 13:53:23 2008 From: mwarden at gmail.com (Matt Warden) Date: Tue, 29 Apr 2008 14:53:23 -0400 Subject: [Javascript] A better way to do this In-Reply-To: References: Message-ID: On Tue, Apr 29, 2008 at 2:23 PM, tedd wrote: > Hi gang: > > There has to be a better way to do this: > > function checkAll( form ) > { > if(form.checkall.checked) > { > form.a1.checked = true; > form.a2.checked = true; > form.a3.checked = true; > form.a4.checked = true; > form.a5.checked = true; > } > else > { > form.a1.checked = false; > form.a2.checked = false; > form.a3.checked = false; > form.a4.checked = false; > form.a5.checked = false; > } > } Making some minor assumptions about your local variable names and the elements in the form, I might suggest (untested)... for (var i=0; i References: Message-ID: <48176ECD.5040309@internetique.com> >>There has to be a better way to do this: Try this (not checked): function checkAll( form ) { for (var i = 1; i<= 5; i++)form['a'+i].checked = form.checkall.checked } -- _______________________________________ REUSE CODE! Use custom tags; See http://www.contentbox.com/claude/customtags/tagstore.cfm (Please send any spam to this address: piegeacon at internetique.com) Thanks. From alaneaston666 at hotmail.com Wed Apr 30 18:48:18 2008 From: alaneaston666 at hotmail.com (Alan Easton) Date: Thu, 1 May 2008 00:48:18 +0100 Subject: [Javascript] IE/FF, getElementById and checkboxes Message-ID: Hi All, I have some validation that works in IE, for when I need to check if any checkboxes are checked in my form. If there are, then I submit the form. Code is below: ------------------------------------------------ Example checkbox field: All are called "delusers", and have different values. Now I know I need to ad "id"'s to all of these, but I am still having trouble. ------------------------------------------------ However this is not working in FF. I know I need to change to use getElementById, but the two lines highlighted above are causing me problems. Any help would be appreciated in order so the validation works in IE and Ff. Thanks, Alan... _________________________________________________________________ Play the Andrex Hello Softie Game & win great prizes http://www.thehellosoftiegame.co.uk -------------- next part -------------- An HTML attachment was scrubbed... URL: From hassan at webtuitive.com Wed Apr 30 19:50:45 2008 From: hassan at webtuitive.com (Hassan Schroeder) Date: Wed, 30 Apr 2008 17:50:45 -0700 Subject: [Javascript] IE/FF, getElementById and checkboxes In-Reply-To: References: Message-ID: <481913E5.8000508@webtuitive.com> Alan Easton wrote: 1. problems in Firefox? install Firebug. now. :-) 2. can't identify a failure? wrap everything in a try/catch block and alert it -- hard to miss, and it stops a failed form submission on the spot >