[11:01:09] arschmitz _|Nix|_ agcolom dam__ [11:01:20] hi [11:01:27] hey [11:02:30] <_|Nix|_> Hey! [11:02:35] hey _|Nix|_ [11:02:53] Hi [11:02:59] hi agcolom [11:03:07] ok let's start [11:03:21] slider and rangeslider [11:03:36] we deprecated those without offering an alternative [11:03:48] except for flipswitch [11:04:05] yeah i was talking to scott about this this morning [11:04:18] and he made a VERY convincing argument that we did this wrong [11:05:01] they should not be deprecated [11:05:39] it is indeed not the right way to deprecate something [11:05:49] what was Scott his argument? [11:06:00] well it should not be deprecated at all [11:06:06] because its not going away [11:06:09] its just being changed [11:06:17] even if its a new widget from a new repo [11:06:24] the functionality will always be there [11:06:27] with no gap [11:06:36] I see [11:06:53] the reason we did it is was to have our hands free the change API, right? [11:07:01] sorry I missed a few because I got disconnected from znc. What has been deprecated and shouldn't have been? [11:07:12] agcolom: slider and rangeslider [11:07:22] uGoMobi: right [11:07:28] uGoMobi: ok, thx [11:07:40] so we don't have to deprecate if we change API? [11:07:47] only if we remove a feature? [11:07:49] well heres the thing [11:07:56] even if its in another repo [11:08:04] there is no reason we could not maintain backcompat [11:08:09] through an extension [11:08:27] so we at that point would deprecate parts of the api and introduce the new [11:08:35] just like any other change we make [11:08:42] right [11:08:58] and its not like sliders have that many options to have to maintain the api [11:09:09] true [11:09:19] like my example to scott was datepicker which they are possibly going to do an api breaking change on [11:09:28] but that has like 50 options [11:09:35] so its just not reasonable there [11:09:39] but slider is pretty simple [11:09:43] yeah, different case [11:10:08] the options for our sliders will probably stay more or less the same [11:10:15] so after that i think we should "undeprecate" them [11:10:26] it's just the code that will be completely rewritten [11:10:39] uGoMobi: api who knows on at this point for options and such [11:10:51] but it does not really matter we can deal with that when it comes [11:11:12] we will just have to patch some functionality here and there [11:11:21] didn't we put the new slider on the roadmap for 1.6 instead of 1.5? [11:11:34] uGoMobi: i think so but i would have to check [11:11:59] <_|Nix|_> arschmitz: TBH, I would wait with the un-deprecation until we have the new slider in place. [11:12:16] _|Nix|_: why ? [11:12:38] <_|Nix|_> arschmitz: Just in case we can't accomplish the API even with an extension. [11:12:52] but still this is not the way to do it [11:13:00] _|Nix|_: then we just do like with datepicker and say sorry it had to happen [11:13:15] because it no longer meets the test of being reasonable [11:13:28] but i really dont think that will be a problem [11:13:34] <_|Nix|_> arschmitz: Yeah, but that's exactly what deprecation is for - to avoid a breaking change from one version to the next. [11:13:38] slider has a very simple api [11:13:51] <_|Nix|_> There's the nice kind of deprecation where the new way overlaps with the old. [11:14:05] _|Nix|_: that's the only way if you ask me [11:14:09] <_|Nix|_> Then there's the ugly kind of deprecation where you're being told your favourite tool is going to disappear. [11:14:20] <_|Nix|_> This is in-between. [11:14:36] not true [11:14:38] You can't deprecate something and say "At some point, we'll just change APIs." [11:14:45] That's not helpful to anyone. [11:14:52] The point of deprecating something is to give the user time to move to the alternative. [11:15:17] exactly [11:15:42] so we can only deprecate at the moment we have something new [11:15:50] http://en.wikipedia.org/wiki/Deprecation [11:15:56] Deprecation is a status applied to a computer software feature, characteristic, or practice indicating it should be avoided, typically because it is being superseded [11:16:07] +1 [11:16:16] what we can do is deprecate the flip toggle switch feature of the slider widget [11:16:25] uGoMobi: right [11:16:29] better.. should do [11:16:30] but not slider and rangeslider [11:16:50] right [11:17:03] however we can still of course refuse to make improvments or change anything besides bugs [11:17:08] because its being rewritten [11:17:33] yup, that's just a matter of priority/planning [11:18:12] <_|Nix|_> OK. You guys are right. [11:18:56] ok we edit the message in the 1.4.0 changelog [11:19:06] and remove notice on api [11:19:11] right [11:19:24] I don't think there is a note in the code itself [11:19:25] <_|Nix|_> Issue? [11:19:32] but will double check [11:19:39] <_|Nix|_> I can jump on it ... [11:20:02] great [11:20:18] next topic is PR reviews [11:20:31] im all for assigning to me [11:20:45] will make it much easier to see what i need to look at lol [11:21:00] <_|Nix|_> arschmitz: Cool! Can you then assign back afterwards? [11:21:00] ok [11:21:08] _|Nix|_: sure [11:21:12] <_|Nix|_> Awesome! [11:21:33] maybe first assign only the ones for 1.4.1 bug fixes [11:21:50] <_|Nix|_> Yeah, for sure. [11:21:54] you can't filter PRs by milestone if I am not mistaken [11:21:57] there "Should" not be any others right now lol [11:22:12] oh ok, didn't check all 40 ;-) [11:22:12] <_|Nix|_> Actually, I think you can. [11:22:39] uGoMobi: no i was alluding to the fact that we should not be working on anything else right now [11:22:46] so there should only be 1.4.1 prs [11:23:08] yeah, but maybe there are some old ones, don't know [11:23:27] uGoMobi: yeah i know it was just a joke there are some that we decided to wait on [11:23:41] <_|Nix|_> Actually, you can filter by milestone and then click "Assigned to me" and you should see both issues and PRs assigned to you. [11:23:43] apparently im not funny :) [11:23:44] :) [11:23:47] haha [11:23:53] arschmitz: now you are :D [11:24:12] <_|Nix|_> You buncha clowns :) [11:24:20] _|Nix|_: and then all tickets have the "Android" label? ;-) [11:24:36] * _|Nix|_ cowers behind a large rock [11:25:19] anyways, when we are done with PR reviews we can do a 1.4.1 release [11:25:32] <_|Nix|_> I will never again check off the checkmark at the top of the issue list. That way be dragons! [11:25:45] and if it's too much work, we review the high priority ones first [11:26:03] <_|Nix|_> The rest can always go into 1.4.2, right? [11:26:07] and the others can wait until 1.4.2 [11:26:11] exactly [11:26:14] uGoMobi: yeah we are making some awesome progress on 1.4.1 issues [11:26:24] I want to do maintenance release more frequently [11:26:35] and even some oldies [11:26:36] not wait untile *everything* is done [11:26:41] because we are never done [11:26:46] arschmitz: yeah awesome [11:27:36] somebody just added AMD to the agenda [11:27:39] what about it? [11:27:48] that was me [11:27:56] AMD has landed in master for UI [11:27:59] ah, I see the rest of the text now [11:28:13] <_|Nix|_> Nice! [11:28:14] yeah, saw that... nice! [11:28:28] bringing us closer to being able to truely interop [11:28:55] so now we need to update to the same UMD wrapper they have [11:28:56] yeah [11:29:00] and ditch our amd one [11:29:23] also would be a good time to update our file names and directory structure [11:29:26] shall we start with that after 1.4.1 release [11:29:30] exactly [11:29:41] <_|Nix|_> So, are we doing the 1.4-stable thing after 1.4.1? [11:29:42] uGoMobi: yes its a after 1.4.1 thing [11:29:50] so we can create 1-4-stable branch after 1.4.1 release [11:29:54] <_|Nix|_> OK. [11:30:00] i just wanted to bring it up since it finally landed in ui master [11:30:03] <_|Nix|_> I always ask 17 seconds too soon :) [11:30:34] then we can get rid of the jquery.mobile.tabs.js file too [11:30:35] _|Nix|_: do you know if Hyunsook and team already started to work on removing style options? [11:30:39] as thats just an amd wrapper [11:30:58] <_|Nix|_> uGoMobi: It's Lunar New Year out East right now. [11:31:02] I know [11:31:03] <_|Nix|_> uGoMobi: Today's meeting was off. [11:31:09] year of the horse :) [11:31:28] <_|Nix|_> uGoMobi: Last week they said they're planning the year, so they haven't had a chance to work on the style removal yet. [11:31:38] that's good [11:32:08] let's do 1.4.1 release next week and then change file structure [11:32:32] after that they can work on removing style options without having to worry about bunch of conflicts [11:32:40] <_|Nix|_> Cool! [11:32:52] <_|Nix|_> Actually, I don't think file structure should be such a big deal. [11:33:00] <_|Nix|_> Git is pretty good about tracking files across moves. [11:34:26] ok, is there anything else we need to discuss? [11:34:34] ah, one thing [11:35:00] arschmitz: I noticed you mentioned something about checkboxradio icons during yesterday's UI meeting [11:35:09] about going back to spans [11:35:09] indeed [11:35:16] err :after I mean [11:35:17] yup [11:35:29] no its going to use spans [11:36:24] 18:07 nothing to discuss its back to where it was with before and after [11:36:36] the status of the widget [11:36:55] ok I misunderstood [11:36:56] its now back to where it was when it used before and after [11:37:01] but now using spans [11:37:10] I thought you tried spans but were moving back to pseudo elements [11:37:17] no [11:37:20] gotcha [11:37:42] so far spans are actually much cleaner [11:37:55] and have had minimal impact on the code [11:37:58] it sure is [11:38:39] oh i just thought of something else [11:38:55] talking about cleaner... I am reviewing the icon optimization PR at the moment and I would really like to have a much more simple solution for that in the future [11:39:13] for demos using external code is it better to link to a stable tag on github or include in library [11:39:21] <_|Nix|_> arschmitz: Lemme get this straigh. checkboxradio uses spans, but we're not doing the buttonMarkup thing where we're doing spans for every single anchor, right? [11:39:21] uGoMobi: link? [11:39:23] I mean, the PR made me aware again of that our icon CSS is confusing [11:39:58] every anchor? [11:40:00] arschmitz: https://github.com/jquery/jquery-mobile/pull/6654 [11:40:50] <_|Nix|_> arschmitz: Well, we used to have Click me [11:40:57] <_|Nix|_> arschmitz: I hope we're not doing that again. [11:41:06] that doesn't look like a checkbox [11:41:12] but yeah, no more inner markup [11:41:22] <_|Nix|_> No, that's why I'm making sure that the span thing is restricted to checkboxradio widgets. [11:41:34] <_|Nix|_> OK, good. [11:41:35] _|Nix|_: it will be text [11:41:42] that sort of thing [11:42:06] so if an anchor has an icon it will have an icon span [11:42:45] <_|Nix|_> arschmitz: OK, but these spans are there a priori, right? No startup DOM manip on our part, right? [11:42:54] BTW - when I pull the changes from that icon PR into a branch and resolved conflicts I ended up with coveralls report directory inside the build directory. something to be aware of. [11:43:09] gseguin will add it to .gitignore [11:43:20] _|Nix|_: it depends [11:43:34] _|Nix|_: a person can add the span and classes them selves [11:43:41] or do it with the widget their choice [11:43:54] but if they use the widget it will be generated [11:44:04] and with checkbox radio it will be generated [11:44:32] <_|Nix|_> arschmitz: OK, but simple anchors no longer have an enhancement step. So, Link is just that. It does not get modified by the framework upon startup anymore - right? [11:44:51] agcolom: anything about documentation or other content that needs to be discussed? [11:45:09] will work on the iframe issue this weekend [11:45:22] will do one and see if it's a good solution [11:45:33] _|Nix|_: in that case if you dont call anything on it yourself by adding rold="button" or with js then you will get whatever you put [11:45:45] so if you add an icon span you get an icon if you dont you dont [11:45:47] agcolom: ok great [11:45:50] in the mean time everyone can vote for me at https://thenetawards.com/vote/developer/anne-gaelle-colom/ [11:45:55] :-) [11:46:01] there is no js involved so its whatever you put in your markup [11:46:04] yeah awesome [11:46:16] <_|Nix|_> arschmitz: OK, that's good. [11:46:31] agcolom: again, congrats with your nomination [11:46:38] uGoMobi: Thanks!!!! :-) [11:46:48] <_|Nix|_> agcolom: Yeah, that's really awesome! [11:46:48] _|Nix|_: thats not really a change though you could do that before when they had 3 spans too [11:46:52] thats just css [11:47:01] _|Nix|_: Thank you :-) [11:47:07] <_|Nix|_> arschmitz: Actually, you'd risk double-enhancing it before. [11:47:17] not if you didnt add data-role="button" [11:47:30] <_|Nix|_> arschmitz: Right - true. [11:47:31] arschmitz _|Nix|_ sounds like a nice discussion for -dev [11:47:33] we only change the behivor if you add data-role="button" [11:47:40] gotta run to pick up alex from rock climbing... [11:47:46] <_|Nix|_> uGoMobi: Yeah, we can move that to -dev [11:47:48] later agcolom [11:47:49] what? im rock clibming [11:47:57] lol [11:47:58] i should really know these things :) [11:47:58] absolutely ;-) arschmitz :-) [11:47:59] <_|Nix|_> arschmitz: Didn't you know? [11:48:09] and I hope you're ready ;-) [11:48:34] speak later all :-) [11:48:39] <_|Nix|_> arschmitz: L8R [11:48:46] <_|Nix|_> agcolom: L8R [11:48:49] <_|Nix|_> arschmitz: Sorry :) [11:48:54] ok thanks all [11:49:00] see you on -dev [11:49:01] bye all