[12:02:23] m_gol, gibson042, DaveMethvin https://docs.google.com/document/d/1uhcW9_TlSwD8JnO1_HNnSYJAriTK9WYZ8uQNDvtAAhA/ [12:03:21] LET´S DO THIS [12:03:40] hai [12:04:09] hey-hey [12:05:15] So, let's start with the elephant. DO we want to do this? https://github.com/jquery/jquery/pull/2850 It could be usefult to remove ready without removing Deferred, but I wonder if it is worth the 39 bytes. [12:05:42] vice versa [12:06:00] with deffereds it looked much better [12:06:33] that said, we could still make it so that jQuery.ready is a consumable, rather than keeping the promise method. [12:06:34] now try..catch [12:06:49] and while inside [12:07:10] and all that wrapped with if [12:07:17] it's a bit messy [12:07:31] yeah, but looks better then initially ) [12:08:29] so, my idea is to keep the added tests, but conform to the behavior using Deferred. [12:08:45] I just like Promise.resolve(jQuery.ready)_ [12:08:47] present [12:08:50] -_ [12:08:51] sorry for the delay [12:08:59] I agree with keeping the behavior [12:09:05] interesting [12:09:14] no strong feelings about the dependency [12:09:42] I can draw up a PR and we can discuss [12:09:49] i'm thinking that is needed for the users that build jquery themselves [12:09:59] m_gol opened the original https://bugs.jquery.com/ticket/15174 [12:10:05] i'm not sure if there is a lot of those users [12:10:50] I wouldn't say needed, just a bonus if you want to remove Deferred without removing ready, but I wonder how often that actually happens. Personally, I don't remove remove Deferred when doing custom builds. [12:11:08] we could start using insight package to get a better picture btw [12:11:47] since we doing a lot of those builds, but it might just not worth the hassle [12:12:23] if someone doesn't use effects or ajax it makes sense to remove Deferred [12:12:42] I don't think it's that uncommon, e.g. Angular 1.x may use jQuery if present but those modules are not used [12:12:45] seems like they can keep it if they want ready too [12:12:55] deffereds also useful by itself [12:13:11] not used? [12:13:15] Angular could write their own ready [12:13:33] it has ;) [12:13:40] then... [12:13:41] like angular doesn't use ajax? [12:13:44] nope [12:13:53] well it doesn't using anything ) [12:14:01] it just using jquery if it is present [12:14:07] if not, their own thing [12:14:15] fetch then? [12:14:16] I don't see them moving away from that [12:14:19] m_gol? [12:14:26] it has its own $http service that relies on $q which is something like Q, Promises/A+ compliant for a long time etc. [12:14:40] what do they use for ajax? [12:14:43] but it uses regular XHR under the hood [12:14:58] we do too ) [12:15:17] it is still called jQuery.ajax right? [12:15:30] it's called $http [12:15:49] which uses the jQuery.ajax if jquery is present? [12:15:52] no [12:15:52] which uses jQuery.ajax if present, but otherwise falls back to its own implementation [12:15:54] never [12:15:59] oh okay [12:15:59] )) [12:16:04] I just assumed [12:16:11] me too [12:16:19] it uses jQuery if present for DOM manip stuff & queries [12:16:24] I see [12:16:28] not for AJAX/promises/effects [12:16:29] only for that? [12:16:58] hm, but anyway we degress [12:17:01] if they keep their own ready, seems like they could still do a custom build without either ready or deferred [12:17:11] yeah [12:17:12] it doesn't mean that angular users build their own jquery for it [12:17:16] that was just one example [12:17:34] yes, Angular doesn't ship with jQuery, you can just attach your own one [12:17:42] yeah, anyway, in what direction are we leaning to? [12:17:54] they use this: https://github.com/angular/angular.js/blob/8bda5ec7350705fe6e80549321105536546b3372/src/jqLite.js#L53-L91 [12:18:21] I'm leaning towards not landing this, but let me present another PR next week that keeps the Promise-consumable behavior [12:18:45] how it would differ from what we have now in master? [12:18:55] oh [12:18:58] I'd love to see core/ready without large dependencies but it's not the most important thing in the world... [12:18:59] sorry, get it) [12:19:13] would be cool to use insight though [12:19:18] how is that sound? [12:19:22] what is insight? [12:19:37] do the npm repo insight [12:19:47] useful thingy) [12:19:48] insight [12:19:53] https://github.com/yeoman/insight [12:20:15] oh, interesting [12:20:37] might also be good to move our grunt task from main repo [12:21:38] how about i will create a ticket for it, sounds good? [12:21:47] we'd need to ask for permission to collect data, does it provide such an option? [12:21:52] it does [12:21:56] has an optout [12:22:05] ticket sounds good [12:22:29] yeah [12:22:43] I'm pretty sure it will break people's builds, though [12:22:49] those permission prompts always do [12:23:03] created https://github.com/jquery/jquery/issues/2890 [12:23:38] yeah, if we do this, we would need to be careful about it [12:23:40] gibson042 https://github.com/jquery/jquery/issues/2073 I'm fine if we want to deprecate all but one property. [12:23:44] a lot of people hit that problem when Bower started using it [12:24:16] maybe we could only run it for grunt custom [12:24:52] or we could enable it all the way and check out user reaction) [12:25:03] also would provide some stats ) [12:26:36] what's next? [12:26:39] Of [":"], filters, and pseudos, is filters our preferred property for custom pseudoes. I can standardize this in the repo. [12:27:31] does anyone have a preference between `pseudos` and `filters`? [12:27:44] The only place I know of that documents this is the Sizzle wiki https://github.com/jquery/sizzle/wiki#-backwards-compatible-plugins-for-pseudos-with-arguments [12:27:50] which uses [":"] [12:28:20] how css spec call these things? [12:28:36] well, it doesn't have a mechanism for custom selectors [12:29:05] ...but it calls such selectors "pseudo-class" [12:29:19] technically, filters are pseudos are both semantically correct. [12:29:23] https://drafts.csswg.org/selectors-4/#pseudo-classes [12:29:29] but pseudos is more precise in terms of the kind of selector [12:29:30] but we like "filters"? [12:29:46] i'd say whenever spec call similar entities [12:29:47] I could go either way [12:30:08] so i guess i would be in favour of pseudos [12:30:10] aligning more with the spec sounds good [12:30:36] yeah, let other people bikeshed that thing [12:30:48] cool; "pseudos" it is [12:31:00] okay [12:31:21] One thing about core/ready - plugins might need it as they can't know they're loaded at the bottom of body; that would mean plugins depend on Deferred even if they don't really need them. And this adds to final size. [12:31:46] my question now is, how do we deprecate this? Update the Sizzle wiki and add a page for creating custom selectors to api.jquery.com? [12:31:52] of course plugins can define their own ready... but that's not a one-liner so few of them would do it [12:32:19] probably migrate should do something about it too [12:32:59] perhaps, yea [12:33:11] hi guys, sorry, catching up with the meeting notes now [12:33:16] hey-hey Dave! [12:33:58] hi [12:34:33] Another possibly big convo is this one. https://github.com/jquery/jquery/issues/2863 [12:34:34] timmywil: sounds good to me [12:35:35] oh, yeah, exhausting much [12:35:58] heh [12:36:10] to cut things short i can do a pr, with perf and all that [12:36:29] it might show what kind of things we should do from my perspective [12:36:34] that would make this easier to review [12:37:01] and save us time right now [12:37:14] timmywil: we don't have a tagname error in Android 4.4, I've fixed it last week. I've removed the note about that from the doc [12:37:26] m_gol: oh, great, thanks! [12:37:27] okay, so if no one objects, i will do a pr and we can finalize those questions there [12:37:29] only the IE9 one failure is still there [12:37:34] yea, I need to get on that [12:37:41] I'm hoping it's a test issue [12:37:49] should be! [12:37:52] looks very weird [12:38:00] otherwise a revert would be needed... [12:38:14] you very radical m_gol) [12:38:18] so markelog will do a PR and we'll discuss further from there [12:38:19] ;) [12:38:26] coolsies [12:38:46] cc gibson042 [12:38:48] Lastly, I leave this one up to DaveMethvin https://github.com/jquery/jquery/pull/2860 [12:39:07] looks like it could improve a lot [12:39:10] i like it, any other opinions? [12:39:17] I like it [12:39:17] i can review and land it if you want this week [12:39:17] weeell ) [12:39:25] haha [12:39:36] i'd say it should be faster [12:39:42] we still need to benchmark of course [12:39:46] definitely [12:39:55] but landing without bench [12:40:13] putting my preferences aside that is [12:40:43] let me take a look and if the perf is good I can land it [12:40:48] DaveMethvin: +1 [12:40:50] but since browsers already use getters for that, I doubt we'd be incurring a large perf penalty for using getters on our side, too [12:41:07] plus we get a BIG boost for cases where we are forcing layout [12:41:10] sounds good to me [12:41:11] yup [12:41:12] which was why we wanted to try this [12:41:27] that's all I have for today. anything to add? [12:41:30] are you gonna profile it, or use jsperf? [12:41:37] yeah! [12:41:39] i will probably profile it [12:41:42] i have couple things [12:41:45] I'd like scott_gonzalez opinion on the core/ready stuff [12:41:48] DaveMethvin: cool [12:41:57] markelog: add to agenda too [12:42:02] ok-ok [12:42:13] it seems minor but I have an impression plugins needs ready and that makes any code that uses plugins depend on Deferred even if not really needed [12:42:52] yeah that is a really unfortunate dependency in the long term i would think [12:43:05] DaveMethvin: why? [12:43:14] we could recomment to use the $(fn) form and people excluding ready would just have to care to put scripts at the bottom but lots of plugins use $(document).ready(fn) and it doesn't seem people are in favor of deprecating that [12:43:16] pulling in Deferred just for ready seems wasteful [12:43:32] so does adding 40 bytes for a use case that may be rare [12:43:51] if it's not a breaking change it can be done later in a 3.x [12:43:53] well deferred is not that big of a module [12:43:57] or pushed to 4.0 i guess [12:44:03] it may be rare because custom building jQuery is not so easy [12:44:05] it certainly would be nicer without it [12:44:06] it's pretty big [12:44:13] relatively [12:44:20] Deferred+Callbacks [12:44:28] but in absolute numbers 3-5 kb? [12:44:35] well plus it's just a different impl of Promise that people may not need in a year's time [12:44:38] even for mobile [12:44:54] didn't we change that? [12:45:01] DaveMethvin: true, but if that day comes, I'd be more inclined to drop Deferred altogether. [12:45:15] i think in the future, we could use standart promises - natives [12:45:26] timmywil: IE11 doesn't have ES6 Promise so I don't see that happening within the next 8 years [12:45:53] wow 8? [12:46:05] that's when support for Windows 8.1 ends [12:46:12] well, 7.5 years [12:46:20] yeah don't exaggerate :P [12:46:25] ha [12:46:27] that's a LONG time [12:46:33] hm, and next version should be 12? [12:46:40] maybe they will release an update for ir [12:46:43] *it [12:46:44] ie11 is the last ie [12:46:45] they won't [12:46:49] they don't plan on adding anything to it [12:46:50] tomorrow or something [12:46:51] edge is the current browser, IE is frozen [12:47:05] we now even depend on IE11 not getting their bugs fixed :P [12:47:05] gush [12:47:11] I have an idea. What about adding these 40 bytes at custom build time? [12:47:25] kind of like the alt selector engine? [12:47:25] oooh, nice [12:47:34] that what i was thinking) [12:47:37] that could work [12:47:47] timmywil: ha. didn't think about it and it sounds good [12:47:55] timmywil is the hero! [12:47:57] ok, I can do a PR. [12:48:05] por que no los dos? [12:48:21] * DaveMethvin raises timmywil on shoulders and shouts ole! [12:48:44] damn, now i'm gonna loose sleep because of it, i wanted to propose it, why didn't i [12:48:51] ;) [12:49:25] okay, so i have an item [12:49:34] https://github.com/jquery/jquery-migrate/issues/111 [12:49:38] yes [12:49:47] i think it is pretty serious than it looks [12:49:57] i have provided a pr for that [12:50:01] FWIW, `grunt custom:-callbacks,-deferred uglify dist compare_size` yields -1258, but it's not quite fair because of reasons above [12:50:07] but i think we should mention it in the blog post [12:50:28] gibson042: i knew you trying to detect the real size! [12:50:31] yeah that's good, thanks markelog [12:50:37] just knew! [12:50:38] :P [12:51:03] i checked out couple effects plugins, they all use those params [12:51:08] for some reason [12:51:16] huh [12:51:26] so it could be big breaking thing [12:52:05] okay, that is it from me [12:52:14] another thing: DaveMethvin: does Migrate warn against "[href=#]"-like selectors? would that be hard? we get a lot of issues about this change [12:52:26] I've already closed a few [12:52:41] i suppose it could be checked with a regex? [12:52:47] it doesn't check right now [12:52:57] doesn't it already warns? [12:53:00] not with migrate [12:53:06] but through sizzle [12:53:16] how so [12:53:17] ? [12:53:23] well it gives an error and stops the program already [12:53:29] it throws a error right? [12:53:35] yeah [12:53:43] so we can just try to resurrect that behaviour in migrate? [12:53:52] but i think the idea is that Migrate could give a warning explaining what is happening so they wouldn't report the bug [12:54:01] and perhaps try to fix it, although that might be tricky [12:54:25] you could revert the regex we changed in sizzle and warn when selector contains [href=#] [12:54:34] i thinking we don't need to go in sizzle internals [12:55:08] yeah, the most frequent case is [href=#sth] [12:55:15] where sth may be "" [12:55:21] I mean, nothing [12:55:21] that could be detected pretty reliably i guess? [12:55:33] yeah, should be. at least those cases [12:55:51] https://github.com/jquery/jquery-migrate/issues/140 [12:56:31] oh [12:56:33] https://github.com/jquery/jquery-migrate/issues/141 [12:56:34] ) [12:56:39] 34 seconds before me) [12:57:34] 26 even [12:57:49] I lost the past couple of minutes, but for the record am against updating behavior so [href=#] works again [12:58:01] i'm full of caffeine today [12:58:01] warnings are cool, though [12:58:05] gibson0421: don't worry, just talking about a warning in migrate [12:58:12] gibson0421: even for migrate? [12:58:23] oh, even for migrate [12:58:29] no shim? [12:58:46] correcting it would be a HUGE pain because you have to tokenize the invalid selector [12:58:46] I mean, it technically wasn't documented, but we usually shim things along with warnings [12:58:53] i think we should be able to shim it [12:59:11] gibson0421: wouldn't the shim be a change to a Sizzle regex? [12:59:16] let Sizzle do the tokenizing [12:59:38] but that's just it; `[href=#]` DOESN'T tokenize [12:59:42] was the change in Sizzle done to fix some other parsing issues? [12:59:58] gibson0421: it used to, and would again with a change to the regex, right? [13:00:14] it's not an exposed regex [13:00:18] oh [13:00:19] since it's not standard behavior i wouldn't mess with hit [13:00:20] m_gol: Sorry, just the ping re core/ready. I'm busy right now, but am happy to discuss in a little bit in #jquery-dev. [13:00:42] scott_gonzalez: we can cc you in relevant issue [13:00:44] we can fix the specific case ppl are reporting by rewriting the selector i think [13:00:52] that way we don't need to mess with Sizzle [13:01:00] to do it right, you'd have to tokenize [13:01:25] `[pathological="[href=#]"]` et al. [13:01:28] yes, if we just fix the case ppl are reporting i think it would be simpler tho [13:01:29] $( "[foo='a[href=#]']" ) [13:01:32] right [13:01:47] there are definitely strange cases but those don't seem to be the ones ppl are reporting [13:01:58] I think https://github.com/jquery/sizzle/commit/a060f6148ab14089cd671165a04780a73950da75 is the Sizzle change [13:01:59] I linked 6 issues that people reported [13:02:07] in https://github.com/jquery/jquery-migrate/issues/140 [13:02:14] they just want [href=#abc] to work afaict [13:02:21] we can see how different they are to each other [13:02:22] markelog: Sounds good. I've sort of been following the thread. [13:03:13] gibson0421: I think it was the commit that unified characterEncoding and identifier [13:03:29] m_gol: 3 of them seem to be from the same plugin, or at least use the same regex, and it's a simple case [13:03:37] scott_gonzalez: will do [13:03:47] yeah, timmywil is right [13:03:48] https://github.com/jquery/sizzle/commit/f204a6112216f31685717d9fc1bf6cabf42b2ef1 [13:04:13] all 6 issues mention selectors in the form of "no-opening-square-bracket[href=#no-closing-square-bracket]no-closing-square-bracket" [13:05:11] these ones should be detectable via a regex [13:05:25] `:contains("pathological=[href=#]")` [13:05:34] lol, pathological [13:05:38] even if we screw up a pathological case it would have died anyway [13:05:46] no, it wouldn't [13:05:51] the above selector is valid [13:05:56] for Sizzle [13:06:01] ok right [13:06:11] but again that's pathological! [13:06:17] I'm ok with false positives for warnings [13:06:18] we could just use "might be an invalid selector" [13:06:23] but for rewriting, much less so [13:06:26] exactly [13:06:27] 5 out of 6 of these issues have selectors starting with a[href*=#] [13:06:44] * 4 of 6 [13:06:50] same problem though [13:06:54] m_gol: yea, gibson0421's point is that by shimming it, we might create problems for selectors that still work the same [13:06:56] with false-positives [13:07:35] ok, if it's hard & unreliable to correct then just adding a warning would be helpful [13:07:42] I'm fine with just an explanation in the warning [13:07:52] this was technically always invalid [13:07:54] in reality people reporting this won't bother to use Migrate, sorry to say [13:08:10] we'll just have the joy of telling them, "you should use Migrate" [13:08:15] :) [13:08:31] this needs to go into a 1.3.1 and the 3.0.0 [13:08:43] we'll have to say that a lot... [13:08:51] DaveMethvin: oh, well, i think most smart ppl use migrate [13:09:20] alright, we're out of time [13:09:25] since this was reported even twice in a row... 2884 & 2885 [13:09:27] right [13:09:42] let's continue discussion in dev, tickets or defer to next week [13:09:58] k [13:09:58] thanks everybody [13:10:03] cu