[11:02:47] <_nickel> I'm here! [11:02:55] <_nickel> as though anyone cared :D [11:03:00] heh [11:03:14] hiya [11:03:44] hi all [11:03:59] The jQuery Mobile team meeting is starting now [11:04:41] I need to keep this shorter today [11:04:56] so we can just do a rundown and discuss any open issues [11:05:05] hey [11:05:06] scottjehl is coming [11:05:11] speak of the devil [11:05:19] ok, who wants to go first? [11:05:48] since everyone's jumping ... I'll go [11:05:49] :-) [11:05:55] transitions [11:06:08] We have it working on the transitions branch [11:06:18] feedback (from you guys) seems to be positive [11:06:26] when should we land? [11:06:50] I've been trying to think about how to unit test the thing, I've only thought up 2 scenarios we need to test for [11:06:54] nao [11:06:56] i didn't do a full test sweep, but i'm guessing you've been testing a pretty wide range of devices kin? [11:07:08] specifically when the "to" or "from" have no transition [11:07:34] based on the tests of the transition vs. keyframe in isolation, I'm not too worried about this being less smooth [11:07:37] toddparker: if wide variety means Android 2.1, 2.2, 3.1, iOS 4.3. (iPad/iPod) [11:07:46] and Blackberry OS6 (Torch) [11:07:59] so looks like you need me to test on WebOS, Nokia, WP7 [11:08:02] and BB [11:08:02] I only have 4 Android devices, one being a Xoom [11:08:20] ...on the ones you tests, are we at least at parity? [11:08:21] toddparker: yeah I don't have any Symbian, windows or WebOS [11:08:38] toddparker: yes, I sent out that matrix the other day to mention what I see [11:08:45] right [11:08:49] animations are still slooooow on Android [11:08:55] you can see frames dropping [11:09:08] ok, let me do some testing tomorrow early and make a call [11:09:11] but in standalone test cases, transitions really do seem to be faster/smoother than keyframes [11:09:14] Android is a hot mess [11:09:20] <_nickel> fact [11:09:21] red-hot [11:09:38] our original WebOS Pre is so much more responsive than any Android device I've used [11:09:50] The Nexus S is disappointing [11:10:14] So other than testing on devices, is there anything outstanding on this? [11:10:45] toddparker: just the unit tests I mentioned above. I need to talk to _nickel about that [11:11:05] toddparker: this stuff is mostly visual so all i can really test for [11:11:06] ok [11:11:14] is that the pages switched in those 2 cases [11:11:18] seems like this is very close then [11:11:25] yeah [11:11:27] thanks kinblas! [11:11:31] I guess all you can test is that the right classes are added/removed [11:11:34] Other than that, I've been looking at bugs on my plate [11:11:40] ok, cool [11:11:51] i've been doing a lot of assigning as I triage [11:11:53] gseguin: right, that was part of the page switching test [11:12:02] feel free to re-assign if you don't want an issue [11:12:21] kin, you wanted to talk about the dom cleanup [11:12:38] toddparker: eh, I guess it isn't as bad as it seems [11:12:46] was looking through bugs [11:12:55] do you want to assign all the related issues to you and get em [11:13:20] sure [11:13:21] <_nickel> kinblas: are you talking about DOM caching bugs? [11:13:27] _nickel: yeah [11:13:50] I was seeing things fly by that I thought were related [11:13:50] there is certainly some confusion about how ti works [11:13:50] <_nickel> other than the one you mentioned earlier toddparker, how many are outstanding? [11:14:03] dunno for sure. kin said he saw a few others [11:14:12] I think it's what todd said [11:14:17] folks are still getting used to how things work [11:14:24] that's for sure [11:14:25] <_nickel> the one earlier is a case where I would tell him to use the anchor [11:14:33] i think this is related... [11:14:34] that coupled with the way the widgets are being initialized now [11:14:35] https://github.com/jquery/jquery-mobile/issues/2258#issuecomment-1783815 [11:14:39] <_nickel> unless he wants to load the page dynamically [11:14:53] the appends a second copy of the starting page [11:14:56] issue [11:15:14] <_nickel> I think the homepage as a special case would be one major source of confusion [11:15:28] _nickel: right [11:15:30] <_nickel> you have to use different forms of reference depending on if you want it to be dynamic or static [11:15:40] well, i think it makes sense that we only nuke pages ADDED to the dom via ajax [11:15:54] the original page, whatever it is, is left alone [11:15:54] _nickel: when working on the nav re-factor [11:16:12] it seems to me that external pages should refer to the first-page [11:16:17] as a deep-link [11:16:25] for PE purposes [11:16:36] <_nickel> PE? [11:16:44] Progressive Enhancement [11:16:59] or Pork Enchiladas [11:17:05] lol [11:17:17] I think I prefer the latter [11:17:23] we're already resolving relative links relative to the base of the page [11:17:32] <_nickel> right [11:17:43] back buttons on those pages shouldn't be any different [11:18:12] so right now, if you ajax in a page, it doesn't know to go back to the original page in the dom so it asks for the same page again? [11:18:15] <_nickel> you're saying its confusing to reference something as an anchor because relatively speaking it means something different [11:19:03] <_nickel> /my/page/ -> #foo-bar-baz is different from #foo-bar-quz -> #foo-bar-baz [11:19:06] _nickel: I'm not sure I parsed that correctly [11:19:12] I'm saying [11:19:18] if page a is the application page [11:19:25] and b has a link in it [11:19:34] [11:19:49] it should be referencing a #foo *inside* b not a [11:19:57] so that URL should be b#foo [11:20:02] right [11:20:11] if folks want to go to a page in 'a' [11:20:15] so now, #foo refers to the first page? [11:20:21] it should be [11:20:43] i think whatever we can do to make linking to internal pages easier, taht wouldbe appreciated [11:21:00] <_nickel> so whats the short term solution [11:21:08] <_nickel> to reap the home page? [11:21:09] people also ask a lot to link to #bar in an external multipage [11:21:25] i think that could be too much [11:21:49] <_nickel> yah I would avoid adding that wrinkle at this stage [11:21:58] it would fix the issue, but it's not consistent with our rule of only nuking pages added [11:22:17] i can see a lot of issues fromt hat [11:22:54] when a page is brought in, can we check links to see if they would go to the parent (original) page and point to that? [11:23:08] lookup in the page dtack [11:23:12] stack [11:23:33] <_nickel> but what if someone wants to dynamically reload that page [11:23:33] hey kinblas [11:23:42] <_nickel> technically the home page was loaded via ajax :D [11:23:42] sorry, my client freaked out [11:23:42] did you miss the last few messages [11:23:52] yeah I missed a bunch [11:24:04] still talking about 2285? [11:24:11] <_nickel> we're just trying to sort out the quick solution to fixing the home page issue [11:24:28] so a couple of issues [11:24:28] _nickel asked if we should nuke hte start page. i said it seemed to dangerous and inconsistent with our rule to only nuke appended pages [11:24:31] <_nickel> and I'm making the case the the first page load is dynamic in that it comes from the server [11:24:54] well, the first page isn't ajax'ed in [11:24:58] I think what we need to do is this [11:24:59] it's a full page [11:25:15] the first-page doesn't necessarily have an id [11:25:26] so it's data-url is blank most of the time [11:25:38] <_nickel> so what I'm saying is that we have a url for it [11:25:42] <_nickel> and it is loaded from the server [11:25:53] <_nickel> so you can actually think of it like ajax if you like [11:25:54] we do have an url for it [11:25:59] it's the base url [11:26:02] <_nickel> :D [11:26:03] or the page url [11:26:15] <_nickel> so we could "replace" it [11:26:19] <_nickel> or [11:26:22] <_nickel> reap and reload [11:26:29] <_nickel> either way [11:26:32] <_nickel> its the same thing [11:26:33] what's the purpose in re-loading? [11:26:36] why can't we just tag it [11:26:40] yeah [11:26:48] data-url="{page-url}" [11:26:52] <_nickel> people defining links expect ajax loading [11:26:57] <_nickel> to my understanding [11:27:15] <_nickel> and in that case how do you get dynamic content from the home page without a page flash? [11:27:35] <_nickel> what if the home page isn't actually a "home page" per-se but just the page the user happens to land on [11:27:44] <_nickel> in the middle of some flow [11:28:05] wouldn't what kin suggested work [11:28:24] <_nickel> I thought kinblas was suggesting we just tag and transition back to the existing dom element [11:28:25] that would pick up the initial page, right? [11:28:39] _nickel: right [11:28:40] i think he's just saying we add the attr [11:28:41] <_nickel> I'm suggesting that people might want the homepage content to reload [11:29:15] <_nickel> something to think about even if we don't support it [11:29:20] yeah [11:29:22] <_nickel> *support it now [11:29:24] could they just set the dom-cache attr to make that happen? [11:29:30] <_nickel> toddparker: yes! [11:29:34] <_nickel> but we'd have to reap it :D [11:29:39] <_nickel> thus [11:29:40] i dunno if it works like that now [11:29:46] we need to be careful here [11:29:48] <_nickel> reap and relaod [11:29:50] <_nickel> or "replace" [11:29:52] the framework tracks the first-page [11:29:53] <_nickel> kinblas: true [11:30:01] <_nickel> alright [11:30:04] <_nickel> clearly thats a feature [11:30:12] seems like we should discuss in depth on -dev [11:30:15] and uses that as a fallback in cases where things fail [11:30:16] <_nickel> so should we just address the current state which is a non dynamic home page [11:30:24] yeah [11:30:27] yeah [11:30:30] <_nickel> sorry [11:30:31] <_nickel> tangent [11:30:35] <_nickel> tabled! [11:30:40] k :) [11:30:43] soooo [11:30:43] _nickel: no it's a valid usecase [11:30:49] _nickel...wassup? [11:30:58] <_nickel> toddparker: just saying we can tabled it :D [11:31:12] <_nickel> s/tabled/table/ [11:31:53] sure [11:32:04] sorry, was asking what you're up to _nickel [11:32:08] <_nickel> ah! [11:32:09] <_nickel> ok [11:32:09] (if kinblas is done) [11:32:14] <_nickel> the refactor landed [11:32:20] <_nickel> I closed a bunch of pull requests [11:32:33] <_nickel> as in I merged them or closed them [11:32:33] <_nickel> https://github.com/jquery/jquery-mobile/pull/1765 [11:32:38] toddparker: done ... just wanted to mention the other issue I'm looking into is the stray clicks over inputs [11:32:59] cool [11:33:22] i saw those pulls - thanks so much! [11:33:33] <_nickel> toddparker: that one needs your eyeballs [11:33:49] <_nickel> I'm going to work on getting a CI server set up on Adobe hardware today / tomorrow [11:33:59] ok [11:34:01] <_nickel> unless the pushstate branch is in dire need of testing/review [11:34:06] <_nickel> that was the next thing on my list [11:34:16] that would be cool to land sooner rather than later [11:34:23] <_nickel> hmm [11:34:32] <_nickel> I'm not totally certain the CI server at OL is still working properly [11:34:38] actually, you can wait on that [11:34:42] <_nickel> no one is watching it since I left I think [11:34:46] scott has a few things to do first [11:34:50] <_nickel> kk [11:34:53] <_nickel> then CI server it is [11:34:59] gseguin? [11:35:01] <_nickel> I'm going to automate that install [11:35:04] regarding pushState [11:35:06] <_nickel> sorry one quick question [11:35:21] been working on small bugs [11:35:24] <_nickel> I'm going to automate the install, and we should post the code for the project somewhere [11:35:27] and a bigger one: https://github.com/jquery/jquery-mobile/pull/2262 [11:35:28] <_nickel> any thoughts? [11:35:36] <_nickel> actually we can talk about that in dev [11:35:39] I wanted to chat with scott/_nickel regarding a way to implement it in a way that devs can also use the same mechanism to update the URL and decode it [11:35:39] * _nickel falls silent [11:35:48] going to land that today after a small refactor [11:36:10] go ahead _nickel, I was typing away [11:36:18] <_nickel> nope it can wait [11:36:19] oh ok [11:36:51] yeah that's pretty much it for me, going down the list of unassigned "critical" bugs [11:36:57] and see if I can address them [11:37:00] cool, thanks! [11:37:09] i tagged a bunh of issues to you too [11:37:15] everyone has a bug old pile now [11:37:32] oh! [11:37:36] one more thing [11:37:38] scott is looking at pushState [11:38:03] Packt Pub contacted me, they're looking for an author for a "jQuery Mobile Cookbook" [11:38:13] right, saw that [11:38:24] they have a bunch of jQM books out an in the wings [11:38:45] I don't feel like I have acquired enough knowledge to take up the task, nor do I think I have the skills and time [11:38:59] but if one of you is interested, I would love to help out [11:39:08] if you guys are more interested in helping to tech edit/refine a book, we can dicsuss that [11:39:13] <_nickel> now that I'm thinking about it a "cookbook" should be done by someone who's using it all day every day [11:39:21] there is an author who wrote a 4-500 page jQM book [11:39:26] <_nickel> yah that guy [11:39:29] <_nickel> he was tweeting [11:39:37] name? [11:39:40] but he's french so it needs a english speaker and tech refiner [11:39:47] hmm [11:39:49] Eric [11:39:54] that sounds like a job for me [11:39:56] Sarron? [11:39:56] :D [11:40:02] yeah, right! [11:40:27] <_nickel> like Yogg Sarron? [11:40:37] he offered to donate the book to the project [11:40:38] <_nickel> http://www.wowwiki.com/Yogg-Saron [11:40:40] who dat? [11:40:50] woah [11:40:51] * _nickel is far nerdier than you could possibly imagine [11:40:56] nerd alert! [11:40:58] yup [11:41:10] where is the weggie command on IRC [11:41:12] <_nickel> If I haven't already I will bring my D&D references [11:41:22] <_nickel> toddparker: you know I could bench press you :D [11:41:30] oh, i kno wit [11:41:34] <_nickel> lol [11:41:41] <_nickel> [11:41:42] scared [11:41:55] alright if you have his info and need me to do something on that front let me know [11:42:26] what's his twitter handle? [11:44:32] not sure [11:44:34] been emailing [11:44:48] ok, we can take that offline [11:44:49] btw - if you guys want to write a book, go for it [11:44:54] didn't mean to derail ya [11:44:55] sure [11:45:02] ok, i think that's it [11:45:08] <_nickel> I'm writting an expose on all the infighting we have on this project [11:45:14] * _nickel will be rich [11:45:18] i'm going to try and do more triaging and create a list of beta 3 items [11:45:28] if you all wantot tag to beta 3 in the tracker, please do [11:45:34] :) [11:45:40] yeah, let's argue! [11:47:03] ok, i think that's it [11:47:07] we'll re-connect on -dev [11:47:12] thanks all! [11:48:07] see you on -dev