Incorrect state when preventting default behavior on checkboxes, radios

[ucavus]

An example of the behaviour. You should be able to cancel the checking of a box or a radio, e.g. after an "are you sure?" confirmation. The underlying form control behaves correctly but the uniform's interface shows the opposite state.

I have been able to work around this by manually changing the checked property of an element and running $.uniform.update(), but this seems a bit clunky.

Perhaps the bound click event could bind another temporary handler, using one() with the same event.type. It would then run after other attached handlers that may call preventDefault(). If the handler is not run because of another handler or returning false or calling stopImmediatePropagation(). The temporary handler could be unbound with the next click on the element, or the entire document.

[LeeBurton]

I have the same issue here, and hoped that it would have been fixed in the latest version, but unfortunately not. We chose to use UniformJS to replace jqTransform for a client, the reason being that they had to use lots of clunky hacks to get jqTransform working correctly. I would rather not have to start implementing clunky hacks for UniformJS too, so would greatly appreciate it if this could be fixed soon.

I also have an issue that the underlying element does not have the "checked" and "value" attributes set to accurately reflect the state of the parent 's "checked" class. This is not very useful when submitting forms...

For now, you should manually call the update method to get the visual appearance to match the underlying values. You can do this when you cancel the event. In the future this should not be necessary.

I'm in the slow process of rewriting Uniform to make it simpler for people to use. The JS will now poll for changes and apply updates as necessary. The double-click behavior of buttons is removed. Events that were used for Uniform updates are no longer used, such as what is causing the above issue for "checked" elements. Classes get automatically propagated to the wrapper. More states of elements are supported (not just disabled, but readonly, required, indeterminate). Having people manually call update would be only a last resort and won't usually be needed.

I'm currently rewriting how the theme sprite is used to avoid a visual glitch where the left cap can overlap on the right cap (antialiasing issue). After that I will be working on an Angular version of Uniform. The JS is quite a bit simpler and should be easier to port to other frameworks.

I've been working on this for a couple months already and I believe the JavaScript portion is done. It's taken a while as the polling used to take a large portion of time (about 7% of the time was spent in polling) and I've improved it a lot (0.04% now). I still have a long way to go as I will need to rewrite CSS to handle the new HTML structures and rebuild theme images so they can scale easier and so designers can build new images easier.

Feel free to contact me (see my GitHub page) if you want to experiment with this new version once I am able to make it style things again. I suspect that I will have a workable version in the first quarter of 2014. The biggest limiting factor here is that I'm doing this in my free time - anything that helps pay the bills will come first.

[fidian]

Sorry - posted as the wrong user. Look up fidian if you want to contact me about the Uniform rewrite.