QSA--buggy in lots of browsers?
in [JavaScript]
|
Prev: Java Lead with GUI & SWT | CA | 10+ months
Next: Presentation of a new native JavaScript database
From: David Mark on 11 Feb 2010 14:16 jdalton wrote: > David, > >> LOL. It's the same guy (gal?) over and over. They just keep changing >> their name to make it look like they are an army. > I not posting as anyone else. I didn't say that you were. > >> There was a bogus test posted that excluded my QSA add-on (without >> noting the fact) and then asserted My Library was "one of the slowest" >> because QSA out-performed it. > That is wrong. The majority of browsers I reported (18 of 23 results) > do *not* have QSA. > >> This was ostensibly because the other >> libraries had gone to great lengths to ensure their QSA tack-ons were >> consistent cross-browser. > I didn't say "great lengths to ensure", I said at least they attempted > to put an effort into it. That was later. The general implication was that there were lots of QSA bugs and therefore my 0 workarounds were way below par. But fair enough. > > Here is what I found: > (I am not counting the try-catch as a bug check because all have that) > > My Library QSA addon has 0 QSA bug checks Right. I'll add the Webkit quirks/className/case check when I have a chance. > > YUI 3.0.0 has 0 QSA bug checks that I could find :( Not surprised. They've got a lot of work to do on the DOM side too. :( > > MooTools 1.2.4 doesn't use QSA Okay. Good for them! Seriously. That's the sensible approach for now. > > Prototype 1.6.1 (next release they are switching to Sizzle) Jeez. Well, at least bugs will be in just one place. :) > WebKit className issue line #3217 > Context check line #3293 I'll look at the second one. > > Sizzle 1.0 (Used in jQuery): > WebKit className issue > http://github.com/jeresig/sizzle/blob/master/sizzle.js#L894 > > Avoid QSA on non HTML elements > http://github.com/jeresig/sizzle/blob/master/sizzle.js#L903 I noted that, but I think it is a waste of time (and not exactly accurate). None of these CSS selector queries are appropriate for XML as far as I can see. They might work in some cases. > > Avoid issues when .length of a nodeList maybe an element > http://github.com/jeresig/sizzle/blob/master/sizzle.js#L724 Are you talking about the workaround for form controls named "length"? That's valid, but not related to QSA. > > jQuery 1.4.1 (in addition to the Sizzle checks) > Avoids QSA for simple id selector line #121 > Avoids QSA for simple tagName selector line #142 That's sensible. > > Dojo 1.4.0 > Starting with combinator check line #9240 I'll look at that one. I don't believe I support queries that start with a combinator at all, but will have to check. Sounds odd. > IE pseudos selector check line #9244 That's covered by try-catch and if the check involves a UA sniff, it is disallowed. > className case bug line #9246 > Avoids `:contains` and `:checked` line #9255 The avoidance of "checked" is an incomplete attempt to make it gibe with the DOM traversal (they all foul up on user data AFAIK). Avoiding the odd :contains psuedo-selector > Avoids attribute selector `|=` line #9256 > Converts to a dojo.NodeList #9583 I don't follow on that last one. I return an Array object, regardless of the fork taken. > > NWMatcher 1.2.1 (line numbers range from 233 - 302) I don't know what that is. > className should be case-sensitive in quirksMode (draft spec) > `:enabled` and `:disabled` bugs with hidden fields (Firefox 3.5 > QSA bug) Don't support those two (and likely never will). I just don't think it makes sense to try to support every selector. > IE8 throws errors with some pseudos > `:checked` bugs with checkbox fields (Opera 10beta3 bug) I'd be careful of any reported bugs related to user data. If they didn't recognize that their DOM traversal was being contaminated, they may be trying to accommodate that shortcoming in the new fork. > link bugs with hyperlinks matching (Firefox/Safari) Also something botched due to attribute handling in DOM traversal, so likely a compensation in the new fork. > Attribute bugs with isMap, checked, disabled, multiple, readonly, > selected I am sure I have those covered. And checked/selected is user data again. And this looks like an incomplete list of issues related to buggy MSHTML attribute methods. I don't believe these are QSA-related. > Avoid QSA for simple id, className and possibly tagName selectors > Avoid issues when .length of a nodeList maybe an element line > #1206 > > I am not debating the quality of there checks but I am saying they at > least attempt to check for inconsistencies/bugs. I do too (on some of those). > > I believe your Slickspeed results aren't very useful because it only > averages the time it takes to execute a method call 4 times per test > which results in a lot of useless 0ms returns. When QSA is involved, I agree. I've mentioned that there is not enough precision to measure. > > So I used a modified version of Slickspeed which tests the max number > of executions a function can perform in a given time period (in this > case 200ms to start, later after Richard's review, I bumped it to > 400ms). Okay, but is it right this time? > > At first I used a version of your My Library from your builder (just > the dom+query module) and then later, after you mentioned your builder > produced outdated code, I switched to the version from your download > page. > (both *without* your QSA addon because I take issue with it) Right. And the builder will be updated soon as it has been few weeks at this point (I've been busy). > > To be fair I then posted results from a range of browsers (most did > not support QSA) and marked your score with an asterisk. > > The results re-posted here for context. > > Win XP (mylib.js from your builder using just the DOM query modules) > ----- > > IE 7.0.5730.11 > 32 51 21 39* 73 59 26 > > IE 6.0.2900.5122.xpsp_sp3.gdr.080814-1236 > 30 50 20 38* 75 59 26 > > IE 8.0.6001.18702 (Compatibility View) > 56 91 33 72* 216 108 62 > > Opera 9.50 (build 10063) > 160 150 55 68* 339 170 128 > > > WinXP (using mylib-min.js from your download page) > ----- > > Opera 9.25 > 49 81 29 40* 151 90 42 > > Opera 9.50 > 159 146 57 112* 347 173 123 > > Opera 9.64 > 127 127 47 98* 316 143 108 > > Opera 10.10 > 201 352 62 109* 554 426 368 > > Chrome 1.0.154.36 > 252 407 139 279* 849 476 448 > > Chrome 2.0.172.28 > 267 615 144 335* 1499 830 716 > > Chrome 3.0.195.21 > 350 946 161 114* 2160 1333 970 > > IE6 > 29 47 18 35* 69 60 24 > > IE8 (Compatibility View) > 61 97 38 81* 234 117 64 > > Firefox 3.6 > 244 305 188 99* 922 354 318 > > OSX 10.4 > -------- > > Safari 2.0.0 > 1 0 9 1* 10 5 0 > > Safari 2.0.4 > 2 0 2 3* 15 0 2 > > Safari 3.04 > 17 20 13 15* 54 24 16 > > Safari 3.1 > 177 302 84 124* 562 387 362 > > Firefox 2.0 > 7 12 7 7* 28 14 7 > > Richard Cornford then reviewed my Slickspeed internals and made some > suggestions (none of which changed the overall result trend) > As per Richards's review I increased the sample time from 200ms to > 400ms and made it display the straight execution count in the results. > > IE8 (Compatibility Mode) > 5,958 8,362 3,238 5,681* 17,768 8,630 3,499 > > Opera 9.25 > 7,675 13,137 4,688 6,599* 25,826 14,941 6,620 > > Opera 9.50 > 33,643 31,268 11,725 24,128* 71,395 36,086 27,150 > > Safari 3.0.4 > 2,715 2,561 2,333 2,325* 8,794 3,787 2,547 > > > Out of the 23 results posted I believe 5 used QSA. > In many of the results `My Library` was one of the slowest libs tested > (though in some it was middle of the road or better) I just don't think such measurements are of any real practical value. And most of the others use browser sniffing and fail to deal with attribute-related issues (in all browsers, but particularly in IE), so I don't accept them as solutions. > > I apologize for any impression that I was trying to mislead people. I > have added a note to the Slickspeed stating MyLib is without the QSA > addon. Okay. I appreciate that. Seems only fair. > > I would like to try to keep the dialog from turning into a flame war > and avoid name calling/personal attacks. You really crossed the line digging into (and misreporting) my private business. But I'm not interested in flaming either. > (I certainly contributed to the first round of dialogs spiraling into > flame bait and would like to avoid it again) Yes. Fair enough. > > I am not cheerleading any major framework and really only raised an > issue with your results because of how abusive, warranted or not, I > think you are toward other frameworks/developers. I've really lost patience with the lot of them. I feel like they are fumbling the game away and we will all end up programming Flash (or the like) because they have made cross-browser scripting look much harder than it is (and have really perverted the whole thing with browser sniffing and other bizarre strategies). > I hope my test > results are useful to you and help you fine-tune your approach. > I will look at them again. Yes, I could do to fine-tune. I haven't profiled or even put much thought into optimizing the DOM traversal end of it. As mentioned, the bulk of that code was written years ago. The thing is, I don't think GP libraries are a good approach to browser scripting at all, so I stopped working on it (and repeatedly warned _against_ using it for anything but an example). I was primarily trying to show how it could be done without browser sniffing. It took until IE8's release to demonstrate that the system worked. I slept right through the release of that thing and was quite pleased to see that My Library came through unscathed when I finally got around to testing it. I feel that is in stark contrast to the other efforts, which are still having problems with that browser (as predicted two years back in my discussions with Resig about jQuery's incessant sniffing). You have noted some legitimate bugs (and some not so legitimate). And, yes my documentation is not quite up to speed yet (which is not a good thing). However, I take issue with the idea that because I made mistakes two years ago (which I have admitted here numerous times), it invalidates my criticism of the same mistakes being made to this day. It doesn't follow. Basically, my attitude on that is "do as I say, not as I did" as you learn from people who have already made the mistakes. Now that I have revived the project and people seem to be ready for a change, I am working to correct those mistakes (and to warn users of the potential for problems in some areas). The other thing is that I don't feel that results from other frameworks' unit tests are appropriate indicators. Of course there will be a lot of overlap as they all cover similar ground, but (other than Dojo) I don't know exactly what they are testing and don't really want to get into it until I have finished my own unit tests and defined _exactly_ what is supported for each module. The typical Web developer is ignorant of the details, so it could serve to mislead people. And, I assure you, due to rotten attribute handling and browser sniffing, most of these other frameworks will fail my unit tests, which cover things they definitely specify as supported. I don't mind criticism at all, but it needs to be honest and definitely should not be personal. If _I_ make (or made) a mistake on something or missed something, it doesn't let the others off the hook for their various failings. Their pitch has always been the vigilance of thousands of users and developers (and the number of years they've been at it). So why can't they keep up with an effort that was thrown together in a couple of months and then ignored for two years? It seems paradoxical to me. And I am by no means the only one capable of such a display. But most professional (and competent) JS developers don't believe in GP libraries as browser scripts should be context-sensitive, hence the lack of good GP examples. Also, I believe that any that reference the UA string are forfeiting the game, and their results should be thrown out. I also don't feel that blowing up in older browsers is appropriate (and I don't see any way to avoid it with most of these other things).
From: Garrett Smith on 11 Feb 2010 14:49 David Mark wrote: > jdalton wrote: >> David, >> [...] >> Avoid issues when .length of a nodeList maybe an element >> http://github.com/jeresig/sizzle/blob/master/sizzle.js#L724 > > Are you talking about the workaround for form controls named "length"? > That's valid, but not related to QSA. > Form control named "length" just barely scratches the surface of the type of problem caused by unsafe name. http://jibbering.com/faq/names Best to just avoid naming form controls (or other element) as "length", "elements", "title", etc. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 Feb 2010 14:55 Garrett Smith wrote: > David Mark wrote: >> jdalton wrote: >>> David, >>> > [...] > >>> Avoid issues when .length of a nodeList maybe an element >>> http://github.com/jeresig/sizzle/blob/master/sizzle.js#L724 >> >> Are you talking about the workaround for form controls named "length"? >> That's valid, but not related to QSA. >> > > Form control named "length" just barely scratches the surface of the > type of problem caused by unsafe name. Yes. I deal with that in the getAttribute wrapper. Though I am on the fence as to whether I should. An immediate failure in IE may be a better tactic. But then, I don't think this issue is present in IE8 standards mode and some Web developers refuse to test IE < 8, so a bug could slip through to production. :( > > http://jibbering.com/faq/names > > > Best to just avoid naming form controls (or other element) as "length", > "elements", "title", etc. > [...] No question.
From: jdalton on 11 Feb 2010 15:03 David, Awesome reply. > Are you talking about the workaround for form controls named "length"? > That's valid, but not related to QSA. It might be still be a QSA issue (for IE, thought I haven't confirmed) but the point was it was still doing extra processing in the QSA branch. As for the IE8 bugs I reported, they are related to QSA as the IE attribute issues and other bugs are carried over into QSA. For example IE8 will return comment nodes in QSA with the `*` wildcard and IE8 QSA seems to ignore PARAM elements (probably others too). > I've really lost patience with the lot of them. I feel like they are > fumbling the game away and we will all end up programming Flash (or the > like) because they have made cross-browser scripting look much harder > than it is (and have really perverted the whole thing with browser > sniffing and other bizarre strategies). I have felt that frustration too but you have to realize that name calling/attacks really turn people off. Try to promote your framework by focusing more on its positives and less on others negatives. > Basically, my attitude on that is "do as I say, not as I did" I think that is a good point but you seem to be currently promoting that same/similar code base (Your tweets/website and what not) > It took until IE8's > release to demonstrate that the system worked. I think the IE8 release is an excellent example that you can use to promote your framework. I was frustrated with how other frameworks handled that too. Just try to focus on how well your framework handled the transition and not attack the others for having to rush out and patch their libs. > The other thing is that I don't feel that results from other frameworks' > unit tests are appropriate indicators. Of course there will be a lot of > overlap as they all cover similar ground, but (other than Dojo) I don't > know exactly what they are testing and don't really want to get into it > until I have finished my own unit tests and defined _exactly_ what is > supported for each module. The typical Web developer is ignorant of the > details, so it could serve to mislead people. I disagree in part. I have found supplementing my existing tests with those of others (at least their css selector unit tests), has helped me find a lot of oddball bugs. Some of their tests are invalid or are API specific and those are weeded out. > Also, I believe that any that reference the UA string are forfeiting the > game, and their results should be thrown out. I agree but I don't see a problem with a lib having UA properties like a `SomeLib.Browser.IE` if they internally don't use them or only use them in cases of visual bugs/bugs that can't be feature tested or lack a relevant object inference. Thanks for your thoughtful reply.
From: Scott Sauyet on 11 Feb 2010 15:19
On Feb 11, 2:16 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > jdalton wrote: >> Avoid QSA on non HTML elements >> http://github.com/jeresig/sizzle/blob/master/sizzle.js#L903 > > I noted that, but I think it is a waste of time (and not exactly > accurate). None of these CSS selector queries are appropriate for XML > as far as I can see. They might work in some cases. I'm curious as to why you say that. There are certain things supported by the various libraries (":enabled", ":checked") that are specific to HTML, but almost all the rest of it looks to me to be appropriate to generic XML. What am I missing? Also, I want to commend both David Mark and John-David Dalton for raising the level of discourse in this thread. -- Scott |