«

Peter Michaux wrote:
> On Mar 3, 5:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Peter Michaux wrote:
>>> On Mar 2, 9:58 pm, David Mark <dmark.cins...@gmail.com> wrote:
>>>> Perhaps in some way queries could be considered a nice idea. Too bad
>>>> the implementation was so completely botched (over the course of roughly
>>>> five years).
>>> *the* implementation of what?
^^^^^^^

>> CSS selector queries (the thing that is discussed in the cited article).
>
> There isn't *one* implementation.

That's not what you asked.

>
>
>
>>>> Executive summary for the cited article: do not use queries.
>>> What do you mean by "do not use queries"? What constitutes a "query"?
>>> Are document.getElementsByTagName or document.getElementById bad in
>>> your books?
>> Obviously not. Those standard DOM methods are what queries attempted to
>> stamp out, despite the fact that they are virtually 100% reliable and
>> work in almost every browser (certainly anything that has come out of late).
>
> What you are writing is confused.

To you perhaps.

> You are suggesting that using the
> DOM methods is ok but writing functions that use the DOM methods is
> not ok.
>

Depends on what those functions do, doesn't it? See above for the
specific types I am referring to.

On Mar 3, 6:03*pm, David Mark <dmark.cins...@gmail.com> wrote:
> Peter Michaux wrote:
> > On Mar 3, 5:01 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> Peter Michaux wrote:
> >>> On Mar 2, 9:58 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >>>> Perhaps in some way queries could be considered a nice idea. *Too bad
> >>>> the implementation was so completely botched (over the course of roughly
> >>>> five years).
> >>> *the* implementation of what?
>
> * * * * * * * * * * * * *^^^^^^^
>
> >> CSS selector queries (the thing that is discussed in the cited article).
>
> > There isn't *one* implementation.
>
> That's not what you asked.

There is still not one implementation.



> >>>> Executive summary for the cited article: do not use queries.
> >>> What do you mean by "do not use queries"? What constitutes a "query"?
> >>> Are document.getElementsByTagName or document.getElementById bad in
> >>> your books?
> >> Obviously not. *Those standard DOM methods are what queries attempted to
> >> stamp out, despite the fact that they are virtually 100% reliable and
> >> work in almost every browser (certainly anything that has come out of late).
>
> > What you are writing is confused.
>
> To you perhaps.
>
> > You are suggesting that using the
> > DOM methods is ok but writing functions that use the DOM methods is
> > not ok.
>
> Depends on what those functions do, doesn't it? *See above for the
> specific types I am referring to.

You haven't written anything worthwhile in this thread and I have no
idea what your point is or why you think your logic leads to your
conclusion.

Clearly being able to find elements in a document is a worthwhile
feature for browser scripting. The DOM methods allow that. Those
methods can be combined to make more complex query functions. Those
new functions are reusable which is a primary goal of good software
engineering. Using a domain specific language (i.e. CSS selectors) to
specify the desired elements provides a compact, declarative API is a
good idea. CSS has shown it to be a good idea. I've used simple
selectors and a selector function in JavaScript and looking back it
was a good idea.

So although your initial post in this thread was very vague, with the
extra details you've provided, the answer to your question...

> Can there be any doubt at this point that queries were a bad idea?

There is definitely doubt. In fact, it is more than just doubt. The
opposite is true. Using CSS selectors for finding elements in a page
(aka queries) is, at the very least, not a bad idea.

Peter

On Mar 3, 7:38*pm, David Mark <dmark.cins...@gmail.com> wrote:
> Peter Michaux wrote:

> > Using a domain specific language (i.e. CSS selectors) to
> > specify the desired elements provides a compact, declarative API is a
> > good idea.
>
> As I said at the outset, it could be considered a nice idea in some
> circles, but has been proven not to be.

No it hasn't *proven* to be a bad idea. Being able to find elements in
a document is important. Building reusable functions to do that is not
a bad idea.

Peter

David Mark wrote:
> Scott Sauyet wrote:

>> If I were to make the following (entirely factual) post, there would
>> be good reason for complaint:
>
> Why?

Do you *really* need to ask that question when you proceed to make
complaints about it?

>> | * I've just posted another update of my version of the Slickspeed
>> | * framework. *You can see it here:
>> |
>> | * * *http://scott.sauyet.com/Javascript/T...d/2010-03-03a/
>> |
>> | * There are a number of new selectors, as proposed by David Marks.

> New selectors? *Not really.

The post you referenced to start this thread, begins, "Added :root
pseudo and finished up the positional selectors. Lots of new tests
added to the SlickSpeed page"

Six weeks ago, you posted your version of Slickspeed with 28
selectors, down from the original 40 that are usually found in
Slickspeed. When I commented on your reducing the number by 30% you
said that it couldn't be that high; for the record 12 is exactly 30%
of 40. I posted a copy of Slickspeed with different libraries but
with the same set of selectors at

