maybe default to that option too

tabs can possibly just be a simple styled list of links that sit in the header/footer, as a sibling to all .ui-page containers. Clicking them will be like clicking any other local or ajax link, except that the global nav tabs will persist while pages animate beneath it.
This approach would let us cut a lot of code, as tabs are quite complex when dealing with aria roles, focus and keyboard management, etc

decide where it makes sense to add -moz, -o, and w3c to css and js events.

possibly fall back to resize when unsupported, or resort to polling on a timeout?

Ideally, let's get scale out of the meta viewport tag.
In testing, one of the devices was zooming when focusing on form controls, then not zooming back on blur. Sorry no detail on which device... :/

• feedback from Paul Irish

however, when I do that, things go haywire!

Rules should be:
Page and Content get ui-body-[theme]
Footer and Header get ui-bar-[theme]

Static markup examples of:

• Search bar (text input) -- do we need to consider adding auto-complete from UI? If so menu style vs. filter list style?
• Button bar (maybe w and w/o button appearance), icon vs. text vs. both
• Filter bar - custom select, toggle, etc.

Other ideas?

Currently, we have to move 180px horizontally, which is far more than other frameworks require.

jQtouch uses a horizontal distance of 35px. I found some native xcode examples that say 25px.
Maybe 30px ish would be nice?

Also, our vertical tolerance is probably a lot larger than necessary too (80px). Maybe closer to 20px would be reasonable.

Apple tab bar with small text labels and 3rd party icon setlike glyphish
http://glyphish.com/

Text only bar with depressed on state, same height as header bar

Also, we need a mechanism for showing only the # of tabs that can fit, add more button that slides bar open to show all.

like how original $.support is done

• from Paul Irish

needs to be removed when traversing back

It might be cool if we added the ability to trigger CSS animations through familiar (and new) jQuery methods.

For example, $(el).slideDown() could replace core's slideDown method, and in this case it'd just do something like the following internally:

$.fn.slideDown = function(){
    return $(this).addClass('slidedown in');
};

Same for others like pop, fade, etc.

Thoughts?

The Ajax support test is pretty much taken care of in core, we should handle it there.

Try and create some basic icons using CSS instead of bitmaps? We could inject the necessary markup with JS. These would be high res and scalable. Most core icons are very simple right now:

+, -, x (delete), arrow up/down/left/right, sort grippy bars

Ideally, we could use this for radiobuttons and checkboxes too. Since Doug's the master, maybe he can weigh in on whether this is feasible.

_t

for some reason, the tabs are hiding on click now. they should stay visible

data-jq-role=collapsible vs .jq-collapsible

Classes are faster. less wordy. but i also like data-jq-* tough call.

• from Paul Irish

Right now we're using hashchange and using getters and setters for the state history - unfortunately we have to include the full BBQ for that. Any help in reducing the plugin down to just what we need would be appreciated. You can see what we're using it for in jquery.mobile.js.

Currently, prevurl only tracks the last page URL, so clicking back more than once will end up using a forward transition.

Remove the BBQ plugin and include Hashchange.

I ran some tests this morning for pushState support (see new test added to jQuery.support.js).

Looks like we might be able to use it in a few places (at least iPhone, iPad, lastest BB, desktop), to combat our non-js bookmarking issue.

!!history.pushState returns:

iPhone w/ iOS4: TRUE
Blackberry 6 (Torch device): TRUE
Stock iPad: FALSE (iPad with update should be TRUE)
Palm Pixi: FALSE
HTC Incredible w/ Android (not sure which version): FALSE
Windows Mobile (not sure which version): FALSE

Chrome 6 mac desktop: TRUE
Firefox 3.6: FALSE
Firefox 4: TRUE (unable to verify right now)
Safari 5 mac desktop: TRUE
Opera 10 desktop: FALSE

styling the native li numbers doesn't seem feasible...

We should show one with more squared off corners and a new color scheme. Maybe something like Aristo/280Slides, but a bit less dingy:
http://cappuccino.org/aristo/showcase/
http://280slides.com/

We're hitting performance problems with the expandable plugin on mobile devices - older iPhones, Android, webOS. Anything that can be done to help would be appreciated - right now we can't really use it.

http://brandonaaron.net/code/expandable/docs

Idea from this article:
http://cubiq.org/you-shall-not-flicker

apply:
-webkit-transform:translate3d(0,0,0) CSS style to all elements inside the scrolling area

We need to be careful because this uses memory

Why isn’t this going to be included in the main iScroll script? The answer is: memory allocation.

