- From: Yehuda Katz <wycats@gmail.com>
- Date: Thu, 17 May 2012 15:21:13 -0700
- To: Brian Kardell <bkardell@gmail.com>
- Cc: Rick Waldron <waldron.rick@gmail.com>, public-scriptlib@w3.org, Scott González <scott.gonzalez@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Arthur Barstow <art.barstow@nokia.com>, public-webapps@w3.org, ext Ojan Vafai <ojan@chromium.org>, John J Barton <johnjbarton@johnjbarton.com>
- Message-ID: <CAMFeDTU6uupMg-0rEunrnGBVuzysGp_0d2D3nOyzb_vnChUqmw@mail.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 On Thu, May 17, 2012 at 3:18 PM, Brian Kardell <bkardell@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.rick@gmail.com> wrote: > >> >> >> On Thu, May 17, 2012 at 3:21 PM, Brian Kardell <bkardell@gmail.com>wrote: >> >>> On Thu, May 17, 2012 at 2:47 PM, Rick Waldron <waldron.rick@gmail.com> >>> wrote: >>> > >>> > >>> > On Thu, May 17, 2012 at 2:35 PM, Brian Kardell <bkardell@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 <wycats@gmail.com> >>> wrote: >>> >> > >>> >> > Yehuda Katz >>> >> > (ph) 718.877.1325 >>> >> > >>> >> > >>> >> > On Thu, May 17, 2012 at 10:37 AM, John J Barton >>> >> > <johnjbarton@johnjbarton.com> wrote: >>> >> >> >>> >> >> On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. < >>> jackalmage@gmail.com> >>> >> >> wrote: >>> >> >> > On Thu, May 17, 2012 at 9:56 AM, John J Barton >>> >> >> > <johnjbarton@johnjbarton.com> wrote: >>> >> >> >> On Thu, May 17, 2012 at 9:29 AM, Rick Waldron >>> >> >> >> <waldron.rick@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 >>> >> > >>> >> > >>> > >>> > >>> >> >>
Received on Thursday, 17 May 2012 22:22:10 UTC