http://scott.sauyet.com/Javascript/T...d/2010-01-22b/

In this thread, you now have 81 selectors. As your page keeps
changing, my version, with your selectors is here:

http://scott.sauyet.com/Javascript/T...d/2010-03-03a/


>>| * jQuery is the clear-cut winner here, followed by YUI, Dojo, and
>>| * Prototype. *My Library is pulling up the rear. *My Library
>>| * errors out on seventeen different selectors, gets twelve others
>>| * wrong, and is the slowest on thirty-four additional ones.
>>| * Clearly My Library has some catching up to do.
>
> As mentioned below, this is all made-up BS. *

And as mentioned before I even posted it. The whole point was that
posting misleading tests is BS. If you still can't see how that
applies to your own post, your blindness is rather stunning.


> You were testing an old
> version without the QSA adapter against libraries that were just handing
> the queries off to the browsers (using QSA). *And you disingenuously did
> not include the latest versions (with or without QSA adapters) that do
> support more of your tested selectors. *It was a stupid comparison then
> and even more so now.

I'm not sure what "then" you are using here. This was a brand new
version of Slickspeed posted today using the set of selectors you
promoted.


>> Of course the most obvious complaint is that this only discusses the
>> results in one browser, and a very recent one at that. *But that is
>> not the worst of it.
>
> Who are you complaining about?

I'm explaining what was wrong with my hypothetical post. By
comparison, you might see some of what's wrong with yours.


>> The main thing is that I included a six-week old version of My
>> Library.
>
> Well, how lame. *Many of the selectors weren't even _present_ in the
> library then. *

So, your six-week old version can't handle many of the tests thrown at
it, but you think it's perfectly legitimate to compare it to a 130-
week old version of jQuery. Hmmm.


> You do understand that I'm only adding them because
> that's what people seem to want (and continue to run tests that use
> them, hence making it look like mine is "broken"). *And then you post
> tests that use a rendition posted six weeks ago (before I started adding
> the bulk of the "standard" selectors). *What are you trying to prove?

The whole point is that I wouldn't actually post such misleading
claptrap, and I really wish you would stop doing so yourself.


>> And many of the tests that you've since added to your
>> Slickspeed version don't work in that older one.
>
> What does that mean? *Why are you testing a version of My Library that
> (as documented), didn't support all of the selectors. *It doesn't make a
> lot of sense as there were appropriate tests for that one at the time. (?)

And yet you continually bemoan how the so-called major libraries
constantly are being updated without stable releases...


> > You've cried foul
> > before on my testing My Library against selectors it doesn't claim to
> > support, even though those were the selectors that have been included
> > with Slickspeed since the beginning.
>
> Just one. *The :not pseudo selector, which I will add shortly, along
> with the of-type stuff, which was never on the "standard" SlickSpeed
> test (quotes indicate there are myriad versions of that test). *Again,
> you don't really know what you are talking about.

Well, testing that six week old library against your new list, there
were 17 errors and 12 additional wrong answers in FF. On the original
forty Slickspeed selectors, there were 5 errors and 10 additional
wrong answers as can still be seen here:

http://scott.sauyet.com/Javascript/T...d/2010-01-22a/

>> But you're adding all sorts of
>> new selectors and pointing out the failure of other libraries to
>> already have them working.
>
> You should re-read my test page. *There are maybe two or three rows that
> do not have the same old selectors (e.g. :root and :lang). *And notice
> that the other libraries appear to work in QSA-enabled environments, but
> then fail when that crutch is not present. *That's no good. *They either
> support the selectors or they don't. *And even variations of ones they
> ostensibly support are botched beyond belief. *You don't have to use the
> specific selectors that were on whatever SlickSpeed page you first
> encountered. *Feel free to riff on them as that is how you test if
> things work in more than a superficial manner. *

Of course you don't have to use the ones you found. You can alter the
document. You can replace the list of selectors. You can even change
how the timing is determined. As long as it seems clear that the
intent is not to simply make one's own library look better, any of
this is fair game. However, if I were to post a version that included
only those queries at which dojo is fastest, and then tried to use it
to demonstrates the superiority of dojo, others would understandably
object. That is what it seems you are doing.


>> You still include jQuery 1.2.1, well over
>> two years old, in your comparison; I'll bet they didn't claim at that
>> time to include all the selectors you've added recently. *At the very
>> best, this is hypocrisy.
>
> Huh? *The old version of jQuery is there for a very good reason. *If you
> would stop and use your head, you'd know what it is (hint: it is the
> last non-QSA-assisted version). *You need to be able to see what their
> slow lane will look like compared to mine as not all browsers have QSA
> and not all queries even work with QSA. *We've had this discussion before.

So, is including QSA an appropriate thing to do or not? Not for the
other libraries, for yours? If it is, fine. If it's not, fine. The
other libraries have made their choices (subject as always to the
vagaries of changing design.) If it's most appropriate to use QSA
with My Library, then stop whining about others including it, and just
use it. If it's not, then live with the fact that others libraries
will probably be faster for a great number of queries, although they
might get things entirely wrong when the native QSA fails. That's
just the way it goes.


>> The main issue is that tools like Slickspeed are great for minor
>> bragging rights about speed. *They are useful to fix a minimal list of
>> expected behavior from libraries. *When you add selectors like this,
>> you're obviously trying to use it in a very different manner:
>
>> * * td[title='test1" # . > ~ + test2[1]']
>
> Don't be juvenile. *It's a stress test. *I added it primarily to make
> sure that _my_ parsing was working as expected. *You are acting like
> this is some sort of contest. *Well, there are no prizes and the other
> libraries have supposedly had a multi-year-head start on most of this stuff.

What's a head start in something that's not a contest?

Don't be disingenuous. You are promoting My Library unabashedly
here. I wouldn't have bothered to respond if it hadn't been for your
saying, "I had a feeling that this would create a lot more black cells
in the results table (in anything West of the last two columns of
course). Did it ever." You are treating this as a contest.


> So what? *I had a feeling that they would foul up the positional stuff
> and many of them did (one so bad it had to be cut).

Yes, it looks like MooTools can't handle nth-*: an + b where a is
negative.


>> Can you re-read that and not see it as simply self-aggrandizement?
>
> It's simply facts. *Unlike the BS you opened with about "catching up". *

No, they are equally BS. That was the point.


>> I've started to play with My Library a bit, and in many ways I like
>> it. *But the attitude you present with posts like that is more than
>> off-putting.
>
> So don't use it. *Did you read the rest of the post? *And did you get
> the main point? *Queries were a very _bad_ idea. *Don't use them. *No
> need to thank me for (hopefully) driving that point home. *And if I
> broke some eggs making that omelet, too bad.

I have nothing to add to Peter Michaud's excellent argument in favor
of CSS-selector queries as a DOM-selection mechanism.

But have you thought about the overall logic of your post at all? The
argument seems to be, "Queries suck. Don't use them. But I'm going
to spend the effort to add them to My Library, so that it's better
than all the other libraries. Just remember not to actually use
them."


>> In most environments I've worked, I wouldn't be able to
>> even *try* to suggest that the client consider using MyLib, not when
>> it's presented in such an arrogant fashion.
>
> Your client is unlikely to read technical posts in my forum. [ ... ]

Many clients want to see the mechanisms for getting help with the
tools I suggest for them. When I point out the helpful community
around Wicket (a Java Web framework) they are much more likely to
accept it as an alternative to the more well-known frameworks. With
My Library, I would have to actively steer them away from your rants
if I ever wanted them to accept it.

David, as much as you may find this hard to believe, I'm one of the
ones who wants to help I don't think the ecosystem of JS libraries is
anywhere near rich enough. I really want to see more innovation. But
the style in which you present your library makes it next to
impossible to even give it a chance.

-- Scott

David Mark wrote:
> Scott Sauyet wrote:
>
>> If I were to make the following (entirely factual) post, there would
>> be good reason for complaint:
>
> And BTW, there really is no "if" about it. *You actually went to the
> time and trouble to create and post it. *That's a lot of effort to look
> stupid. *

Well, I learned from the master.

Actually, posting a new version of the slickspeed test takes me only a
few minutes. The only reason this one took as much as ten minutes was
because the slickspeed framework didn't properly handle selectors with
single-quote characters in them, and I had to fix that.

>>| * There are a number of new selectors, as proposed by David Marks.
>
> And, just as those are not "new selectors" (did you think "2n+1" and
> "2n" were the extent of the positionals?),

I understand the distinction you are making. But it is I think not
the common usage of "selector". It is certainly not how I use it.
"div" and "p" are distinct selectors to me, as are ":nth-child(2n +
3)" and ":nth-child(2n -1)".


> my name is not "Marks."

I apologize.


> Gee, look at this, QSA can handle lots of "new selectors" and a library
> that never _claimed_ to support them can't. *Personally, I think I'd
> post a follow-up that claims an intruder broke in an used my PC to post
> that stuff. *It would be just as credible. *

I wish your post had a credible excuse.

-- Scott

Peter Michaux wrote:
> On Mar 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>> Peter Michaux wrote:
>
>>> Using a domain specific language (i.e. CSS selectors) to
>>> specify the desired elements provides a compact, declarative API is a
>>> good idea.
>> As I said at the outset, it could be considered a nice idea in some
>> circles, but has been proven not to be.
>
> No it hasn't *proven* to be a bad idea. Being able to find elements in
> a document is important. Building reusable functions to do that is not
> a bad idea.
>

