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