[11:00:14] hi [11:00:19] Hey everyone! [11:00:20] hi [11:00:22] hey [11:00:24] <_nickel> I'm actually here on time, though my relative value for the discussion is debatable :( [11:00:31] The jQuery Mobile team meeting will start in a minute [11:00:48] woo hoo. special day, we're all here with no technical glitches [11:00:56] agenda here: https://docs.google.com/document/d/1kqZVgb9fcvv_hVWV8Vr62wgQB6sLJyDj1UDMFFiGbdA/edit [11:01:51] Note: This meeting is for core mobile team members only so please don't jump in tif that's not you. Support for mobile is available on the #jquerymobile channel [11:02:07] Ok, should we jump in? [11:02:15] * _nickel nods [11:02:24] sure [11:02:31] ok, let's see where we're at on navigation [11:02:51] decoupling & cleanup is 100% done right? [11:03:16] think so - Kin? [11:03:18] I think we still need to decouple a few more things, but for the most part [11:03:28] what we need to move forward is done [11:03:28] done enough for beta 1? [11:03:30] yeah [11:03:31] cool [11:03:45] I just meant things like decoupling hashchanges, etc [11:03:52] so folks don't need it if they don't want it [11:03:57] but that can happen much later [11:04:00] gotcha [11:04:03] makes sense [11:04:14] maybe create a new ticket for each of those so we can track [11:04:20] yeah [11:04:23] next item: [11:04:24] ok, so the improved URL handling and base href stuff [11:04:37] in a branch right now, right? [11:04:46] I was hoping to have it done today, but I'm still fixing a few things [11:05:01] and I've busted lots of the unit tests due to path utility name changes [11:05:10] I'm focused on it today [11:05:18] so hope to make some good progress today. [11:05:18] cool [11:05:24] the public branch is 'path-fixes' [11:05:30] tell everyone to leave you alone [11:05:43] so just so folks know [11:06:00] great [11:06:03] I'm trying to make it so that we can handle any relative variant, and also not drop query params [11:06:11] etc [11:06:34] right. do you need anything from us to wrap that up? [11:06:37] once I land the last of my fixes (hopefully today) I need to test things on the devices [11:06:39] <_nickel> I think thats expected by some of the integration tests currently [11:06:41] sounds about right. Once we implement pushState, that'll become even more important [11:06:44] and with phone gap where this stuff really matters [11:06:48] yeah [11:06:55] kinblas: Let me know when I can pull and test it against Jive's use case [11:07:09] i'm here if you want me to test...give send me a (short) URL and list of devices [11:07:15] gseguin: will do ... though I haven't done anything regarding URL hooks [11:07:20] it's my priority to help you out on testing [11:07:28] ok will do [11:07:46] you mean the "extensibility hooks" item in the agenda [11:08:35] is that the kind of thing where it should be tackled as a big, holistic thing or is it easy to add a hook or two now then keep adding later? [11:08:36] yeah ... hooks include allowing developers to encode/decode the urls [11:08:40] or I should format/unformat [11:08:52] ah, so you mean just for URLs [11:08:55] so for example they can stick our page hash urls in a query param [11:09:09] no other hooks include pre-processing content after its loaded [11:09:14] support for other formats like JSON [11:09:15] etc [11:09:40] folks like Jive and John R. are using JSON instead of HTML to load pages [11:09:48] gotcha. let's land the core stuff first and create a wiki/issue to track the extensibility stuff, maybe for beta 2? [11:09:51] but they're forced to tweak our source [11:09:58] yeah [11:09:59] that's bad [11:10:22] are there any low-hanging fruit things we could do shorter-term? [11:10:40] in terms of hooks? [11:10:43] well, I think John R was setting some things up on touchstart/mousedown so that the page was present when ajax ran through. Pretty cool actually [11:10:57] not modding source for it [11:11:07] but anyway... we need hooks for sure :) [11:11:12] sure do [11:11:27] scottjehl: the more examples I have the better the decisions we can make on how to structure and place hooks. [11:11:44] so yeah, i was asking if there were a few easy hooks to add this week or if this is a bigger thing that we should wait until beta 2 [11:12:11] * kinblas thinks [11:12:26] we can add a hook for post-insert of a loaded page [11:12:43] so folks can inject content or invoke their own widgets or whatever [11:12:57] we can modify loadPage to take a contentType [11:13:26] I was holding off on stuff like that till I could get a clear picture of things after the dust settled, but if someone else wants to think about and do it that's fine [11:13:43] thoughts all? [11:14:00] i think we should probably wait til beta 2 [11:14:03] <_nickel> Anyone have docs or information on the best way to provide hooks? [11:14:09] <_nickel> out of curiousity [11:14:12] i'd rather get beta 1 out sooner and with fewer bugs [11:14:14] Kin, doesn't that pre-insert hook need to take place before ajax even goes out? [11:14:35] <_nickel> before kin put his changepage hook in I was looking at the namespaced events provided by jquery but I haven't any idea what the issues involved might be [11:14:39] (we can discuss later) [11:14:41] this is why I was wanting to wait [11:14:44] think so [11:14:45] in theory what we want to do is [11:15:04] give folks a chance to catch the raw data returned from the server so they can munge it [11:15:25] there's also the phase where that resulting HTML data should be turned into a DOM [11:15:29] ...or generate pages on the fly from data already in JS? [11:15:37] so we need a hook to allow them to do stuff before/after enhance [11:15:42] lots of possible scenarios [11:15:44] right [11:15:47] toddparker: right [11:15:58] that was the other thing i mentioned a while back [11:16:07] was the idea of setting up loadHandlers [11:16:10] based on content type [11:16:17] yeah. let's wait and do some thinking on this [11:16:17] yeah... they might have a JSON store for the whole app up front [11:16:22] cool sounds good [11:16:27] moving on... [11:16:28] some loadHandlers will use ajax, others just build from data structures in memory [11:16:29] Page caching on/off flag (Steven) - BETA 1 [11:16:29] Add a simple "don't cache" flag per page via a new data-cache attribute on the page div to tell framework to re-load it if shown again, default is “true” (re-use the page) but you can set data-cache="false" to tell the framework to re-load everytime it’s viewed [11:16:30] Issue: https://github.com/jquery/jquery-mobile/issues/1554 [11:16:42] stevenblack has a pull for this i believe [11:16:50] kinblas - exactly [11:17:03] He has a pull for the basic utility for removing pages from the DOM [11:17:09] I think he closed all his pull requests [11:17:12] first question: critical for beta 1 or add it in beta 2 [11:17:20] did he? [11:17:31] it wasn't hard [11:17:34] we can add this one pretty easily [11:17:39] you just look for the element by selector [11:17:46] tomorrow maybe Kin and I can take a look [11:17:58] I'd like to start with what Steven had, if it's available, and mod what we need to [11:18:02] but either way [11:18:09] scottjehl - that would be great, esp. if you could take the lead on landing that sucker [11:18:21] it was just a selector lookup and compare against the first and last thing on the stack [11:18:24] we can check into it tomorrow when I've got time for jqm again [11:18:26] i agree with starting with steven's work [11:18:39] sure. i'm making time for you this week. [11:18:41] Kin: yeah. sounds good [11:18:51] ok, so we'll try to land this for beta 1 if we can [11:18:53] we'll get back in touch on that one [11:19:09] so the snag with the caching stuff [11:19:15] was the nested lists, according to steven [11:19:24] yeah, it's a problem [11:19:33] sure. I'm not sure of how much benefit it'll bring perf-wise, but it'll let folks hit the server when they want to [11:19:46] yeah, is that in the agenda? [11:19:49] nested lists? [11:19:59] it is...we can discuss now [11:20:00] it landed btw :-) [11:20:09] they're always going to be hash-dependent, even if pushstate is in place [11:20:09] * kinblas claps for gseguin [11:20:11] woo hoo [11:20:18] that is the ID issue, right? [11:20:19] thanks gseguin :) [11:20:19] /me blushing [11:20:43] you're welcome [11:21:07] nested lists and dialogs are the only widgets that'll require hash usage even in pushstate browsers. They'll always be JS dependent as well [11:21:08] scottjehl: so the pushstate issue has to do with the fact that it has to always pont to real content? [11:21:17] so the issue scottjehl_ is talking about is how to handle nested lists (and select menu dialogs) with Ajax off [11:21:30] well, that's one thing [11:21:48] but mainly, the nested list is in fact just an anchor reference to content within a page [11:21:57] so we can't use pushstate for that [11:21:59] needs to be # [11:22:08] right. it's like an internal page ref [11:22:21] (there's no server resource for that nested list) [11:22:24] yep. [11:22:29] on top of that it might not have a reference on it [11:22:31] so that'll mean even more forking [11:22:52] if we have pushstate, would that allow us to support # anchors again? [11:22:59] oh btw, deep linking to a nested list still doesn't work though [11:23:09] yeah? [11:23:15] <_nickel> gseguin: neither does deep linking to dialogs [11:23:16] do we have an issue for that? [11:23:23] todd: yeah but not if we ALSO still support hashchange [11:23:29] right [11:23:30] gseguin: it doesn't work in a specific case I thought [11:23:32] which I guess we will? [11:23:46] think we have to if pushstate isn't well supported [11:24:03] <_nickel> I thought the stance was that you can't deep link to dialogs [11:24:17] _nickel: right [11:24:33] that's true but they need to create a history entry [11:24:33] kinblas: I'll double check and we'll take that offline [11:24:34] think that's true [11:24:36] so that'll use # [11:25:38] ok, so moving on? [11:25:41] gseguin: I just tested it, it works, it's just the listview in the app document case. [11:25:55] if it used pushstate, it'd have to be a query string I guess. Which btw, we could still consider (we use a query param for nested lists as-is), but it seems more intrusive in non-hash urls [11:26:09] we can move on, sure [11:26:56] nested lists will be an issue if hashchange is broken too [11:27:06] anyway, we can mull that stuff over [11:27:14] kinblas - next is [11:27:21] Same-page as a navigation target (Kin) [11:27:21] Some developers are opting to repeatedly re-use the same container as a target for generated markup. Think self-referent pages as a desirable feature design-wise (Steve to elaborate). [11:27:28] That's part of the hooks discussion [11:27:37] this is part of the url extensibility stuff really [11:27:40] <_nickel> hmm [11:27:42] right, moving on... [11:27:53] the hooks we're talking about would allow you to catch a URL,map to specific page, and then modify it [11:28:00] right [11:28:03] <_nickel> same page nagivagation is dangerous unless we're dong it purely with hooks eh? [11:28:08] right [11:28:20] _nickel: yeah, it's an advanced case [11:28:24] Jive is doing this [11:28:27] a dev would need to handle all this themselves via hooks [11:28:31] <_nickel> yes [11:28:34] cool [11:28:36] <_nickel> we can't do that in a generic way [11:28:41] <_nickel> I thought long and hard about that one lol [11:28:49] heh [11:28:52] next [11:28:56] scottjehl_ [11:28:57] Page show initial focus: can we handle this better? (Scott) [11:28:57] We need to have focus brought to the top of the current page on transition for accessibility and keyboard/focus-based navigation [11:29:09] have you had a chance to think about this? [11:29:15] if not, we can move on [11:29:33] I think we should talk on this one tomorrow morning [11:29:40] but I have ideas to try out [11:29:53] named anchors for one... heh [11:29:55] ok, cool [11:30:14] next [11:30:20] kinblas [11:30:22] Transitions: how to smooth out, eliminate blinking and jumpiness (Kin) [11:30:41] there was that issue you responded to a few days ago, somewhat related [11:30:50] So someone posted a patch for switching everything over to transitions [11:30:56] *for* Android [11:31:00] meh [11:31:08] i agree with you [11:31:16] Not sure we want to support both methods. We should just use one method [11:31:27] google needs to de-crappify their browser [11:31:34] but the key thing about his patch was that he was placing a translate3d() on the body [11:31:40] great tweet about it being the IE6 of mobile browsers. so true [11:31:46] transitions would mean scraping hardware acceleration in favor of gaining some browser support? [11:31:57] that forces all rendering through the GPU pipeline, but it may have some significant memory implications [11:32:07] = crashtastic [11:32:10] heh [11:32:20] that is dangerous bizness [11:32:31] anyways, we can probably try it out with what we have, it would be a one line CSS change to try [11:32:32] think we're going to have to look at this for beta 2...sound like a plan? [11:32:39] ok, worth a shot [11:32:48] maybe scott and i can give this a test tomorrow? [11:32:53] <_nickel> can we send them a strong worded email? [11:32:57] heh [11:32:58] <_nickel> *strongly [11:33:05] like in all caps? [11:33:07] :-) [11:33:14] <_nickel> just ask nicely for anti-aliasing at least? [11:33:15] "please anti-alias your corners. kthanx." [11:33:24] <_nickel> seriously [11:33:32] <_nickel> :/ [11:33:47] <_nickel> hmm [11:33:49] <_nickel> it is open source [11:34:09] fix it _nickel! [11:34:12] <_nickel> lol [11:34:21] <_nickel> I was just thinking who I could bribe [11:34:37] _nickel: this is in refernce to gpu for transitions/animations? Or for the rounded corners? [11:34:48] <_nickel> both [11:34:49] <_nickel> sorry [11:34:53] they are working on it [11:34:59] <_nickel> I'm just whining [11:35:11] the 3d hooks are there in webkit, but every vendor needs to implement it [11:35:15] what's up next [11:35:19] self-invocation via binding to pagecreate + push/replacestate will be beta 2, right? [11:35:41] self-invoke could happen sooner [11:35:50] what does that mean? [11:35:52] some quick testing will tell us how feasible [11:35:52] :- [11:35:57] like in the next day or two? [11:36:14] that widgets init themselves by binding to pagecreate [11:36:23] let's look at the blockers first to see...i might have some stuff for you to look at :) [11:36:32] ...would be awesome tho [11:36:34] scottjehl: any chance that will get rid of the need for mobilinit? [11:36:34] and aren't called out individually in the page plugin [11:36:45] no [11:36:49] that's for globals [11:36:51] but what about if you append markup to a page? [11:37:06] needs to be a way to auto-update then, not just at pagecreate, right? [11:37:06] (and widgets of course, but mostly globals) [11:37:06] the mobileinit just feels wierd [11:37:21] the way you have to go about using live() and a callback [11:37:23] WE NEED MORE MAGIC [11:37:36] suggestions on overriding globals another way are welcome :) [11:37:53] the reason I asked about the self init thing [11:38:03] Todd, if you append an input, you can call the widget method on it, right? [11:38:09] was because I think the reason we have to do it that way is because some of the widgets initialize on JS load [11:38:16] much more efficient that way [11:38:36] think so, but people keep asking if there is a way to append a bunch of markup and say "enhancify" [11:38:56] oh yeah, pull out the magic in page() [11:38:58] basically, not need to pick through and call the refresh or plugin manually on each doodad in your markup [11:39:00] into a callable function [11:39:14] exactly. [11:39:15] the enhance magic [11:39:29] magicalUnicornRainbows() [11:39:36] heh [11:40:19] that is really the thing. people would be ok calling enhance() or whatever on their markup if it sort of worked like page where it auto-enhanced everything [11:40:19] hmm... yeah we could think about that [11:40:33] that might be even more useful [11:40:43] cool...keep mulling that over [11:40:48] that's it for nav! [11:40:55] k [11:40:59] eddiemonge - any update on the docs template? [11:41:30] bueller? [11:41:36] alrighty, moving on [11:41:52] so i started making a short list of blockers for beta 1 [11:42:04] toddparker, not yet but this week [11:42:36] cool. if you can get that set up, i bet i can get some voluteers to help us fill it out [11:42:55] so i *really* want to ship beta 1 very soon [11:42:56] there is a new milestone you can assign issues to: https://github.com/jquery/jquery-mobile/issues?sort=created&direction=desc&state=open&page=1&milestone=5 [11:43:14] let's go thru a few items, some are more questions [11:43:27] ChangePage() and Navigation paths refactor [11:43:27] https://github.com/jquery/jquery-mobile/issues/1778 [11:43:54] issue 1778 wasn't due to the refactor [11:44:14] anyways, the work I'm doing will make this consistent [11:44:25] of course that will involve lots of unit test changes :-( [11:44:48] because the unit tests rely on the old behavior (non site relative url) [11:44:54] sounds good [11:45:09] Todd: I need to duck out in 2-3 mins [11:45:20] so is this issue still kind of open [11:45:26] k [11:45:37] yeah leave 1778 open until I land [11:45:56] ok, but is should pretty much be fixed with the stuff in the branch right? [11:45:59] just an fyi, this is only a problem if you programatically call changePage() [11:46:09] these all appear to be nav items except for the radios one. I can look at that one tomorow [11:46:18] sorry guys, gotta jump off [11:46:21] thanks!! [11:46:30] toddparker: yeah it will be consistent (fixed) [11:46:30] ok, yeah those radios would be good for you to look at scott [11:46:35] cool [11:46:35] no matter how you invoke changePage() [11:46:48] Double vclick - not an issue? [11:46:49] https://github.com/jquery/jquery-mobile/issues/1787 [11:47:03] kin, you said this is probably operator error? [11:47:08] I have to get more details before I can fix anything [11:47:14] it's not happening for us? [11:47:15] :-) [11:47:26] I explained how things work in the issue but have not heard back [11:47:31] ok, moving on. we'll see if he writes back [11:47:44] iOS scroll position history broken in A4 [11:47:44] https://github.com/jquery/jquery-mobile/issues/1342 [11:47:45] Fixed? [11:48:03] hmmm that's not showing up in the list [11:48:04] for me [11:48:25] #1342? [11:48:50] i just can't tell what's up with this one [11:48:56] i'll pass this to scott [11:49:07] <_nickel> stepping out guys thanks! :D [11:49:21] that's the scrolling one? [11:49:23] thanks _nickel [11:49:26] ya [11:49:34] s'ok [11:49:42] i just send this over to scott to look at [11:49:45] well we fixed the scrolling/focus problem after A4 [11:49:51] remember that problem where things were chopped off? [11:49:57] I'm wondering if this is related [11:49:59] riiight [11:50:14] but seems like people had issues after scott's commit [11:50:21] the issue trail is kinda confusing [11:50:30] oh yeah that is [11:50:42] odd, right? [11:50:43] the quote eddie posted in that issue was me talking to him on skype [11:50:51] anyway, i'll see what scott says tomorrow [11:50:57] ok should be fixed [11:50:58] oh [11:51:07] but lets let scott confirm? [11:51:23] sure [11:51:37] so kin, the next two issues seem like they are already on your radar [11:51:38] AJAX requests broken due to incorrect host name [11:51:38] https://github.com/jquery/jquery-mobile/issues/1640 [11:51:38] Ajax in Chrome & Android [11:51:38] https://github.com/jquery/jquery-mobile/issues/1605 [11:51:59] i tagged them as b1 blockers anyway [11:52:00] yes, they should be fixed already in my branch [11:52:10] we can close a bunch of stuff when you land that stuff today/tomorrow [11:52:13] ok, cool [11:52:30] scott is going to look at those 2 radiobutton issue [11:52:43] last item i had: Change page CSS error [11:52:43] https://github.com/jquery/jquery-mobile/issues/1507 [11:52:50] I can give another look at #1507 [11:52:52] great, I haven't had the bandwidth to engage folks on that issue at all [11:53:00] gseguin - that would be great! [11:53:26] looks like the last fix failed, I'll spend some time on it after lunch [11:53:36] that's fine kin. i'd rather keep you focused on navigation. always better to have you looking at one big gnarly issue at a time [11:53:42] great [11:54:02] are there any other issues that seem really bad that we should try to fix for beta 1? [11:54:04] * kinblas puts his blinders back on [11:54:09] anything that jumps out [11:54:12] dates! [11:54:21] for the release? [11:54:31] betas and releases [11:54:38] we need to come up with some strawman dates [11:54:51] and put that against availability/projects [11:55:04] agreed. we had some already but we're already off by at least a week :0 [11:55:23] do you think we can get nav and these few items in good shape for thursday? [11:55:31] I have folks asking me internally all the time for dates [11:55:34] do you think beta 1 will happen this week? [11:55:39] if so, we can target beta 1 for friday [11:55:41] they're getting tired of me shrugging my shoulders :-P [11:55:45] same here [11:55:50] gseguin - how much time do you have this week [11:55:52] me too! [11:56:04] I have this afternoon [11:56:11] and Thursday I think [11:56:19] generally, i think beta 1 will happen this week or very early next [11:56:29] actually just half of this afternoon [11:56:40] beta 2 should happen by july 4th!!! [11:56:58] 1.0 sometime in mid august [11:57:15] I'll be back August 1st [11:57:24] looking at where we are, i think a lot of the bigger items are getting wrapped up [11:57:40] we have a ton of issues but i think i can close a lot soon [11:57:50] once we get the big stuff done [11:57:54] we can jam on the issues [11:57:59] it will be good to have a few weeks of your time before 1.0 kin [11:58:02] yeah [11:58:04] we tend to fix a lot of them when we're not distracted with big ticke items [11:58:12] i'm trying to free up some of scott's time [11:58:17] yeah [11:58:26] we've just been slammed with the globe project [11:58:32] I can imagine [11:58:35] gots to feed the kids [11:58:46] yep. gots to deliver the e-newspaper [11:58:49] heh [11:59:03] so let's all try to crank the next 2 days [11:59:13] scott will be on this tomorrow for sure too [12:00:03] the nav changes are the only big ticket item right now [12:00:08] the other issues are pretty small [12:00:15] and it seems like you're close [12:00:21] yeah [12:00:23] so let's just push hard for friday [12:00:33] ok, then I'm going to get back to work :-P [12:01:33] toddparker: I think I tagged all of the blockers with my name (minus the css ones) [12:01:53] I think we'll be able to close all of them soon. [12:02:20] Any other issues? [12:03:39] not that i can see, but i'll comb though the issues to see if there are any baddies we should close for beta 1 [12:03:49] thanks all...back to work! [12:03:50] ok [12:03:57] ok