You are still playing dumb. What's the point?

On Mar 4, 2:06 pm, Peter Michaux <petermich...@gmail.com> wrote:
> On Mar 3, 7:38 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Peter Michaux wrote:
> > > Using a domain specific language (i.e. CSS selectors) to
> > > specify the desired elements provides a compact, declarative API is a
> > > good idea.
>
> > As I said at the outset, it could be considered a nice idea in some
> > circles, but has been proven not to be.
>
> No it hasn't *proven* to be a bad idea. Being able to find elements in
> a document is important. Building reusable functions to do that is not
> a bad idea.

I think the basis of David's argument is that they are a bad idea
because of the differences in implementations. Because various
libraries introduce an additional set of inconsistencies, the range of
possible outcomes is greatly increased.

I think simple CSS queries can be very helpful, but most of those can
be easily replaced with simple ad hoc functions. Complex selectors can
be harmful, not only for performance, but they more tightly bind
programming logic to document layout so that a small change may cause
a script to fail or enhancements to become unreliable.

I also suspect that complex selectors are more likely to have
inconsistent results, but don't have any proof.

As for David's hyperbole, I took it as just that. Scale it back to
half-throttle and you get "[CSS] queries can lead to problems", which
is true. It wasn't that long ago that it was standard practice to
ensure sites worked without scripting and that script only enhanced
usability. Lately there has been a trend to sites that are
dysfunctional without scripting. I expect that within a few years,
browsers that do not have efficient built-in query selector support
will find the web quite unfriendly. That will lead to problems for
less capable browsers and platforms.

Incidentally, I tried surfing with Safari 1.0.3 recently - very few
sites were functional, including apple.com. Considering it's younger
than IE 6 (2004 vs. 2001), it is clear that if IE 6 didn't have the
market share it has, developers would have stopped coding around its
quirks many years ago and it would be dead by now. Imagine a web where
most browsers were DOM and CSS 3 compliant and HTML5 was mostly
implemented, then javascript libraries could focus on efficient
delivery of high-level functionality, not smoothing over browser
quirks.

And this thread would be irrelevant.


--
Rob

Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:
>
>>> If I were to make the following (entirely factual) post, there would
>>> be good reason for complaint:
>> Why?
>
> Do you *really* need to ask that question when you proceed to make
> complaints about it?
>
>>> | I've just posted another update of my version of the Slickspeed
>>> | framework. You can see it here:
>>> |
>>> | http://scott.sauyet.com/Javascript/T...d/2010-03-03a/
>>> |
>>> | There are a number of new selectors, as proposed by David Marks.
>
>> New selectors? Not really.
>
> The post you referenced to start this thread, begins, "Added :root
> pseudo and finished up the positional selectors. Lots of new tests
> added to the SlickSpeed page"

New tests, not new selectors. CSS3 has been around for years, as have
the claims of support for them by makes of selector engines. What you
meant to say was that I added variations of the same old CSS3 selectors
(e.g. mth-child(4n+3) as opposed to the usual nth-child(2n+1)). Somehow
, you see this as "cheating", which indicates you don't really
understand what these tests are for.

>
> Six weeks ago, you posted your version of Slickspeed with 28
> selectors, down from the original 40 that are usually found in
> Slickspeed.

You are wildly mistaken. I posted that roughly two years ago. And it
was perfectly appropriate to remove the tests for selectors I did not
support when I first wrote the library. In fact, there was a disclaimer
that the top that point it out.

> When I commented on your reducing the number by 30% you
> said that it couldn't be that high; for the record 12 is exactly 30%
> of 40.

Um, don't break your arm patting yourself on the back for accuracy. I
didn't count them at all. So what? Is that supposed to make up for all
of this newly posted and misleading nonsense?

> I posted a copy of Slickspeed with different libraries but
> with the same set of selectors at
>
> http://scott.sauyet.com/Javascript/T...d/2010-01-22b/

Yes, we've been over that. You didn't understand at the time about QSA.
We finally got past that (or so I thought). Anyway, so what?

>
> In this thread, you now have 81 selectors.

Yes, adding additional test cases is a good thing.


> As your page keeps
> changing, my version, with your selectors is here:

Yes, adding non-DIV's to test is a good thing too. Testing DIV's
exclusively is inherently limited (for reasons that should be obvious).
I find myself asking you this a lot, but what's the point in all of
this? It's like you go on and on about nothing and hope that the sheer
weight of it will make naive readers think there is something to it.


>
> http://scott.sauyet.com/Javascript/T...d/2010-03-03a/
>
>
>>> | jQuery is the clear-cut winner here, followed by YUI, Dojo, and
>>> | Prototype. My Library is pulling up the rear. My Library
>>> | errors out on seventeen different selectors, gets twelve others
>>> | wrong, and is the slowest on thirty-four additional ones.
>>> | Clearly My Library has some catching up to do.
>> As mentioned below, this is all made-up BS.
>
> And as mentioned before I even posted it. The whole point was that
> posting misleading tests is BS. If you still can't see how that
> applies to your own post, your blindness is rather stunning.

No, as I explained. You are blind to the fact that 98% (go calculate it
and tell me it is really 97) of the additions are variations of
selectors that are ostensibly supported by the "competition". Do you
not understand that you have to test variations to get anything more
than the same superficial results that have been deluding you (and the
library authors) into thinking all is well?

>
>
>> You were testing an old
>> version without the QSA adapter against libraries that were just handing
>> the queries off to the browsers (using QSA). And you disingenuously did
>> not include the latest versions (with or without QSA adapters) that do
>> support more of your tested selectors. It was a stupid comparison then
>> and even more so now.
>
> I'm not sure what "then" you are using here. This was a brand new
> version of Slickspeed posted today using the set of selectors you
> promoted.

The "then" was when you compared QSA to non-QSA and proclaimed that QSA
was faster.

ISTM you are doing something similar now, proclaiming (admittedly
disingenuously) that an old rendition of mine, which predates any
support for the newly added CSS3 selectors is "broken", "miscounting",
etc. and that the others are "faster", when in fact, the others are
simply handing the queries off to the browsers (using QSA) and have been
demonstrated to screw up lots of them when that crutch is taken away (as
it often is in the wild).

>
>
>>> Of course the most obvious complaint is that this only discusses the
>>> results in one browser, and a very recent one at that. But that is
>>> not the worst of it.
>> Who are you complaining about?
>
> I'm explaining what was wrong with my hypothetical post.
^^^^^^^^^^^^

FYI, That's spelled h-y-p-o-c-r-i-t-i-c-a-l. It's like making an
obnoxious joke and qualifying it with something like "if I were a real
jackass, I would have said..." You said it. You also posted bogus
tests.

> By
> comparison, you might see some of what's wrong with yours.

No, that was your qualification that was supposed to make you look
gallant and restrained rather than disingenuous and obnoxious.

>
>
>>> The main thing is that I included a six-week old version of My
>>> Library.
>> Well, how lame. Many of the selectors weren't even _present_ in the
>> library then.
>
> So, your six-week old version can't handle many of the tests thrown at
> it, but you think it's perfectly legitimate to compare it to a 130-
> week old version of jQuery. Hmmm.

You really need to get a grip. There are _three_ versions of jQuery on
that page. They are all clearly labeled. It is up to you to interpret
what the results mean to you. Seeing the history of these things has
been a real eye-opener for those who can think straight. It's not a
conspiracy to make jQuery 1.21 look lousy. But then, jQuery 1.21
claimed to support virtually all of the selectors on the page.

And, as for my six-week-old version, it handled exactly what I claimed
it would handle and I listed exactly what was _not implemented at all_
six weeks back. See the difference now? I never even wanted to add all
of these silly selectors, but as there have been requests and tests
posted that made it look broken due to the fact that it didn't support
some "standard" set of selectors...

Again, what are you trying to say?

>
>
>> You do understand that I'm only adding them because
>> that's what people seem to want (and continue to run tests that use
>> them, hence making it look like mine is "broken"). And then you post
>> tests that use a rendition posted six weeks ago (before I started adding
>> the bulk of the "standard" selectors). What are you trying to prove?
>
> The whole point is that I wouldn't actually post such misleading
> claptrap, and I really wish you would stop doing so yourself.

But you did. That's one of my points. The other is that much of what
you say and do with regard to these SlickSpeed tests is laughably inept
and demonstrates a severe misunderstanding about JS libraries, their
claims, history and how all of this paints a picture of enduring abject
incompetence. The fact that I never wanted to follow in their
footsteps, hadn't really done so six weeks back, did trample them of
late, etc. is irrelevant. Look at the big picture and imagine if I had
never even wrote a library.

>
>
>>> And many of the tests that you've since added to your
>>> Slickspeed version don't work in that older one.
>> What does that mean? Why are you testing a version of My Library that
>> (as documented), didn't support all of the selectors. It doesn't make a
>> lot of sense as there were appropriate tests for that one at the time. (?)
>
> And yet you continually bemoan how the so-called major libraries
> constantly are being updated without stable releases...

So what? I've never released mine at all. In fact, it sat on the shelf
for over two years, with me telling anyone who would listen not to use
any GP library (including mine). During that time, despite numerous
mistakes on my part, it survived the releases of several major browsers,
including IE8 without my lifting a finger. That demonstrated how the
feature testing beat the hell out of the browser sniffing that was
popular at the time. A month or two back, I started working on it
again, tested all the way back to the late 90's browsers, patched some
holes in the feature detection as a result and will release it when I
feel like it. So what?

