[09:07:06] okay [09:07:08] thanks timmywil [09:07:19] nickserv doesn't like me [09:07:27] * jaubourg like DaveMEt [09:07:52] * jaubourg like DaveMethvin [09:07:52] olol² [09:07:52] you mean chanserv? [09:07:52] +1 would like again [09:08:03] ;) [09:08:22] no it won't auth me so chanserv thinks i'm not me [09:08:36] oh i see [09:08:36] hey [09:08:36] this happened once before, something about the bouncer [09:08:36] hey orkel [09:08:44] who else is here? [09:09:13] looks like gibson042 gnarf rwaldron are on [09:09:13] I'm around [09:09:35] gibson042 is arONd [09:10:08] okay, so https://docs.google.com/document/d/1oQ966Lq9szqP41BehdlmAJV33lgNcrE0C0tktLvIz5s/edit [09:10:39] howdy [09:10:50] hey rwaldron [09:11:50] so several of the topics relate to the build process, with/without AMD, and whether we'll have alternate implementations [09:12:01] so we could tackle those kind of together [09:12:19] in general i think custom builds are an advanced thing [09:12:43] since people need to know that the result won't work as documented or at least as expected (e.g., rAF) [09:13:01] it's a nice way for us to experiment with things though [09:13:22] we can create something we think is an improvement and daring people can use it [09:14:07] so, like, on rAF, if we reintroduce it are we likely to get a bunch of "it doesn't work right" bug reports? [09:14:23] probably [09:15:40] so we should leave rAF out then? [09:16:08] I don't see much promise from it [09:16:17] i think either as build option or leave it be [09:16:27] could be a duck-punch plugin at least [09:16:39] gnarf has a plugin for it already i think [09:16:48] ah, cool [09:17:07] well, maybe we could reassess after AMD anyway [09:17:27] I think AMD will make us rethink some of these deps [09:17:30] rAF should provide smoother animation and should better on battery live, right? [09:17:49] orkel: yes, but users need to know the differences in behavior [09:17:51] yeah, it just breaks (bad) assumptions about animations in jQuery [09:18:19] how much better? [09:18:32] the classic is that someone wants a slide show to auto-advance every 10 secs so they use setInterval to fire off a 1sec animation [09:18:48] when using rAF and the window is out of view they all stack up [09:18:59] and then the page goes crazy when it comes back into view [09:19:07] the problem is that jQuery should promote the use of anything that saves battery.I just wish rAF wasn't a all or nothing kinda deal. It is fundamentally not compatible with how $.animate works. And I disagree that all assumprions made regarding $.animate are unreasonable. It's not unreasonable to expect a 1 sec anim not to take 3 hours to complete. [09:19:56] we'd need a cleanup setTimeout( _, 1 ) thingy at the very least [09:20:10] but it all points to separating scheduling and actual animating [09:20:16] i am really comfortable with having rAF be a plugin :) [09:20:29] which, as I pointed at the conf is a nightmare with the element-centric nature of $.animate [09:20:30] agreed [09:20:44] and custom builds -effects [09:21:01] +1 [09:21:18] which is to the other point, whether there are better ways to do animation and whether it might be useful to have an alternate experimental API to try it out [09:22:04] if nobody has an itch to do it, I'm fine with leaving that one for now [09:22:07] CSS animations works by 1) defining an animation 2) applying it to one or several elements. That's how a new API should work if we wanted to successfully introduce rAF [09:22:10] DaveMethvin: possibly, if someone has the desire to experiment with that [09:22:18] hi [09:22:25] jaubourg, agreed [09:22:34] we want something that maps well to what browsers can do [09:22:38] hey mike [09:22:41] does someone have that desire? [09:22:44] hey mikesherov [09:22:52] maybe mikesherov [09:22:58] DO EET MIKE [09:23:03] mikesherov, desire? :) [09:23:04] do what? [09:23:10] a new animation api [09:23:17] I'm about to go on paternity leave, so…. MAYBE?! [09:23:24] doesn't have to be ready until Friday [09:23:27] HAHA [09:23:29] "CSS animations works by 1) defining an animation 2) applying it to one or several elements. That's how a new API should work if we wanted to successfully introduce rAF" [09:23:33] orkel: I'm not sure but I think the project (jQuery as a whole) should participate in this because it is very important and we shouldn't let it take dust... but heh [09:24:13] jaubourg: hmm, okey i see your point [09:24:31] we can also let third-party plugins fill this need, that's fine, but if we have some ideas they'll get a bit more showcasing if we do them [09:24:35] I personally don't have time to lead a new animation API thingy... also, it could be interesting to wait for the W3C animation API [09:24:43] So, the goal is to get it to a point where it can work with rAF? or is the goal to get it to emulate transitions? [09:24:47] and participate in that too [09:25:13] mikesherov: whichever is reasonable [09:25:26] yeah it's brainstorming at this point [09:25:33] DaveMethvin; yeah, though I dunno what the timetable for this is [09:25:41] it's no hurry [09:25:57] mainly tryna decide what things we might want to remake [09:26:06] things that need work [09:26:06] 1.x or 2.x? [09:26:11] or both? [09:26:13] both, potentially [09:26:23] mikesherov: i say, it should use css-animations as much as possible [09:26:24] but if it's a plugin it could be just 2.x for now [09:26:38] it's not part of the formal API [09:26:54] definitely should start this stuff as plugins [09:27:10] and the AMD setup helps us with letting ppl do custom builds to include it [09:27:18] somehow... :D [09:27:39] * mikesherov waves hands [09:27:42] AMD [09:27:45] MAGIC [09:27:47] so, anyway, animation is out there if someone wants it [09:27:59] let's talk about ajax [09:27:59] Well, I'm actually more interesting in $.fn.css [09:28:11] its down here somewhere [09:28:18] inerested*, but I'll poke around with animations in my non-existent spare time [09:28:43] so the ajax api has the biggest surface area b/c we have a single call with a huge options object [09:29:06] is there a way we can simplify that? [09:29:23] either a proper subset or some other rewrite with a new API [09:29:53] well... [09:30:11] the single entry point was always supposed to simplify things [09:30:33] DaveMethvin: actually, I'm not sure what you have in mind [09:30:37] the problem is that the xhr object is getting one new option/method/peculiarity each month [09:30:47] which always translates into a new option needed in $.ajax [09:30:49] So, I gave this some thought, too [09:30:54] that doen't make sense for other transports [09:31:31] and I'm not saying I have the answer, but perhaps a way to approach this is to deprecate "options" that have incompatibilities with other options [09:31:32] right, i think it might work better if xhr and script weren't trying to look the same [09:31:40] DaveMethvin: exactly [09:31:55] so, it's tempting to say, "scratch that", let's have several entry points [09:32:01] but you still have common behaviour [09:32:27] so you'd probably need to pass from the monolithic system we have to a factory based one [09:32:35] jaubourg: sure [09:32:41] where you provide the transport/whatever to the ajax factory [09:32:49] to create your ajax helper [09:33:01] keeping all the common logic in place [09:33:14] you can scratch the conversion logic (not needed with promises) [09:33:37] you can have specific options for each transport that do not collide [09:33:46] but it's a massive inversion in the approach [09:34:14] yeah i agree it's an inversion [09:34:15] tell me if that makes sense guys [09:34:24] right, but I think jquery has in general seen that our initial approach NEEDS inversion [09:34:43] whenever we pave over too much, there's often a scaling back that needs to happen [09:34:54] I can look into this, but thet bottom line is: no more ajaxTransport, ajaxPrefilters, etc [09:35:04] *cough* $() -> $.parseHTML() *cough* [09:35:12] i just see people struggle with the complexity of the ajax sub-api all the time and it usually takes me a while to figure out what is going on [09:35:28] well, I think it's more than just ajaxTransport, etc... [09:35:30] not that they are used that much but the effort made to have the 1.4.x API being maintainable goes away [09:35:38] it's also about incompatible option [09:35:45] for example, "crossDomain" [09:35:55] I don't think the outcome needs to be a fully compatible $.ajax() API [09:36:01] which turns everything into jsonp in old browsers [09:36:18] if it IS there it possibly might be layered on whatever makes more sense [09:36:32] you won't prevent people from saying: "but I have a headers option for xhr, why don't I have it for jsonp", new API won't solve this, especially if it tries to minimize code duplication [09:36:32] that is, $.xhr and $.jsonp or something [09:36:46] jaubourg: no, you won't prevent them at all. [09:36:57] But don't provide the footgun [09:37:10] the docs can do a better job of explaining $.jsonp separately and what its limits are [09:37:21] well, is it a footgun? It's not like it's actually trying to send the headers if you see what I mean [09:37:41] I'd rather have people complain "why is there no async for jsonp?", rather thsan "why doesn't async work" (10 hours pass) "oh, it's jsonp!!!!" [09:37:58] got you [09:37:59] lol yeah [09:38:25] we're talking making the transport implicit [09:38:33] basically yeah [09:38:45] which also makes a bunch of other things clear in the process [09:38:52] so it's pretty much $.xhr and $.injectScript [09:38:53] like no POST or headers for jsonp [09:38:55] maybe $.xdr [09:38:59] jaubourg: sure [09:39:04] each with specific options [09:39:19] if you look at ajax docs now, each option has a set of caveats [09:39:19] yeah so the challenge is to refactor in a way that we prevent those from having a bunch of dup code [09:39:21] and some common [09:39:58] but also, if we are defining new apis for those they may not have all the options anyway so perhaps not so much dup code anyway [09:40:27] like, $.xhr may have progress but $.injectScript not [09:40:31] I really doubt we can make this and use it as a fundation for a backward compatible $.ajax... so it's probably good to start as a plugin, without trying and refactoring existing ajax code [09:41:07] yeah, and i wouldn't want backcompat to be a guiding principle for the new api anway [09:41:11] jaubourg: exactly [09:41:17] like we did in 1.9 [09:41:30] free ourselves from backcompat issues with a compat library [09:41:50] DaveMethvin: the progress thingy is interesting, because it depends if you're doing an upload, or just a standard request. "progress" is high level a concept. I honestly dunno how to handle it properly [09:41:53] or, by just including the real $.ajax with all its code if they want that [09:42:05] DaveMethvin: right [09:42:32] so jaubourg are you up for doing a bit of design on this? [09:43:13] point is, the fact some options in ajax will dramatically change what happens is not random... that's how the native XHR object always worked by using low-level thingies in order to specify high-level differencies :/ [09:43:29] jaubourg: point well taken [09:43:34] and thats cool [09:43:50] right, jQuery's job is make it APPARENT it's not random [09:43:50] yeah, I think I've taken enough room away from ajax to have a fresh perspective now [09:43:59] like I hate my code now, which is a good thing [09:44:09] we all hate our code [09:44:16] you scared me there ;) [09:44:17] if you don't hate your code a year after you wrote it, you're doing the wrong thing [09:44:32] or the code is a very good tradeoff [09:44:38] and you need 2 years [09:44:45] okay, i'll move to the next item, we're running out of time [09:44:56] Deferreds and Callbacks optoinal [09:45:05] the only use right now is in core for .ready() [09:45:13] and effects? [09:45:21] right effects/ajax too [09:45:24] all over effects and ajax [09:45:26] but those are optional modules themselves [09:45:42] crazy idea, let's make $.ready optional [09:45:45] I hate $.ready being a promise, btw [09:45:53] we never documented it :D [09:46:00] SOLD [09:46:08] people are generally misusing ready [09:46:08] mikesherov: $.when( $.ajax(...), $.ready ) is nice [09:46:13] I use it everywhere now [09:46:21] O_o oh man [09:46:24] that's awesome [09:46:29] exactly [09:46:33] if Deferred is included we can still have ready promise [09:47:10] but when timmywil goes to refactor for AMD these dependencies are gonna mess up the module deps [09:47:12] key here is that advanced user that do custom build will almost all include scripts at the end of the body [09:47:14] hint hint [09:47:14] What I dislike though is the fact that ready theoretically can be synchronous [09:47:19] maybe they don't need ready [09:48:00] when I tried to get ready to fire on readyState == interactive, it sometimes ran synchronously, and broke the web [09:48:21] just seems that SOOO much code uses ready that only completely custom code would work [09:48:32] mikesherov: it was always so even before using deferreds. We can always setTimeout() the hell out of it [09:48:40] jaubourg: agreed [09:49:00] maybe ready should be its own module [09:49:03] I'm +1 on making $.ready.promise optional along with deferred and callbacks [09:49:09] timmywil: +1 [09:49:13] timmywil yeah could do it that way [09:49:29] I think the best solution is to make ready itself optional [09:49:34] liek timmywil says [09:49:37] like even [09:49:51] jquip did that [09:49:55] I can integrate that into AMD-fiying [09:50:04] ok cool [09:50:29] imma keep moving ... will clean up the meeting notes later [09:50:39] we can provide an alternative readyness code for when Deferred is not there, without torturing the hell out of the current logic to inverse the way the Deferred is integrated if you get my grip [09:50:41] do we have a ticket for AMD yet? [09:50:53] i never actually created one [09:51:01] timmywil oh then i'm not sure [09:51:15] Ok, I'll ad one [09:51:17] add [09:51:47] jaubourg yeah i was concerned about that, i could come up with a few simple changes to make deferred optional but they changed the order of the callbacks being called [09:52:03] and of course there should't be any code that depends on that ... HAHAHAHAH [09:52:13] users do the funniest things [09:52:26] alrighty then so on jquery.support [09:52:45] oleg asked about the perf impact [09:52:52] well, the Deferred code ensures ordering (callbacks will always be executed in the order they are provided). WHat you shouldn't rely on is shoddy "it should be asynchronous" code. [09:53:01] yeah, we should remove jQuery.support [09:53:09] Modernizr exists for that [09:53:10] surprisingly, perf impact is minimal [09:53:21] it just seems like it will simplify AMD if the feature test is in the same module as where it's needed [09:53:26] when I tested $.newInstance, it was faster than $.sub [09:53:26] DaveMethvin: +1 [09:53:34] yet re-executing all support tests [09:53:47] iirc [09:53:53] i'm more worried about mobile phones [09:53:57] prob a lot slower there [09:54:02] but it's sooo hard to measure [09:54:16] so i'll go with the "cleaner code" argument :D [09:54:24] true, but I'm only concerned about what requires dom readyness [09:54:34] (another problem with making ready optional btw) [09:54:45] damn [09:54:59] sorry [09:55:02] * jaubourg hides [09:55:16] well it's not a problem unless someone asks for something where we need a detect that can't run until the page is ready [09:55:21] I liked my secondare body so much, gotta hate IE8 [09:55:26] and as we saw from that recent ticket, we're kinda screwed there [09:56:01] well, the thing is [09:56:04] but at least we could KNOW were are screwed for that case if we know the user is calling the API and we don't have the ability to do the feature detect yet [09:56:18] that we can do support tests lazily if we undocument them [09:56:29] can we? [09:56:38] what about lazy support tests per-module that still attach to the object on jQuery.support? [09:56:42] in fact, just moving the tests into the modules is the first step [09:56:59] second step is make them only fire when needed [09:57:07] timmywil sure that sounds like a good first step [09:57:22] what I'm concerned about is the penalty of testing if support tests has been performed in a generic fashion (probably by generating methods to avoid code duplication and if ( suuportWasPerformed ) {} nightmares) [09:57:47] so, jQuery.support is initialized to {} on load, but runs little to no tests [09:57:51] we're adding function calls [09:57:55] tests are run as needed [09:58:06] i think we'll have to see what it looks like once we get there [09:58:06] $.newInstance is still fine because support is simply cleared [09:58:25] so we need to make sure those "was support test done" code are bypassed as soon as we're inside jQuery [09:58:31] if that makes sense [09:58:46] yes, jaubourg [09:58:57] once I'm in core and I know support test has been controlled, let's not control it anymore [09:59:15] (I'm not talking performing it but just controlling it has been performed) [09:59:30] mikesherov: thank god, I don't even understand what I write myself :/ [09:59:39] so difficult to explain simply [09:59:48] jaubourg: I'm actually confused :P [10:00:02] once we get to the code i think it will be clearer :D [10:00:24] have folks got a few more minutes to run over? [10:00:28] isn't keeping track of whether it was performed just a matter of checking if there is a value on jQuery.support? [10:00:32] we've got some more stuff here [10:00:45] jaubourg is worried about the overhead of if ( !("supportTestName" in jQuery.support) ) { runTest(); } [10:01:04] no, I'm worried about the overhead of doing that generically [10:01:08] right [10:01:11] to avoid code duplication [10:01:39] something like $.myMethod = withSupport( runTest, runMethod ); [10:01:51] to avoid having "name" in jQuery.support everywhere [10:02:12] gotcha [10:02:12] right, although we'd probably bundle all the support tests for a single module into a single init function [10:02:26] we'll get tehre [10:02:30] do we want to remove jQuery.support or do we want to make lazy? Or both? [10:02:35] yes, but you'd have to test for it for each method ;) [10:02:49] I'm just saying, let's be careful [10:03:00] I'm in favor of timmywil's suggestion [10:03:01] for now i think the plan was to make it lazy, then yell louder about how nobody should be using it anyway :D [10:03:16] since we won't be setting those values unless WE need them [10:03:27] how much code can we add to make this happen? [10:03:45] let's find out how much it takes and then decide if it's too much [10:03:45] what's the limit? [10:03:54] okey :-) [10:03:59] we're gonna grow for sure [10:04:11] amd will grow us a bit even if the wrappers go away [10:04:24] well, the clear advantage is that, if you know a method cannot be called before the document is ready, there is no need to test for dom readyness is support tests... so they can be performed synchronouly [10:04:35] s/is/in [10:04:41] shall we move on? [10:04:45] okay, next is our "visible" checks [10:04:58] FUN [10:05:02] i feel like i'm smoking crack for even mentioning this [10:05:10] yea, I don't see a way around the reflow and make it work as expected [10:05:20] so, is the goal here to get rid of offsetWidth/offsetHeight? [10:05:33] yes, among other things [10:05:40] since they cause reflows [10:05:49] whereas display:none does not [10:05:58] and gCBR doesn't solve it either [10:06:01] width: 0; height: 0; display: block; is still hidden to me [10:06:21] yeah, i know :( [10:06:27] well, can we short circuit this? [10:06:42] I mean, we already defer the reflow as long as possible, right? [10:06:47] i think we already do, if you mean checking display:none [10:07:02] the code checks that first [10:07:11] to avoid a reflow [10:07:16] it's not so much defaultDisplay as accessing the .offsetWidth/Height property [10:07:25] yeah [10:07:25] right [10:07:36] although defaultDisplay can be a shit show too [10:07:48] it has the possibility of creating an IFRAME [10:08:07] okay, i am probably just crazy for mentioning this one [10:08:17] true, but the offset property access is both a reflow and a sync layout calc [10:08:22] why is reading a value causing a reflow? Is it CSS level or are WE doing something weird? [10:08:26] ok, I don't know what I'm arguing [10:08:30] I don't see a solution [10:08:35] me neither [10:08:51] jaubourg when you ask for the width of an element it recalcs the dimensions [10:08:52] (<= stupid inside) [10:08:57] so let's move to te next one since we have mikesherov [10:09:07] k [10:09:08] our old pals offsetHeight/Width again [10:09:15] I can get up to speed later [10:09:25] jaubourg: we replace the display to get a proper value in some cases (reflow) and accessing the property before other layouts are completed causes it to synchronously calculate the layout (also bad) [10:10:18] so i *think* we might actually solve a bunch of these "bad dims when page is zoomed" problems if we avoided offsetHeight [10:10:25] since it's rounding [10:10:38] DaveMethvin: yes [10:10:42] timmywil: thanks, I see now [10:11:03] we should be using gBCR.width and gBCR.height [10:11:06] DaveMethvin: so retrieve a rect? [10:11:12] mikesherov: gotcha [10:11:20] ok, I'm fine with that [10:11:23] so what's the downside mikesherov? i guess people will not expect floats [10:11:35] right [10:11:37] WELL THEY"RE GONNA GET FLOATS [10:11:44] except we already have subpixels in some cases [10:11:51] hmmm, our tests may not expect floats either [10:11:54] yeah, just inconsistently [10:11:56] that could be fun [10:12:19] and actually, we should eventually migrate to .usedStyle [10:12:20] subpizzle is the shizzle now [10:12:25] which exists now [10:12:31] but that's another story [10:12:46] mikesherov: didn't I just see some argument in the mailing lists about removing that? [10:12:55] so is it as easy as switching to gBCR mikesherov? [10:13:09] timmywil: it was just added [10:13:29] ah, I must have seen the wrong side of the argument [10:13:40] yeah some loudmouth talked them into it [10:13:41] :D [10:13:46] https://dvcs.w3.org/hg/csswg/rev/7e12087e6188 [10:13:52] SOME LOUDMOUTH [10:14:20] "look at me, i can't figure out dimensions!" [10:14:49] alright, getting towards the end [10:15:10] I can take that on [10:15:19] if there's a ticket you can assign me, that'd be awesome [10:16:04] you already own it mikesherov 9628 [10:16:09] OH YEAH [10:16:19] rwaldron mentioned he already has a branch to try attaching data directly to elements, i want to experiment with that [10:16:36] so i'll take a look [10:16:43] still a couple of tricky issues [10:16:55] but if we could do that, at least for 2.x, that would be awesome [10:17:06] FINAL item [10:17:19] courtesy of m_gol [10:17:49] will the usedStyle stuff fix this as well mikesherov? [10:18:02] DaveMethvin: theoretically [10:18:14] i saw you'd filed a bug on webkit for this [10:18:30] right now, jQuery tries to get resolved style [10:18:36] I've found the thread to which I was referring. I don't we should count on usedStyle yet, but I think there will be something we can use eventually. [10:18:39] sounded like they planned to do it the "right" way even though that wasn't the way the spec said [10:19:04] which is "used" for width height margin padding border [10:19:19] and is used for positioned elements for top right left bottom [10:19:28] in the meantime do we just leave this as-is? [10:19:40] sorry guys, I have to go :/ [10:19:50] thanks jaubourg sorry about the overrun [10:19:59] half of it is probably my fault :P [10:20:03] as for which unit to return, the spec writers are talking about a Values API that will return the value in whatever unit you want [10:20:06] * jaubourg vanishes [10:20:09] that's probably the direction things are going [10:20:38] and then people will be upset that we always "convert to pixels" :) [10:20:42] I vote we leave it as whatever value gets returned. [10:20:57] that's what we're doing now [10:21:00] timmywil: we should return resolved value [10:21:03] it's just that we think its pixels [10:21:06] DaveMethvin: no [10:21:07] when it's not [10:21:24] there are cases where "auto" and "em" or "%" are returned [10:21:30] which are clearly not "used value" [10:21:32] and are bugs [10:21:39] oh, true enough. you're talking about .width()/.height()/etc [10:21:44] which I think we should pave over [10:21:54] no, even .css("width") [10:21:56] do we have a ticket for thos? [10:22:00] DaveMethvin: yes [10:22:11] they are all filed with the vendors [10:22:49] mikesherov: right, but I'm not sure it's much better to normalize everything to pixels in .css [10:22:56] it sounds like we may want to wait that out, or are you suggesting we try workarounds in the meantime? [10:23:27]