Skip to main content

Jquery Mobile Form - Select Menus Part I

    Today we will take a look at the select boxes styling and usage using Jquery Mobile. Select menus has a little more explanation and examples than other controls and so I am dividing the select menus tutorial into 2 parts. In the first part, we will take a look at the basics of the Jquery Mobile select menus and in the second part we will take a look at the more complex examples involving the select menus.

    The Jquery Mobile select menu is based on the native HTML select element, which is styled and modified to suite the Jquery Mobile framework's style. By default, the framework leverages the native OS options menu to use with the custom select button. When the button is clicked, the native OS menu will open. When a value is selected and the menu closes, the custom button's text is updated to match the selected value. The framework also offers the possibility of having custom (non-native) select menus; which we will discuss in part 2 of this tutorial. Refer to the screenshots below to understand how the native select menus work.

The Native menu - Android 4.1.1/ HTC One X


The Native menu - iPhone 4S/ iOS 6.1.3


    The select boxes can be used singularly or in a vertical group or can be even grouped horizontally. These select boxes can be used along with data-mini="true" too, which renders the select boxes in a smaller size. We will take a look at all this in the example that follows.


    The first implementation of the select box in the above code is the regular, simple select box. The framework styles this select element as per the Jquery Mobile framework styles displaying a button with custom down arrow and using the native OS menu. The second implementation is exactly similar to the first one with the only difference of data-mini="true" attribute. Addition of this data attribute to the select element renders a smaller select box..

    In the next implementation we have the label and the select box aligned side-by-side. To achieve this, we need to wrap the select element with in a div with data-role="fieldcontain". Adding this data attribute to the div tells the framework to align the label and the select box side-by-side.

    In the fourth implementation we have the regular select element with the optgroup used for the options. Including options within the optgroup element, groups these options visually under a single optgroup label. However, the support for this feature in mobile selects is a bit spotty, but is improving by the day.

    Multiple select boxes can be grouped together like checkboxes or radio buttons to achieve visual grouping of the select elements. The select boxes can be grouped vertically as well as horizontally. To achieve this the select elements need to be wrapped within a fieldset element with data-role="controlgroup". Doing this would group the select boxes vertically (which is the default grouping technique). To group the select boxes horizontally as seen in the last implementation, you need to add another data attribute data-type="horizontal" to the fieldset element.

    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. While the label will no longer be visible, it will be available to assisitive technologies such as screen readers.

    Hope this post has cleared out your basics of the Jquery Mobile select menus. In part 2 of this tutorial, we will take a look at the advanced select menu options where we can override the default menu behavior and create differently styled select menus. Stay tuned for the advanced topics on select menus in the next post and you can also look at the complete list of Jquery mobile listview and form elements examples. Fun is on it's way!

Comments

Recommended for You

Where does Google get it's live traffic data from?

Referring to a post that I wrote earlier, Google’s - Live traffic Layer , ever wondered how Google collected this data? I was wondering the other day, how Google received live data to display it on their maps as a layer! I looked up the web and found something very interesting and am sharing the same with you all. As we all know, the traffic layer is available most accurately in several states in USA. Most major metro areas in the US have sensors embedded in their highways. These sensors track real time traffic data. Easy to miss at high speeds (hopefully anyway, traffic permitting), more commonly noticed may be the similar sensors that often exist at many busy intersections that help the traffic lights most efficiently let the most amount of people through. The information from these tracking sensors is reported back to the Department of Transportation (DOT). The DOT uses this data to update some of the digital signs that report traffic conditions in many metro areas. They als

GIS Technology to identify all properties in BBMP Limits

          The Bruhat Bangalore Mahanagara Palike (BBMP) has for the last two years, been in the process of conducting a massive exercise to map the 13.87 lakh properties in the 198 wards in the city. Geographical Information System (GIS) has proven to be an effective tool for analysing and displaying thematic maps of all the roads for proper evaluation and correction of zones.            As of now, 11 lakh properties have come under the tax net. The aim of this programme, which is perhaps the first such exercise being conducted in the country on such a large scale, covering 800 square km, is to bring all properties under the tax net and ensure that the BBMP has accurate information pertaining to the properties’ dimension, built-up area, land use and classification. The process of validation of GIS maps will be completed in January 2011.           The process uses satellite digital maps of the BBMP area to generate a vector map from the information obtained. These high r

Geodesic Polyline

    Today we will have a look at a very interesting polyline example - "The geodesic polyline". Now the first question that will pop is "What is geodesic?". Mathematically, geodesic means the shortest line between two points on a mathematically defined surface, as a straight line on a plain or an arc of a great circle or sphere.     The next question after reading the above definition is clearly, "Why do we need geodesic polylines?" and that would be followed up with "What is this Great Circle?". We will discuss this first, before we move on to the actual example today. The example is very very similar to the normal polyline example, with just a small change.     Having said so, I will now try to explain why we need a geodesic polyline? The shortest distance between two locations on the earth is rarely a straight line as the earth is roughly spherical in nature. So any two points on the earth, even if they are very close lie on a curve and n

Playing with the markers and info window bubbles...

    In the last few posts, we have seen some marker examples and some information window examples. Now, lets do something interesting combining these two things. Just writing that "This is an info window" in the information bubble is not very interesting! And I know this...Have gone through the same phase!     So, today we will do something interesting! We will display the latitude- longitude co-ordinates of the point that the user clicks on the map! Doing this is not at all complex! Copy paste the following code and you will see for yourself a map coming to life!     The output of the above code looks as seen in the result section above! If you have any queries regarding the above code please comment on the blog post or feel free to contact me at my mail ID .

The bitter divorce of PSD and HTML

    Today's article is an interesting post that I read. The original post in Portuguese and authored by Fabricio Teixeira  can be found at arquiteturadeinformacao  (Now don't ask me pronounce this =)).     Some are calling it the death of PSD  but I prefer calling it a "divorce". PSD and HTML are both healthy and living strong, just that they do not live together anymore. "PSD to HTML", which for years was the most accurate and sometimes the only right path to web design process, seems like has its days counted.     Firstly you draw a page in Photoshop; impeccable layout, representing exactly how the web pages would appear when opened in a browser. After a sign-off on this picture (PSD) from the client the front end developer transforms these pictures into HTML, CSS and Javascript. The assets are cut, one by one, exported from the PSD and integrated into the HTML. Plugins and new tools are created in the process and some companies even charge upto $1