And how is adding support for additional selectors the same as endlessly
twiddling with browser sniffing, epiphanies about IE that should have
occurred years ago, etc.? It's not as if I am fixing bugs in my
non-existent release version, am I? As a matter of fact, I'm not fixing
bugs at all. I'm adding features by request (notably from you).

And remember, one of the biggest selling points of those "major"
libraries is that they are so well-tested because they have so many
vigilant users and developers. LOL.

>
>
>>> You've cried foul
>>> before on my testing My Library against selectors it doesn't claim to
>>> support, even though those were the selectors that have been included
>>> with Slickspeed since the beginning.
>> Just one. The :not pseudo selector, which I will add shortly, along
>> with the of-type stuff, which was never on the "standard" SlickSpeed
>> test (quotes indicate there are myriad versions of that test). Again,
>> you don't really know what you are talking about.
>
> Well, testing that six week old library against your new list, there
> were 17 errors and 12 additional wrong answers in FF. On the original
> forty Slickspeed selectors, there were 5 errors and 10 additional
> wrong answers as can still be seen here:
>
> http://scott.sauyet.com/Javascript/T...d/2010-01-22a/

Um, once again, you were testing selectors that I explicitly did not
support, which was plainly documented at the top of the page. I never
claimed (two years ago) to support all forty of those "standard"
selectors (quotes indicate there are lots of variations of this test out
there). So how stupid is it to keep parroting about these imagined
failures? You can't have a failure without an assertion, can you?

>
>>> But you're adding all sorts of
>>> new selectors and pointing out the failure of other libraries to
>>> already have them working.
>> You should re-read my test page. There are maybe two or three rows that
>> do not have the same old selectors (e.g. :root and :lang). And notice
>> that the other libraries appear to work in QSA-enabled environments, but
>> then fail when that crutch is not present. That's no good. They either
>> support the selectors or they don't. And even variations of ones they
>> ostensibly support are botched beyond belief. You don't have to use the
>> specific selectors that were on whatever SlickSpeed page you first
>> encountered. Feel free to riff on them as that is how you test if
>> things work in more than a superficial manner.
>
> Of course you don't have to use the ones you found. You can alter the
> document. You can replace the list of selectors.

And what sort of fool wouldn't? The original set of selectors was all
DIV's (as was 99% of the document). How stupid was that?

> You can even change
> how the timing is determined. As long as it seems clear that the
> intent is not to simply make one's own library look better, any of
> this is fair game.

And obviously adding (4n+3) and (-2n+1) next to (2n+1) is necessary to
verify that your positional selectors are working properly. What sort
of fools (besides the authors of the original test page) wouldn't do
that? FYI, as mentioned, the primary purpose of that page is to _test_
my engine. Embarrassing the other efforts is just a highly unexpected
bonus.

> However, if I were to post a version that included
> only those queries at which dojo is fastest, and then tried to use it
> to demonstrates the superiority of dojo, others would understandably
> object. That is what it seems you are doing.

You are completely full of ****. How is adding lots of additional
positional tests going to make mine appear faster? I can't even fathom
what you are saying. Do you think I studied the ins and outs of all of
the others and determined that this area (which was coincidentally
lacking in the original list) was the perfect place to add more tests to
make mine look faster?! And perhaps adding lots of attribute variations
(which preceded these latest additions) would also make mine look faster
too. Or maybe, just maybe, I want to create as stressful a set of tests
as I can and never mind the impact on speed (an area where I have never
been exactly lacking?) Think about it.

>
>
>>> You still include jQuery 1.2.1, well over
>>> two years old, in your comparison; I'll bet they didn't claim at that
>>> time to include all the selectors you've added recently. At the very
>>> best, this is hypocrisy.
>> Huh? The old version of jQuery is there for a very good reason. If you
>> would stop and use your head, you'd know what it is (hint: it is the
>> last non-QSA-assisted version). You need to be able to see what their
>> slow lane will look like compared to mine as not all browsers have QSA
>> and not all queries even work with QSA. We've had this discussion before.
>
> So, is including QSA an appropriate thing to do or not?

Depends on what you are trying to compare, doesn't it?

> Not for the
> other libraries, for yours?

Huh? AFAIK, the others don't give you any option. That's why you have
to look at their old versions side by side to compare with both of mine
(meaning with and without the QSA add-on). I really hope these concepts
are starting to congeal at this point.

> If it is, fine. If it's not, fine.


> The
> other libraries have made their choices (subject as always to the
> vagaries of changing design.)

Huh?

> If it's most appropriate to use QSA
> with My Library, then stop whining about others including it, and just
> use it.

Whining?! I've always included both versions on my tests. End of
story. What you do is really of no consequence, except that it often
exposes your lack of understanding for what your tests are comparing.

> If it's not, then live with the fact that others libraries
> will probably be faster for a great number of queries, although they
> might get things entirely wrong when the native QSA fails. That's
> just the way it goes.

Why not compare both and let the users decide what they want. That's
what I did.

>
>
>>> The main issue is that tools like Slickspeed are great for minor
>>> bragging rights about speed. They are useful to fix a minimal list of
>>> expected behavior from libraries. When you add selectors like this,
>>> you're obviously trying to use it in a very different manner:
>>> td[title='test1" # . > ~ + test2[1]']
>> Don't be juvenile. It's a stress test. I added it primarily to make
>> sure that _my_ parsing was working as expected. You are acting like
>> this is some sort of contest. Well, there are no prizes and the other
>> libraries have supposedly had a multi-year-head start on most of this stuff.
>
> What's a head start in something that's not a contest?

I clearly was referring to your use of the word "contest". But call
them efforts as it is more appropriate.

>
> Don't be disingenuous. You are promoting My Library unabashedly
> here.

Over using YUI or Dojo or jQuery? You bet. And I hope it is clear at
this point that you really shouldn't use CSS selector queries,
regardless of the library.

> I wouldn't have bothered to respond if it hadn't been for your
> saying, "I had a feeling that this would create a lot more black cells
> in the results table (in anything West of the last two columns of
> course). Did it ever." You are treating this as a contest.

No, it is a chart of results. Nothing more. My assertion was that they
would have lots of errors (and miscounts) for these less-than-trivial
additions and they did. So what?

>
>
>> So what? I had a feeling that they would foul up the positional stuff
>> and many of them did (one so bad it had to be cut).
>
> Yes, it looks like MooTools can't handle nth-*: an + b where a is
> negative.

Yes. It sends them into an infinite loop, which doesn't speak well of
their QA. Again, the "well tested by many eyes" argument turns out to
be bunk.

>
>
>>> Can you re-read that and not see it as simply self-aggrandizement?
>> It's simply facts. Unlike the BS you opened with about "catching up".
>
> No, they are equally BS. That was the point.

Don't write wrong answers on the blackboard as somebody is likely to
copy them down.

>
>
>>> I've started to play with My Library a bit, and in many ways I like
>>> it. But the attitude you present with posts like that is more than
>>> off-putting.
>> So don't use it. Did you read the rest of the post? And did you get
>> the main point? Queries were a very _bad_ idea. Don't use them. No
>> need to thank me for (hopefully) driving that point home. And if I
>> broke some eggs making that omelet, too bad.
>
> I have nothing to add to Peter Michaud's excellent argument in favor
> of CSS-selector queries as a DOM-selection mechanism.

Oh Christ, take me now. He had no argument at all. It was the same
generalized BS over and over. It was like he was posting from a coma.

>
> But have you thought about the overall logic of your post at all? The
> argument seems to be, "Queries suck. Don't use them. But I'm going
> to spend the effort to add them to My Library, so that it's better
> than all the other libraries. Just remember not to actually use
> them."

Actually, that is what I am saying and it is quite logical. Nobody will
even consider a library if it doesn't have CSS3 selector queries.
That's a fact of life. I say don't even include that crap in the build
(and have always said that). And if I am going to honor requests for
more selectors, I'm going to make sure that they work in as many
browsers and configurations as I can before announcing that they are
available for user. Logical?

>
>
>>> In most environments I've worked, I wouldn't be able to
>>> even *try* to suggest that the client consider using MyLib, not when
>>> it's presented in such an arrogant fashion.
>> Your client is unlikely to read technical posts in my forum. [ ... ]
>
> Many clients want to see the mechanisms for getting help with the
> tools I suggest for them. When I point out the helpful community
> around Wicket (a Java Web framework) they are much more likely to
> accept it as an alternative to the more well-known frameworks.

Java?! So what?

> With
> My Library, I would have to actively steer them away from your rants
> if I ever wanted them to accept it.

Don't be ridiculous. Even my harshest critics have acknowledged that my
support (particularly in that forum) is grade-A. I don't think your
client would care what I said about the other libraries, particularly as
it is all true.

>
> David, as much as you may find this hard to believe, I'm one of the
> ones who wants to help I don't think the ecosystem of JS libraries is
> anywhere near rich enough.

It's been on the brink of bankruptcy for years.

> I really want to see more innovation. But
> the style in which you present your library makes it next to
> impossible to even give it a chance.
>

For God's sake, if you want me to make progress (on the code) cut out
these marathon responses.