We do not have control over memory in mobile webkit. If we use too many resources the browser just crashes, and of course if you have thousands elements inside the scrolling area, forcing the browser to cache everything, would just make your application crash.

rename all ui-body and ui-body-a/b/c classes to ui-box* ("body" could be confused with the element)

If we decide to implement multiple classes, here is a test for it:

https://gist.github.com/37ccfa73b624772a6f62

Dialogs can simply be ui-page divs with a different class applied to style them as an overlay. The link that references the dialog can just use either data-transition="pop" or "slideup"... or, we could add a data attribute like data-behavior="overlay" or something, that could use existing transitions in addition to adding the overlay class "ui-dialog" or "ui-overlay" to the loaded page.

Essentially, this would take the place of writing a dialog plugin at all.

The only logic it'd need is to decide if the page is short enough to overlay on the existing page, or if it should go to a new page for scrolling purposes.

https://github.com/jquery/jquery-mobile/wiki/_pages

Like iOS, add list groupings like for date, letter, etc. in the static examples

If I simply include the jquery-mobile code in a document with no jquery-ui/mobile markup (no classes/attributes) there seems to be some listener installed that catches a swipe right and causes the browser to navigate to the previous page. I see this behavior with both touch and mouse events.

Waiting on possible workaround from Dave Balmer.

Currently, pages that are loaded via ajax are loaded relative to the location.pathname of the first real URL visited. This works for the first requested page, but quickly falls apart when relative links on that page are clicked.

To fix this issue, we need to maintain a global base path variable for prepending to all new hash changes. This basepath should be an absolute path matching the location.pathname of the current file.

currently, we can't ajax link to the globalnav page and get a globalnav, because it's outside of the ui-page div.

currently, pages have a class of ui-page in the foundation markup. This class should instead be JS-generated, so we can reliably hide all ui-page divs and only show the one with ui-page-active class.

...just like they currently do in bars
This change would mean all theme swatches need font styles, link and button styles

thoughts?

and update the manifest.php files

Listview currently hogs the whole hash for state tracking, which is fine if you start on the page that contains a nested listview (like _listview.html), but not fine if you got to _listview.html through an ajax transition. If you did, the next level of the tree will be something like...
pagefoo.html#ui-listview-2

which of course doesn't exist on pagefoo.html.

Doug suggested using a slash to reach sub-page pages:
pagefoo.html#_listview.html/ui-listview-2

Another way we could try would be something like:
pagefoo.html#_listview.html&sublist=ui-listview-2

Either way, this would at least allow us to deep-link for JavaScript users. Non-JS linking is still unresolved.

So far, we've made these core methods public in the $ namespace:

• $.ajaxClick (could probably use a better name... sometimes local,sometimes ajax)
• $.fn.animationComplete (I think this should be moved into events and normalized for full animation event support)

I think these methods could be useful to plugin development as well:

• hideBrowserChrome
• mobilize
• pageLoading
• changePage

For example, it'd be very useful if selectmenu could use $.changePage to wrap its menu options in a ui-page div and do a normal page transition over to the menu, without having to trigger a hashchange to do so (as select menus shouldn't add to the urlStack).

Thoughts?

good for nested lists, but simple lists of links behave in a similar way, with a lot less code. Maybe we don't need tree, or if we keep it, it'd be better if the leaf nodes end up going to a new page rather than loading it into the UL structure.

this would allow us to remove classes from the markup and prevent unwanted css from applying in failing browsers.

new attrs would be:
data-role="header"
data-role="content"
data-role="footer"

Note that footers can instead be tagged as data-role"globalnav", which allows them to persist across pages, until another global nav is loaded.

Clicking the page just produces a slicer bit no mac. When I hit back button, I saw mac appear on index page, then disappeared.

John's got an idea... :)

Will be very useful for the mobile work.

The new AJAX form plugin is great if you're good with server-side tech, but since most mobile apps consist of lots of list views it would be cool to adapt the jQuery UI autocomplete plugin to search against the list markup so you could hand-write a list, add the auto-search plugin and as the user typed in the search box, the list would winnow down on the fly.

Supporting a way to filter against structured data would also be slick. For example I could add a toggle in the toolbar to only view flagged emails and, when pressed, it would look in the "aside" for the string 'flagged' and hide all items that dont' have this. This would require at least simple scoping to say where to look for the data -- could be any selector.

Adding client-side sorting of lists would be incredibly powerful. Anyone want to take a crack at this?

something like...

$.support.media = $.media('screen and (min-width: 0)');

Also, investigate how MQ support aligns with our A / C browser divide. Perhaps we could require $.support.media for JS enhancements...?