You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 16, 2021. It is now read-only.
Issue #270 could have been avoided entirely if Uniform detected and responded appropriately to form reset events. Unfortunately, I don't know if this feature would cause more problems than it solves, plus I'd want it to work in a really generic way. Since input elements don't need to be in a form or can be in multiple nested forms or can be automatically added/removed at a whim, the simple solution of binding to $('form').on('reset', ...) is problematic. We'd need to find the parent form, then all child elements that are uniformed. Or, perhaps a manual reset button/link is used and we need to somehow tie into that.
Due to the difficulties I currently see, I'm making this a feature request but am not implementing it for 2.0.x.
The text was updated successfully, but these errors were encountered:
@fidian , issues such as (from those I resolved recently) #348 and #349 also were related to this issue. But it is my firm belief that handling certain action mechanisms shouldn't be Uniform's responsibility. The sole goal of this package is to "style" form elements, simple as that. And in doing so, it is responsible of making sure when form elements are transformed to Uniform'ed state (i.e. uniform()) or the other way around (restore()), the values are preserved and are accurate. I realize the fact that form reset changes values as well, but to be honest, a lot of mechanisms actually change values when we start coding an interactive layer for our web views. Ultimately, we handle them ourselves, no plugin does that for us. So instead of creating event binders and potentially causing a confusion especially for new developers who hardly can capture event handlers and reuse them, I say we stay completely out of that business. The fewer bindings/event-handling we do with Uniform, the easier the task of this package will be - meaning, Uniform should strive to leave as few footprints as possible as it performs its job.
To that end, just to resolve this "reset" form issue, our users should just update their form elements via update() through setTimeout() with a millisecond delay, to avoid potential race condition, where Uniform sometimes acts sooner than browser manages actually to finish its native reset event:
That's it, this completely solves our reset problem. From here on, we will only have performance problems, tied to the speed of update(), but that's rather general problem, not necessarily related only to this reset issue. When we solve performance issues (for forms where up to hundred form elements need uniform-ing), we will solve all related problems as well.
To that end, I am closing this issue once and for all.
Issue #270 could have been avoided entirely if Uniform detected and responded appropriately to form reset events. Unfortunately, I don't know if this feature would cause more problems than it solves, plus I'd want it to work in a really generic way. Since input elements don't need to be in a form or can be in multiple nested forms or can be automatically added/removed at a whim, the simple solution of binding to
$('form').on('reset', ...)
is problematic. We'd need to find the parent form, then all child elements that are uniformed. Or, perhaps a manual reset button/link is used and we need to somehow tie into that.Due to the difficulties I currently see, I'm making this a feature request but am not implementing it for 2.0.x.
The text was updated successfully, but these errors were encountered: