On 5/17/12 7:03 PM, ext Julian Aubourg wrote:
To me the biggest abomination of all is

Just a reminder that WebApps' [PubStatus] page enumerates all of its specs and for each spec, there (or will be): a) a link to the spec's Bugzilla component; b) a link to the spec's Test Suite.
Finally, fixing xhr issues always seem like low priority items in browser bug trackers because there's always some kind of workaround, that libraries like jQuery have to put in their code (provided it can be feature tested which it cannot most of the time).

I've been meaning to do a test suite to help provide guidance to implementors (something I figure would be much more useful than yet another round of specs) but I admit I haven't got to it yet.

Dunno how people feel about this, but I think providing test suites that browsers could test against as a way to prevent regressions and inconsistencies could help a lot as a starting point.


2012/5/18 Yehuda Katz <wyc...@gmail.com <mailto:wyc...@gmail.com>>

    I am working on it. I was just getting some feedback on the
    general idea before I sunk a bunch of time in it.

    Keep an eye out :D

    Yehuda Katz
    (ph) 718.877.1325 <tel:718.877.1325>



    On Thu, May 17, 2012 at 3:18 PM, Brian Kardell <bkard...@gmail.com
    <mailto:bkard...@gmail.com>> wrote:

        Has anyone compiled an more general and easy to reference list
        of the stuff jquery has to normalize across browsers new and
        old?  For example, ready, event models in general, query
        selector differences, etc?

        On May 17, 2012 3:52 PM, "Rick Waldron"
        <waldron.r...@gmail.com <mailto:waldron.r...@gmail.com>> wrote:



            On Thu, May 17, 2012 at 3:21 PM, Brian Kardell
            <bkard...@gmail.com <mailto:bkard...@gmail.com>> wrote:

                On Thu, May 17, 2012 at 2:47 PM, Rick Waldron
                <waldron.r...@gmail.com
                <mailto:waldron.r...@gmail.com>> wrote:
                >
                >
                > On Thu, May 17, 2012 at 2:35 PM, Brian Kardell
                <bkard...@gmail.com <mailto:bkard...@gmail.com>> wrote:
                >>
                >> So, out of curiosity - do you have a list of
                things?  I'm wondering
                >> where some efforts fall in all of this - whether
                they are good or bad
                >> on this scale, etc... For example:
                 querySelectorAll - it has a few
                >> significant differences from jQuery both in terms
                of what it will
                >> return (jquery uses getElementById in the case that
                someone does #,
                >> for example, but querySelectorAll doesn't do that
                if there are
                >> multiple instances of the same id in the tree)
                >
                >
                > Which is an abomination for for developers to deal
                with, considering the ID
                > attribute value "must be unique amongst all the IDs
                in the element's home
                > subtree"[1] . qSA should've been spec'ed to enforce
                the definition of an ID
                > by only returning the first match for an ID selector
                - devs would've learned
                > quickly how that worked; since it doesn't and since
                getElementById is
                > faster, jQuery must take on the additional code
                burden, via cover API, in
                > order to make a reasonably usable DOM querying
                interface. jQuery says
                > "you're welcome".
                >
                >
                >
                >>
                >> and performance (this
                >> example illustrates both - since jQuery is doing
                the simpler thing in
                >> all cases, it is actually able to be faster (though
                technically not
                >> correct)
                >
                >
                >
                > I'd argue that qSA, in its own contradictory
                specification, is "not
                > correct".

                It has been argued in the past - I'm taking no
                position here, just
                noting.  For posterity (not you specifically, but for
                the benefit of
                those who don't follow so closely), the HTML link also
                references DOM
                Core, which has stated for some time that
                getElementById should return
                the _first_  element with that ID in the document
                (implying that there
                could be more than one) [a] and despite whatever CSS
                has said since
                day one (ids are unique in a doc) [b] a quick check in
                your favorite
                browser will show that CSS doesn't care, it will style
                all IDs that
                match.  So basically - qSA matches CSS, which does
                kind of make sense
                to me... I'd love to see it "corrected" in CSS too
                (first element with
                that ID if there are more than one) but it has been
                argued that a lot
                of stuff (more than we'd like to admit) would break.

                >> in some very difficult ones. Previously, this was
                something
                >> that the browser APIs just didn't offer at all --
                now they offer them,
                >> but jQuery has mitigation to do in order to use
                them effectively since
                >> they do not have parity.
                >
                >
                > Yes, we're trying to reduce the amount of mitigation
                that is required of
                > libraries to implement reasonable apis. This is a
                multi-view discussion:
                > short and long term.
                >

                So can someone name specific items?   Would qSA / find
                been pretty
                high on that list?  Is it "better" for jQuery
                (specifically) that we
                have them in their current state or worse?  Just curious.


            TBH, the current state can't get any worse, though I'm
            sure it will. Assuming you're referring to this:
            
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1454.html


            ... Yes, APIs like this would be improvements, especially
            considering the pace of implementation in modern browsers
            - hypothetically, this could be in wide implementation in
            less then a year; by then development of a sort of "jQuery
            2.0" could happen -- same API, but perhaps modern browser
            only?? This is hypothetical of course.



            Rick


                [a] -
                
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-getelementbyid
                [b] - http://www.w3.org/TR/CSS1/#id-as-selector












                >
                > Rick
                >
                >
                > [1]
                
http://www.whatwg.org/specs/web-apps/current-work/#the-id-attribute
                >
                >
                >>
                >>
                >> On Thu, May 17, 2012 at 2:16 PM, Yehuda Katz
                <wyc...@gmail.com <mailto:wyc...@gmail.com>> wrote:
                >> >
                >> > Yehuda Katz
                >> > (ph) 718.877.1325 <tel:718.877.1325>
                >> >
                >> >
                >> > On Thu, May 17, 2012 at 10:37 AM, John J Barton
                >> > <johnjbar...@johnjbarton.com
                <mailto:johnjbar...@johnjbarton.com>> wrote:
                >> >>
                >> >> On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr.
                <jackalm...@gmail.com <mailto:jackalm...@gmail.com>>
                >> >> wrote:
                >> >> > On Thu, May 17, 2012 at 9:56 AM, John J Barton
                >> >> > <johnjbar...@johnjbarton.com
                <mailto:johnjbar...@johnjbarton.com>> wrote:
                >> >> >> On Thu, May 17, 2012 at 9:29 AM, Rick Waldron
                >> >> >> <waldron.r...@gmail.com
                <mailto:waldron.r...@gmail.com>>
                >> >> >> wrote:
                >> >> >>> Consider the cowpath metaphor - web
                developers have made highways
                >> >> >>> out
                >> >> >>> of
                >> >> >>> sticks, grass and mud - what we need is
                someone to pour the
                >> >> >>> concrete.
                >> >> >>
                >> >> >> I'm confused. Is the goal shorter load times
                (Yehuda) or better
                >> >> >> developer ergonomics (Waldron)?
                >> >> >>
                >> >> >> Of course *some* choices may do both. Some
                may not.
                >> >> >
                >> >> > Libraries generally do three things: (1) patch
                over browser
                >> >> > inconsistencies, (2) fix bad ergonomics in
                APIs, and (3) add new
                >> >> > features*.
                >> >> >
                >> >> > #1 is just background noise; we can't do
                anything except write good
                >> >> > specs, patch our browsers, and migrate users.
                >> >> >
                >> >> > #3 is the normal mode of operations here.  I'm
                sure there are plenty
                >> >> > of features currently done purely in libraries
                that would benefit
                >> >> > from
                >> >> > being proposed here, like Promises, but I
                don't think we need to push
                >> >> > too hard on this case.  It'll open itself up
                on its own, more or
                >> >> > less.
                >> >> >  Still, something to pay attention to.
                >> >> >
                >> >> > #2 is the kicker, and I believe what Yehuda is
                mostly talking about.
                >> >> > There's a *lot* of code in libraries which
                offers no new features,
                >> >> > only a vastly more convenient syntax for
                existing features.  This is
                >> >> > a
                >> >> > large part of the reason why jQuery got so
                popular.  Fixing this both
                >> >> > makes the web easier to program for and
                reduces library weight.
                >> >>
                >> >> Yes! Fixing ergonomics of APIs has dramatically
                improved web
                >> >> programming.  I'm convinced that concrete
                proposals vetted by major
                >> >> library developers would be welcomed and have
                good traction. (Even
                >> >> better would be a common shim library
                demonstrating the impact).
                >> >>
                >> >> Measuring these changes by the numbers of bytes
                removed from downloads
                >> >> seems 'nice to have' but should not be the goal IMO.
                >> >
                >> >
                >> > We can use "bytes removed from downloads" as a
                proxy of developer
                >> > ergonomics
                >> > because it means that useful,
                ergonomics-enhancing features from
                >> > libraries
                >> > are now in the platform.
                >> >
                >> > Further, shrinking the size of libraries provides
                more headroom for
                >> > higher
                >> > level abstractions on resource-constrained
                devices, instead of wasting
                >> > the
                >> > first 35k of downloading and executing on
                relatively low-level
                >> > primitives
                >> > provided by jQuery because the primitives
                provided by the platform
                >> > itself
                >> > are unwieldy.
                >> >
                >> >>
                >> >>
                >> >> jjb
                >> >>
                >> >> >
                >> >> > * Yes, #3 is basically a subset of #2 since
                libraries aren't
                >> >> > rewriting
                >> >> > the JS engine, but there's a line you can draw
                between "here's an
                >> >> > existing feature, but with better syntax" and
                "here's a fundamentally
                >> >> > new idea, which you could do before but only
                with extreme
                >> >> > contortions".
                >> >> >
                >> >> > ~TJ
                >> >
                >> >
                >
                >





Reply via email to