Scott Sauyet wrote:
> David Mark wrote:
>> Scott Sauyet wrote:
>>
>>> If I were to make the following (entirely factual) post, there would
>>> be good reason for complaint:
>> And BTW, there really is no "if" about it. You actually went to the
>> time and trouble to create and post it. That's a lot of effort to look
>> stupid.
>
> Well, I learned from the master.

Throwaway lines don't really change the score.

>
> Actually, posting a new version of the slickspeed test takes me only a
> few minutes. The only reason this one took as much as ten minutes was
> because the slickspeed framework didn't properly handle selectors with
> single-quote characters in them, and I had to fix that.

I suppose. I don't remember having that problem. I test both single
and doubles.

>
>>> | There are a number of new selectors, as proposed by David Marks.
>> And, just as those are not "new selectors" (did you think "2n+1" and
>> "2n" were the extent of the positionals?),
>
> I understand the distinction you are making. But it is I think not
> the common usage of "selector". It is certainly not how I use it.
> "div" and "p" are distinct selectors to me, as are ":nth-child(2n +
> 3)" and ":nth-child(2n -1)".

Okay, fair enough. In that sense, I added "new selectors", but how is
that being sneaky or disingenuous? I think it is just being thorough.
Now, if I added lots of rows of the of-each stuff (coming tomorrow
likely, but with a disclaimer of course), which the others (mostly) do
not support...

And I'll have you know that I'll be adding NWMatcher whenever I have a
chance. AFAIK, it is as (or more) robust than mine in most respects and
perhaps faster too (at least in the slow lanes in some browsers).

>
>
>> my name is not "Marks."
>
> I apologize.

NP on that one.

>
>
>> Gee, look at this, QSA can handle lots of "new selectors" and a library
>> that never _claimed_ to support them can't. Personally, I think I'd
>> post a follow-up that claims an intruder broke in an used my PC to post
>> that stuff. It would be just as credible.
>
> I wish your post had a credible excuse.
>

I think you are making way too much out of what was a couple of
paragraphs in my own forum (and a few asides here).

On Mar 3, 9:10 pm, RobG <rg...@iinet.net.au> wrote:

> I think the basis of David's argument is that they are a bad idea
> because of the differences in implementations. Because various
> libraries introduce an additional set of inconsistencies, the range of
> possible outcomes is greatly increased.

I think that doesn't necessarily make the idea bad but the
implementations could be judged as bad. Original compilers (e.g.
Fortran) were complex and challenging to build and presumably buggy
but compilers weren't a bad idea.


> I think simple CSS queries can be very helpful, but most of those can
> be easily replaced with simple ad hoc functions. Complex selectors can
> be harmful, not only for performance, but they more tightly bind
> programming logic to document layout so that a small change may cause
> a script to fail or enhancements to become unreliable.

I agree. Actually my selector function can only handle simple
selectors with any combination of tag, id, and class values.


> I also suspect that complex selectors are more likely to have
> inconsistent results, but don't have any proof.

I've written a couple complex selector engines and they are
significantly more difficult to implement than simple selector
engines.


> As for David's hyperbole, I took it as just that. Scale it back to
> half-throttle and you get "[CSS] queries can lead to problems", which
> is true. It wasn't that long ago that it was standard practice to
> ensure sites worked without scripting and that script only enhanced
> usability. Lately there has been a trend to sites that are
> dysfunctional without scripting.

I work on such web apps. The implementation overlap between a no-
JavaScript version and a JavaScript version is so little that business
says they don't care to pay for the no-JavaScript version.


> I expect that within a few years,
> browsers that do not have efficient built-in query selector support
> will find the web quite unfriendly. That will lead to problems for
> less capable browsers and platforms.

By that time canvas and HTML video may be significant players also and
be incentive for people to upgrade.


> Incidentally, I tried surfing with Safari 1.0.3 recently - very few
> sites were functional, including apple.com. Considering it's younger
> than IE 6 (2004 vs. 2001), it is clear that if IE 6 didn't have the
> market share it has, developers would have stopped coding around its
> quirks many years ago and it would be dead by now. Imagine a web where
> most browsers were DOM and CSS 3 compliant and HTML5 was mostly
> implemented, then javascript libraries could focus on efficient
> delivery of high-level functionality, not smoothing over browser
> quirks.

I think the JavaScript libraries will always smooth over browser
quirks for the most recent set of browser features. When IE7 dies, XHR
libraries will be only a thin layer of sugar. If IE ever implements
the DOM2 event model then that wrapper library can go away. But new
things like canvas and video will probably have various browser bugs
to work around and so the JavaScript libraries will live on for them.


> And this thread would be irrelevant.

In some ways. The popularity of the query selectors implemented in
JavaScript were the motivation for the built-in query selectors.
History often repeats itself and I wouldn't be surprised if similar
developments for a different browser scripting topic happens again.

Peter