jQuery’s mobile strategy can be summarized simply: A unified user interface system that works seamlessly across all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation. Focused on a feature-rich but lightweight codebase built on progressive enhancement with a flexible, theming system and ThemeRoller tool.
+jQuery's mobile strategy can be summarized simply: A unified user interface system that works seamlessly across all popular mobile device platforms, built on the rock-solid jQuery and jQuery UI foundation. Focused on a feature-rich but lightweight codebase built on progressive enhancement with a flexible, theming system and ThemeRoller tool.
The framework includes an Ajax navigation system that brings animated page transitions and a core set of UI widgets: pages, dialogs, toolbars, listviews, buttons with icons, form elements, accordions, collapsibles, and more.
-The critical difference with our approach is the wide variety of mobile platforms we’re targeting with jQuery Mobile so no browser or device is left behind. We've also focused on making jQuery Mobile easy to learn with a simple, markup-based system to applying behavior and theming. For more advanced developers, there is a rich API of global configuration options, events, and methods to apply scripting, generate dynamic pages, and even build native apps with tools like PhoneGap.
+The critical difference with our approach is the wide variety of mobile platforms we're targeting with jQuery Mobile so no browser or device is left behind. We've also focused on making jQuery Mobile easy to learn with a simple, markup-based system to applying behavior and theming. For more advanced developers, there is a rich API of global configuration options, events, and methods to apply scripting, generate dynamic pages, and even build native apps with tools like PhoneGap.
To make this broad support possible, all pages in jQuery Mobile are built on a foundation of clean, semantic HTML to ensure compatibility with pretty much any web-enabled device. In devices that interpret CSS and JavaScript, jQuery Mobile applies progressive enhancement techniques to unobtrusively transform the semantic page into a rich, interactive experience that leverages the power of jQuery and CSS. Accessibility features such as WAI-ARIA are tightly integrated throughout the framework to provide support for screen readers and other assistive technologies.
diff --git a/docs/api/events.html b/docs/api/events.html index fd879c22958..3bf9aca8381 100644 --- a/docs/api/events.html +++ b/docs/api/events.html @@ -56,7 +56,7 @@Triggers when a horizontal drag of 30px or more (and less than 75px vertically) occurs within 1 second duration but these can be configured:
$.event.special.swipe.scrollSupressionThreshold (default: 10px) – More than this horizontal displacement, and we will suppress scrolling.$.event.special.swipe.durationThreshold (default: 1000ms) – More time than this, and it isn’t a swipe.$.event.special.swipe.durationThreshold (default: 1000ms) – More time than this, and it isn't a swipe.$.event.special.swipe.horizontalDistanceThreshold (default: 30px) – Swipe horizontal displacement must be more than this.$.event.special.swipe.verticalDistanceThreshold (default: 75px) – Swipe vertical displacement must be less than this.Collapsible headings’ default icon positioning can be overridden by using the data-iconpos attribute, either at the collapsible-set level or on an individual collapsible basis.
Collapsible headings’ default icon positioning can be overridden by using the data-iconpos attribute, either at the collapsible-set level or on an individual collapsible basis.
Collapsible headings’ default icon positioning can be overridden by using the data-iconpos attribute. In the below case, data-iconpos="right".
Collapsible headings’ default icon positioning can be overridden by using the data-iconpos attribute. In the below case, data-iconpos="right".
The checkbox controls below use standard input/label markup, but are styled to be more touch-friendly. The styled control you see is actually the label element, which sits over the real input, so if images fail to load, you'll still have a functional control. In most browsers, clicking the label automatically triggers a click on the input, but we've had to trigger the update manually for a few mobile browsers that don't do this natively. On the desktop, these controls are keyboard and screen-reader accessible. View the data- attribute reference to see all the possible attributes you can add to checkboxes.
-To create a single checkbox, add an input with a type="checkbox" attribute and a corresponding label. If the input isn’t wrapped in its corresponding label, be sure to set the for attribute of the label to match the id of the input so they are semantically associated.
To create a single checkbox, add an input with a type="checkbox" attribute and a corresponding label. If the input isn't wrapped in its corresponding label, be sure to set the for attribute of the label to match the id of the input so they are semantically associated.
There are therefore two ways to create a checkbox and with a label as shown below:
diff --git a/docs/forms/docs-forms.html b/docs/forms/docs-forms.html
index 2d2a449cd0c..d3cc7582e2e 100644
--- a/docs/forms/docs-forms.html
+++ b/docs/forms/docs-forms.html
@@ -54,7 +54,7 @@ Mini sized elements
Hiding labels accessibly
- For the sake of accessibility, jQuery Mobile requires that all form elements be paired with a meaningful label. To hide labels in a way that leaves them visible to assistive technologies - for example, when letting an element’s placeholder attribute serve as a label - apply the helper class ui-hidden-accessible to the label itself:
+ For the sake of accessibility, jQuery Mobile requires that all form elements be paired with a meaningful label. To hide labels in a way that leaves them visible to assistive technologies - for example, when letting an element's placeholder attribute serve as a label - apply the helper class ui-hidden-accessible to the label itself:
<label for="username" class="ui-hidden-accessible">Username:</label>
diff --git a/docs/forms/selects/index.html b/docs/forms/selects/index.html
index 0162e98a90f..e96addade95 100644
--- a/docs/forms/selects/index.html
+++ b/docs/forms/selects/index.html
@@ -286,7 +286,7 @@ Vertically grouped select inputs
Select inputs can also be used for grouped sets with more than one related selections. To make a horizontal button set, add the data-type="horizontal" to the fieldset. Note that the buttons which trigger the select will resize depending on the currently selected option’s value. Note that browsers without support for display: inline-block; will group the selects vertically, as above.
Select inputs can also be used for grouped sets with more than one related selections. To make a horizontal button set, add the data-type="horizontal" to the fieldset. Note that the buttons which trigger the select will resize depending on the currently selected option's value. Note that browsers without support for display: inline-block; will group the selects vertically, as above.
<fieldset data-role="controlgroup" data-type="horizontal">
diff --git a/docs/pages/page-anatomy.html b/docs/pages/page-anatomy.html
index 89723a63ff1..237ed98a33e 100644
--- a/docs/pages/page-anatomy.html
+++ b/docs/pages/page-anatomy.html
@@ -178,7 +178,7 @@ Multi-page template structure
Conventions, not requirements
-Although the page structure outlined above is a recommended approach for a standard web app built with jQuery Mobile, the framework is very flexible with document structure. The page, header, content, and footer data-role elements are optional and are mostly helpful for providing some basic formatting and structure. The page wrapper that used to be required for auto-initialization to work is now optional for single page documents, so there isn't any required markup at all. For a web page with a custom layout, all of these structural elements can be omitted and the Ajax navigation and all widgets will work just like they do in the boilerplate structure. Behind the scenes, the framework will inject the page wrapper if it's not included in the markup because it’s needed for managing pages, but the starting markup can now be extremely simple.
+Although the page structure outlined above is a recommended approach for a standard web app built with jQuery Mobile, the framework is very flexible with document structure. The page, header, content, and footer data-role elements are optional and are mostly helpful for providing some basic formatting and structure. The page wrapper that used to be required for auto-initialization to work is now optional for single page documents, so there isn't any required markup at all. For a web page with a custom layout, all of these structural elements can be omitted and the Ajax navigation and all widgets will work just like they do in the boilerplate structure. Behind the scenes, the framework will inject the page wrapper if it's not included in the markup because it's needed for managing pages, but the starting markup can now be extremely simple.
Note that in a multi-page setup, you are required to have page wrappers in your markup in order to group the content into multiple pages.
diff --git a/docs/pages/page-scripting.html b/docs/pages/page-scripting.html
index ab5a79ab487..9a61cc21584 100644
--- a/docs/pages/page-scripting.html
+++ b/docs/pages/page-scripting.html
@@ -93,11 +93,11 @@ Create vs. refresh: An important distinction
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 placed on an element container to tell 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 auto-initialization.
- 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.
+ 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 placed on an element container to tell 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 auto-initialization.
+ 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 child links or forms from the AJAX navigation system behavior.
+ 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 child links or forms from the AJAX navigation system behavior.
Scrolling to a position within a page
diff --git a/docs/pages/page-titles.html b/docs/pages/page-titles.html
index e0e62ab8587..0053f412440 100644
--- a/docs/pages/page-titles.html
+++ b/docs/pages/page-titles.html
@@ -27,7 +27,7 @@ Page titles
Titles in Ajax navigation
- When you load the first page of a jQuery Mobile based site, then click a link or submit a form, Ajax is used to pull in the content of the requested page. Having both pages in the DOM is essential to enable the animated page transitions, but one downside of this approach is that the page title is always that of the first page, not the subsequent page you’re viewing.
+ When you load the first page of a jQuery Mobile based site, then click a link or submit a form, Ajax is used to pull in the content of the requested page. Having both pages in the DOM is essential to enable the animated page transitions, but one downside of this approach is that the page title is always that of the first page, not the subsequent page you're viewing.
To remedy this, jQuery Mobile automatically parses the title of the page pulled via Ajax and changes the title attribute of the parent document to match.
Titles in multi-page templates
diff --git a/docs/pages/page-transitions.html b/docs/pages/page-transitions.html
index b462b2ef405..92b1ed7f4f8 100644
--- a/docs/pages/page-transitions.html
+++ b/docs/pages/page-transitions.html
@@ -133,7 +133,7 @@ Defining fallback transitions for non-3D support
$.mobile.transitionFallbacks.slideout = "none"
Setting a max scroll for transitions
- By default, transitions are disabled (set to "none") when you’re either coming FROM or going TO a page where the scroll position is 3x the height of the device’s screen.
+
By default, transitions are disabled (set to "none") when you're either coming FROM or going TO a page where the scroll position is 3x the height of the device's screen.
This feature was added because of the slow response times and the possibility of browser crashing when clicking on a list item (or any navigation element) far down a long page which leads to the
browser trying to animate a really massively tall page from the scroll position to the top of the screen. The scroll position, not total screen height, is the determining factor for performance.
This scroll position breakpoint is configurable via the new getMaxScrollForTransition function.
diff --git a/docs/toolbars/bars-fixed.html b/docs/toolbars/bars-fixed.html
index b332d703748..d4c49359629 100644
--- a/docs/toolbars/bars-fixed.html
+++ b/docs/toolbars/bars-fixed.html
@@ -89,7 +89,7 @@ Known issue with form controls inside fixed toolbars, and programmatic scrol
Known issues in Android 2.2/2.3
-
Android 2.2/2.3’s implementation of position: fixed; can, in conjunction with seemingly unrelated styles and markup patterns, cause a number of strange issues, particularly in the case of position: absolute elements inside of position: fixed elements. While we’ve done our best to work around a number of these unique bugs within the scope of the library, custom styles may cause a number of issues.
+ Android 2.2/2.3's implementation of position: fixed; can, in conjunction with seemingly unrelated styles and markup patterns, cause a number of strange issues, particularly in the case of position: absolute elements inside of position: fixed elements. While we've done our best to work around a number of these unique bugs within the scope of the library, custom styles may cause a number of issues.
- Form elements elsewhere on the page—select menus in particular—can fail to respond to user interaction when an empty absolute positioned element is placed within a fixed position element. In rare cases—and specific to Android 2.2—this can cause entire pages to fail to respond to user interaction. This can seemingly be solved by adding any character to the absolute positioned element, including a non-breaking space, and in some cases even whitespace.
- The above-described issue can also be triggered by an absolute positioned image inside of a fixed position element, but only when that image is using something other than its inherent dimensions. If a height or width is specified on the image using CSS, or the image src is invalid (thus having no inherent height and width), this issue can occur. If an image that is inherently, say, 50x50 pixels is placed in a fixed element and left at its inherent dimensions, this issue does not seem to occur.
@@ -98,7 +98,7 @@ Known issues in Android 2.2/2.3
- Any element that triggers the on-screen keyboard, when placed inside a
position: fixed element, will fail to respond to user input when using anything other than the default keyboard. This includes Swype, XT9 or, it seems, any input method apart from the standard non-predictive keyboard.
- While we will continue to try to find ways to mitigate these bugs as best we can, we currently advise against implementing fixed toolbars containing complicated user styles and form elements without extensive testing in all versions of Android’s native browser.
+ While we will continue to try to find ways to mitigate these bugs as best we can, we currently advise against implementing fixed toolbars containing complicated user styles and form elements without extensive testing in all versions of Android's native browser.
The following pages are designed to test fixed toolbars and form elements:
demo app,