I am having some issues with scrollview and forms across various platforms (in the xoom it all just goes to hell) and am studying the testing page you've got right here:
I am going to attempt to fix scrollview, but need to ask some questions before that:
1) we know now that different platforms handle touch and mouse and buttons/nubs etc differently. as a result, preventDefault (PD) and stopPropagation (SP) gives different results across different platforms. how do you plan to handle this in scrollview? will it be some scripts that handle platform detection and assigning PD and SP accordingly?
2) Do you have a more updated table of results for what works across various platforms other than what you have up on that page? how do you go about testing the platforms to come up with the results in the table in the page above (just wanna make sure i don't leave out any test cases when i do)?
3) do you plan on having vmouse events used in scrollview? or will it stay separate: touch and mouse events? how wud vmouse help if we do use it?
hope to hear from you soon - am reading the scrollview code for now (with aspirin by my side :p )
hi folks, i'm starting this discussion to help anyone who needs help or want to discuss issues regarding the splitview plugin we developed for jquerymobile.
any suggestions, critiques, questions, issues are welcome!
I'm just wondering what is the purpose of these two variables - what is it that it is meant to achieve?
am working on some plugins for jQm and have some problems with these - would like to know what they are for so i can determine how to work around them. Thanks!
I'd like to make a suggestion, which if you guys think is ok I'd like to try out in my own fork and let you know how it turns out.
I'm working on making a SplitView for jQueryMobile that will allow pages to be rendered in two columns for tablets(e.g. ipad) and desktops, and a standard single column for mobile apps - using media query to determine how to render the page layouts.
I'm finding that the fixHeaderFooter toolbars give me a lot of problems, with the css settings for top not getting calculated properly (because what i do causes it not calculate right)... but particularly since all the hiding and showing is no longer necessary in a tablet and desktop layout, but am finding it difficult to unbind all the bindings to scrollstart, silentstop, silentscroll, resize etc since they're not named and i don't want to unbind anything else.
also, I've a feeling the entire plugin can be quite redundant for a desktop/tablet layout - so may want to roll out my own plugin for it, which I would gladly share...
so here's my suggestion:
1) name the event handlers so that other plugin devs can unbind them if they want to. this enables them to override specific functionality within the plugins and/or
2) at mobileinit, set an array that can be overriden that tells jQuery Mobile what plugin methods it should run for all the core plugins. Example:
$.mobile.plugins = {
toolbars: fixHeaderFooter(),
buttons: buttonMarkup(),
lists: $.mobile.listview()
}
(apologies if this syntax is wrong, I'm still a little new to jQuery)
this allows other developers to roll out their own plugins for core features by just binding into the mobileinit event. In fact, this also allows core to do something like this:
toolbars: $.mobile.media("screen and (min-width: 768px)") ? fixHeaderFooter() : standardHeaderFooter(),
so you can create different methods that handle certain features differently according to media query.
hope to hear from the team! looking forward to contributing
This is just a suggestion, and is more of an aesthetic one than functional,
i just feel that when there are more than 5 nav items in a navbar, the buttons should wrap into three columns per row instead of the current two. I think it looks better and uses less vertical space.
will be happy to provide an update if this is agreed upon.