[02:01:38] hello can you hear me [02:02:25] somebody here [11:03:09] Ok, fixed [11:03:19] The JQuery Team meeting is starting [11:03:25] chime in if you're here [11:03:32] hi [11:03:36] chime [11:04:09] hey [11:04:13] hey buys [11:04:16] guys [11:04:23] eating and typing = bad thing [11:04:50] is _nickel around? [11:05:13] looks like _nickel is away, I just pinged him on -dev [11:05:18] k [11:05:26] so gseguin, you had a question [11:05:27] question was around that commit: https://github.com/jquery/jquery-mobile/commit/a620d97868844f8f5b0721bc07d24f415d66ed1c [11:05:28] ★ Commit on jquery-mobile by gseguin (22h, 56m ago): Re-uses the boolean create at creation time to let the refresh functions know that they've been called by create [11:05:36] i think this is a good scottjehl q [11:05:50] looking [11:06:05] wow like the socialhapy bot [11:06:36] what's that? [11:06:55] when you posted the github url [11:07:14] socialhapy happy grabbed the description of the commit and posted it [11:07:23] yeah... [11:07:26] cool [11:07:28] it takes pulls and issues too [11:07:29] https://github.com/jquery/jquery-mobile/pull/2298 [11:07:29] ★ Pull request on jquery-mobile by h-andreas (11h, 31m ago): More options for selectmenus [11:07:33] oh, i see now [11:07:38] so the question on that commit? [11:07:39] very nice! [11:07:48] can we have socialhapy on -dev? [11:08:01] dunno who sets that up [11:08:16] me [11:08:21] gseguin: he's in #jquery-dev already [11:08:24] oh goodie! [11:08:29] scottjehl [11:08:30] the create flag was not being sent to refresh at create time [11:08:30] and I was wondering if you had any idea why [11:08:35] jquerymobile-dev I meant [11:08:57] yeah back to that [11:09:09] hmm no not sure why [11:09:26] scottjehl: ok that's fine [11:09:34] so adding it is ok? [11:09:46] scottjehl: re-using it solved pretty much all my problems [11:09:52] think so? if it tests out, it makes sense to me [11:10:01] cool [11:10:10] just wanted to close that one out from earlier [11:10:26] ok, so kinblas seems like the new transitions are pretty close now [11:10:35] * kinblas grumbles [11:10:38] I was playing with it lastnight [11:10:40] now that we understand the case of those darn properties [11:10:44] and noticed that on iPad [11:10:54] there is a flash on reverse transitions [11:11:02] where the 'to' page [11:11:05] doesn't animate [11:11:09] so things like [11:11:15] slideup, slidedown, and pop [11:11:17] are affected [11:11:21] a flas instead of a transition or after the transition finishes? [11:11:24] I'm currently trying to figure out why [11:11:42] it's as if as soon as we add the classes to start the transition, the 'to' page flashes to the top [11:11:44] 4.2? [11:11:46] and then goes where it should [11:11:46] 3.2? [11:11:53] 4.3.5 [11:12:11] top as in z-index [11:12:22] toddparker: you beat me to it [11:12:33] or scroll position [11:12:33] yeah that's all set up [11:12:47] ? [11:12:48] anyways, I'm playing with it now [11:12:51] ok [11:12:54] to see if I cna fix it [11:13:02] I've spent the last few days ... of spare time [11:13:04] and you're pulling opera out [11:13:09] trying to fix up the transition tests [11:13:11] * _nickel is here [11:13:12] so we just have webkit, moz [11:13:22] are we doing non-prefixed too? [11:13:30] hey _nickel [11:13:45] oh, we nee dto pull the -o rules from the transition CSS [11:13:50] I'll comment them out [11:13:59] btw, have you seen the latest opera mobile? [11:13:59] think so, right ghislain? [11:14:05] It always uses a slide transition [11:14:08] between pages [11:14:11] opera? [11:14:11] yes [11:14:17] mobile? [11:14:19] it was a bit disorienting for me at first [11:14:24] because I thought it was us [11:14:24] mini slides [11:14:28] but then I went to other sites [11:14:31] what? havent's tried latest version [11:14:33] <_nickel> kinblas: can we just remove them? I'm against commenting out when we have scm :( [11:14:38] * _nickel is nitpicking [11:14:43] what's scm? [11:14:49] <_nickel> source control management [11:14:52] oh heh [11:14:56] what's that ;) [11:15:00] <_nickel> toddparker: :D [11:15:05] no problemo not a big deal [11:15:13] so nix the rules [11:15:20] was thinking it was documentation to show folks we are aware they exist [11:15:33] I'll remove [11:15:37] miketaylr will give us a heads up when opera releases a version with better transitions and we'll add them right in [11:15:48] yep [11:16:10] miketaylr - desktop opera supports these now, but the issue is that is kills perf on mobile, right? [11:16:13] so question about opera mobile [11:16:20] so we need to nix opera transitions across the board [11:16:20] essentially, toddparker [11:16:33] for the transitions, yes [11:16:39] just making sure i'm square on this stuff [11:16:44] thanks miketaylr [11:16:48] np [11:16:57] so for opera mobile, we disable ajax too? [11:17:01] shoot kinblas, while we have miketaylr here [11:17:18] that is, we're doing it for both mini and mobile? [11:17:30] er ... we're disabling ajax for both mini and mobile? [11:17:34] mini is opted out of the the ajax nav [11:17:40] so transitions are moot [11:17:45] what about mobile [11:17:54] mobile is a full browser so it gets the ajax nav and transitions [11:18:00] mobile does AJAX or pushState just fine [11:18:06] but perf is not up to snuff [11:18:07] hmmm ok, it seemed to be loading new pages [11:18:14] hence the discovery of slidig [11:18:17] sliding it does [11:18:24] mobile? [11:18:26] yeah [11:18:32] have a test page? [11:18:38] I think Mobile is opted into the ajax nav [11:18:40] I'll try it again ... make sure I wasn't on crack [11:18:53] ok [11:18:56] miketaylr: I was using jqm docs [11:18:58] you can ping me at miket@opera.com if you need some help kinblas [11:18:59] put down that pipe [11:19:02] or (it passes the media query test) [11:19:06] miketaylr: ok thanks [11:19:36] so the net of all this transition work is that things pretty much look the same as they do now with keyframes [11:19:44] lol [11:19:50] tho it gives us the ability to easily add other platforms [11:19:59] like FF and Oera [11:20:01] yeah, I'm worried about perception [11:20:11] there are still browser bugs related to all this stuff [11:20:16] a little less code weight too right? keyframes are more verbose? [11:20:19] tho FF mobile doesn't seem to support this *yet*, only desktop 5+ me thinks [11:20:26] so the expectation that switching was going to solve everything is wrong [11:20:31] yeah [11:20:51] you can blame me if it ever comes up ^_^ [11:20:51] if things are HW accelerated, that solves the issue. but most aren't yet [11:20:55] heh [11:20:55] smaller CSS ... but more code ... and timers (yuck!) to manage the start of the animations [11:21:11] IT'S ALL MIKETAYLR'S FAULT [11:21:16] I feel better now [11:21:26] that's basically a keynote right there [11:21:26] miketaylr: blame for what? [11:21:40] kinblas: whatever you'd like :P [11:21:41] well keyframes or not, we're going to get scroll-jumping on any browser that doesn't support scrolling-overflow:touch anyway. (once we implement that, at least) [11:21:44] do we know of any improvements in quality or compatibility on this switch? [11:21:58] miketaylr - any plans to support that in Opera? [11:22:03] (not second guessing, thinking about the blog post) [11:22:10] for what it's worth, transitions are a bit faster on Android, but I think that's mainly due to the fact that it doesn't have to look things up in the CSS keyframe rules every iteration [11:22:12] scrolling-overflow? i can find out [11:22:13] * scottjehl hopes [11:22:55] miketaylr - also ask if they are going to couple that with that [roperty above. that is essential. [11:23:37] with which property? [11:23:45] we're likely going to base our truly fixed toolbars on that property's existence [11:23:49] sorry, scrolling-overflow plus overflow [11:23:52] -webkit-scrolling-overflow: touch [11:23:54] (sorry, haven't been following) [11:23:54] the former is the key part [11:24:01] got it [11:24:02] (not just webkit) [11:24:09] well, currently it's only ios5 [11:24:21] but we'd write tests for all vendors [11:24:25] but we hope everyone follows this model [11:24:42] it will get you true fixed toolbars and silky transitions [11:25:13] so kinblas - do you know when this may land? [11:25:52] toddparker: well I was sort of waiting to hear the verdict from you on WebOS, WP7, and Symbian ... and then of course there's the 'reverse' problem I'm looking into at the moment [11:26:05] I got the unit tests green btw on the branch [11:26:15] oh, did you miss my test results on Friday? [11:26:19] but that's not testing visual aspects, just mechanics [11:26:21] those are all at parity [11:26:31] they look good [11:26:32] oh I didn't see a reply [11:26:45] or I saw something but I thought it was dated during July [11:26:50] i did it here on IRC in -dev,sorry email would have been better [11:26:50] when I was out [11:26:54] heh [11:26:56] oh then I missed it [11:27:07] just an FYI, i've been *VERY* distracted by a couple of things internally [11:27:12] nope. i did a full batch of testing last week on your branch [11:27:13] no red flags [11:27:30] ok I'll look for the email [11:27:30] my bad, sorry [11:27:37] IRC is not a good medium for that stuff [11:27:42] I havne't really touched the CSS/js part of the transitions stuff since last week [11:27:55] so things should still be the same as when you tested [11:28:10] anyways, my concern at the moment is iPad/reverse [11:28:14] I'll get back to you today on that [11:28:22] Do you need an email from me? I can tell you that all on our test devices, things seemed at least at party with /test/ [11:28:29] lol [11:28:29] ok, cool [11:28:31] yes Please [11:28:41] I'm suffering from scatter-brain-syndrome [11:28:44] just listing what i tested [11:28:50] * kinblas has a finger in too many pies at the moment [11:28:52] k [11:29:05] so _nickel - what are you up to now? [11:29:15] I've been assgning select issues to you BTW [11:29:18] <_nickel> replacestate [11:29:23] <_nickel> yah I've seen those [11:29:26] awesome. [11:29:29] how's that goin [11:29:31] kinblas: I have iOS 5 on an iPad2 here if needed [11:29:34] <_nickel> pretty well [11:29:39] <_nickel> I have one more bug to work out [11:29:43] <_nickel> but the tests are proving to be a bitch [11:29:45] I saw you mentioned the double dialogs [11:29:51] good catch [11:30:05] <_nickel> yah Kins work in nav handled all of that [11:30:20] <_nickel> the one left is the initial hash [11:30:27] <_nickel> doesn't seem to work [11:30:34] man, we should have a light version of this that doesn't make exceptions for multi-page, dialogs, nested lists. much simpler [11:30:53] sorry, tangent [11:30:54] <_nickel> the tests are really difficult though [11:31:01] initial hash - is that the thing I pointed out? [11:31:04] <_nickel> all thats left is the main nav tests [11:31:07] <_nickel> everything else passes [11:31:10] <_nickel> scottjehl: not sure [11:31:11] no forward button in Chrome [11:31:20] <_nickel> I don't know if its related [11:31:23] when you back up to the first page [11:31:25] k [11:31:35] <_nickel> when I go to the docs and I enter something like [11:31:48] oh I remember mentioning a chrome bug related to history [11:31:48] <_nickel> domain.com/#/foo/bar/baz.html [11:32:00] in an issue a while back [11:32:05] <_nickel> resuls in just the page at domain.com/ [11:32:08] <_nickel> *results [11:32:24] k [11:32:37] that's odd [11:32:48] what is the bug? [11:32:49] so anything on a root domain or what? [11:32:58] <_nickel> scottjehl: I have no idea [11:33:02] <_nickel> haven't tested it extesively [11:33:06] <_nickel> *extensively [11:33:12] <_nickel> BUT [11:33:19] k. [11:33:28] <_nickel> there is one other thing that ties in here [11:33:41] <_nickel> that I talked with kin and gseguin about this morning [11:33:48] <_nickel> that is browser state in the tests [11:34:26] <_nickel> so much pain in trying to get the tests to work with both pushstate and hash [11:34:32] <_nickel> because of the page state etc [11:34:35] hmm. a url like this seems to work fine for me http://filamentgroup.com/examples/pushstate/#/examples/pushstate/docs/toolbars/index.html [11:34:57] i thought we were going to test pushstate separately? [11:35:21] <_nickel> we are [11:35:26] <_nickel> we're testing it twice [11:35:37] <_nickel> "separately" [11:35:44] <_nickel> we can't write two sets of tests [11:35:54] ok [11:36:04] <_nickel> that would be impossible to maintain [11:36:23] <_nickel> right now I'm stuck duplicating the fixtures which is bad enough [11:36:28] <_nickel> most of them pass [11:36:30] so same tests, run with and w/o PS [11:36:33] <_nickel> yes [11:36:49] <_nickel> and only modifying tests that check the url as part of the test [11:36:59] <_nickel> content based tests stay the same [11:37:27] <_nickel> anyway [11:37:34] <_nickel> I have a solution to our browser state testing woes [11:37:34] I noticed one other (much more minor) thing. If jQ + jQM are loaded dynamically, pushstate doesn't end up getting initialized. I think it's because registerInternalEvents doesn't fire. calling init myself made it work fine [11:37:48] something to keep in mind for later anyway [11:37:51] <_nickel> ok [11:38:05] <_nickel> so I'm going to continue to work on getting the tests working as is today [11:38:10] so we just have those 2 issues plus the tests to work out? [11:38:17] <_nickel> but if I run into too much more resistence I might go off and solve that problem [11:38:17] great [11:38:28] scottjehl: could be because loading is async and happens after the domready/load fires? [11:38:35] we usually dynamically load jq and such in client projects. [11:38:47] domready still fires [11:38:57] scottjehl: after the JS loads? [11:39:00] anyway, not a blocker [11:39:20] scottjehl: anyways, we'll talk on dev [11:39:24] yeah. if you call $(foo) in the console, it'll execute [11:39:27] <_nickel> whats the schedule for beta 3? [11:39:36] <_nickel> I want to know if I'm pressed for time [11:40:00] we really need to ship 1.0 by september [11:40:07] i'd like to get B3 out in the next week or two at the latest [11:40:11] we do [11:40:15] <_nickel> alright [11:40:34] that's why we need to button up these bigger changes and focus on bug fixes and perf [11:40:45] <_nickel> so is this the last big change? [11:40:52] <_nickel> aside from the transitions? [11:41:03] overflow-scrolling [11:41:05] scottjehl - do you think we can get those overflow: powered fixed toolbars and transitions in for b3? [11:41:10] read my mind [11:41:10] I've been working on that one [11:41:40] i sort of feel like we need to get this in because it's really the only way forward for improving toolbars and transitions [11:41:41] it's super easy to pull off for normal pages. basically, we just set the page's height instead of min-height, and apply that property. [11:41:57] however, for fixed toolbars, we have to set height on the content div and overflow that instead [11:42:12] ...and this can then support a polyfill like scrollview if neded? [11:42:19] so it gets complicated, butI've been working on it [11:42:53] toddparker: yeah maybe. Still not sure that's something we should recommend, but for a phonegap app I could see that [11:42:57] can you all think of any other bigger changes we need to do to get things in good shape for 1.0? [11:43:16] toddparker: 2 other issues [11:43:23] oh, we were going to add an extensibility hook somewhere to help devs doing dynamic stuff [11:43:26] those are all I know of. Oh, lastscroll [11:43:30] I've seen folks turning off transitions and couplaining about double clicks [11:43:37] lastscroll definitely needs to be fixed [11:43:40] <_nickel> I need time after this pushstate to deal with the select menu bugs [11:43:44] ticket #? [11:43:45] <_nickel> and then to fix this testing problem [11:43:47] toddparker: right the 2nd was the extensibility hook [11:43:48] <_nickel> and get out server set up [11:43:57] we've got a fix for lastscroll that I'd like to improve and land [11:44:24] ooh. yeah extensibility hook [11:44:31] can we discuss the high-level plan for that? [11:44:42] we need to tag these few items w/b3 [11:45:00] I think we just need an encode/decode hook for updating the location [11:45:05] like, are you thinking it'd just be an even that you could bind to, where the first arg is the server response, and you could return whatever string you want? [11:45:11] default for this messes with hashes (our default) [11:45:14] event* [11:45:27] that is why I was hoping push-state could leverage the same mechanism [11:45:54] is this the lastscroll ticket? https://github.com/jquery/jquery-mobile/issues/1774 [11:45:55] ★ Issue #1774 on jquery-mobile, reported by badtoto (2m, 2w ago): about lastscroll in the nightly version [11:45:59] scottjehl: well there are 2 cases we need to handle [11:46:06] hashchange urls [11:46:19] well that's the only case I think [11:46:20] :-) [11:46:22] $( document ).bind( "jqmnavresponse", function( data) { return runMyTemplate( data ); }); [11:46:29] and then on the page change side [11:46:50] we need code to allow for encoding the URL [11:47:06] encoding... [11:47:21] encoding === I have this page url I just loaded [11:47:28] i want to save it to the location somehow [11:47:37] default would be the hash deal we do today [11:47:41] for someone like jive [11:47:52] isn't that $.mobile.path.set ( url ); ? [11:47:53] they would stuff it in a property that is part of the hash they manage [11:48:31] hmmmm, I suppose they could monkey patch that [11:48:33] hmm... client-side, js-dependent content? [11:48:56] this url wouldn't mean anything to the server, or? [11:49:23] I think its up to the app ... today the hash means nothing to server [11:49:39] right, which is why pushstate is critical [11:49:44] well, we can hash this out in dev. I think it's lengthy. [11:50:04] do you envision the event part being similar to the example above? [11:50:11] anyways those are the 2 pending things [11:50:17] or more of a callback approach? [11:50:52] regarding the double click issues I've seen floating around in other issues [11:50:54] <_nickel> so do we have a cutoff yet on the features for 1.0 [11:50:59] * _nickel senses things creeping [11:51:41] these are the items we've had for a long time [11:51:53] .. I spent some time last week looking at the case where a touch results in something being hidden, only for the click to be intercepted by a text input of some sort below [11:51:54] guess the iOS5 overflow is new [11:52:17] before we move on, do we have a ticket for this extensibility hook? [11:52:42] I think so [11:52:47] * kinblas looks [11:52:54] i want to tag that to B3 [11:53:01] <_nickel> toddparker: yah it just seems like a lot to do and get stable in the next couple of weeks [11:53:12] i'm going to tag some more stuff this weekend so we have a short list [11:53:15] I think part 1 of the hooks is very doable soon [11:53:26] the hook can be pretty modest [11:53:27] https://github.com/jquery/jquery-mobile/issues/836 [11:53:28] ' [11:53:28] ★ Issue #836 on jquery-mobile, reported by jblas (6m, 4w ago): path.get() needs a callback hook or options to configure how urls get processed [11:53:32] a filter callback so people can run the response through a templater [11:53:54] oops that for options [11:53:54] ok, assigned to kin and flagged as B3 [11:54:07] man! not my day... [11:54:16] then we can make a demo where the server returns markup or json depending on headers, and people can run with it [11:54:31] gseguin - wrong issue? [11:54:34] the url management thing seems like a bigger projects [11:54:56] toddparker: yeah I misread [11:55:10] I'll look for it I just can't find it right now [11:55:15] ok [11:55:19] and don't want to hold folks up [11:55:20] tag it when you do [11:55:23] k [11:55:29] https://github.com/jquery/jquery-mobile/issues/1872 [11:55:30] so can I just finish up something about double click? [11:55:30] ★ Issue #1872 on jquery-mobile, reported by toddparker (1m, 3w ago): Add extensibility hooks to allow for dynamic page creation and mgmt [11:55:39] sure [11:55:44] kinblas go ahead [11:56:01] I saw some mentions in other transition related issues regarding double click ... because folks are turning off blinky tansitions [11:56:32] most of the issues I saw had to do with hiding something that was clicked and then some flash of the keyboard because a text input was revealed at the spot where the user had previously touched [11:56:40] I verified ... we *ARE* canceling the clicks [11:56:44] but [11:56:52] the browser gives focus to inputs [11:56:55] on mousedown [11:57:15] so it isn't a click problem per-se [11:57:20] the flash happens because [11:57:27] the browser gives the text input focus [11:57:31] but then our page transition code [11:57:37] gives focus to something else when it is done [11:57:43] ah [11:57:59] anyways, what I was thinking was that we really can't perform actions on vclick [11:58:06] because folks can get into this situation [11:58:15] so they hide a button when clicked and the browser bounces focus to an input on the page [11:58:19] before the transition [11:58:19] I believe it was a select box that was causing this [11:58:28] saw that one [11:58:40] toddparker: no it gives focus *AFTER* the transition because there is no transition [11:58:48] they turned it off by setting default to "none" [11:58:52] so it hides instantly [11:58:52] ah. [11:59:00] before the mouse events are dispatched [11:59:08] anyways, the only way to get around these bugs [11:59:11] is to perform the action [11:59:13] on click [11:59:15] and is focus on the new page or the old one? [11:59:27] that way the mouse events are already dispatched before things get hidden [11:59:40] focus is given to the element below the touch position on the new page [11:59:45] and that happens to be a text input [12:00:05] interesting. so random [12:00:13] anyways ... the same approach for the ajax click is in order here [12:00:22] we *MUST* perform the action on "click" [12:00:22] so are you saying we can't use vclick anywhere/ [12:00:29] sucks [12:00:30] <_nickel> just bind to click then? [12:00:37] well we can give feedback on vclick [12:00:50] but the action can't be dispatched till click if you want to avoid all these problems [12:00:55] so bind to vclcik for flipping active [12:01:00] but click for the action [12:01:05] right, instant feedback, delayed action [12:01:14] <_nickel> ugh [12:01:17] kin - we really need to write up how to best use vclick in the docs [12:01:18] sux [12:01:29] i just added the bare minimum for B1 [12:01:42] yeah, basically vclick isn't good when content changes out from underneath it [12:01:44] but there is a lot to know about how these work and how to use 'em [12:01:48] right [12:02:06] btw, this isn't a vclick immplementation problem [12:02:12] it's just how the events work on these devices [12:02:17] so it would be ok for a toggle controlling content below, but if it made the page change or re-flow, it could be bad [12:02:21] sure [12:02:32] right [12:02:38] if you change content underneath the touch [12:02:40] it's bad [12:03:13] anyways, I'm done, after delivering that sunshine [12:03:22] ok [12:03:29] so is that a change you want to make? [12:03:37] we need to make it to avoid these problems [12:03:39] or is this jsut advice [12:03:45] affects, listview and select (custom) [12:04:09] so we need to tweak the events on all these [12:04:19] yeah [12:04:30] I think folks are seeing it most with selects (custom) [12:04:39] because those pages tend to have selects and text inputs together [12:04:43] ok [12:04:55] actually I think it may be just selects [12:04:55] can you tag those related for B3? [12:05:03] better [12:05:09] I'll have to file a bug ... these are just mentions in transition bugs [12:05:15] is this critical for B3? https://github.com/jquery/jquery-mobile/issues/1376 [12:05:16] ★ Issue #1376 on jquery-mobile, reported by StevenBlack (4m, 1w ago): pagebeforeshow event not fired at the correct juncture. [12:05:24] or still true [12:06:16] it's an old issue [12:06:31] I have trouble parsing the original description [12:07:40] but I believe we now have the state set to the new page before we fire the transitions [12:07:52] should i ask for confirmation then> [12:08:12] ok [12:08:20]