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: Garrett Smith on 11 Feb 2010 15:37 David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> jdalton wrote: >>>> David, [...] >>> >> 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. :( > if(badNamesExp.test(name)) { throw new TypeError("Bad form control name: " + name + "."); } -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 11 Feb 2010 15:39 jdalton wrote: > 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). Yes, "*" is a pain anyway you slice it (and highly ill-advised). There are disagreements between some of the frameworks on this one (even without QSA). I'll look at that. And IE has always handled OBJECT/PARAM combinations strangely. I imagine that carries over to their QSA. > >> 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) Somewhat, but I have made a lot of improvements in the last month or so (and I don't see a lot of progress on the others, which really bugs me as I pointed out some of the more blatant missteps years ago). They seem keen to pile on "cool" new features, but neglect to deal with the bugs in the old ones. > >> 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. Yes. I agree with that and have touched on it from time to time in various forums. The "pitch" on my site is admittedly vague and I have been working on some comparison tests (starting with these two quasi-standard suites) to demonstrate the differences. > >> 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. I completely agree that running their tests could illuminate problems that I may have missed. I will definitely do so when I feel it is appropriate (not quite yet). > Some of their tests are invalid or are API specific and those are > weeded out. Right. And I don't have time to do that weeding at the moment. I'll get to it. > >> 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. The problem is that anything based on the UA string is misleading. If you must expose such flags, it would be better to use multiple object inferences. And most of the time, IE is the culprit and it has its own mechanisms for dealing with its quirks (e.g. conditional comments/compilation). And yes, if they abstain from using those internally, then they are not disqualified. So it will take more than a search for navigator.userAgent in the source to determine if they have false fronts. > > Thanks for your thoughtful reply. > NP.
From: David Mark on 11 Feb 2010 15:47 Scott Sauyet wrote: > 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? I don't mean that the idea can't work for XML documents, just that the current implementations are not equipped for that (e.g. botched handling of get/hasAttribute and expandos which may be disallowed in XML DOM's). On the latter, I think some _attempt_ to detect XML and set custom attributes in lieu of expandos, but that's really shaky. > > Also, I want to commend both David Mark and John-David Dalton for > raising the level of discourse in this thread. > Thanks for the vote of confidence. Contrary to popular belief, I am not "trolling" here, nor am I interested in flame wars. I want to raise awareness for problems that I see as continuing endlessly for no good reason (e.g. browser sniffing, botched DOM traversal, etc.) It is certainly counter-productive when things devolve into non-arguments. :)
From: David Mark on 11 Feb 2010 15:59 Garrett Smith wrote: > David Mark wrote: >> Garrett Smith wrote: >>> David Mark wrote: >>>> jdalton wrote: >>>>> David, > > [...] > >>>> >>> 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. :( >> > > if(badNamesExp.test(name)) { > throw new TypeError("Bad form control name: " + name + "."); > } That's a possibility. Though I try to avoid introducing try/catch/throw in the core modules. It's not that I care about NN4 and the like, but I find it invaluable to be able to test the bulk of the core (particularly the DOM-related modules) in ancient browsers at the moment. I'm getting to the point where I care less about that though as I think I've filled in the cracks in the feature testing well enough at this point (i.e. the older browsers have a chance to degrade gracefully). At the moment, Flash and Ajax are the only two that trigger the wholesale parse error degradation when included in the build.
From: jdalton on 11 Feb 2010 16:04
> I don't mean that the idea can't work for XML documents, just that the > current implementations are not equipped for that (e.g. botched handling > of get/hasAttribute and expandos which may be disallowed in XML DOM's). > On the latter, I think some _attempt_ to detect XML and set custom > attributes in lieu of expandos, but that's really shaky. Actually some, like NWMatcher and other new comers, are supporting XML/ XHTML/SVG documents > Thanks for the vote of confidence. Contrary to popular belief, I am not > "trolling" here, nor am I interested in flame wars. I don't know, some of your threads seem to be full of flame bait. You could have probably approached them in a better way to provide constructive feedback without the flame injected into them. > I want to raise awareness for problems that I see as continuing endlessly for no good > reason (e.g. browser sniffing, botched DOM traversal, etc.) It is > certainly counter-productive when things devolve into non-arguments. :) I agree, I think those are problems that should be highlighted. Speaking of raising awareness, have you thought about submitting speaking proposals to the various JS conferences ? |