").hide().css("display") // ? [12:09:38] I see merit to both sides. On the one hand, we've had tickets complaining about show/hide behavior on responsive stylesheets. On other hand, it could be seen as odd that $detached.show().appendTo("body") does not guarantee the element to be shown. [12:09:53] right [12:10:13] there is no winning thing here b/c it will always break someone's expectations [12:10:19] markelog: that case is the same either way, right? [12:10:25] but I'd answer display: none [12:10:38] m_gol:DaveMethvin:? [12:11:13] it's one of those tree-falls-in-a-forest questions, what does it mean to hide something not in a doc? [12:11:19] I'd answer 'none' as well but detached elements don't seem so important to me overall [12:11:33] because of what DaveMethvin said [12:11:34] that pull all about detached elements [12:11:43] yes [12:11:54] i agree it restores the old behavior [12:11:55] that matters when you append it to Dom [12:12:10] okay, so DaveMethvin: ? [12:12:11] but i don't know if we want to restore the old behavior [12:12:23] it does, but we can guarantee hide without interfering with responsiveness, so it's a bit different. [12:12:29] show is the problem area [12:13:32] if 'jQuery("

").hide().css("display")' set defaultDisplay, it also an issue for responsiveness [12:13:51] yes since the stylesheet may change [12:14:01] not if we don't lock in a display on show [12:14:15] we lock it on hide() [12:14:30] as i recall, gibson042 correct? [12:14:43] are you asking about 2.x or master? [12:14:52] master [12:15:03] yeah [12:15:24] DaveMethvin: so i assume your answer is the same as of m_gol? [12:15:36] we do, just checked [12:15:41] on master, private data is only set when hiding an element with non-empty inline display [12:15:53] so, yes :) [12:16:16] markelog well, no. in your example $("

") doesn't have inline [12:16:21] and only retrieved when showing an element with inline display: none [12:16:41] 'display !== "none"' this is the condtion [12:16:50] which means if display is empty [12:16:58] it sets display [12:17:08] but at that point display was retrieved with elem.style, so it would be "" [12:17:22] yes, so it does sets it [12:17:27] not the same as locking in a display [12:17:34] as "" respects cascade [12:17:42] display will be locked on "none" [12:17:50] because it is not "none" [12:18:07] you lost me there. we don't save "none" in private data. [12:18:14] we do ) [12:18:23] timmywil: what will get saved is empty string [12:18:32] gibson042: that's what I said [12:18:34] :P [12:18:58] how does "none" get saved. it's if (display !== "none") { // save [12:19:08] "none" never gets saved [12:19:24] okay, so [12:19:26] jQuery("

").show().css("display") // ? [12:19:40] yea, that's the question [12:19:44] we're with you [12:19:52] '' [12:20:10] Right now, it's "" [12:20:21] is that expected behaviour? [12:20:21] and there are upsides/downsides [12:20:39] expected by ... ? :) [12:20:51] depends on the use case, yea [12:20:54] by users who set display on detached elements :) [12:21:15] we have 5 ticket in the old bug-tracker about it [12:21:17] the default display after attaching the div to the document is non-none so I'd expect the display to not be set [12:21:19] 5 or so [12:21:21] markelog: if someone asked me how to do that, I'd tell them to use .css [12:21:35] can't write plugin that way [12:21:54] right, i understand your point about the old tickets, we rolled over really quickly on that and it may mean that there is so much code out there that we can't fix this [12:22:24] we can try it this way though and change it back later if we need to [12:22:34] / In other words [12:22:34] jQuery("

").hide().css("display") // none? [12:22:34] jQuery("

