New jQuery announced!
in [JavaScript]
|
From: Matt Kruse on 19 Dec 2009 10:46 On Dec 19, 12:25 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Ah, so the selected property is true after onload, but false while the > page is loading. I can reproduce that. > The workaround of accessign - selectedIndex - of the parent causes the > OPTION's - selected - to be true. > That is considerably different then what the comment states: > | // Safari mis-reports the default selected property of a hidden option Indeed, the source is misleading. > > Here was my recommended change to the jQuery source: > HTat's a totally different comment then what appears in the jQUery source.. Yup, I re-wrote it. > You wrote earlier that attr() deals only with string values. After I > posted that code, you wrote:- > | I didn't look at the source closely enough. > Did you propose that and then think they did not integrate that proposed > change, and instead decided to not return values from boolean properties? I don't really follow. I posted my corrected comment and code for the above issue to the jquery-dev mailing list a few days ago. I'm not sure any attention was paid to it. Matt Kruse
From: David Mark on 19 Dec 2009 11:43 On Dec 19, 12:28 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 18, 9:49 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > >>>> | if ( name == "selected" && elem.parentNode ) > > One more time: Can anyone demonstrate the problem that the workaround > > exists for? > > Yes:http://ejohn.org/files/bugs/selected/ > > The bug (or quirk) is valid, but should be documented better, and it's > debatable whether it should even be "fixed" to begin with. > > Here was my recommended change to the jQuery source: > > // In Safari, if no option is explicitly selected and the first > // option gets selected by default, this option will report > // selected==false _while the page is still loading_. Accessing the > // containing select element causes the option to set its > // selected state correctly. Since options may be nested in > // <optgroup> elements, access two levels up just to be safe. > // Simply accessing the .selectedIndex property even if it doesn't > // exist shouldn't cause a problem in any browsers. > //http://ejohn.org/files/bugs/selected/ > if ( name == "selected" && elem.parentNode ) { > elem.parentNode.selectedIndex; > if (elem.parentNode.parentNode) { > elem.parentNode.parentNode.selectedIndex; > } > > } > Ridiculous. Try detecting the problem you are trying to solve (once preferably). There's just no basis for this "solution" (which is also outrageously inefficient). Blind faith has no place in programming (especially not browser scripting). During initial feature detection, you could create a SELECT, add a selected option and check the selectedIndex property. If the SELECT must be in a document to duplicate the quirk, wait until one is passed and do the test on it (perhaps replacing the method as a result). This stuff is not rocket science. :) And didn't they just "punt" (again) on the "issue" of frames? Something about "common use cases?" Why are you going for it here? It's fourth and a mile. ;)
From: David Mark on 19 Dec 2009 11:48 On Dec 19, 10:46 am, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 19, 12:25 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > > > Ah, so the selected property is true after onload, but false while the > > page is loading. I can reproduce that. > > The workaround of accessign - selectedIndex - of the parent causes the > > OPTION's - selected - to be true. > > That is considerably different then what the comment states: > > | // Safari mis-reports the default selected property of a hidden option > > Indeed, the source is misleading. As usual. That's a by-product of the authors' general confusion. Similar clueless comments are strewn throughout all of the "major" libraries and the related code is now etched across the Web like a scar. Even worse, newcomers reference these things like they were bibles, gleefully re-posting the "wisdom" within, so the misconceptions multiply. > > > > Here was my recommended change to the jQuery source: > > HTat's a totally different comment then what appears in the jQUery source. > > Yup, I re-wrote it. One baby step for mankind. :) > > > You wrote earlier that attr() deals only with string values. After I > > posted that code, you wrote:- > > | I didn't look at the source closely enough. > > Did you propose that and then think they did not integrate that proposed > > change, and instead decided to not return values from boolean properties? > > I don't really follow. I posted my corrected comment and code for the > above issue to the jquery-dev mailing list a few days ago. I'm not > sure any attention was paid to it. > Probably not. What does that tell you?
From: Matt Kruse on 19 Dec 2009 16:40 On Dec 19, 10:43 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Ridiculous. Try detecting the problem you are trying to solve (once > preferably). There's just no basis for this "solution" (which is also > outrageously inefficient). Detecting the problem would surely be less efficient than simply accessing a property, when the latter works just fine. > Blind faith has no place in programming > (especially not browser scripting). It's not blind faith, it's tested and proven successful. > During initial feature detection, you could create a SELECT, add a > selected option and check the selectedIndex property. What does selectedIndex have to do with anything? It returns the correct value. It's the <option> tag's 'selected' property that is incorrect. > If the SELECT > must be in a document to duplicate the quirk, wait until one is passed > and do the test on it (perhaps replacing the method as a result). > This stuff is not rocket science. :) If you wait until the document is ready, then the problem goes away. It's a weird quirk, but it looks like you are just spewing "answers" when you've never actually looked at the problem. Matt Kruse
From: David Mark on 19 Dec 2009 18:05
On Dec 19, 4:40 pm, Matt Kruse <m...(a)thekrusefamily.com> wrote: > On Dec 19, 10:43 am, David Mark <dmark.cins...(a)gmail.com> wrote: > > > Ridiculous. Try detecting the problem you are trying to solve (once > > preferably). There's just no basis for this "solution" (which is also > > outrageously inefficient). > > Detecting the problem would surely be less efficient than simply > accessing a property, when the latter works just fine. Nonsense. You detect it _once_. > > > Blind faith has no place in programming > > (especially not browser scripting). > > It's not blind faith, it's tested and proven successful. Proven? It's certainly reasonable to expect the line will be discarded as a noop. It's unreasonable to expect it will magically updated the state of the DOM, particularly in the presented case where the document hasn't finished parsing. > > > During initial feature detection, you could create a SELECT, add a > > selected option and check the selectedIndex property. > > What does selectedIndex have to do with anything? It returns the > correct value. It's the <option> tag's 'selected' property that is > incorrect. So you can eliminate that as a possible test, but it would certainly make for a more logical workaround. ;) > > > If the SELECT > > must be in a document to duplicate the quirk, wait until one is passed > > and do the test on it (perhaps replacing the method as a result). > > This stuff is not rocket science. :) > > If you wait until the document is ready, then the problem goes away. I didn't say to wait until the document is ready. > > It's a weird quirk, but it looks like you are just spewing "answers" No, if there is one thing you should have picked up by now is that I have the answers and they are virtually always the same. ;) You seem sure you've isolated a quirk. Now write a test for it. You couldn't get an answer from selectedIndex. What next? :) > when you've never actually looked at the problem. I don't need to. I often solve such problems without seeing them (usually in advance of their manifestation). ;) |