New jQuery announced!
in [JavaScript]
|
From: David Mark on 18 Dec 2009 09:44 On Dec 17, 7:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > Garrett Smith wrote: > > Matt Kruse wrote: > >> On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > >>> Matt Kruse wrote: > >>> | obviously the attr() method is meant to only set string attributes. > > [...] > ng is a event handlers (click, etc) get attached. > > > Consider what jQuery actually does with ready, and then with:- > > > var el = jQuery("redBox")[0] > > correction: > var el = jQuery("#redBox")[0]; One other correction:- jQuery("#redBox")[0] == document.getElementById('redBox'); They don't have a single element abstraction, so the wrappedEl mentioned previously was just a plain node reference. I agree with the points made. It's even worse when you consider that jQuery uses QSA for some browsers and its own attribute-botching BS for others. Similar XPath-based forks exist in other "major" libraries as well. There are lots of cases (some demonstrated recently) where the two forks will diverge, even in HTML DOM's (XML/ XHTML are certainly out of the question if consistency is desired). In a nutshell, the "silver bullet" solutions just make basic concepts harder to grasp (see the recent jQuery Summit on Attributes), less consistent across browsers and prone to obscure errors (especially when new browser versions are released). Handing these scripts (and accompanying books) to neophytes is not likely to turn out well. And expecting the authors of these things to gain understanding one "show me" at a time is dreaming. :)
From: Garrett Smith on 18 Dec 2009 16:22 David Mark wrote: > On Dec 17, 7:15 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >> Garrett Smith wrote: >>> Matt Kruse wrote: >>>> On Dec 11, 1:06 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: >>>>> Matt Kruse wrote: >>>>> | obviously the attr() method is meant to only set string attributes. >> [...] >> ng is a event handlers (click, etc) get attached. >> >>> Consider what jQuery actually does with ready, and then with:- >>> var el = jQuery("redBox")[0] >> correction: >> var el = jQuery("#redBox")[0]; > > One other correction:- > > jQuery("#redBox")[0] == document.getElementById('redBox'); > > They don't have a single element abstraction, so the wrappedEl > mentioned previously was just a plain node reference. > Yep. wrappedEl was a very misleading variable name. The second example using - var el - got it right. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 18 Dec 2009 22:49 Garrett Smith wrote: > Stefan Weiss wrote: >> On 11/12/09 08:35, Garrett Smith wrote: >>> Garrett Smith wrote: >>>> jQuery.attr has specific handling for many odd cases. What does attr >>>> have to do with: >>>> >>>> | if ( name == "selected" && elem.parentNode ) >>>> | elem.parentNode.selectedIndex; >>>> [snip] >> >> It would appear that this was intended as a bug workaround, and that >> reading the selectedIndex property is all that's required. Still, it's a >> strange thing to do, and could very well be optimized away by a minifier >> tool or by the JS engine itself. >> > A workaround, but to what problem? > > <body onload ="alert(document.getElementById('c').selected)"> > <select id="x"> > <option id="a">a</option> > <option id="b">b</option> > <option id="c" style="visibility: hidden;" selected>c</option> > <option id="d">d</option> > </select> > > In Safari, the 'c' is selected, the alert is - true - and when the > select is expanded, the 'c' option is blacked out. > > Perhaps someone can demonstrate what the workaround actually fixes. One more time: Can anyone demonstrate the problem that the workaround exists for? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Matt Kruse on 19 Dec 2009 00:28 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; } } Matt Kruse
From: Garrett Smith on 19 Dec 2009 01:25
Matt Kruse 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. 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 > > Here was my recommended change to the jQuery source: > [snip] HTat's a totally different comment then what appears in the jQUery source. 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? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |