-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Bugfix for #3288 #3290
Bugfix for #3288 #3290
Changes from all commits
59abc6f
83765f0
ca2ada8
9afaf8b
8312e62
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -51,8 +51,11 @@ $.widget( "mobile.checkboxradio", $.mobile.widget, { | |
}); | ||
|
||
// Wrap the input + label in a div | ||
input.add( label ) | ||
.wrapAll( "<div class='ui-" + inputtype + "'></div>" ); | ||
var wrapper = document.createElement('div'); | ||
wrapper.setAttribute('class','ui-'+inputtype); | ||
input[0].parentNode.insertBefore(wrapper,input[0]); | ||
wrapper.appendChild(input[0]); | ||
wrapper.appendChild(label[0]); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did we get confirmation from @toddparker, @scottjehl, or @Wilto as to whether the order of the input and label matters? The original code would preserve the content order in the file, while the new change forces labels to always come after the input. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope—no issues with input/label source order, as far as I know. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It seems that in original version checkboxradio plugin also always places the label after the input element even if the label was set before the input in the markup. I also don’t see any ‘data’ attributes that allow to change this order. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you look at the implementation of There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... just to finish off my last comment ... so this:
will actually produce a collection that reflects the order in which the input and label appear in the document, even though the label was added to the collection containing the input. When wrapAll() is called, the items in the collection are added in the order they appear in the collection, into the new div, which means the order they appeared in the document is preserved. Knowing about this default document order sorting of elements in the collection is why I originally flagged this change. |
||
|
||
label.bind({ | ||
vmouseover: function( event ) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I like the fact that we are searching for a listview in a dialog. If this is an optimization for a custom select menu, then perhaps a constructor config option is in order, for example $("#foo").dialog({ addCornerBottom: false }).
Also, I get what you are caching in the footer var added, but for someone new reading that code, I'm not so sure it's obvious because the collection context changes quite a bit in that chain. ( dialog > header > dialog > content + footer). If we need to cache things, I'm wondering if it will be easier to read if we broke the chain into 2 parts, followed by the config check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To follow on to what Kin is saying, this sort of "lite" coupling between widgets is something we suffer from everywhere in the library. If we want this to be a general purpose configuration for performance reasons (see kin's example) it's fine to put it in the dialog but otherwise if it's widget specific (in this case listview specific) we should find a way to move this to the listview itself.