").show().css("display") // ""? [12:22:42] this is expected behaviour [12:22:42] yes [12:22:47] correct? [12:22:47] markelog: that's what we're talking about trying, yea [12:23:04] timmywil: that is why i wanted to make a quick pull [12:23:11] if that is expected, we move on [12:23:23] otherwise it would took to long :) [12:24:08] markelog: But I think we all realize that you could be right and we'll have to change this back in a future release. I'd like to try this tho. [12:24:26] okay, closing the pull, we can move on now [12:24:33] I'd like to get back to 1.12.2/2.2.2 for a moment [12:24:42] m_gol: ok [12:24:57] 1.12.1/2.2.1 were released almost a month ago [12:25:08] with very broken AMD modules [12:25:25] and so far we've received a little ticket here & there and we've been fixing it [12:25:29] https://github.com/jquery/jquery/issues/2863 is still open though [12:25:32] but we can do it for a looong time [12:25:41] so I think we shouldn't drag it further [12:25:57] even if shortly after releasing 2.2.2 we have a reason to release 2.2.3, that's fine IMO [12:26:06] the 2.2.1+1 fixes it on npm tho right? [12:26:17] there's no 2.2.1+1, is it? [12:26:20] m_gol: there's only one more ticket. I think we can get it done. [12:26:28] DaveMethvin: no, npm prohibits that now apparently [12:26:30] sure, unless we get another one in 5 days :-) [12:26:33] oh [12:26:40] I tried [12:26:50] so I'd like us to not add new tickets to 1.12.2/2.2.2 [12:26:53] m_gol: no, I agree. we won't add more tickets. [12:27:00] even if someone reports sth, we can always do 2.2.3 [12:27:02] ok, thx [12:27:04] any more go in another patch [12:27:12] yea [12:27:45] that said, there's a workaround for the AMD problem, just not a pretty one. [12:28:39] change "sizzle": "path/to/sizzle" to "external/sizzle/dist/sizzle": "path/to/sizzle" [12:28:56] but I still want to fix it. [12:29:17] k [12:29:24] if everyone consumed versions via npm i wouldn't worry about spinning new patches every week [12:29:46] but most ppl get it manually i suspect so frequent releases fragment the installed base more [12:30:14] or from the cdn, which wouldn't be affected by this [12:30:41] yeah, I was mostly saying that since there's been almost a month since 2.2.1, if we release 2.2.2 and shortly afterwards we get a critical ticket that will require us to release 2.2.3 really quickly, that's not a huge problem [12:30:51] agreed [12:31:00] right [12:31:01] that's not a release every week, that's a release every month + an occasional hotfix release [12:31:19] and we *should* be releasing more often than we have in the past i think [12:31:30] DaveMethvin: thanks for starting the migrate guide [12:31:36] Yeah, 2 years was a little too much. But we know it now. [12:31:39] i think thats why timmywil wants to get 3.0 out :) [12:31:46] ^ [12:31:51] oh, speaking of [12:32:05] DaveMethvin: harder for us, we would need upgrade documentation and migrate for each release, if not patch [12:32:12] I'm not going to make https://github.com/jquery/jquery/issues/2863 a blocker [12:32:34] yeah, it's started and i should have it ready this week, just need to to go through the tickets and clarify some things [12:32:38] we can add more tests in 3.0.1+ if we don't get to it [12:32:50] and if behavior needs to change, that will affect our decisions there [12:32:54] timmywil: it would be inconsistent behaviour [12:33:02] what would [12:33:12] if https://github.com/jquery/jquery/issues/2863 is not fixed [12:33:31] new logic and old logic collide there [12:33:38] depends on whether you consider it a fixed regression or not :) [12:33:41] but not a lot of people would be affected [12:33:50] it wouldn't be a regression though [12:34:09] meh, now that we have a decision on show/hide I'll just put up a PR by Thursday [12:34:13] just inconsistent new api [12:34:20] that would be good [12:34:25] i could definitely use some help describing the real-world cases for show/hide that change in 3.0 [12:34:39] gibson042: that works, thanks [12:34:46] i think we discuss this previously [12:34:53] not much you can do in migrate [12:35:10] but we should point it out in release notes, i think [12:35:18] and the upgrade guide [12:35:19] the upgrade guide text yeah [12:35:33] I also think we shouldn't be adding new issues to the 3.0.0 milestone unless we have a PR and it's LGTM'd to land (because then we'll keep moving it further by a few days over & over again). markelog disagreed with me about that at https://github.com/jquery/jquery/issues/2986 so I wanted to hear others here. [12:35:34] oh, there is that [12:36:00] i don't disagree with that [12:36:16] m_gol: it would have to be very high priority at this point [12:36:22] I put 3.0.1 because I don't consider it necessary for 3.0.0 [12:36:40] i think we should ship 3.0.0 and not delay it for little things that we can fix in a patch or minor [12:36:41] but if it's ready, it could go in [12:36:47] that ^ [12:36:50] I don't mind getting things done sooner and fitting it in [12:36:50] code seems ready to me, but it might have some consideration i didn't notice [12:36:58] but I don't want to delay [12:36:59] if it's ready i'm good with it landing too [12:37:00] I haven't tested it against our suite [12:37:09] i don't think we should delay [12:37:22] brb 1min [12:38:10] So if its ready land, if not, wait a until the next release, which i guess will be a hot one :) [12:38:54] +1 [12:39:15] I agree with that. ;-) My remark was mostly technical. [12:39:34] back [12:39:57] what's this about ie6? [12:40:01] BrowserStack has been pinging me when they can turn off the IE 6 machines [12:40:09] ah right [12:40:10] we have the pool of 30 machines available [12:40:21] but they also keep 2 IE 6 ones just for us, constantly running [12:40:32] see http://swarm.jquery.org/clients [12:40:36] that sounds like burden for them [12:40:39] and they'd love to turn them off :-) [12:40:45] only for us, that's friendly [12:40:54] I just asked them for some more time so that we finish with 1.12 [12:40:57] that is nice of them, but we need them for 1.12.x [12:41:11] they wouldn't be gone completely [12:41:20] they'd just start normally like any other machine [12:41:24] now they're constantly online [12:41:28] oh [12:41:30] because they're that slow [12:41:35] well, we don't use them that much do we? [12:41:37] heh [12:41:37] and that speeds it up a little [12:41:49] they are used after every commit to 1.12-stable [12:41:50] it seems it also easier to support [12:41:54] and the same for Migrate [12:42:01] maybe after 1.12.2 release, we can tell them, we can deal with slower runs [12:42:08] yeah [12:42:13] we should try to be nice to them [12:42:16] that was my thinking, just wanted to run it by you [12:42:25] i sure hope we can avoid a lot of updates [12:42:27] I'll talk to Leo as well as QUnit still uses them [12:42:37] for 1.x [12:42:39] i think, they do that because it easier to maintain, not because they are slow [12:42:58] i mean, because they are slow it easier to maintain if they always online [12:43:02] easier to maintain? [12:43:23] yeah, a lot of networks heartbeats you need for slower machines [12:43:33] not necessarily, they've explicitly asked about not having to keep them online [12:43:46] especially that they're extra, they don't count in the 30 machines limit that we have [12:44:10] whatever is easier for them [12:44:12] oh, then totally, i think we can deal with slowness [12:44:18] timmywil:+1 [12:44:21] we can always restart on TestSwarm [12:44:24] the unit tests run really fast for migrate so having to spin up an ie6 box for the 1.x-stable there wouldn't be bad [12:44:34] I'll wait for 1.12.2 & write to them [12:44:35] right [12:44:37] k [12:44:44] so we the last fence, who still supports ie6 [12:44:51] that's crazy :) [12:45:05] i would thought lodash would be last [12:45:38] heh, lodash already dropped [12:46:00] so when do we want to release? [12:46:09] I'll do it as soon as I can [12:46:30] but this week for sure [12:46:35] yeah, fire when ready [12:46:39] just after fixing https://github.com/jquery/jquery/issues/2978 I guess :) [12:46:43] right [12:46:51] timmywil: i mean 3.0 [12:47:04] ah [12:47:06] you mean the same, right? [12:47:15] if gibson042 gets out a PR on Thursday, I'd say as early as next week. [12:47:20] since we are locking issues and staff [12:47:25] i think we need the upgrade guide ready, and it should be by then [12:47:38] do we not wait for Migrate 3.0? [12:47:46] rc first [12:47:51] ah, right [12:48:00] rc for 3.0? [12:48:06] yea [12:48:09] i thought you wanted final [12:48:15] I did, but DaveMethvin talked me into rc [12:48:17] you didn't want to do a beta [12:48:21] oh, okay [12:48:36] we still need Migrate to be done so we can do the Core RC even if it's identical to the final one :) [12:48:36] what convince you? [12:49:01] several of the 3.0 things should be easy, the others i need help on or perhaps we don't do them for the first release [12:49:10] yeah, that is rc, so it expected to be pretty much the same [12:49:31] show/hide i think we decided we can't detect, i wonder if we really want to patch back in all the old code [12:49:54] let me see what I can do on that this week as well [12:50:20] timmywil: what is the reason of not releasing the final? [12:50:22] I'll try to find some time for Migrate [12:50:32] DaveMethvin: i'd say yeah [12:50:40] it one of the most important changes [12:51:09] i can take this one, fyi [12:51:14] ok great! [12:51:31] do you have a ticket? [12:51:48] https://github.com/jquery/jquery-migrate/issues/102 [12:51:50] cool [12:51:56] markelog: an rc gives more of a heads-up than a beta, and we have some changes since the beta that I'd like to give a heads-up on. [12:52:18] ok, so more info in the blog-post [12:52:18] ? [12:52:35] yea, for instance, we added jQuery.escapeSelector [12:52:52] timmywil: do not forget about https://github.com/jquery/jquery-migrate/issues/111 [12:52:57] that is important one! [12:53:19] we can point ppl to the upgrade guide in the rc blog post [12:53:30] do you think a lot of ppl use the old easing params? [12:53:36] yeah, i do [12:53:46] all plugins that i have checked use them [12:53:47] maybe indirectly with the easing plugin [12:54:02] and i checked about 3-4 [12:54:05] it's very easy to upgrade, though [12:54:16] not really, actually [12:54:28] it is easy, but not easy to get what's happening [12:54:29] find+replace [12:54:32] sure [12:54:36] since those properties weren't documented [12:54:41] maybe we should put up an explanation somewhere [12:54:42] sth like https://github.com/jquery/jquery/issues/2964#issuecomment-191229690 [12:55:12] We'll include in the upgrade guide [12:55:26] i would pointed it out in the blog post too [12:55:41] but that's me [12:55:54] i made a note to be sure and put it in, there's a ticket in the jquery tracker marked behavior-change so i would have found it eventually :) [12:56:08] coolsies [12:56:09] It's low-level. I think the blog post can link to the upgrade guide on this one. [12:56:10] most IDEs allow to refactor the variable/param names so sth like my comment might help them to know what to change to what [12:56:19] timmywil: if you say so [12:56:32] i think the blog post should mostly point to the upgrade guide because we want people to refer to that, it will be updated as we make changes [12:56:32] but yeah, it may be linked [12:56:36] blog posts are more static [12:56:49] yeah, and we've seen what happens to static changelogs :) [12:57:10] oh, speaking of, I'm updating the 1.12.0/2.2.0 blog post today [12:57:11] it can link to the guide, i'm saying this should be noted [12:57:24] since that is pretty big one [12:57:25] with those issues m_gol updated [12:57:44] markelog: I think the ones interested are plugin authors, not regular users [12:58:00] one more thing: can we disable automatic running of the Periodic Jenkins jobs for 1.x/2.x after 1.12.2/2.2.2 are released? [12:58:00] regular users use plugins [12:58:05] ok gotta run... i will keep working on the upgrade guide and try to knock off a few migrate tix [12:58:09] we can say, that most plugins would not work with it [12:58:14] and give couple examples [12:58:14] but they don't need to know how plugins work. they just use the easings [12:58:17] they actually fail a lot, I just come to the page every few days & restart what failed :P [12:58:31] yes, that is why we can just say, what plugins would not work [12:58:44] oh, yea, I can say that [12:58:45] often I join the swarm with my local Android 2.3 so that restarts don't fail as well [12:58:50] cool, thanks [12:59:27] m_gol: emulator? [12:59:33] or do you have a real one? [12:59:34] yes, but the x86 one [12:59:36] m_gol: yes, but we'll need manual runs if we do 1.12.3/2.2.3 [12:59:41] burn it! [12:59:42] those disabled jobs can always be fired manually when needed [12:59:51] ok cool [13:00:03] time's up [13:00:04] BrowserStack claims they tried the x86 emulators and they didn't notice speed difference [13:00:06] burn it straight to hell! [13:00:08] but that's not my experience [13:00:24] still here: would like to spam about GSoC [13:00:40] markelog: I mean the x86 emulator, not a real one. It's still fast [13:00:50] all3fox: let's discuss in -dev [13:01:00] hah :), burn the macbook on which you have that emulator [13:01:01] :) [13:01:21] thanks everybody