By default, jQuery Mobile will automatically enhance certain native form controls into rich touch-friendly components. This is handled internally by finding form elements by tag name and running a plugin method on them, so for instance, a select element will be found and initialized with the "selectmenu" plugin, while an input element with a type="checkbox" will be enhanced with the "checkboxradio" plugin. Once initialized, you can address these enhanced components programmatically through their jQuery UI widget API methods (see documentation on available methods here: Form Plugin Methods).
-
+
Preventing auto-initialization of form elements
If you'd prefer that a particular form control be left untouched by jQuery Mobile, simply give that element the attribute data-role="none". For example:
Or, if you'd like to prevent auto-initialization without adding attributes to your markup, you can customize the selector that is used for preventing auto-initialization by setting the page plugin's keepNative option (which defaults to "[data-role="none"]. Be sure to configure this option inside an event handler bound to the mobileinit event, so that it applies to the first page as well as subsequent pages that are loaded.
One special case is that of selects. The above sample will prevent any and all augmentation from taking place on select elements in the page if select is included. If you wish to retain the native performance, look/feel of the menu itself and benefit from the visual augmentation of the select button by jQuery Mobile you can set $.mobile.nativeSelectMenu to true in a mobileinit callback as a global setting or use data-native="true" on a case by case basis.
+
Dynamic form layout
In jQuery Mobile, all form elements are designed to be a flexible width so they will comfortably fit the width of any mobile device. One optimization built into the framework is that we present labels and form elements differently based on screen width.
-
If a page is fairly narrow (~480px), the labels are styled as block-level elements so they will stack on top of the form element to save horizontal space.
+
If a page is fairly narrow (~480px), the labels are styled as block-level elements so they will stack on top of the form element to save horizontal space.
On wider screens, the labels and form elements are styled to be on the same line in a 2-column layout to take advantage of the screen real estate.
Field containers
-
+
To improve the styling to labels and form elements on wider screens, we recommend wrapping a div or fieldset with the data-role="fieldcontain" attribute around each label/form element. The framework will add a thin vertical bottom border on this container to act as a field separator and visually align the label and form elements for quick scanning.
-
\ No newline at end of file
+
diff --git a/docs/forms/forms-all.html b/docs/forms/forms-all.html
index cc116b03..665988fb 100755
--- a/docs/forms/forms-all.html
+++ b/docs/forms/forms-all.html
@@ -1,14 +1,14 @@
-
-
+
+
-
- jQuery Mobile Docs - Forms
-
+
+ jQuery Mobile Docs - Forms
+
-
-
+
+
@@ -17,43 +17,43 @@
-
+
-
+
-
\ No newline at end of file
+
diff --git a/docs/forms/forms-selects.html b/docs/forms/forms-selects.html
index 7c9f32a8..c6259f3b 100644
--- a/docs/forms/forms-selects.html
+++ b/docs/forms/forms-selects.html
@@ -1,15 +1,15 @@
-
-
+
+
-
- jQuery Mobile Docs - Forms
-
+
+ jQuery Mobile Docs - Forms
+
-
-
+
+
@@ -18,19 +18,19 @@
-
+
+
+
-
-
+
+
-
+
Disabled options
jQuery Mobile will automatically disable and style option tags with the disabled attribute. In the demo below, the second option "Rush: 3 days" has been set to disabled.
If no items are selected, the button's text will default to the placeholder text.
If no placeholder element exists, the default button text will be blank and the header will appear with just a close button. Because this isn't a friendly user experience, we recommended that you always specify a placeholder element when using multiple select boxes.
-
+
-
+
When a select is large enough to where the menu will open in a new page, the placeholder text is displayed in the button when no items are selected, and the label text is displayed in the menu's header. This differs from smaller overlay menus where the placeholder text is displayed in both the button and the header, and from full-page single selects where the placeholder text is not used at all.
-
+
+
+
+
+
Data attribute support
+
You can specify any jQuery Mobile button data- attribute on a select element too. In this example, we're setting the theme, icon and inline properties though data- attributes.
A "page" in jQuery Mobile consists of an element (usually a div) with a data-role attribute set to "page", which generally contains div elements with roles of "header", "content", and "footer", each containing common markup, forms, and custom jQuery Mobile widgets.
-
The basic workflow with page loading is as follows: first, a page is requested with a normal HTTP request, and subsequent "pages" are then requested and injected into that page's DOM. Because of this, the DOM may have a number of "pages" in it at a time, each of which can be re-visited by linking to its ID attribute.
+
The basic workflow with page loading is as follows: first, a page is requested with a normal HTTP request, and subsequent "pages" are then requested and injected into that page's DOM. Because of this, the DOM may have a number of "pages" in it at a time, each of which can be re-visited by linking to its data-url attribute.
When a url is initially requested, there may be one or more "pages" in the response, and only the first one will be shown. The advantage of storing more than one "page" is that it allows you to pre-fetch static pages that are likely to be visited.
@@ -52,31 +52,20 @@
jQuery Mobile manages http requests using a combination of generated absolute URL paths and manipulating a generated <base> element's href attribute. The combination of these two approaches allows us to create URLs that contain full path information for loading pages, and a base element to properly direct asset requests made by those loaded pages (such as images and stylesheets).
-
jQuery Mobile core contains 4 internal functions for manipulating a base url to be used in normalizing relative http requests:
-
Note: These functions have changed - docs will be updated soon!
-
-
getPathDir: function that returns a path with the last "/"-split segment removed (which is assumed to be a file url).
-
getBaseURL: function that returns either the location.hash, or a path specified via its argument, with the last segment removed.
-
setBaseURL: sets the <base> element's href attribute to the value of getBaseURL()
-
resetBaseURL: sets the <base> element's href attribute to the relative path of the initially-http-requested page.
-
These are called at certain times during page requests and transitions:
- On DOM ready, during the initial page load, a <base> element is created and appended to the <head> of the page. Immediately after that, resetBaseURL() is called to set the <base> element's href to location.pathname.
-
-
Whenever a link with a relative URL is clicked, the $.mobile.changePage() function will prefixed that link's href with the value of getBaseURL(), which creates a full path to that file, relative to the document.
-
-
Changing the hash value triggers the hashchange event handler, which first calls resetBaseURL(), and makes an Ajax request to the value of the hash (which is already a full path, requiring no base url). After that request is sent, setBaseURL() is called, which resets the <base> element's href attribute to the value of getBaseURL() and allows any references to images, stylesheets, and scripts within that page to be requested with a proper base path.
+
TODO: update description of internal base and urlHistory objects
+
Auto-generated pages and sub-hash urls
-
Some plugins may choose to dynamically break a page's content into separate navigable pages, which can then be reached via deep links. One example of this would be the Listview plugin, which will break a nested UL (or OL) into separate pages, which are each given an ID so they can be linked to like any normal "page" in jQuery Mobile. However, in order to link to these pages, the page that generates them must first be requested from the server. To make this work, pages that are auto-generated by plugins use the following special ID structure:
- <div id="page.html&subpageidentifier">
+
Some plugins may choose to dynamically break a page's content into separate navigable pages, which can then be reached via deep links. One example of this would be the Listview plugin, which will break a nested UL (or OL) into separate pages, which are each given a data-url attribute so they can be linked to like any normal "page" in jQuery Mobile. However, in order to link to these pages, the page that generates them must first be requested from the server. To make this work, pages that are auto-generated by plugins use the following special data-url structure:
+ <div data-url="page.html&subpageidentifier">
-
So, for example, a page generated by the listview plugin may have an ID like this: id="artists.html&ui-page=listview-1"
+
So, for example, a page generated by the listview plugin may have an data-url attribute like this: data-url="artists.html&ui-page=listview-1"
When a page is requested, jQuery Mobile knows to split the URL at "&ui-page" and make an HTTP request to the portion of the URL before that key. In the case of the listview example mentioned above, the URL would look like this: http://example.com/artists.html&ui-page=listview-1
- ...and jQuery Mobile would request artists.html, which would then generate its sub-pages, creating the div with id="artists.html&ui-page=listview-1", which it will then display as the active page.
+ ...and jQuery Mobile would request artists.html, which would then generate its sub-pages, creating the div with data-url="artists.html&ui-page=listview-1", which it will then display as the active page.
-
Note that the ID of the element contains the full URL path, not just the portion after &ui-page=. This allows jQuery Mobile to use a single consistent mechanism that matches URLs to page IDs.
+
Note that the data-url attribute of the element contains the full URL path, not just the portion after &ui-page=. This allows jQuery Mobile to use a single consistent mechanism that matches URLs to page data-url attributes.
Cases when Ajax navigation will not be used
@@ -96,7 +85,7 @@
When linking to directories, without a filename url, (such as href="typesofcats/" instead of href="typesofcats/index.html"), you must provide a trailing slash. This is because jQuery Mobile assumes the section after the last "/" character in a url is a filename, and it will remove that section when creating base urls from which future pages will be referenced.
-
Any unique assets referenced by pages in a jQuery Mobile-driven site should be placed inside the "page" element (the element with a data-role attribute of "page"). For example, links to styles and scripts that are specific to a particular page can be referenced inside that div. However, a better approach is to use jQuery Mobile's page events to trigger specific scripting when certain pages load.
+
Any unique assets referenced by pages in a jQuery Mobile-driven site should be placed inside the "page" element (the element with a data-role attribute of "page"). For example, links to styles and scripts that are specific to a particular page can be referenced inside that div. However, a better approach is to use jQuery Mobile's page events to trigger specific scripting when certain pages load. Note: you can return a page from the server with a data-url already specified in the markup, and jQuery Mobile will use that for the hash update. This allows you to ensure directory paths resolve with a trailing slash and will therefore be used in the base url path for future requests.
Conversely, any non-unique assets (those used site-wide) should be referenced in the <head> section of an HTML document, or at the very least, outside of the "page" element, to prevent running scripts more than once.
The "ui-page" key name used in sub-hash url references can be set to any value you'd like, so as to blend into your URL structure. This value is stored in jQuery.mobile.subPageUrlKey.
Just a simple static progressbar, for future reference.
-
-
-
-
-
-
-
-
-
-
-
-
-
\ No newline at end of file
diff --git a/experiments/ui-datepicker/index.html b/experiments/ui-datepicker/index.html
index 4f3e36e9..68ca44fd 100644
--- a/experiments/ui-datepicker/index.html
+++ b/experiments/ui-datepicker/index.html
@@ -5,67 +5,71 @@
jQuery Mobile Framework - Datepicker
-
-
+
+
+
+
+
+
-
-
-
-
-
-
-
-
Datepicker Styled for mobile
+
jQuery UI's Datepicker Styled for mobile
-
-
+
The included files extend the jQuery UI datepicker to make it suitable for touch devices. This plugin is not included in jQuery Mobile by default, so you'll need to include the files yourself if you'd like to use them. Scroll down for usage instructions.
+
+
+
+
Usage Instructions
+
+
The datepicker auto-generates from a regular input element with a type="date" attribute.
We'd recommend wrapping the label and input in a fieldcontain div for presentation purposes, and these elements should be placed within a form element for C-Grade browser accessibility.
+
+
Note: This plugin is not included in jQuery Mobile by default, so you'll need to include the following files in order to use it:
You'll also want to configure the page plugin to convert "date" input elements to "text" inputs after they're enhanced with our datepicker, so that no native datepicker will conflict with the custom one we're adding. To do this, bind to the "mobileinit" event and set input types of "date" back to text using the page plugin's options: