- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 18 May 2012 06:38:05 -0400
- To: ext Julian Aubourg <j@ubourg.net>
- CC: Yehuda Katz <wycats@gmail.com>, Brian Kardell <bkardell@gmail.com>, Rick Waldron <waldron.rick@gmail.com>, public-scriptlib@w3.org, Scott González <scott.gonzalez@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps@w3.org, ext Ojan Vafai <ojan@chromium.org>, John J Barton <johnjbarton@johnjbarton.com>
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 <wycats@gmail.com <mailto:wycats@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 <bkardell@gmail.com > <mailto: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 <mailto:waldron.rick@gmail.com>> wrote: > > > > On Thu, May 17, 2012 at 3:21 PM, Brian Kardell > <bkardell@gmail.com <mailto:bkardell@gmail.com>> wrote: > > On Thu, May 17, 2012 at 2:47 PM, Rick Waldron > <waldron.rick@gmail.com > <mailto:waldron.rick@gmail.com>> wrote: > > > > > > On Thu, May 17, 2012 at 2:35 PM, Brian Kardell > <bkardell@gmail.com <mailto: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 <mailto:wycats@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 > >> > <johnjbarton@johnjbarton.com > <mailto:johnjbarton@johnjbarton.com>> wrote: > >> >> > >> >> On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. > <jackalmage@gmail.com <mailto:jackalmage@gmail.com>> > >> >> wrote: > >> >> > On Thu, May 17, 2012 at 9:56 AM, John J Barton > >> >> > <johnjbarton@johnjbarton.com > <mailto:johnjbarton@johnjbarton.com>> wrote: > >> >> >> On Thu, May 17, 2012 at 9:29 AM, Rick Waldron > >> >> >> <waldron.rick@gmail.com > <mailto: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 Friday, 18 May 2012 10:38:57 UTC