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

Discussion in 'Javascript' started by David Mark, Mar 3, 2010.

  1. David Mark

    David Mark Guest

    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).

    http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d

    I don't think I need to add much to that. As an aside, I'll mention
    that SlickSpeed's error handling is bullshit (at least for YUI3 which
    managed to slip one past the goalie in IE--hell of a shock to see
    something like that).

    I'll have to see if there is a new MooTools available. As mentioned, I
    removed both versions (1.2.4 was the newest IIRC) due to infinite loop
    problems on some of the position-based queries.

    I'm surrounded by incompetence, but will break out before long. :)

    Executive summary for the cited article: do not use queries.
     
    David Mark, Mar 3, 2010
    #1
    1. Advertising

  2. David Mark

    Scott Sauyet Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    David Mark 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).
    >
    > http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d


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

    | I've just posted another update of my version of the Slickspeed
    | framework. You can see it here:
    |
    | http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/
    |
    | There are a number of new selectors, as proposed by David Marks.
    |
    | You can see the result of one of my recent runs in Firefox 3.6 at
    |
    | http://tinyurl.com/ylyhzu5
    |
    | 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.

    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.

    The main thing is that I included a six-week old version of My
    Library. And many of the tests that you've since added to your
    Slickspeed version don't work in that older one. 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. But you're adding all sorts of
    new selectors and pointing out the failure of other libraries to
    already have them working. 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.

    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]']

    The article you link to starts

    | Added :root pseudo and finished up the positional selectors. Lots
    of
    | new tests added to the SlickSpeed page:-
    |
    | http://www.cinsoft.net/slickspeed.html
    |
    | 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. :(

    Can you re-read that and not see it as simply self-aggrandizement?

    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. 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.

    And I'm not complaining just about style here. You're adding all
    sorts of new selectors, you're changing the underlying test document,
    you're mixing and matching all sorts of library versions, and you're
    presenting the results as if they prove much more than they actually
    do.

    It's really a shame that a pretty solid piece of work is being buried
    in this nonsense.

    -- Scott
     
    Scott Sauyet, Mar 3, 2010
    #2
    1. Advertising

  3. David Mark

    Matt Kruse Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 2, 11:58 pm, David Mark <> wrote:
    > Executive summary for the cited article: do not use queries.


    Oh I don't know, I use them quite a bit and they work great and result
    in much shorter code that is easier to read and way less work to
    write.

    Perhaps you should qualify your over-generalized conclusion.

    Queries FTW!

    Matt Kruse
     
    Matt Kruse, Mar 3, 2010
    #3
  4. Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 2, 9:58 pm, David Mark <> 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?


    > http://groups.google.com/group/my-library-general-discussion/browse_t...
    >
    > I don't think I need to add much to that.  As an aside, I'll mention
    > that SlickSpeed's error handling is bullshit (at least for YUI3 which
    > managed to slip one past the goalie in IE--hell of a shock to see
    > something like that).
    >
    > I'll have to see if there is a new MooTools available.  As mentioned, I
    > removed both versions (1.2.4 was the newest IIRC) due to infinite loop
    > problems on some of the position-based queries.
    >
    > I'm surrounded by incompetence, but will break out before long.  :)


    Leaving the planet?


    > 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?

    Peter
     
    Peter Michaux, Mar 3, 2010
    #4
  5. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Scott Sauyet wrote:
    > David Mark 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).
    >>
    >> http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d

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


    Why?

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


    New selectors? Not really.

    > |
    > | You can see the result of one of my recent runs in Firefox 3.6 at
    > |
    > | http://tinyurl.com/ylyhzu5


    Or they can just run it in FF3.6. :)

    > |
    > | 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. 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.

    >
    > 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?

    >
    > 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. 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?

    > 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. (?)

    > 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.

    > 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. :)

    > 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.

    >
    > 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.

    >
    > The article you link to starts
    >
    > | Added :root pseudo and finished up the positional selectors. Lots
    > of
    > | new tests added to the SlickSpeed page:-
    > |
    > | http://www.cinsoft.net/slickspeed.html
    > |
    > | 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. :(


    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).

    >
    > 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". :)

    >
    > 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.

    > 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.

    >
    > And I'm not complaining just about style here. You're adding all
    > sorts of new selectors,


    NO, I haven't. You don't know what you are talking about. Re-read it.

    > you're changing the underlying test document,


    So what! I had to add some stuff to the bottom so that I could test
    something other than DIV's (e.g. form controls). And you tested with a
    completely different document. What the hell is wrong with testing with
    different documents?

    > you're mixing and matching all sorts of library versions,


    They are all clearly documented. The latest of each is included and
    each is labeled as to whether it supports QSA. What is your problem?
    In clear (perhaps even technical) terms, please. Mixing and matching,
    indeed. :(

    > and you're
    > presenting the results as if they prove much more than they actually
    > do.


    In what way did I present them? The primary points were:-

    1. No compatibility between browsers
    2. No portability between libraries
    3. How did this simplify things?

    And they spent years trying to get it right. It didn't work, did it?
    It's true whether I had taken the time to add more selectors to My
    Library (or even written a library).

    >
    > It's really a shame that a pretty solid piece of work is being buried
    > in this nonsense.


    My thoughts exactly. What a nonsensical bunch of hyperbole.
     
    David Mark, Mar 4, 2010
    #5
  6. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Matt Kruse wrote:
    > On Mar 2, 11:58 pm, David Mark <> wrote:
    >> Executive summary for the cited article: do not use queries.

    >
    > Oh I don't know, I use them quite a bit and they work great and result
    > in much shorter code that is easier to read and way less work to
    > write.


    Is that supposed to be funny?

    >
    > Perhaps you should qualify your over-generalized conclusion.


    Perhaps you should read the article and accompanying test results.
     
    David Mark, Mar 4, 2010
    #6
  7. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Peter Michaux wrote:
    > On Mar 2, 9:58 pm, David Mark <> 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).

    >
    >
    >> http://groups.google.com/group/my-library-general-discussion/browse_t...
    >>
    >> I don't think I need to add much to that. As an aside, I'll mention
    >> that SlickSpeed's error handling is bullshit (at least for YUI3 which
    >> managed to slip one past the goalie in IE--hell of a shock to see
    >> something like that).
    >>
    >> I'll have to see if there is a new MooTools available. As mentioned, I
    >> removed both versions (1.2.4 was the newest IIRC) due to infinite loop
    >> problems on some of the position-based queries.
    >>
    >> I'm surrounded by incompetence, but will break out before long. :)

    >
    > Leaving the planet?


    Nope.

    >
    >
    >> 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).
     
    David Mark, Mar 4, 2010
    #7
  8. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Scott Sauyet wrote:
    > David Mark 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).
    >>
    >> http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d

    >
    > 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. ;)

    >
    > | I've just posted another update of my version of the Slickspeed
    > | framework. You can see it here:
    > |
    > | http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/
    > |
    > | 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?), my name is not "Marks."

    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. :)
     
    David Mark, Mar 4, 2010
    #8
  9. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Scott Sauyet wrote:
    > David Mark 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).
    >>
    >> http://groups.google.com/group/my-library-general-discussion/browse_thread/thread/b0963750135d884d

    >
    > 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. ;)

    >
    > | I've just posted another update of my version of the Slickspeed
    > | framework. You can see it here:
    > |
    > | http://scott.sauyet.com/Javascript/Test/slickspeed/2010-03-03a/
    > |
    > | 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?), my name is not "Marks."

    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. :)
     
    David Mark, Mar 4, 2010
    #9
  10. Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 3, 5:01 pm, David Mark <> wrote:
    > Peter Michaux wrote:
    > > On Mar 2, 9:58 pm, David Mark <> 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.



    > >> 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. You are suggesting that using the
    DOM methods is ok but writing functions that use the DOM methods is
    not ok.

    Peter
     
    Peter Michaux, Mar 4, 2010
    #10
  11. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Peter Michaux wrote:
    > On Mar 3, 5:01 pm, David Mark <> wrote:
    >> Peter Michaux wrote:
    >>> On Mar 2, 9:58 pm, David Mark <> 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.
     
    David Mark, Mar 4, 2010
    #11
  12. Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 3, 6:03 pm, David Mark <> wrote:
    > Peter Michaux wrote:
    > > On Mar 3, 5:01 pm, David Mark <> wrote:
    > >> Peter Michaux wrote:
    > >>> On Mar 2, 9:58 pm, David Mark <> 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
     
    Peter Michaux, Mar 4, 2010
    #12
  13. Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 3, 7:38 pm, David Mark <> 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
     
    Peter Michaux, Mar 4, 2010
    #13
  14. David Mark

    Scott Sauyet Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    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/Test/slickspeed/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/Test/slickspeed/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/Test/slickspeed/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/Test/slickspeed/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
     
    Scott Sauyet, Mar 4, 2010
    #14
  15. David Mark

    Scott Sauyet Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    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
     
    Scott Sauyet, Mar 4, 2010
    #15
  16. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    Peter Michaux wrote:
    > On Mar 3, 7:38 pm, David Mark <> 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?
     
    David Mark, Mar 4, 2010
    #16
  17. David Mark

    RobG Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 4, 2:06 pm, Peter Michaux <> wrote:
    > On Mar 3, 7:38 pm, David Mark <> 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
     
    RobG, Mar 4, 2010
    #17
  18. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    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/Test/slickspeed/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/Test/slickspeed/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/Test/slickspeed/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/Test/slickspeed/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 shit. 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.
     
    David Mark, Mar 4, 2010
    #18
  19. David Mark

    David Mark Guest

    Re: Can there be any doubt at this point that queries were a badidea?

    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).
     
    David Mark, Mar 4, 2010
    #19
  20. Re: Can there be any doubt at this point that queries were a badidea?

    On Mar 3, 9:10 pm, RobG <> 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
     
    Peter Michaux, Mar 4, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    1,269
    Big K
    Feb 2, 2005
  2. Dr Mephesto

    App idea, Any idea on implementation?

    Dr Mephesto, Feb 4, 2008, in forum: Python
    Replies:
    3
    Views:
    745
    Dennis Lee Bieber
    Feb 5, 2008
  3. rantingrick
    Replies:
    44
    Views:
    1,297
    Peter Pearson
    Jul 13, 2010
  4. Saraswati lakki
    Replies:
    0
    Views:
    1,411
    Saraswati lakki
    Jan 6, 2012
  5. Replies:
    0
    Views:
    592
Loading...

Share This Page