W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Spec Bugs and Test Suites [Was: Re: Shrinking existing libraries as a goal]

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 18 May 2012 06:38:05 -0400
Message-ID: <4FB6268D.3060900@nokia.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT