#jquerymobile-dev_20110906.txt

[08:47:09] <scottjehl> mornin
[08:50:29] <scottjehl> mvta - we'll be addressing that in a way that'll work best in iOS5 soon, since iOS5 will have the first native internal scrolling implementation (and position fixed implementation) we can safely build upon. That aside, you'd need to try using a JS-driven scroller to support other devices for that. We don't officially support JS scrolling, but there are a few projects you can try: Scrollability, or
[08:50:29] <scottjehl>  our experiments/scrollview folder.
[09:14:54] <toddmparker> hey scottjehl
[09:19:33] <scottjehl> hey toddmparker
[09:19:38] <scottjehl> working on lastscroll now btw
[09:19:48] <scottjehl> and then ios5 stuff that builds on that
[09:20:08] <toddmparker> sweet
[09:20:21] <toddmparker> sorry to bombard everyone last night on issues
[09:34:12] <scottjehl> nah, good stuff
[09:36:22] <kinblas> toddmparker: ping
[09:36:39] <toddmparker> hi kinblas
[09:37:16] <kinblas> toddmparker: I think your iphone has my gmail account as my primary address while all other tools you use ... go to my adobe address
[09:37:40] <kinblas> I don't check my gmail half as much as I do work. :-)
[09:37:51] <kinblas> so sometimes I miss topics you start on the gmail address
[09:37:51] <toddmparker> great, thanks for the heads up
[09:37:56] <toddmparker> wasn't sure
[09:39:24] <scottjehl> hey kinblas
[09:39:29] <kinblas> scottjehl: yo
[09:39:47] <scottjehl> I pushed up a start for the beforechangepage preventdefault
[09:39:52] <scottjehl> not sure if you'd have time to take a look
[09:39:59] <scottjehl> I didn't build a demo on top of it
[09:40:11] <kinblas> scottjehl: now would be good to look ... I have a string of meetings after lunch
[09:40:23] * kinblas checks the branches
[09:44:28] <kinblas> scottjehl: so quick question about trigger
[09:45:05] <kinblas> scottjehl: the args *AFTER* the event object, do they get stuffed into the event.data? If so, how does it know what to name the props it sticks in event.data?
[09:45:15] * kinblas does a quick lookup in the jquery api docs
[09:48:22] <scottjehl> no those are just an array of args after the even object
[09:48:34] <scottjehl> hmm. should be passed as an array actually
[09:49:50] <scottjehl> Essentially, I didn't take this very far, but I'd like to see how you'd trigger it and use it externally. Something similar to the demo I'd made for the JSON templating callback would probably work, except the JSON could be in the page at the start as well, if the dev prefers
[09:50:06] <scottjehl> or they could run $.getJSON(...) e.preventDefault()
[09:52:10] <scottjehl> one thing that came up in my workshop:
[09:52:26] <scottjehl> people are confused why this event is inconsistently named with the other page events
[09:52:33] <kinblas> heh
[09:52:35] <kinblas> changepage?
[09:52:43] <scottjehl> maybe we can deprecate it in favor of pagebeforechange
[09:53:12] <scottjehl> it's not your fault so much as the original name I used for changePage
[09:53:14] <kinblas> it's because that's the name of the function :-P
[09:53:18] <scottjehl> but I agree it's confusing
[09:53:33] <kinblas> ok so pagebeforehchange and pagechange
[09:53:46] <scottjehl> yeah.
[09:54:06] <scottjehl> I mean, we might consider deprecating changePage for pageChange() while we're at it
[09:54:13] <scottjehl> pre-1.0 luxuries
[09:54:21] <scottjehl> both should work of course
[10:14:39] <toddmparker> rename now or forever hold your peace
[10:14:51] <toddmparker> looks like thursday is the day folks
[10:15:17] <toddmparker> i think that this hook is pretty important to land
[10:15:27] <toddmparker> scroll history too
[10:16:04] <toddmparker> the transitions are a bit harder...if they are looking solid code-wise i can test a few more platforms today and we cna make a decision
[10:16:51] <toddmparker> kinblas: what's your take on the state of transitions
[10:16:58] <toddmparker> looked good on-device on thursday
[10:17:13] <toddmparker> scott - i still need your opinion on the implications of not usign display:none
[10:20:48] <kinblas> toddmparker: yeah I'm just nervous as to the implications of not using display:none
[10:22:38] <toddmparker> I think we can work around the accessiblity concerns
[10:22:41] <toddmparker> even post B3
[10:22:54] <toddmparker> unless scottjehl howls
[10:23:15] <toddmparker> { crickets }
[10:23:26] <toddmparker> ok, he is ok with it ;)
[10:26:04] <scottjehl> heyo
[10:26:59] <scottjehl> so, we're not using display: none at all anymore? I thought you just needed to display:block before transitioning?
[10:27:09] <scottjehl> ...but then truly hiding after that?
[10:27:51] <scottjehl> last I heard, aria-hidden support isn't good enough to rely on it solely when an element is not display:none
[10:31:22] <toddmparker> when you add display:none, you get a horrible blink on Android, esp honeycomb
[10:31:47] <toddmparker> so i'm thinking that we can try to add accessibility features to keep them on the current page
[10:31:54] <toddmparker> but not display:none
[10:32:04] <toddmparker> scottjehl
[10:35:28] <kinblas> toddmparker: it's display:none *AND* visibility:hidden that cause the blink
[10:39:08] <toddmparker> ah, thanks kinblas
[10:39:36] <kinblas> toddmparker: btw, I got a reply from Google, but it was more of a Cc'ing someone that might be able to help us
[10:39:51] <kinblas> that was Friday, but he never replied
[10:39:55] <kinblas> I just pinged again.
[11:00:29] <scottjehl> toddmparker
[11:00:33] <scottjehl> umm not sure
[11:00:40] <scottjehl> there are so many ways around that
[11:00:50] <scottjehl> managing focus is only one
[11:01:15] <scottjehl> I mean, accidental ways too. Not worried about people who try to get out of a page
[11:06:48] <toddmparker> so that's why i wanted to talk to you about this
[11:06:56] <toddmparker> we basically are in a tough spot
[11:07:28] <toddmparker> where we either have perfect screenreader experience but pretty horrible transitions or we find a middle ground
[11:07:40] <toddmparker> i understand it's not ideal
[11:08:09] <toddmparker> but if we can keep you on the active page in voiceover, that is the full extent of mobile accessiblity testing we need to address
[11:08:17] <toddmparker> that might support the aria properties we need too
[11:08:29] <toddmparker> on desktop, it will be more of a mixed bag
[11:08:47] <toddmparker> totally open to your recommendations here
[11:09:14] <toddmparker> if you're in the office, try out the few links kin posted on honeycomb. it's a big diference
[11:10:08] <toddmparker> the other side of this is IF honeycomb supports overflow and we want to let them into the iOS 5 style transitions in some way, we could see if that approach makes transitions smoother
[11:10:18] <toddmparker> sort of a complex set of IFs here
[11:10:35] <toddmparker> but on honeyvomb, transitions really aren't usable on master
[11:10:41] <scottjehl> so we can't toggle display after the page is gone, huh
[11:10:43] <toddmparker> didn't realize how bad until last week
[11:10:56] <kinblas> scottjehl: nope
[11:11:02] <kinblas> scottjehl: it still blinks
[11:11:36] <toddmparker> kinblas: it blinks using 2 overflow divs
[11:12:01] <toddmparker> basically if you display none something, it blicks?
[11:12:26] <kinblas> toddmparker: I think it's related to abs pos
[11:12:33] <toddmparker> hmm
[11:12:39] <toddmparker> android is so bad
[11:12:44] <toddmparker> shockingly so
[11:12:46] * kinblas digs up a test case
[11:13:01] <toddmparker> scottjehl: open to any and all options here
[11:13:18] <kinblas> toddparker: http://webpro.host.adobe.com/people/jblas/research/page-transitions/page-transitions-08.html
[11:13:19] <toddmparker> i just think that  the current state frankly isn't good enough
[11:13:21] <kinblas> oops hang on
[11:13:28] <toddmparker> and i understadn why people turn 'em off
[11:13:42] <kinblas> toddmparker: http://goo.gl/KnvxJ
[11:13:52] <toddmparker> scottjehl: give that a test on a playbook and the galaxy tab
[11:14:00] <toddmparker> compared to master
[11:14:05] <toddmparker> still not perfect, but better
[11:14:09] <toddmparker> lot better
[11:14:22] <scottjehl> playbook too? Is this more of a larger-screen issue than a honeycomb issue then?
[11:14:34] <toddmparker> kin - did you see my Q re: trying to mitigate the scroll blink again with the translate
[11:14:45] <toddmparker> playbook saw improvements
[11:15:02] <toddmparker> course thsi si keyframe vs. transitions + no display:none
[11:15:07] <toddmparker> so it's not a pure test case
[11:15:14] <toddmparker> multi-factor
[11:15:55] <kinblas> toddmparker: I saw a message, are you talking about experimenting with the transform before/after scroll to avoid the jump?
[11:16:00] <toddmparker> honeycomb still blinks when going back
[11:16:04] <toddmparker> but it's good in
[11:16:12] <toddmparker> kinblas: yep
[11:16:21] <toddmparker> think that caused another blink
[11:16:24] <kinblas> toddmparker: I'm still a bit mystified by the blink on back
[11:16:24] <toddmparker> yay!
[11:16:28] <scottjehl> toddmparker where's the honeycomb
[11:16:34] <toddmparker> yeah, i dunno
[11:16:46] <toddmparker> you seeing that too?
[11:17:19] <scottjehl> I'll try the motorola
[11:17:23] <toddmparker> k
[11:17:44] <toddmparker> i gotta head out fir a dr appt
[11:17:46] <kinblas> toddmparker: anyways that tests case above is what I was using to try and figure out what causes blinks
[11:17:58] <toddmparker> will be bac online in about 2 hours
[11:18:02] <kinblas> ... for some reason it now crashes my xoom
[11:18:03] <scottjehl> ugh needs charging
[11:18:07] <toddmparker> discuss amongst yourselves
[11:18:27] <toddmparker> i guess i have hte galaxy tab here
[11:18:30] <toddmparker> i'll test when back
[11:18:32] <kinblas> scottjehl: yo have the galaxy?
[11:18:38] <toddmparker> ya
[11:18:44] <toddmparker> k, be back later
[11:18:47] <scottjehl> master was transitioning okay on the galaxy when I was testing my workshop stuff
[11:19:12] <scottjehl> I mean, okay in that it just dropped frames like a tablet does (aside from iPad)
[11:19:33] <kinblas> scottjehl: heh
[11:19:50] <kinblas> the dropping of frames (aside form blinks) is what annoys folks
[11:20:08] <kinblas> anyone ever see an animation/transition on an Android device that was smooth?
[11:20:23] <scottjehl> so are you currently adding aria-hidden=true when it's off screen?
[11:21:04] <scottjehl> or, how are you planning to keep hidden pages hidden
[11:21:08] <scottjehl> ?
[11:21:26] <scottjehl> also, we're still removing from DOM by default right?
[11:22:24] <kinblas> scottjehl: yeah, I just changed the method of how we hide things
[11:22:28] <scottjehl> because if that somehow doesn't cause blinks, maybe we should always remove from the DOM, even if we simply detach() until we need the page again
[11:22:42] <kinblas> width: 0, height: 0, overflow: hidden; left: -100%;
[11:22:46] <scottjehl> ...for pages that need to stay
[11:25:13] <kinblas> oh hmmm
[11:25:25] * kinblas wonders if part of the blinking is the removal of the "from" page
[11:26:02] <kinblas> scottjehl: toddmparker: so I've been trying to look into event related bugs (tap, taphold and click)
[11:26:22] <kinblas> so if you guys want to consider this I'll need to switch back to transitions
[11:26:43] <scottjehl> consider what?
[11:26:52] <kinblas> scottjehl: landing the transitions stuff
[11:26:52] <scottjehl> landing transitions for b3?
[11:26:55] <kinblas> yeah
[11:28:05] <scottjehl> k. yeah I dunno. Seems like some considerable workarounds here to get honeycomb improvements. What are the overall pros/cons at this point for landing the branch?
[11:28:11] <scottjehl> Firefox support?
[11:29:27] <kinblas> scottjehl: pros: transitions are implemented on more browsers.
[11:29:49] <kinblas> cons: when using inside jQM, the perf differences aren't noticeable
[11:30:01] <kinblas> cons: Things still blink on some android devices.
[11:30:21] <toddmparker> And this version that doesn't hide pages is smoother on non iOS
[11:30:53] <kinblas> cons: we're bending the way we hide pages just for smoother transitions on a specific platform
[11:31:19] <kinblas> cons: the event we have to listen to to tell if the animation is done, is really too low-level
[11:31:39] <scottjehl> so on the first pro: does this get us Firefox support now, at least?  Or what does it add?
[11:32:15] <scottjehl> so, one thing to consider, just to play devil's advocate for a sec...
[11:32:34] <toddmparker> Firefox desktop, mobile not yet
[11:32:39] <kinblas> scottjehl: yes, though it *STILL* look horrible on desktop
[11:32:52] <scottjehl> huh. hmm
[11:32:57] <toddmparker> Easy to add opera mobile once they patch up transitions
[11:32:57] <kinblas> scottjehl: I just tried it in FF 6
[11:33:04] <scottjehl> so we're better disabling it in FF6 anyway?
[11:33:06] <toddmparker> IE10 :)
[11:33:22] <kinblas> strange FF6 on desktop *STILL* drops frames
[11:34:01] <toddmparker> I think we need to make a call on this switch today-ish
[11:34:03] <scottjehl> what if we focused on this post-1.0? I guess I'm wondering if it's worth a big change right now for "slightly smoother on android sometimes"
[11:34:18] <kinblas> lol
[11:34:23] <kinblas> I like that sum up
[11:34:28] <toddmparker> If we say it's not worry it quite yet, that's an ok answer
[11:34:47] <toddmparker> Its where we're going, but could wait post 1.0
[11:34:59] <kinblas> toddmparker: I had a hard time parsing that first statement
[11:35:03] <scottjehl> devil's advocate: i've got the ios5 scrolling thing underway here. It makes transitions great in iOS5. We could opt-in a few other overflow-scroll-supporting browsers by UA
[11:35:17] <scottjehl> such as playbook
[11:35:26] <scottjehl> and honeycomb
[11:36:05] <toddmparker> Ultimately, the animated page transitions are going to be a big selling point. In master, they aren't that good right now. We know that, but we understand the limitations.
[11:36:20] <scottjehl> $.support.nativeOverflow = supports("overflow-scrolling" ) || playbook || honeycomb;
[11:36:50] <scottjehl> just saying this is a possibility if we found a hopefully-not-UA detect method for playbook and honeycomb
[11:37:02] <scottjehl> since they support momentum overflow: auto
[11:37:10] <toddmparker> Scottjehl - I think that could be a good solutio
[11:37:28] <toddmparker> Agree
[11:37:47] <toddmparker> Agreed
[11:37:51] <scottjehl> I hate that we had to spend so much time on transitions to find it's not worth pursuing yet
[11:38:07] <toddmparker> I agree
[11:38:09] <kinblas> yeah it sucks
[11:38:20] <kinblas> hence my joy in fixing bugs on Friday
[11:38:23] <scottjehl> a few of those conditions worry me though. Disp none in particulary
[11:38:34] <kinblas> +1
[11:39:44] <toddmparker> So Scott, I'd like to include those platforms in the scrolling and test em out
[11:40:19] <toddmparker> If its an improvement, I'd be ok with saying we're heading there and will add transitions later
[11:40:34] <scottjehl> yep I will. So it all comes down to this branch then... great :/
[11:40:41] <scottjehl> :)
[11:41:50] <scottjehl> k so last-scroll is just about ready to land
[11:42:02] <toddmparker> Its all on you Scott
[11:42:09] <toddmparker> Done yet?
[11:42:22] <scottjehl> I've got an edge case with going "forward" to a page that didn't have a scroll remembered
[11:42:25] <scottjehl> v close
[11:43:56] <kinblas> toddmparker: scottjehl: so what should we do with transitions?
[11:44:31] <kinblas> toddmparker: scottjehl: like I said I'm still workin' the google angle to see if they can give us some tips
[11:49:47] <toddmparker> Let's let Scott jam on this and well see if we want to go here
[11:50:58] <toddmparker> If you could help with scroll back, scottjehl could just work on the overflow stuff...
[11:56:13] <scottjehl> scrollback is just about done
[11:56:26] <scottjehl> I'll push and then would love some feedback before landing
[12:13:05] <scottjehl> toddmparker - you in campfire?
[13:16:18] <toddmparker> Scottjehl - still at the dr.
[13:16:31] <toddmparker> Email me the 'fire link?
[15:13:03] <kinblas> scottjehl: I'm in the process of creating a sample for the beforechangepage branch ... I already stumbled on to the fact that notification has to be a bit higher ... *BEFORE* the isPageTransitioning