Saturday, February 18, 2012

Radio buttons and jQuery Mobile

APEX 4.2 is supposed to put mobile front and center in APEX. But some developers aren't waiting. If you're in that small group of folks that is pushing forward with mobile development using jQuery Mobile prior to version 4.2, you may have found an issue with radio buttons.

jQuery Mobile does a fantastic job of enhancing the look and feel of elements in the DOM so that they look and work better in mobile browsers. For various reasons, including accessibly and proper alignment of elements, jQuery Mobile expects some specific HTML. In most cases, satisfying these requirements in APEX is as simple as wrapping the label and the element with a wrapper div. Even in 4.1 this can now be done from the label.

Radio buttons, on the other hand, are a good example of where APEX will need to be enhanced even more to work properly with jQuery Mobile. For now we just have to do a little extra work. Here's the standard HTML output for a single column radio button in APEX:

The markup produces the following when rendered in a browser:

When we go into "mobile mode" the table is gone and the elements are wrapped with a div so we get the following HTML output:

Once jQuery Mobile applies it's enhancements to the markup, we get the following rendering:

It may not be noticeable at first, seeing as how it's so different from the standard rending, but the look is not quite optimal. The reason is that jQuery Mobile is expecting output more like this:

The differences, while subtle, are important. Some are easy to spot while others are not. Here's a brief list:
  1. The fieldset that jQuery Mobile is expecting has some important attributes (data-role and data-type) 
  2. APEX uses a label for the fieldset while jQuery Mobile wants a legend (inside the fieldset)
  3. The fieldset in APEX has the CSS display property set to block via apex_4_1.min.css
  4. Each label in the fieldset in APEX is followed with a br element
  5. APEX adds the tabindex attribute (causes jQuery Mobile to "focus" incorrectly)
While we can't control everything that APEX outputs, we can modify the output after it makes it to the browser and before jQuery Mobile goes to work enhancing it. Here's some jQuery code that does just that:

Since most of use are not using the Ajax based page loading that jQuery Mobile like to use be default, putting the code in the Execute when Page Loads portion of the page attributes will work fine. Once jQuery Mobile is finished enhancing the new markup the radio buttons will render as follows:

Or, if you prefer, you can remove the optional .attr('data-type', 'horizontal') line from the JavaScript to get the following rendering:

If you haven't already gotten started with mobile development in APEX, check out Marc Sewtz's blog for details and downloads that can get you up and running quickly and easily. I'm really looking forward to seeing what Marc and the rest of the team has planned for the 4.2 release!


  1. Hi Dan,

    how about a radio group item type plugin which already emits the HTML code you need without having to modify it with jQuery? I think that would make the usage easier.


  2. Hi Dan,

    i use the standard Radio-Group and put the JQM Fieldset-Definition into Pre-/Post-Element-Text. This together with setting the "Number of Radio Columns" to 4 gives me 4 radio-buttons nicely put next to each other.

    Ok, i have to admit there is a little space between the buttons, but as you can see on (click on Konferenzprogramm) it looks quite good.

    +1 for a Plugin (as native type in APEX 4.2).

  3. Patrick,

    Having created a number of plug-ins at this point, I can say first hand that there are some downsides to them. The plug-ins must be found by those that need them and the code must be maintained going forward.

    While this additional effort may be well warranted, it's hard for plug-in developers outside of the APEX team to make that determination as we don't know what enhancements you are planning to make to the core.

    This solution should help people get to APEX 4.2. When that's released we can decide what else may need to be done.


    The spaces you mentioned would be fixed by this solution. When you use multiple columns you end up with an HTML table which is less fluid.

    Also, this solution also addresses alignment and focus issues that could occur with multiple items on the page.

    What do you mean by "plug-in as a native type"?


  4. Hi Dan,

    i agree with Patrick that a Plugin would be more usable for most developers.
    Advanced Developers can always come up with workarounds, e.g. your and my solution.

    So a Plugin would be fine.

    Even better when that Plugin is provided by Oracle or built in APEX 4.2 (that's what i meant with "native").

  5. Hi Dan,

    Nice post!

    I had the same issue a couple weeks ago.
    The solution was very easy to me: just add the code below to the page CSS.

    #P1_PETS br {
    display: none;

    This simply removes the break lines between the radio items and you're done.