Skip to content

December 5, 2012


jQuery Mobile: The Concept of Linking Mobile Pages (2)

by Joe Kuan

Scenario 3: Load mobile page from another HTML document via Ajax

Recalling the scenario 2, we can load a mobile page from another HTML document using a normal HTTP request. This is the simplest way to load an external mobile page because any custom JavaScript code (e.g. pageinit handler code) can be put inside the <script> embedded inside the HTML <head> section. So once the document is loaded with HTTP request, the pageinit bind event code is also guaranteed to be run for all the mobile pages in that document. The downside is that we don’t get animated page transition because the previous DOM has been destroyed from the new document load.

This scenario explains how jQM can load an external mobile page using Ajax to preserve the existing DOM and achieves animated page transition. However, that means special care on pageinit handler code is required. The setting is pretty much the same as scenario 2 that index.html contains a menu page with reference to A.html and B.html and JavaScript code/files embedded inside the <head> section. The only difference is that no special attribute (data-ajax=’false’) is used, hence the default transfer method for remote page is via Ajax load. The following diagram summaries how this is done:

jQuery Mobile: Loading mobile page block from another HTML document via Ajax

jQuery Mobile: Loading mobile page block from another HTML document via Ajax

First, index.html is loaded from normal HTTP request, any code within <script> tags are executed and the first mobile page is initialised, rendered and pageinit is triggered. Then the user clicks on menu linked to B.html, jQM launches Ajax request (by default) to retrieve the remote document in the background. At this point, the user still have control over the web interface. When the remote document arrives, jQM extracts the first mobile page block which is B1. The framework loads and inserts the whole page B1 <div> content into current document DOM. As a result, any JavaScript code within the <head> section and other mobile page contents are ignored, except the <script> code placed inside the B1 page block. Note that this embedded <script> is run before the B1 page is inserted to the DOM, initialised and then rendered. Hence the page initialisation code is loaded before the pageinit is triggered. Since this is all happening through Ajax and the DOM level, it is possible for jQM to animate page transition between the menu page and page B1.

In a nutshell, the major difference to scenario 2 is the fragmentation of JavaScript code in the remote page. In order to insert B1 and it’s page initialisation code into the browser current document, the JavaScript code specific to the page needs to be embedded inside the page block. It is because there is no way to tell the client browser to run JavaScript code selectively for page B1.

Scenario 4: Load mobile page from another HTML document via Ajax – another approach

Another approach to retrieve remote mobile page via Ajax is to put the custom JavaScript code in the referrer, so that there is no need to embed the JavaScript code into specific page block.  The following diagram illustrates how this is done:

jQuery Mobile: Loading mobile page from another HTML document - approach 2

jQuery Mobile: Loading mobile page from another HTML document – approach 2

The setting for this scenario is slightly different and redundant. This time all the initialisation code for B.html are also put inside the <head> section of index.html. So when the index.html is loaded, it runs all the JavaScript code which includes the initialisation code for pages in B.html. Then users selects menu B to bring up the first page block in B.html via Ajax request. JQM extracts the page content and inserts into current DOM but there is no embedded <script> to run this time. The page is initialised and rendered, it also triggers the pageinit event and runs the handler code loaded in the beginning.

This approach has couple drawbacks. First, a considerable amount of JavaScript code needs to be loaded initially if a remote page is several levels deep from the top level page. It also loads the code for some of the mobile pages that may never be used during a user session. Secondly, this approach requires more management in loading JavaScript code/files than scenario 3. This is because the JavaScript code/files are duplicated in the <head> section in both index.html and B.html. E.g. If B.html is required to include another JavaScript file, same change needs to be applied to index.html. Moreover, if there are more than one file referencing B.html, the effort to keep JavaScript code in sync also increases.


There are 4 different ways of linking mobile pages with JavaScript code. Scenario 1 demonstrates how to load mobile page in local document, scenarios 2 loads remote mobile page in normal HTTP request, whereas scenarios 3 and 4 illustrates the subtle difference of loading remote mobile page via background Ajax load. There are tradeoff between scenarios 2, 3 and 4; scenario 2 requires the least JavaScript code management but cannot have animated page transition. Scenarios 3 and 4 allows page transition but requires splitting JavaScript code.


For the demo, try them on your desktop browser: Scenario 1, Scenario 2, Scenario 3 and Scenario 4. Bring up JavaScript console and observe the console log messages output (generated from pageinit handlers) as well as the document and XHR transfers in the Network section. For the source code, click here to download.

Read more from jQuery Mobile, Web
4 Comments Post a comment
  1. There’s definately a lot to know about this topic. I love all the points you have made.

  2. val
    Aug 16 2013

    hello, before all, thanks very much for this post, i nedd to ask about multipage navegacion on scenario 3 and 4, it´s possible? i try use it multipage navigation on a loaded page from another HTML document via Ajax, e.g.: user click on href=”scen_4A.html” button, load page, user click on href=”#4B” — nothing happends

    • Joe Kuan
      Aug 20 2013

      Sorry for the late reply. I am currently on leave until the end of this week. I wrote that article ages ago, so it will take me a while to recap the topic. Let me know if you still need my help.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: