[12:01:59] markelog, m_gol, DaveMethvin, gibson042 https://docs.google.com/document/d/1uhcW9_TlSwD8JnO1_HNnSYJAriTK9WYZ8uQNDvtAAhA/edit [12:02:09] happy new doc! [12:02:17] 2016! [12:03:18] ho ho ho [12:03:22] ...or whatever [12:03:33] hey-hey [12:04:13] happy new year [12:04:26] Looks like gibson042 released Sizzle for us! [12:04:55] gibson042: this is the release to use for 3.0, correct? [12:04:57] cool! [12:05:03] correct [12:05:13] cool [12:05:20] and now that it's finally done, there's nothing left for me except show/hide [12:05:53] markelog: how's 1.12? [12:06:05] I know I need to get you the merge, but anything other than that? [12:06:16] nuh, seems good [12:06:23] cool [12:06:29] would be good to verify 1.12 changes though [12:06:42] I've got a docs branch mostly ready for when 1.12/2.2 is released. [12:06:44] just in case [12:06:48] will do [12:07:08] it is not to much for you alone? [12:07:26] nah, I'll just do what I did with 2.2. Easier the 2nd time. [12:07:37] ok-ok [12:08:17] https://github.com/jquery/jquery/issues/2795 px whitelist [12:08:31] not pressing [12:08:36] I think what we need to make this decision is which is bigger [12:08:40] i'd say we can wait until 4.0 [12:09:03] when is 4.0? [12:09:09] tomorrow? [12:09:10] ) [12:09:12] lol [12:09:15] roughly... [12:09:23] idk 3rd quarter? [12:09:34] don't want to release major versions too fast [12:09:37] i'd say we would need to see how would 3.0/2.2/1.12 would be accepted [12:09:44] i think we went WAYY too long last time, Q3 seems reasonable but no later than a year from now [12:09:56] seems reasonable [12:09:59] 2 per year seems slow enough, some say 1 per year [12:10:09] we can figure out what we want to change in 4.0 [12:10:24] but I'm thinking q3 [12:10:42] i really like the idea of turning the list around tho [12:10:45] would be good to release on some summit or conference [12:10:56] new exceptions will continue to be found no doubt [12:11:03] present, sorry for being late [12:11:05] yeah [12:11:25] so this would be our first for the 4.0 milestone then? [12:11:37] whitelist is easier to fix on the user side, which so attractive in this proposal [12:12:16] DaveMethvin: yup! [12:12:19] sounds like it, but we need to investigate [12:12:40] https://github.com/jquery/jquery/issues/2796 closest context [12:12:41] i'd say it is not 100% clear right now [12:12:47] I'd just like to reiterate my idea [12:12:51] that this is a mis-feature [12:12:59] and that we should only append px to high-profile cases [12:13:00] I read through this, but who put it up for review? [12:13:05] me [12:13:06] which is mostly positioning & sizes [12:13:20] so right now context is only used for positional selectors [12:13:25] if we wanted to target everything then this list might get longer, who knows [12:13:27] i think it should stay that way [12:13:30] m_gol: agreed [12:13:36] m_gol: might be seen as inconsistency [12:13:41] m_gol: regardless, next step is to try it [12:13:45] yup [12:13:50] exactly [12:14:01] Sizzle.matchesSelector doesn't accept a context [12:14:16] which is why we call Sizzle directly for delegated events [12:14:29] DaveMethvin: agreed. We did do contextual matching for event delegation, but this has been this way for a long time [12:14:35] I think this is mostly misdocumentation [12:14:42] yep i would say this is docs [12:15:00] ok then i can note that and open a docs ticket [12:15:06] cool [12:15:24] but the existing `this.context` for positional selectors should _probably_ be `this` [12:15:37] I'll bet it isn't even covered by unit tests [12:15:51] I wonder, yea [12:16:23] i remember we removed something from closest() not to while ago [12:16:35] maybe we just forget to update the docs [12:16:52] I think it's always used matchesSelector [12:17:07] which means it didn't use context matching [12:17:36] it's probably not frequently encountered which is why this is the first bug report in 10 years :) [12:17:39] except for the ternary for pos [12:18:06] seems strange that such behaviour lived for such long time and not many people noticed [12:18:19] I've nevert passed a context to closest [12:18:23] never* [12:18:37] https://github.com/jquery/jquery/issues/2781 isNumeric(hex) [12:18:57] I defer to gibson042 on this one. Seems like we agree we just need more examples in the docs? [12:19:16] that would be my solution [12:19:28] just add a negative hex example to the unit tests and docs [12:19:48] this seems like on of those methods that we shouldn't expose at all... [12:20:04] well, it's been exposed forever and it's not very big [12:20:28] but yeah, if it stays, I agree gibson042's doc update is enough here [12:20:43] ok [12:20:44] get back in that pandora's box! [12:21:18] Should https://github.com/jquery/jquery/pull/2793 animation-iteration-count go in 3.0? [12:21:23] docs + more unit tests [12:21:33] timmywil: even in 1.12/2.2 IMO [12:21:35] this is a bug fix [12:21:38] timmywil: i would add it even in 2.2/1.12 [12:21:42] lol [12:21:48] m_gol: high five! [12:21:51] fine then [12:21:52] ) [12:21:52] every property that accepts numeric values and is not on this list is our bug, unfortunately [12:21:56] markelog: :) [12:22:22] I can land this [12:22:26] cool [12:22:44] can you add it to the 2.2/1.12 too, while you at it? [12:23:34] anyone want to land that spelling pr? [12:23:43] markelog: sure [12:23:45] just for the sake of it, we can check out other new CSS properties [12:24:10] maybe there more then that "animation-iteration-count" [12:24:33] timmywil: can do [12:24:46] markelog: thanks [12:25:06] So, show/hide in progress and I'll finish up my work for 1.12. Anything else? [12:25:15] well, yeah ) [12:25:25] shoot [12:25:34] i think we should revert show/hide changes before we introduce the new code [12:25:48] markelog: we're leaving that up to gibson042 [12:25:55] it might be dangerous otherwise, since we might not make to the date [12:26:03] which is less then 10 days [12:26:24] If we don't make the date, we'll delay the release [12:26:28] also, we have big issue that it seems we forgetting, or i'm forgetting that we already did this ) [12:26:30] but still announce [12:26:39] I can't take time out from forward progress to make a conflicting revert [12:27:19] cool ) [12:27:24] so the 12th right? [12:27:30] that's the plan [12:27:37] crunch time [12:27:44] so lodash and prototype releasing with us? [12:27:54] lodash yes. I'm not sure about prototype. [12:28:10] I haven't heard more about the announcement. I'll follow up. [12:28:10] I wanted to talk about brunches as well [12:28:13] heard some rumors about it [12:28:13] * branches [12:28:26] branches? [12:28:35] brunches are nice, too, though [12:28:38] yeah, two things [12:28:49] 1. do we want to keep the 1.11-stable & 2.1-stable branches? [12:28:59] I have local copies but they're not on a remote anymore [12:29:13] m_gol: not necessary. any bug fixes will go in 1.12/2.2 [12:29:15] which means 2.1.x/1.11.x tags are lying completely outside of any branch [12:29:19] we don't have those branches [12:29:26] we have the tags [12:29:31] you mean 1.12-stable and 2.2-stable? [12:29:38] no, 1.11-stable & 2.1-stable [12:29:49] I renamed them to 1.12-stable & 2.2-stable because I thought we'd be cherry-picking [12:30:04] yeah, so we don't have "1.11-stable & 2.1-stable" [12:30:09] but they were reset to different commits so those tags got far away from any branch [12:30:14] since you renamed those ) [12:30:19] m_gol: yea, I think it's okay to drop them. [12:30:20] so I was just asking if we want to have them on origin or not [12:30:22] k [12:30:23] 2. [12:30:28] I'd drop the `compat` branch [12:30:34] people are asking about it [12:30:47] I initially wanted to keep it as it had some commits that I didn't want to just lose [12:30:48] yea, it's going away when I'm done verifying 1.12-stable [12:30:56] but since compat is lying on 1.12-stable now it seems fine to go [12:30:57] cool [12:31:08] wait, i'm confused [12:31:13] hm? [12:31:15] what "1.11-stable & 2.1-stable" [12:31:26] we have 5 branches [12:31:31] killphp [12:31:34] compat [12:31:35] we had 1.11-stable & 2.1-stable [12:31:41] before they got renamed [12:31:42] yeah, "had" [12:31:44] I have local copies [12:31:52] doesn't matter if we're fine with not having them [12:31:52] m_gol was asking if we need them [12:31:55] yup [12:32:09] but we don't, because we're not adding patches to 1.11/2.1 [12:32:12] oh, don't have local copies of it already ) [12:32:29] so compat is going away after timmywil verifies 1.12-stable [12:32:42] i'd say we need "1.12-stable & 2.2-stable" after release cause there might be patches for them [12:32:50] and killphp once jaubourg emerges and finishes the Node-based server? ;) [12:32:51] markelog: sure [12:32:56] markelog: no doubt! [12:33:04] cool [12:33:14] ok, thanks everybody. See you in -dev! [12:33:16] i would remove the compat after the release [12:33:24] I had one other question [12:33:32] if you're still there ;) [12:33:34] m_gol: sry, what's your question [12:33:51] can we deprecate $.parseJSON & start using JSON.parse on master? [12:33:55] it's now a pure alias [12:34:05] and we kept it mostly because of Android 2.3 & IE<8 [12:34:22] with compat going away it's no longer a concern [12:34:29] i'm fine of it just being an alias until 4.0 [12:34:37] hmm, I'd open an issue so we can discuss [12:34:42] k [12:34:43] also [12:34:55] since we're not removing now, we can deprecate e.g. in 3.1 [12:34:57] gibson042 said that he doesn't have a time for the revert [12:35:15] i think we still should do a revert [12:35:23] since i did twice i can do it [12:35:35] thrice [12:35:41] I agree with gibson042 there. It's not necessary about time. It's more efficient to update the existing code. [12:35:48] necessarily [12:35:51] how so? [12:36:09] just don't want to postpone the release because of it [12:36:43] since we wanting to introduce these changes for two months (?) already [12:36:44] The show/hide changes are important. I don't want to release 3.0 without addressing the performance issue at all. The proposed changes address it for some common cases. [12:36:52] and now we can have less then 10 days [12:37:01] (created https://github.com/jquery/jquery/issues/2800 for the $.parseJSON issue) [12:37:06] if you want a revert in the hopper as emergency break-the-glass, that's fine [12:37:12] but I don't want it to land [12:37:27] timmywil: mm, i'm not sure if new changes would address the perf ones [12:37:40] we'd have to see them in place [12:37:41] gibson042: ? [12:37:42] markelog: it does for certain cases [12:37:51] which is better than no cases [12:38:02] we could became more consistent, but not faster [12:38:15] or am i misunderstood something? [12:38:22] right... they're fast on master now, but these changes will put them back to suck [12:38:30] mine pr with defaultDisplay could improve the perf though [12:38:43] for some cases ) [12:39:05] it's been a while since i looked at it but i thought the middle ground that was discussed in NYC eliminated some of the forced layouts from the 2.x approach without breaking so many current scenarios [12:39:08] it will put them back to suck for most. But it's my understanding that there will be cases where we don't need to read display, which was the perf issue. [12:39:08] gibson042: maybe then, you could integrate it to your changes, if that is okay? [12:39:51] not sure how we can achieve that [12:40:03] i only notice that defaultDisplay improvement [12:40:03] Whatever is faster for gibson042. If getting the proposed changes implemented is faster without a revert, I don't want a revert. [12:40:31] i like the gibson042 plan [12:40:34] I'll put it this way: if there is a revert, I will rebase on top of a revert of _that_ [12:40:37] that i will revert in the pr [12:40:43] +1 [12:40:46] but not land it [12:40:57] if we not gonna make it until the 12 [12:41:03] then we should consider land it [12:41:11] *landing it [12:41:11] markelog: ok, that's fine [12:41:23] but I'm opposed to releasing without the changes [12:41:44] unless I end up in the hospital, we won't have to [12:41:51] you mean releasing with current changes? [12:42:06] I mean I'm opposed to releasing without gibson042's changes [12:42:25] oh, okay, so all hope on gibson042 not getting to the hospital ) [12:42:25] agreed [12:42:31] on both points! [12:42:38] ok [12:42:46] cool [12:42:58] that should wrap it up [12:43:00] * timmywil looks around [12:43:06] gibson042: please cc on you pr [12:43:15] *cc me on your pr [12:43:28] will do [12:43:31] thanks [12:43:33] thanks everyone