If I use 'a href' to navigate between the pages and then go backwards using history.back() from Page 13, then I get this path: Page 13 -> Page 1 -> Page 0

If I use $.mobile.navigate to navigate between the pages and then going backwards using history.back() from Page 13, then I get this path: Page 13 -> Page 1 -> Page 12 -> Page 1 -> Page 11 -> Page 1 -> Page 0.

Items as 'iOS Orientaion Change', 'Match Media Polyfill', 'nojs Classes' and other excotics items, how do I know if I'm using these? If I havn't done anything specific regarding these items, can I conclude that my solution is not using them?

When using the Theme Roller, I can upload my 'old' theme and download a new version in the newest format.

It would be lovely if the same could be done when using the Download builder. Instead of I must select/deselect items every time I want to download a new version of my JQM build, it would be nice if I could just upload a configuration file and then all my seletions/deselections were done.

It is just an idea. It would make upgrading much faster, as I dont have to remember which settings I use for each of my JQM projects.

It's nice to see that we (as in users of JQM) is not the only one that can get frustrated from time to time.

These was found in the comments in 1.2.0-RC2:

// TODO sweet jesus we need to break some of this out

//append to page and enhance // TODO taging a page with external to make sure that embedded pages aren't removed // by the various page handling code is bad. Having page handling code in many // places is bad. Solutions post 1.0

// TODO sort out a better way to track sub pages of the listview this is brittle

// TODO extremely confusing dependency on the open method where the pagehide.// bindings are stripped to prevent the parent page from disappearing. The way // we're keeping pages in the DOM right now sucks

// TODO exceedingly naive method to determine difference // ignores value changes etc in favor of a forcedRebuild // from the user in the refresh method

// use the prototype options so that people can set them globally at // mobile init. Consistency, it's what's for dinner

To all you developers, thanks for a great work. It can be frustrating from time to time, but we are a lot of people that appreciate your work.

Is there a way to force JQM into believe that the code is executed under another browser/platform than it really is?

An example could be fooling JQM into thinking that it is execution on a 'Retina' display, when it is actually running in Firefox. I know I could use a Proxy, where I can set these 'properties' but if there is a buildin debug/dev mode I could use instead, I would do that.

I have just found out that beta 1 is released and have already implemented into production :-)

The scroll of listviews seams to be much better, thanks for that.

Is there anyway that I can subscribe to posts on the blog? I keep getting tired of looking by 'Blog' every day. It would be nice to be able to subscribe to an email service sending me a notification when there is a new Blog.

On my mobile web app (http://gosushi.dk/mobile/default.aspx) when ever there is a transistion to a page, that doesn't fill the whole screen, the url bar is shown in Andriod. Is there not a way to do like jqMobi where the url bar is never shown, even if the user scrolls completely to the top?

On iOS there doesn't seem to be this problem.

If I can use 'native' JQM that would be great as I'm not that keen on importing more plugins as the file sizes are big enough as it is :-(

I have made the theme that are attached to this post. If you take a closer look you can see that the background colour of textfield (Text Input) and slider (55) are gray. Should they not be white as all the other forms elements?

My problem is that when I use it as prescribed some of colours, font etc. are not as expected. My site doesn't look nearly like the one I'm shown, when I'm creating the theme. I can get it working but only with some additional styles, but should it not just work out of the box?

I allso have some problems that when a listitem is pressed, then the 'active' theme has another font, and yes I have tried to use FireBug, but my skills must be limited as I'm unable to resolve my problem.

I have been reading some of all the discussions about the new RC and I can see that there are a lot of things to do/fix. Someone suggested using jqMobi and because I'm new in this world I headed over to there website and watched some of there videos where the compare their solution to JQM. What surpprised was the difference in size and speed compared to JQM. I know that it's it completely different from JQM and they have another/less ambitious goal with there solution and that fine. My small research got me wandering if there are a better way to structure the code. As far as I know JQM requires JQ which doesn't have restrictions on memory, speed etc. as we do on the mobile. So when we as developers use JQ we suffer with the penalties that aren't measurable on the web because the resources isn't an issue. Do we need all the features that JQ provides us? Are all these optimized to mobile use or would it be an idea to look for optimization there to gain speed/less use of resources etc.? As I wrote above I'm novice to JQ and JQM so maybe all these question/remarks are just because of my lack of knowledge. Sorry if that's the case.

Another thing. As far as I have read some of the newly changes have made things work differently, fx. transitions. I have an idea but I don't know if it's possible at all or even make sense but I'll give it a shot. Would it be an idea to split the code into different pieces? My idea is to have a header piece that finds out what phone/browser/capabilities the client have and then load the specific piece of code (javascript file) that have been optimized specific to the capabilities of users device/browser/hardware etc.. By doing this iPhone, iPad etc. would be able to use their hardware accelerated transitions while Android uses would use the newly transitions with fade effect. In that way the code would be more tailored to the specific resources available at the client side thereby using the best solution available to the client. The size of code (down)loaded to the client would be smaller and maybe faster because there wouldn't be a lot of exceptions to take care of.There could be a fall back file if it wasn't possible to detect the client capabilities.

Sorry English isn't my primary language, but I hope you understand what I'm trying to say. If not I'll give it another try :-)