[11:04:13] gabriel_schulhof: jasperdegroot: agcolom: cgack gseguin|away MEeting Time! [11:04:24] howdy [11:04:26] Yo! [11:04:28] hi [11:04:40] I only have 20 minutes [11:04:50] of which 15 are left [11:05:19] agenda https://docs.google.com/spreadsheet/ccc?key=0AskujzE4Ig0QdG5nSmZiSUhjYm4ya29CdjhLZmJwSWc&usp=drive_web#gid=46 [11:05:22] jasperdegroot: ok [11:05:52] I propose we start with whatever jasperdegroot has. [11:05:59] gabriel_schulhof: agreed [11:06:06] ok [11:06:09] not much [11:06:14] I started with button css [11:06:20] in branch button-css [11:06:33] replaced btn by button [11:07:45] jasperdegroot: ok [11:07:56] button element will be auto initiated by new button widget, right? [11:08:00] jasperdegroot: Ping me as soon as thats ready to review [11:08:03] jasperdegroot: yes [11:08:14] and anchors with data-role="button" [11:08:19] then we have to move demos back again [11:08:28] from button markup demo to button widget [11:08:46] jasperdegroot: well button markup is no more either way [11:08:51] arschmitz: I think we need a ticket with a checklist what needs to be done [11:08:57] jasperdegroot: and we still support and recomend css only buttons [11:09:04] arschmitz: right, but we have a demo page with that name [11:09:10] jasperdegroot: yes [11:09:12] maybe we need to merge those two [11:09:24] the two demo pages I mean [11:09:25] jasperdegroot: probably [11:09:46] jasperdegroot: yes [11:09:51] Why are CSS-only buttons on the same page as the button widget elements? [11:10:05] gabriel_schulhof: all buttons [11:10:13] just two different ways to do them [11:10:47] Well, that's the same as we have now. What was our motivation for having two pages, and why is that no longer relevant? [11:11:05] gabriel_schulhof: because we use to have buttonMarkup and button widget [11:11:06] gabriel_schulhof: it was to avoide confusion between button widget and button markup [11:11:14] but now button markup is gone [11:11:22] right [11:12:01] Actually, if this is the rationale, we should already have unified the two pages in 1.4.0, because buttonMarkup was gone in 1.4.0. We kept it around for backcompat, but it was not used at all. [11:12:16] So, good. Unify ALL the buttons! [11:12:42] buttonMarkup wasn't gone in 1.4 [11:12:51] it was deprecated [11:12:54] jasperdegroot: It was gone for all intents and purposes. [11:13:02] jasperdegroot: We updated all the demos to not use it. [11:13:11] gabriel_schulhof: not true its stil lthere you can still call it if you want [11:13:23] arschmitz: Yes, but it's ... ummm .. orphaned. [11:13:33] gabriel_schulhof: the seperation was to ease migration [11:13:48] rather then just remove the page you keep it and show new way [11:14:08] Backcompat at the demo level, I suppose. We're too nice :) [11:14:17] anyway [11:14:31] arschmitz: is there a ticket with all work that needs to be done for buttons? [11:14:49] jasperdegroot: there is the pr for the 1-12 branch [11:15:01] with checklist? [11:15:08] no but we can add one [11:15:25] I think that would be good [11:16:00] lot of work to do so it's good to keep track of what's done and has to be done [11:16:17] especially lot of work on demos [11:16:28] +1 for checklists [11:16:44] and we work on things in different branches [11:16:48] jasperdegroot: demos really only need to be adjusted for icons [11:16:56] and to merge the pages [11:17:11] I can go over the demos once more and add the necessary spans. [11:17:12] oh wait no we need to switch all the ui-btn to ui-button [11:17:20] but thats just a search and replace so not a big deal [11:17:22] right [11:17:22] I can do that. [11:17:30] gabriel_schulhof: I already did that [11:17:35] jasperdegroot: Oh, wow! Cool! [11:17:39] in branch button-css [11:17:43] Sweet! [11:17:54] jasperdegroot: Man, that can be tedious. Good work! [11:18:11] well, still need to check if I broke something [11:18:22] that's most of the work [11:18:35] jasperdegroot: I wonder if casper can be of assistance. [11:18:52] not sure [11:19:12] if you could write a js test of some sort it could [11:19:50] arschmitz: Maybe not. It's hard to capture the intention in the markup. Like, "this button is supposed to have an icon, but doesn't". [11:20:11] yup [11:20:27] it couldnt do much better then just doing a serch in the repo for ui-button [11:20:31] ui-btn i mean [11:20:56] that's what I did [11:21:27] jasperdegroot: i assumed [11:21:29] Actually, searching for ui-btn is a very good idea, because that'll show you all the places where icon spans need to be added too. [11:21:46] gabriel_schulhof: no searching for ui-icon will :) [11:21:53] I think icon span needs to wait until we are finished with button css and demos [11:22:07] it's in a different branch too [11:22:15] Oy! [11:22:25] jasperdegroot: why? [11:22:48] they are both needed to make buttons render properly they should be together [11:23:47] true [11:24:08] maybe better to cherry pick that commit from icon-span branch [11:24:30] into the button-css branch [11:24:33] jasperdegroot: yes i think so [11:24:43] Or rebase the button-css branch onto icon-span [11:24:44] ok, will do that [11:25:09] jasperdegroot: thank you [11:25:10] that was it for me [11:25:18] have to go now, sorry [11:25:31] later all [11:25:45] jasperdegroot: K L8R [11:25:53] jasperdegroot: have a good one [11:26:05] adios jasperdegroot [11:28:02] ok so moving on [11:28:04] 1.4.5 [11:28:10] lets get this out asap [11:30:25] what is left for 1.4.5? iPhone 6 iOS8 stuff? [11:30:49] basicly [11:31:02] or anything else that makes sense thats done by the time the ios8 stuff is [11:32:33] so 1.5 [11:33:49] there are LOTS of prs [11:33:54] most need updates [11:34:07] cgack: i need to review a couple of yours you updated this week [11:34:26] gabriel_schulhof: i think all your classes ones still need updating right ( even before the new classes stuff ) [11:34:50] arschmitz: yepper looking forward to it :) [11:35:02] arschmitz: I've updated some of them to deprecate the boolean style options. [11:35:06] cgack: they will all need more updating either way though [11:35:09] I've done popup, collapsible, and listview. [11:35:33] gabriel_schulhof: are they also update for "" vs null and to use the theme classes where they should? [11:35:35] arschmitz: In petersendidit's PR, the default value for a class key is null, not "". Is that going to change to ""? [11:35:44] gabriel_schulhof: its mixed in the pr [11:35:55] arschmitz: So, what's it gonna be? "", I assume. [11:35:55] and we decided to standardize on "" [11:35:57] OK. [11:36:06] so that you can do value += " newclass" [11:36:24] I thought the theme classes were not to be part of the key's value, because theme's not a boolean style option. [11:36:28] i can make that change in my pull request but I know that branch as been pulled in to other branches and don't want to break things [11:36:56] petersendidit: That's fine. We're not depending on it. We just wanna make sure we get the convention straight. [11:36:59] petersendidit: i can do it [11:37:10] petersendidit: i need to make some much bigger changes in there any way [11:37:14] ok [11:37:27] to implement updates of classes via setOption [11:37:46] cool [11:37:48] arschmitz: So, I thought we decided to continue to handle theme-related options the same was as now. [11:38:02] arschmitz: OK. No. Sorry. I meant **swatch** related options. [11:38:04] gabriel_schulhof: no [11:38:09] swatch yes theme no [11:38:40] arschmitz: ui-shadow and ui-corners and ui-inset (which is currently still separately ui-listview-inset and ui-collapsible-inset) are now values of the class keys. [11:38:49] I mean ui-corner-all [11:39:01] yes [11:39:14] arschmitz: Yeah, that's done for collapsible and popup. [11:39:42] gabriel_schulhof: ok [11:39:43] arschmitz: When I started doing page.dialog though, boy did I get mired. [11:40:03] page and page.dialog are laden with deprecated stuff that's just in the way. [11:40:07] gabriel_schulhof: cgack: all the current classes prs will need updates once changes land in ui [11:40:22] we will need to handle classes updates in setOption [11:40:32] arschmitz: Wait wait wait. [11:40:39] All we need is to provide buy-in, right? [11:40:46] gabriel_schulhof: most likely [11:40:51] but the buy in is to handle them [11:40:55] so its the same thing] [11:41:32] cool, I'll be ready to give it a go once the changes land [11:41:37] OK, so you're not going to go with the extension point that provides a jQuery object given a class key? [11:41:58] gabriel_schulhof: it will probably be ver similar to what you suggested [11:42:44] arschmitz: OK, that's good, because in that case we need to do very little actual class manipulation, because the factory can take care of all that. We only need to give the factory a hand with identifying the targets of the class manipulation. [11:42:56] gabriel_schulhof: yes [11:43:10] Awesome! [11:43:25] Oh, and I can't wait to see the new autoinit drop into place! [11:43:50] yeah its basicly done just need to drop it into a pr and add all the deprecated stuff back in [11:45:03] gabriel_schulhof: whats going on with table pr? [11:45:18] gabriel_schulhof: did frequent ever talk to you about it? [11:45:19] arschmitz: Would it be worth doing a $.fn.enhanceWithin = ( function( original ) { return function() { /* do all the deprecated stuff */ }})( $.fn.enhanceWithin )? [11:45:31] gabriel_schulhof: i dont think so [11:45:38] arschmitz: ... and having a separate backcompat module we can later drop? [11:45:47] gabriel_schulhof: its like 2 lines [11:45:54] much of it was deprecated in 1.4 [11:46:04] arschmitz: OK. Good. [11:46:15] its just like nojs and keepnative i think left [11:46:32] arschmitz: keepNative is not deprecated? [11:46:41] no i dont think so [11:46:45] it will be in 1.5 [11:46:45] Wha ... ? [11:47:13] nopt its not [11:48:01] The comments in the code say deprecated in 1.4 remove in 1.5 ... [11:48:05] oh and degrade inputs too [11:48:16] we moved where it was stored [11:48:20] we deprecated on page [11:48:27] and moved to $.mobile [11:49:30] OK. This is complicated. [11:49:49] gabriel_schulhof: it is currently moving to $.mobile made it pretty simple [11:49:52] now its deprecated [11:49:52] I need to either separate the page.dialog classes PR into two PRs, or have a PR that does two things. [11:50:21] ... because it does two things: Add classes option and remove the dialog widget from **everywhere**, including nav. [11:50:35] Like, dialogHashKey and all that jazz. [11:50:45] gabriel_schulhof: those should be seperate [11:51:11] classes has nothing to do with dialog deprecation [11:51:19] dialog deprecation should be on master too [11:51:34] no deprecation but removal [11:52:29] arschmitz: Well, yes and no, because the class names belong to the dialog widget, and the CSS file needs to change to use the new class names (ui-page-dialog, and ui-page-dialog-contain) for consistency, and the CSS file itself should be renamed to reflect the fact that it belongs to page.dialog, and not dialog, so it kinda sequays into removal. [11:53:06] does not sound to me like any of that has to do with classes option [11:54:10] arschmitz: OK, how about I make a deprecation PR, and put the classes PR on top of that? [11:54:36] No. That's bad. [11:55:00] I'll put the classes PR on top of ui-1-12, and the removal PR on top of master. [11:55:23] do a removal pr on master [11:55:28] yea that [11:55:31] Then I'll have to rebase at least one of them, depending on which lands first. [11:55:37] and i will rebase master [11:55:46] onto ui-1-12 [11:55:58] which will likely happen a few times [11:56:16] Wait, no, the other way around. You'll rebase ui-1-12 onto master. [11:56:29] yeah sorry [11:57:19] arschmitz: As for table, please just give it a round of review. [11:57:33] gabriel_schulhof: sure [11:59:09] gabriel whats this about data-rel="transient" [11:59:45] arschmitz: A widget-agnostic way of doing dialog-state-like URLs. [12:00:03] arschmitz: You replaceState the URL with itself after creating a new history entry. [12:00:30] So, you can't deepLink, but you still have a history entry, and the popstate data tells you to skip over it during back/forward navigation. [12:00:46] gabriel_schulhof: this is basicly changehash false on the link more or less? [12:00:47] It's basically dialogHashKey done right. [12:00:48] oh ok [12:01:00] we can think about it when we look into nav more [12:01:06] in 1.6 [12:01:57] arschmitz: Well, I kinda wanna do it for the selectmenu and popup. I played around with it today, and it can be done with few modifications, because nav is already in pretty good shape for it. [12:02:07] But, of course, it's nav, so it needs a thorough looking at. [12:02:31] I guess it probably won't make it for 1.5 even if I did write it, because we have so much other stuff to line up. [12:02:50] gabriel_schulhof: i dont think we will be doing any real nav stuff in 1.5 [12:02:59] arschmitz: Oh, the crucial thing: This would be done via data-rel="transient" on the anchor. [12:03:27] Which is great, because we now have data-rel="dialog" and data-rel="popup", which is bad, because they both really mean data-rel="transient" [12:03:48] data-**role** should be equal to "widgetname", not data-rel. [12:04:23] Worse yet, in nav, we store the value as data-rel in a setting key called "role", confusing matters further. [12:04:33] gabriel_schulhof: no [12:04:47] gabriel_schulhof: both of those will be done through widget hooks in nav in future [12:04:53] we have talked about this quite a bit [12:05:13] So, if data-role tells nav which widget we're talking about, what does data-rel tell it? [12:06:34] data-role does not tell nave anything [12:06:36] nav [12:06:45] datarole is for initalizing a widget [12:07:04] OK. [12:07:05] Right. [12:07:10] data-rel is to give a relationship between the link and something else [12:08:02] arschmitz: OK, so just to get it straight in my head, give me examples of future values data-rel might take on. [12:08:32] data-rel="popup" [12:08:35] same as no [12:08:57] will mean when the link is clicked call the popupwidget on the target with the open method [12:09:08] and close on back with close method [12:09:14] OK. I had forgotten that we're gonna go via data-rel. [12:09:47] there will be also 2 new data- options for calling something besides open and close if need be [12:10:30] arschmitz: OK, and how are we going to do the actual navigating? Will we set the hash to the ID of the widget all the time? [12:10:45] ... or to the path of the external page like we do now? [12:11:00] Disregarding pushState here entirely, because that's purely cosmetic. [12:11:22] gabriel_schulhof: actually we will seperate push and hash like it should be [12:11:28] since we dont support ios4 anymore [12:11:36] arschmitz: Right, I know. [12:12:08] What I'm asking is, regardless of whether we use push or hash, how are we going to get the browser to create a new history entry? By using the hash like we do now? [12:12:11] so we wont change the url at all for push state we will just push the same state [12:12:19] OK. [12:12:20] Right. [12:13:03] for hash we will have to do something like we do now not sure exactly what it will look like since we have not done it yet [12:13:49] For hash we have no choice but to continue as we do now. Things will appear to be deep-linkable, but the deep links will not work, because the corresponding IDs will be hidden or detached. [12:14:26] ok we are running late [12:14:31] does any one have anything else? [12:14:55] OK. Let's move to -dev ... [12:15:33] anything from the community [12:16:11] ok see everyone back on -dev [12:16:16] later [12:16:24] L8R