Styling of added checkbox incorrect when in controlgroup

[offsky]

If you programmatically add a new checkbox to a controlgroup of existing checkboxes, the styling is incorrect. It does not merge the borders with the adjacent checkboxes.

Example: http://jsfiddle.net/JwWpX/1/

[samdz]

you are correct. I have tried your code in jsfiddle. It does not work. Not even with the 'trigger' or 'page' methods

[tbosch]

Yes, here is a Gist to reproduce this (with a bookmarklet to run it):
https://gist.github.com/1729775

You need to trigger the "create" event, that's missing in the example above. But even if you do so (like in my example), the old checkboxes still have the ui-corner-bottom css class.

Tobias

[samdz]

I think this is still an outstanding bug that needs to be fixed. I tried you code, even adding

$("#page").page("destroy").page();

It does not work in Firefox, safari, chrome or IE.

[klemensz]

Same problem here. Will this be fixed or is there a workaround?

[toddparker]

@tigbro - Is this a bug in jQM or Angular? Can't quite tell from this thread. If it's on our end, could you post a test page using latest? Template using latest here: http://jsbin.com/agewuy/edit

[tbosch]

Hi,
sorry, about my last comment. I confused the projects (thought that this tracker was part of my jqm angular adapter...), so I deleted my last comment.

Anyway, the issue is in jquery mobile, not in angular nor in my adapter.
Here is another jsfiddle to reproduce this (sorry, somehow the jsbin template did not work, it always showed the jqm wait icon...):
http://jsfiddle.net/hDc38/

As far as I can see, the problem is the following:
$.fn.controlgroup does not remove the style classes ui-corner-left, ui-corner-right, ui-corner-top, ui-corner-bottom.

By the way, it would be great to turn $.fn.controlgroup into a real jqm widget, just like collapsibleset or listview, with a refresh function. Same would be cool to have for $.fn.grid. This would help creating single page apps with jquery mobile that use those components.

Tobias

[toddparker]

Thanks @tigbro. Mind creating issues for making thoe into real widgets if there isn' already one? I agree we should give that a look.

[jaspermdegroot]

hi @tigbro

You are right about the cause of the problem and that means it might only require a minor change to make this work.

By adding the classes you mentioned (and ui-controlgroup-last) to the list of classes that have to be removed we can use the current controlgroup function to refresh a controlgroup as well.
Only difference with real widgets would be that you don't have to send the 'refresh' parameter: $(#mycontrolgroup).controlgroup(); This is something we would have to add to the info in the docs.

Here is a fiddle that loads a version of the JS in which I made the change: http://jsbin.com/agayas/11/
Of course it requires some more testing and thinking about edge cases but so far I don't see a problem.

I don't think controlgroup needs to become a 'real' widget because it is always used in combination with another widget (button, checkboxradio or selectmenu). So it is more like an extension of those.
Maybe we can make it work this way that when you refresh those widgets the framework checks if they are wrapped in a controlgroup and, if so, trigger controlgroup() on that element.

I am in favour of a grid widget! It would be great when the grid/block classes are added by the framework like it is done for navbars so you can dynamically inject a new block.

@offsky
In your fiddle you use document ready. In the docs at the page about events you can read why you shouldn't use that. Also, you call .checkboxradio() after appending new button markup. That function is to refresh the button after you manipulated the state of it. When injecting one you should use .trigger( "create");

[Update: changed link to new version of fiddle after relocating JS file]

[jaspermdegroot]

This line in my previous comment makes no sense: "Maybe we can make it work this way that when you refresh those widgets the framework checks if they are wrapped in a controlgroup and, if so, trigger controlgroup() on that element." Sorry.

Refreshing a button, checkboxradio or selectmenu means updating its state. No reason to refresh the controlgroup corner styles after that. It would only apply after you used trigger("create") to inject a new button. So we could look into a way to make that event trigger the controlgroup function on the parent element with data-role controlgroup

[klemensz]

Is this supposed to be resolved? I still get the same effect with 1.1.1.

[deakjahn]

Not particularly nice but it works:

function workaround($controlgroup) {
  $controlgroup
    .controlgroup()
    .trigger("create")
    .find("label, label .ui-btn-inner")
      .removeClass("ui-btn-corner-all ui-corner-top ui-corner-bottom ui-corner-left ui-corner-right ui-controlgroup-last ui-shadow")
    .end()
    .find("label:first, label:first .ui-btn-inner")
      .addClass("ui-corner-top ui-controlgroup-first ui-shadow")
    .end()
    .find("label:last, label:last .ui-btn-inner")
      .addClass("ui-corner-bottom ui-controlgroup-last ui-shadow");
}

To be called after dynamic modification of the control group.

[dotnetwise]

Bummer, this bug still exists in 1.2 Any news when it will get fixed??