Announcing jQuery Mobile 1.1.0 RC1
The jQuery Mobile team is excited to announce the first release candidate of 1.1.0. This release has been a real labor of love, with hundreds of commits and tons of improvements, big and small, to make jQuery Mobile feel faster, smoother and more polished across the board. We encourage the community to help us test and shake out any final bugs before we release the final version in the upcoming weeks. Try it now!
Demos & docs | Key changes | Download & CDN | Supported Platforms
KEY CHANGES
True fixed toolbars: Lightweight, CSS-based & broadly compatible
Browser support for fixed toolbars
- iOS5 – iPhone and iPad
- Android 2.2 and 2.3
- Android 3.x tablets (Honeycomb)
- Android 4.x (ICS)
- Chrome for Android (beta)
- BB Playbook 1-2
- BB7
- Nook Color/Tablet
- Kindle Fire
- Kindle 3
- All modern desktop browsers (IE, Firefox, Safari, Chrome, etc.)
When we first started developing the library, CSS support for position:fixed in mobile platforms was pretty much non-existent so our “fixed” toolbar solution dynamically re-positioned the toolbars each time you scrolled the page. Although it was a decent stopgap, the way mobile browsers would freeze the DOM during scroll would result in the toolbars briefly scrolling with the document which was impossible to completely fix. Alternate approaches use JavaScript-based momentum scrollers to achieve true fixed toolbars, but these only work on a small subset of platforms, have non-native scrolling physics, and can introduce performance and usability issues in less capable devices. None of this was an acceptable option for this project.
Luckily, around the time we released 1.0, Brad Frost posted his results of extensive tests of position:fixed on mobile browsers. Surprisingly, support is now quite good so we set about prototyping and testing a CSS-based replacement for our fixed toolbars.
We now have a solid re-write that provides true fixed toolbars on the a lot of popular platforms and safely falls back to static toolbar positioning in other browsers.
The coolest part about this approach is that, unlike JS-based solutions that impose the unnatural scrolling physics across all platforms, our scrolling feels 100% native because it *is*. This means that scrolling feels right everywhere and works with touch, mousewheel and keyboard user input. As a bonus, our CSS-based solution is super lightweight and doesn’t impact compatibility or accessibility.
Since we’re removing the 1.0-era fixed toolbar re-positioning script, some platforms like iOS 4 will now fall back to static positioning where the toolbars simply scroll with the page but we feel it’s better to have a crisp divide: it either works perfectly or falls back to a safe and usable solution.
The new fixed toolbars also have a robust set of options and methods you can tap into to customize the behavior such as whether toolbars are visible on page load, whether the tap to toggle toolbar feature is enabled, toggle transition (defaults to slide up/down)
Improved transitions: Smoother, faster
Our AJAX navigation system is one of the best things about jQuery Mobile because it makes page navigation faster and adds animated page transitions. We did a ton of work leading up to 1.0 to make our transitions as smooth as possible, but there were two significant things that turned out to very difficult: the need to scroll the page between transitions and Android’s poor animation performance.
First, we have a hard constraint that both the page you’re on and the page you’re animating to are both sitting on the same viewport — we animate and scroll the viewport to achieve the transition effect. This means that if you are scrolled down on a page and click a link, we need to first scroll to the top of the page, then begin the transition (yeah, we tried every CSS trick to avoid scrolling, none work well on longer pages or Android). Since we also restore your scroll position if you go back, we may need to scroll up, transition, then scroll down to restore your scroll position. On mobile devices, scrolling is pretty slow so you’d see the page scroll by then stop at the top which can make things feel jumpy.
Because we don’t have widespread CSS support for overflow:auto on mobile browsers and aren’t satisfied with the limitation of JS-based scrollers, we had to think creatively. For 1.1, we embraced the scroll jump constraint and shuffled the sequence of the page transition JS handler to first fade out the current page, then scroll the page into position before transitioning in the new page. Since we’re scrolling a blank page, it scrolls faster and the scroll jump is invisible so things feel much more controlled and smooth. As a bonus, the fade out/in animation is impressively smooth and blink-free on every platform. This does mean that every transition has a place where we need to fade out a screen to accomodate the scroll jump, but we think this still looks pretty sharp.
On the second topic, I won’t mince words here: Android as a whole has abysmal performance rendering CSS keyframe animations. Regardless of version or device, Android devices stutter, drop frames and blink when performing any page page animation other than a simple fade.
Post-1.0, we went back to the drawing board to investigate exactly what combination of CSS properties caused the most issues so we could re-vamp our transitions to be as easy on Android as possible. We found that most common things we wanted to do like animating size or position along with opacity would cause blinks, missing animations and odd opacity rendering on box-shadows. With this in mind, we spent weeks testing on a wide range of Android-based devices to arrive at a set of minimal transitions that would be as non-taxing as possible.
Unfortunately, after a ton of work, we’ve determined that it’s not possible to dumb down page transitions enough to get acceptable performance in Android 2.x, even on a newer device like a Nexus S running 2.3. After a lot of deliberation, we’ve decided to use a feature test for 3D transforms to target transitions: if a browser passes, it will see the full range of transitions. By default, if a browser fails this 3D test, they will fall back to a fade transition, regardless of the transition specified. All Android 1.x-2.x devices fail this test but Android 3.x and 4.x pass. The fallback behavior for each transition is completely configurable if you want to change this behavior.
TL;DR: The default page transition is now be a super fast and smooth fade out/in animation. All the 1.1 page transitions (slide, flip, etc.) have been tweaked to have a place it the animation where we fade out to accomodate the scroll jump, but we think this looks pretty sharp and always in control. On some platforms like Android 2.x that don’t support 3D effects, the simpler fade transition will be the only game in town, regardless of the transition specified. View the new 1.1 page transitions.
Two new transitions in 1.1: Turn and Flow.
In addition to re-vamping all the 1.0 transitions, we’ve added a turn transition that is similar to the WP Metro style page effect and a flow transition that is bit like the iOS tab switching transition where pages zoom in and out. Both look great on platforms such as iOS and Blackberry PlayBook that support 3D.
Firefox support for transitions
Yep, we’ve added -moz prefixed rules for all the page transitions to bring support to newer versions of Firefox desktop and (hopefully) a future build of Firefox mobile. We will continue to add vendor-prefixed rules for Opera, IE, etc. as these browsers gain support prove they have support with acceptable performance. Vendor prefixes add a lot of code when working with CSS keyframe animations so we want to add these only when supported to keep the file sizes down.
New AJAX loader design and options
As we revisited page transitions, we found that a more subtle loader design actually made the navigation feel faster so we re-designed the loader to be as minimal as possible and ended up with a light spinner image with no text to keep things simple. Hoever, we understand that there will be times when you do need to display text along with the loader so we’ve beefed up the loader to be much more flexible. There are now a few new global options that let you set whether you want to see the text, loader or both and set the theme or text at runtime. For example, this will show the loader with theme A and a custom message: $.mobile.showPageLoadingMsg("a", "Loading theme a...");. View a demo of these new loader options in the docs.
Related: TouchOverflow feature to be deprecated in 1.1
We introduced the experimental touchOverflow feature in 1.0 because it made our transitions smoother and brought true fixed toolbars in iOS5. This came at the cost of code complexity and a lot of CSS rendering bugs due to Apple’s buggy implementation. Now with our new fixed header and transitions approach, we don’t see any viable use case for this feature so we’re deprecating it at 1.1.0. Deprecation here simply means no errors are going to be thrown by its removal: we will keep our $.support and $.mobile.touchOverflowEnabled properties defined to avoid throwing issues in custom code that leveraged this feature.
Support for jQuery 1.7.1
jQuery Mobile 1.1.0 now supports both 1.6.4 and 1.7.1 versions of jQuery core. We recommend that you use 1.7.1 to take advantage of all the great improvements in the latest release. If you stick with 1.0.1 for a while, remember that only supports 1.6.4.
Mini form elements
As we worked on fixed toolbars, we started to test the rendering of form controls in headers and footers and in 1.0, things were a bit broken. In 1.1, we’ve spent a lot of time tweaking the form elements so they will render nicely in toolbars but the standard versions seemed a bit big in toolbars.
We had a smaller button style already hard-coded in headers so we used the vertical height of that button as a basis for a new “mini” version of all our form elements (buttons, selects, inputs, sliders, switches, etc.).
By adding the data-mini="true" attribute to these elements, the more compact version will be displayed which is perfect for toolbars. The image on the right compares the standard vs. mini versions of each element.
Flip switch: Improved design
As we started to look at our form elements, the flip switch seemed like it could use a bit of visual cleanup. We looked across popular mobile platforms and they all seemed to use a pretty consistent design that used a smaller handle to maximize horizontal space for the text. In 1.1, we’ve tweaked the design to use a round handle (or square, depending on your theme) for the flip switch and re-vamped the underlying code to make it more robust.
Slider: Highlight feature
We also added a feature to add a track highlight from the left of the track to the slider position. Just activate the highlight feature, add data-highlight="true" attribute to the range input.
Slider: Step attribute support
The step attribute is part of the HTML5 range input spec and allows you to specify the increment the slider handle must move. This defaults to 1, but now you can specify the step to slide by increments (step="25") and the handle will snap to these points. If a value in entered into the numeric input next to the slider that is outside the steps, it will round to the closest one. We borrowed this code from the jQuery UI project so thanks guys.
Zoom fixes: orientation change iOS bug and select/input zoom
If you wanted to avoid the page zooming in oddly when you rotated an iOS device into landscape mode, you needed to disable user zooming via the viewport meta tag. However, we think that it’s nice to keep user zooming enabled if at all possible so after a lot of tinkering, Scott Jehl came up with a clever hack that uses accelerometer data to determine if a device is in the process of being rotated. If it is, we temporary disable zooming to avoid the orientation bug, then quickly restore it. We’ve created a new utility (zoom.iosorientationfix.js) in jQuery Mobile that uses this technique to fix the iOS orientationchange zoom bug.
There is another utility zoom.iosfocusfix.js, which disables zoom as a select or input element is focused, preventing iOS from zooming into that element and cropping the viewport. Zoom is restored just after the focus event fires (a half second timeout).
We added a general utility: $.mobile.zoom, which as 3 members: enabled [bool], disable [function], and enable [function]. This simple utility is used to disable user scaling in devices like iOS. The disable() method disables user-scaling. The enable() method enables user-scaling. The enabled property keeps track of state. This utility is used by the two features above and can be used in custom scripting events as well.
AMD module support
In jQuery Mobile, we’re using AMD to express dependencies between the different modules for the build scripts and to support our in-progress download builder tool. However we strip out all the AMD overhead in the final source files. It will export an anonymous AMD module if an AMD loader is present, the same way jQuery Core does it. Special thanks to James Burke (@jrburke) for jumping in and helping us polish our AMD implementation.
data-enhance=false data attribute
As of jQuery Mobile 1.0, all the markup within a page is scanned for elements to be enhanced. This is problematic for 3rd party widgets/libraries that don’t want anybody enhancing their markup or attaching behavior. We heard requests for a data-* attribute that can be place on an element container to tells the framework not to enhance anything inside it for these situations. In 1.1, we’ve added a new data-enhance=false attribute that can be added to a container to prevent both auto-initialization and link/form hijacking. This is also available via $.fn.jqmEnhanceable. It’s important to note that because of the performance impact incurred by finding a parent element with the data-enhance=false attribute this feature must be turned on explicitly with $.mobile.ignoreContentEnabled=true.
data-ajax=false now works on containers
On a related topic, we’ve always offered the ability to disable the AJAX navigation system from hijacking a link or form submit via the data-ajax="false" attribute, but people have asked for a way to apply this exclusion more efficiently to a grouping of links. In 1.1, this is now possible by simply adding, and setting $.mobile.ignoreContentEnabled=true, the data-ajax attribute to a parent container and it will exclude all the parent link or forms from the AJAX navigation system behavior.
New docs navigation and search
We spend quite a bit of time refining our docs and we think they are pretty solid. However, there are now a lot of pages and it can be hard to find what you need simply by browsing around. For 1.1 we’ve added a button in the upper right corner of every page that opens a searchable sitemap that contains an alphabetized list of pages in a filterable listview. Although this isn’t a true site search, we’ve used the hidden filtertext feature to load up each list item with a rich set of keywords you might be looking for. We plan on making some larger docs changes in future releases, but this seemed like a nice addition to the docs.
Please help us test!
We’re looking for help with testing this release so we can release a final build as soon as possible. Browse the docs or try out the 1.1.0 release in your projects, then report issues in the GitHub tracker. Be sure to specify the device, OS version, browser, steps to reproduce and include a simplified test case that uses the latest build (template here). If all goes well, we hope to release the final build in about 2 weeks.
Download
CDN-Hosted JavaScript:
- Uncompressed: jquery.mobile-1.1.0-rc.1.js (useful for debugging)
- Minified and Gzipped: jquery.mobile-1.1.0-rc.1.min.js (24KB, ready to deploy)
CDN-Hosted CSS:
- Uncompressed with Default theme: jquery.mobile-1.1.0-rc.1.css (useful for debugging)
- Minified and Gzipped with Default theme: jquery.mobile-1.1.0-rc.1.min.css (7KB, ready to deploy)
- Uncompressed structure without a theme: jquery.mobile-1.1.0-rc.1.css (useful for theme development)
- Minified and Gzipped structure without a theme: jquery.mobile-1.1.0-rc.1.min.css (6KB, ready to deploy)
Copy-and-Paste Snippet for CDN-hosted files (recommended):
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.1.0-rc.1/jquery.mobile-1.1.0-rc.1.min.css" /> <script src="http://code.jquery.com/jquery-1.7.1.min.js"></script> <script src="http://code.jquery.com/mobile/1.1.0-rc.1/jquery.mobile-1.1.0-rc.1.min.js"></script>
ZIP File:
If you want to host the files yourself you can download a zip of all the files:
- Zip File: jquery.mobile-1.1.0-rc.1.zip (JavaScript, CSS, and images)
Microsoft CDN hosted jQuery Mobile files:
Fork jQuery Mobile on GitHub
https://github.com/jquery/jquery-mobile
Platform support in 1.1.0 RC1
jQuery Mobile has broad support for the vast majority of all modern desktop, smartphone, tablet, and e-reader platforms. In addition, feature phones and older browsers are supported because of our progressive enhancement approach. We’re very proud of our commitment to universal accessibility through our broad support for all popular platforms.
We use a 3-level graded platform support system: A (full), B (full minus Ajax), C (basic). The visual fidelity of the experience and smoothness of page transitions are highly dependent on the CSS rendering capabilities of the device and platform so not all A grade experience will be pixel-perfect but that’s the nature of the web.
A-grade – Full enhanced experience with Ajax-based animated page transitions.
- Apple iOS 3.2-5.0 – Tested on the original iPad (4.3 / 5.0), iPad 2 (4.3), original iPhone (3.1), iPhone 3 (3.2), 3GS (4.3), 4 (4.3 / 5.0), and 4S (5.0)
- Android 2.1-2.3 – Tested on the HTC Incredible (2.2), original Droid (2.2), HTC Aria (2.1), Google Nexus S (2.3). Functional on 1.5 & 1.6 but performance may be sluggish, tested on Google G1 (1.5)
- Android 3.1 (Honeycomb) – Tested on the Samsung Galaxy Tab 10.1 and Motorola XOOM
- Android 4.0 (ICS) – Tested on a Galaxy Nexus. Note: transition performance can be poor on upgraded devices
- Windows Phone 7-7.5 – Tested on the HTC Surround (7.0) HTC Trophy (7.5), LG-E900 (7.5), Nokia Lumia 800
- Blackberry 6.0 – Tested on the Torch 9800 and Style 9670
- Blackberry 7 – Tested on BlackBerry® Torch 9810
- Blackberry Playbook (1.0-2.0) – Tested on PlayBook
- Palm WebOS (1.4-2.0) – Tested on the Palm Pixi (1.4), Pre (1.4), Pre 2 (2.0)
- Palm WebOS 3.0 – Tested on HP TouchPad
- Firebox Mobile (10 Beta) – Tested on Android 2.3 device
- Chrome for Android (Beta) – Tested on Android 4.0 device
- Skyfire 4.1 – Tested on Android 2.3 device
- Opera Mobile 11.5: Tested on Android 2.3
- Meego 1.2 – Tested on Nokia 950 and N9
- Samsung bada 2.0 – Tested on a Samsung Wave 3, Dolphin browser
- UC Browser – Tested on Android 2.3 device
- Kindle 3 and Fire – Tested on the built-in WebKit browser for each
- Nook Color 1.4.1 – Tested on original Nook Color, not Nook Tablet
- Chrome Desktop 11-17 – Tested on OS X 10.7 and Windows 7
- Safari Desktop 4-5 – Tested on OS X 10.7 and Windows 7
- Firefox Desktop 4-9 – Tested on OS X 10.7 and Windows 7
- Internet Explorer 7-9 – Tested on Windows XP, Vista and 7
- Opera Desktop 10-11 – Tested on OS X 10.7 and Windows 7
B-grade – Enhanced experience except without Ajax navigation features.
- Blackberry 5.0: Tested on the Storm 2 9550, Bold 9770
- Opera Mini (5.0-6.5) – Tested on iOS 3.2/4.3 and Android 2.3
- Nokia Symbian^3 – Tested on Nokia N8 (Symbian^3), C7 (Symbian^3), also works on N97 (Symbian^1)
C-grade – Basic, non-enhanced HTML experience that is still functional
- Blackberry 4.x – Tested on the Curve 8330
- Windows Mobile – Tested on the HTC Leo (WinMo 5.2)
- All older smartphone platforms and featurephones – Any device that doesn’t support media queries will receive the basic, C grade experience
JQM makes it easier for the developers and better for the end users for mobile browsing. Keep up the good work!
I did find a couple of typos:
“…a basis for a new “mini” version of all our form elements (buttons, selects, inputs, sliders, switches, etc.).”
The link to the mini version is to localhost:8080.
Also found a typo, “our scrolling feels 100% native because is *is*”.
Thanks, I just fixed both of these typos.
Awesome news on the tool bars. Been working with JQM for a while and some of these fixes are just what I was looking for!
Great job on this release; very pleased with the fade-out fade-in transition on Android and the new loader. But there is one thing that really annoys me since the release of the first alpha, and that’s the way the “forward-arrow” icons in the menu look on Android (2.3, HTC Desire (HD)). Isn’t there something that could be done to fix that?
Do you mean the arrow shape? The disc style?
The JQMobi team seems to think that Android does animation just fine, when you use CSS3 animations. (See http://www.youtube.com/watch?v=MwNdWZsRXgk for explanation & http://www.jqmobi.com/testdrive/index.html#jqmtransitions for working samples that look great on my Thunderbolt) – so my question is, why not use CSS3 animations for those platforms (including Android) that support it, then degrade from there, rather than simply forcing most Android users to a single “fade” transition?
Jeremy,
Both the jQuery Mobile and Sencha teams have done a lot of work to accomodate android in their transition frameworks but the bottom line is that for anything outside of toy examples the stock browser simple falls flat on it’s face. You’ll note that the jQMobi examples are extremely small (5 list items) where as our demos are very large.
In point of fact you’ll actually see transition issues for large pages on iOS as well for all these frameworks. This is a function of the way the gpu acceleration works by splitting large pages into chunks and rendering them on the fly.
I’m sorry it’s not as simple as we’d all like it to be especially given that Android is so ubiquitous.
I have to say that having a listview with 30 elements and two (or even one) fixed toolbars make my Desire HD very laggy. Same thing works very nice on iPad 2
Any word on when ThemeRoller will be able to handle the new version (if not already)?
ThemeRoller will be ready when we hit 1.1 final in about 2 weeks. There will be a tool to upgrade your 1.0 theme to 1.1 too.
Cool, thanks for the info!
+1 on this. The theme I made for my website no longer works. I would really appreciate more information as to when the themeroller will work with this version.
Awesome your work, congratulations boys
The new fixed tool-bars are great and just what i was waiting for
BUT
Transitions on iPhone iOS 5 seem terrible – to the point i will have to revert to 1.01 – blank white page in transition, lots of flickering even more so when launching from home-screen app.
Am i jumping the gun or are there still some things been done about this?
Same here.
Hmm, I found the transitions to be much better than 1.0.1 on my iPhone 4S. Do you have a code snippet for your page?
Are you seeing this in the demos and docs or in your custom code? I don’t see any flickering on iOS5. Wondering if you have some older cached files in play?
Hi Todd,
To be fair i am not seeing this so much in the demos/docs. Will try and figure out whats causing this today in my code and report back.
To report back..
The problem seems to be in full screen ( home screen button ) mode only.
Both my code and the the jqm demos are fine in the safari browser. As soon as i have added my app to home screen, i see a huge flicker after the transition has completed, on all pages even a very simple one.
I am using the below metas
For me this problem occurred only while using fixed toolbars…
same problem here… flickering only occurs in fullscreen-mode (home-screen-app) and using fixed toolbars. It does not flicker when running the page in safari
Hi, I switched over to this update and quickly switched back to 1.0.1 after experiencing the new “Fade” transition behavior on iOS 5.0
As Matty emphasized in his post, the transitions on iOS (5.0 in my case) seem terrible and need a lot of work. Huge step back from 1.0.1
Keep in mind, I am still experiencing “Slide” transition issues on iOS 5.0 in release 1.0 and 1.0.1. The “Slide” transition seems to work fine in iOS 4.3 in the emulator.
Transitions are one of the most attractive aspects of jQM. Please play closer attention and take more care in building out this critical behavior before releasing updates.
Hi, We noticed exactly the same thing with several Samsung Galaxy SII’s (2.3.3) and a Galaxy Tab (3.2). Only difference in app was moving from 1.1.0-rc1 from 1.0.1.
Agreed, same here.
Yes, the new fixed toolbars are great, but why doesn’t work the “slide” transition? On Galaxy s with 2.3.6 …
See the section on the new transitions. We now test for 3D support and fall back to fade for all transitions if this test fails to exclude Android 2.x and other poorly performing platforms.
any word on having the ‘back’ button fixed in mango?
Is there an issue in the tracker for this?
Really love the work being done here!
Not sure if the GitHub repo is the right place, I can’t seem to find this ‘zoom.iosfocusfix.js’?
We might have rolled that into another plugin…need to double check that file name.
Typo: We now have a solid re-write that provides true fixed toolbars on the a lot of popular platforms and safely falls back to static toolbar positioning in other browsers.
Don’t think “the” was intended.
Since upgrading, I’m having trouble pulling values from radio buttons within it’s own bind(“change”) event. All values returned are undefined. Any ideas?
Mind logging and issue with test page?
When I try to turn off tapToggle feature with $(“[data-role=footer]”).fixedtoolbar({ tapToggle: false }), the page’s header (except the first page) will be invisible by default. Check it with the following code:
test page
Page Main
Go to Page One
Page Footer
Page One
WHERE is the header?
Bala bala …
Page Footer
$(document).ready(function(){
$(“[data-role=footer]”).fixedtoolbar({ tapToggle: false });
$(“[data-role=header]”).fixedtoolbar({ tapToggle: false });
});
Same problem here.
great work JQM team, would you have a roadmap for out of the box carousel support ? and in general is there a link where we can see all release planned features.
fixed toolbars – works!!!! well done guys
Fixed Headers are great on most devices but don’t seem to work on Samsung Galaxy S Android 2.3 – they don’t scroll with the page, just reposition when you stop scrolling
We’ve seen some odd behavior in Android where certain devices/builds have non-standard CSS position:fixed behavior. If the bars are repositioning themselves after scroll, that means that your version of 2.3 handles :fixed that way because we’re using native features here, we’re not re-positioning the toolbars via JS. Odd though, both of our 2.3 devices have true fixed toolbars. Hooray for Android fragmentation, yours has a cool “feature” others don’t.
This sounds more like an 1.5 update (not an 1.1). Very awesome!
I am soooo grateful to the jQuery Mobile developers. It enables non-GUI programmers to create nice looking user interfaces with less effort and more reach than native apps. Plus, the things I learn from using jQuery Mobile apply to browser based development in general.
没事做，来你博客看看。
I have problem with this release and google maps.
The new CSS from 1.1 RC cause defects in google maps.
The map zoom feature looks defect.
I haven’t tested it, but just based on your description it sounds like a similar problem that twitter bootstrap ran into https://github.com/twitter/bootstrap/issues/1552
There the issue was with max-width on img being set to 100%
Workaround (@splaice) was adding this to the css:
#map_canvas img {
max-width: none;
}
Again only conjecture as I have not actually tested it.
Danny thanks for your help,
the issue was solved by setting:
#map_canvas img {
max-width: none;
}
Congratulation !! But I think that i found a bug
// with JQM 1.0 get the value, but with JQM 1.1 RC get “Undefined”
var value = $(“input[type=’radio’]:checked”).val();
I had the same problem, the response I got was “Mind logging and issue with test page?”
Unfortunately I reverted all of my code and jquery back to 1.0.1 after trying to work around it for a couple hours.
The reason they ask you to file a bug report, is so it gets added to the queue to get fixed. If the team isnt aware of the issue, how are they supposed to fix it?
Like the new transitions and data-position=fixed – however I’m having a problem when both header and footer have. data-position= fixed. The header is fixed, but the footer is not 🙁 It scrolls up and down as if it were inline, or am I missing the point here? Should it not be fixed so it is visiable all the time when you scroll up and down? Great work, look forward to test the data-enhance=false 🙂
Simply fantastic progress and changes here. Really loving it. Thank you all so much.
I am testing using Galaxy nexus (android 4). Fixed tool bar works fine. However, when orientation changes to landscape, the tool bar does not function as expected. I have to roll back the version to 1.0.1. Please fix the orientation change issue. Thanks.
Just tested RC2 build, the fixed tool bar length does not change when orientation switch from portrait to landscape, same issue as RC1.
I tried testing a sample two page app on Android 2.3.3 emulator installed on Ubuntu11.10 system. It was not rendering the first page itself, then when i switched back to v1.0.1 it worked fine for me.
Is it a bug??
I had a look at the new release on some platforms, mainly for the fixed toolbars functionality and I observed that for iOS5 (iPhone) and BB7 everything works great related to the fixed toolbars.
On Android 4 (Nexus), not everything worked so smoothly like on iOS5/BB7. As long as I was keeping the phone on Portrait orientation everything worked ok, similar if keeped the phone on Landscape, and also I observed no problem when changing the orientation from Landscape to Portrait, BUT when changing orientation from Portrait to Landscape, the width of the toolbars did not changed, remaining the same as in Portrait orientation. After some tapping on the page the toolbars stretched finally on the entire screen width. But after this the behavior of the fixed toolbars become more erratic, the toolbars being some time on the screen, and after some scrolling simply disappearing, and appearing again after some more scrolling.
Also on Android 2.3 the behavior of the fixed toolbars is identical with the behavior that they had in 1.0 and 1.0.1 releases.
Transitions seemed very ok on all devices, I couldn’t observe any issue.
Great work guys !
I hope that you could fix the behavior for fixed toolbars on Android 2.* and 4 also.
I really like the ‘fixed toolbars fix’ though their are some improvements needed! For instance there is no option to disable the automatic padding, which is needed for a 2 column layout (like iPad fixed menu) where the padding is not necessarily. I now need to replace the ‘updatePagePadding’ function myself and check if the page column is visible and just return without adjusting padding. This is needed because of the fact this can’t be corrected only using CSS. A quick solution would be adding something like ‘data-position-options=’fixed-no-padding” 🙂
Also buttons have a ‘undefined’ theme hover bug..
Awesome!! Just in time…
I really really like nearly every single change, SAVE ONE. The FLIP SWITCH… ? It didn’t work great in the last version so I was excited to see you revamped it but it now smooshes all words so a user can’t even read them.
I’m just going to go away from the flip I think completely for now and use radio.
Thanks though for all you guys do, this thing is AWESOME!!!
why cant you leave the way the toolbars are now in ios 4?
I’d really like the toolbars re-position themselves when the user stops scrolling
Merely changing the jqm version, my header sticks to my footer and the content stays above them.
Hey, some really great updates with this version thats to all involved, just testing it out noticed a small issue with fixed footer
It seems like the min-height calculation is not quite correct when the content shorter than the viewport
You’ll notice from this example that the vertical scrollbar is always present, I think this is because there’s extra padding to accomodate the footer however that is not subtracted from the min-height value: http://jsfiddle.net/robaldred/t5WcD/
Does the fixed positioning footer bar work with a menu as well? I have updated to this version yet the header/footer behaves as it did before this update. This is on iOS5+
Just discovered JQM and am building a POC…
I noticed that on 1.0.1 I am getting a flicker when transitioning to pages that are taller than the viewport ( using iPhone4S). Tried to upgrade to 1.1.0 RC and now my flicker is gone BUT my header is disappearing when I transition back (either with a back link or using back button) and my footer is appearing fixed in the middle of my content.
Ideas?
Love the update! Much better performance on my SGS2 with Android 4.0.3. But there is one thing that is terrible! When using fixed header the transitions won’t work. They flicker.
Thought I had done something wrong, but when I removed fixed headers the transitions works like a charm.
Hi & thanks for the good work,
Unfortunately the slide transition was “better” (from an esthetic point of view) in 1.0.1. The problem is that the page first slides, then the “toPage” appears.This is somehow different from a “native” app in which you see the toPage “push” the fromPage and everything slides smoothly.
It’s a bit weird to me to see that a blank page slides then the target page shows up.
For example, you wouldn’t like a flip transition to flip to a blank page and then display the target page. Since it works perfectly for “flip”, why isn’t it the same for ‘slide’ ? Is it a bug or is it on purpose ?
At the moment, I would not use the 1.1.0 because of this problem since most of my transitions are “slide”…
Thanks for your time and for building such a nice framework !
Christophe.
Add this to your css:
.ui-icon-loading
{
background-position: center center !important;
}
Else the loading icon is not aligned in the center when using the structure css without theme.
Amazing Update! Everything is so much smoother and faster!
I tried using this as an loading message override but its not doing anything. Is there something wrong with the code. Im trying to get a loading message with the spinner and loading text “One Moment Please…”. Anyone?
$(document).bind(“mobileinit”, function(){
$(document).bind(“mobileinit”, function(){
$.mobile.loadingMessageTextVisible = true;
$.mobile.loadingMessage = “One Moment Please…”;
});
});
double $(document).bind(“mobileinit”)’s maybe
strangely this version permanently activates GPS Compass Calibration on the iphone. It wasn’t the case with the previous version. just don’t get the bug…
If you use MobiScroll with this version of jQuery Mobile, the dialog box with the scroller/clicker is covered in shadow/mask like the background. When the jQuery Mobile 1.0.1 version .css file is used in place of the 1.1.0.rc version, it works, so looks like something not right in the css file.
Appears to break simpledialog2 when using ‘button’ mode. No dialog, not error messages.
Is the hash url navigation working properly?
My hash navigation is not displaying in the URL, only the page itself lalala.php
nice mobile jQuery…i like it to use this in my mobile application..
http://tive2012.blogspot.com
Any updated time frame for a full release? Should be close according to this comment by Todd Parker about two weeks ago:
“ThemeRoller will be ready when we hit 1.1 final in about 2 weeks. There will be a tool to upgrade your 1.0 theme to 1.1 too.”
Is that still accurate? Haven’t seen any ‘official’ communication since then indicating any changes to that ‘unofficial’ schedule…
w7oosh-rap.com طه فهد مرشحة
On Windows Phone7.5 “taphold” event dose not work well
On Android2.3(HTC G12) “fixed header” has a problem. when i scroll form after clicked a “textarea” in “data-role=content” ,the “fixed header” will not fixed!
When I use data-position=”fixed” on a header or footer, the page flickers shortly after the transition