Response title
This is preview!
Move this topic
mixing JQuery Mobile with JQuery UI widgets... don't ?
in jQuery Mobile
•
12 years ago
Forgive me if this seems like a silly idea to begin with, but to "tide me over" while certain JQuery Mobile widgets do not exist yet (calendar, tabs etc.) I thought I'd just load up JQuery UI and bring those widgets in from there.
It was not pretty.
Are the two not supposed to co-exist ? Wouldn't it be nice to leverage JQ UI widgets in JQ M applications ?
Or is their CSS / js base too different to make that practical ?
Or - should it work and I just screwed up in which case I will try again :)
5
Replies(10)
Out of curiosity, what made it not so pretty? I never tried doing this yet but I figured a few widgets would look okay like the tabs widget maybe and others that probably use fix widths like calendars would just never work for mobile screens.
Whoa. Pilot error.
I stand corrected, after some unrelated refactoring it magically works like a charm.
... must have had something messed up
Sorry for the false alarm.
JQuery UI and mobile DO get along after all :)
PS: definetly include the jquery UI stylesheet before the jquery mobile stylesheet works and that order makes sense, if you reverse it your jQuery mobile icons will revert to something much less fancy (canvas rendered with some rotations missing it appears)
Leave a comment on mikethecoder's reply
Continuing exploration on mixing UI and Mobile:
including the jquery-ui-1.8.6.custom.css messes up the mobile slider thumb a bit FYI
JQuery UI Datepicker
getting the UI Datepicker to work is non trivial.
Unless you are willing to spend some time on it, it's probably better to wait for the jQuery mobile datepicker which will undoubtedly work and look better (thanks to Filament)
But if you really want a datepicker, now, read on. Some of the solutions (defanging the aggressive enhance) may be appropriate when trying to integrate other plugins into mobile as well - or perhaps mobile's enhancer could be adapted a bit ;)
Anyway, here we go:
Without the button trigger (DatePicker's showOn, buttonImage, buttonImageOnly) it already works (plusminus A href comments below)
However, you don't really want a text field & focus, because at least on the iphone the keyboard comes up and covers the calendar, defeating the whole purpose of showing it.
So I use
showOn: 'button',
buttonImage: '/images/DatePicker.gif',
buttonImageOnly: true,
and I have my datepicker INPUT field disabled so the user never focuses inside it.
But when you turn on the DatePicker button like that, you run into JQ Mobiles aggressive enhance in several places. It really wants to mark up the button that is inserted by the DatePicker as a peer to your date INPUT.
It wraps it in DIVs, cuddles it in all kinds of button classes, and finally wraps the button in an A. Too much of a good thing.
Turns out there is already a mechanism in JQM to prevent automatic enhancement (thanks for Scott Jehl for pointing this out - see http://jquerymobile.com/test/#docs/forms/docs-forms.html
Just add the data-role="none" on the datepicker button:
myDatePicker.datepicker( options )
myDatePicker.parent().find('button').attr( "data-role", "none" );
Also, the jQuery UI DatePicker (and I suspect plenty of other plugins) have some A's that don't have an href (because they use an onclick handler). For example, the next month and prev month buttons are like that.
Well mobile does not like A's without hrefs. The fix is easy:
jquery.mobile.js #3111 was
href = $this.attr( "href" ).replace( location.protocol + "//" + location.host, ""),
change to
hasHref = $this.attr( "href" );
if( !hasHref )
return; // do nothing for anchors that have no href
href = hasHref.replace( location.protocol + "//" + location.host, ""),
After all that I now have a working (if not yet superbly styled) datepicker on the iphone at least - the button that caused so much trouble is below instead of to the right of the date field in the narrow layout. I can live with that for now...(you'd have to make the text field width 80% and keep display: inline-block I think, but I am no CSS guru, so won't go there)
Oh one last thing:
the day numbers on the calendar are A's (this time WITH an href='#')
When clicked on an iphone, the hash change in the address bar causes Safaris location bar to briefly drop down, just like it does when an ajax request is made (why doesn't apple fix this, I wonder, or do they think this is a feature ? For what ?)
To solve, get rid of the href='#' (I tried live binding an onclick handler - too late, click already happened - or removing the href attr's in the DatePicker beforeShow() but doesnt work.)
So you have to hack the actual Datepicker source. Find these two lines in your datepicker js or combined ui source:
/* Generate the HTML for the current state of the date picker. */
_generateHTML: function(inst) {
and scroll down to where it makes the tbody of the calendar table (or just look for href in that function :) and shred the href:
'" href="#">' + printDate.getDate() + '</a>')) + '</td>'; // display selectable date
I tried it and that indeed prevents the "dipping address bar problem"
Yow.
It is actually worse.
Looks like the class names in jQuery UI and jQuery Mobile frequently overlap but have different style rules and semantics. This seems like a poor (hopefully temporary) design decision because it makes using jQuery UI compatible widgets very hard to use in jQuery mobile (without a lot of custom hacking in either their or the jQM code)
Examples of overlapping classes are
ui-icon, ui-icon-alert, ui-icon-gear, etc.
ui-slider, ui-slider-handle etc.
and likely many more.
Which means for example you cannot include a datetimepicker mod that uses jQ UI sliders. Or any jQ UI widget that uses jQUI sliders.
I cannot figure out whether this was a conscious design decision (with the assumption that by 1.0 styles would be unified/harmonized with jQ UI or the less attractive alternative assumption that all widgets would have to be rewritten for jQ mobile)
Or whether it was an oversight (I doubt it, the Filamenters are very good at what they do)
Either way for the moment those of us trying to leverage the large ecosystem of existing jQUI plugins are likely up the creek without a paddle.
If harmonizing the styles with JQUI is not in the plan, perhaps we can somehow namespace the JQM classes so they do not overlap with the jQUI classes and thus widgets can peacefully co-exist ?
Eg like:
jQUI: ui-icon, ui-slider
jQM: jqm-ui-icon, jqm-ui-slider
Or am I totally missing something and there is an easy workaround ??
Leave a comment on toad99's reply
I got the Autocomplete widget to work as well after dealing with the same href issue above and tweaking the CSS. For more info refer to this post:
Leave a comment on mynameistechno's reply
Thanks Toad99 for the bit of background experience with the slider widget conflicts between the UI library and the mobile library...saves me wasting time attempting to attempt to mix mobile & UI ...I too have been commenting on the lack of ported functionality in similar/parallel component jquery widgets between UI and mobile...especially now that jqm is at a supposedly v1 level...it's disappointing: I simply can't roll out a pure jqm solution, unless it's crutched to the point of crippled. It's also disappointing the almost complete lack of any comments on this forum describing what they are doing to improve or fix the situation...when working on the Google Maps API their development team would at least once in awhile wade in with some comments and feedback...most all you get here on this forum is the sound of: crickets.
Leave a comment on hornerf's reply
@toad99
Thank you for your insight. I did try integrating jQuery UI into a JQM project and it was disastrous. Being fairly new to jQuery and JQM I didn't have the skill to determine what was going on.
So I'll wait for the JQM solution re: additional widgets.
It is a shame that the JQUI widgets don't work (properly) in JQM, but I guess the JQM dev boys are flat out firefighting, trying to get V1 released bug-free. After 1.0 is released I expect they'll turn their attention back to strategy.
@hornerf
Yeah, I find it strange that the JQM boys don't comment on these forum posts (not that I've seen anyway). I guess they are short on human resources and are strapped to the boards with R1.0. Thankfully there is a small community of developers that are here and have helped me out with some issues.
Thank you for your insight. I did try integrating jQuery UI into a JQM project and it was disastrous. Being fairly new to jQuery and JQM I didn't have the skill to determine what was going on.
So I'll wait for the JQM solution re: additional widgets.
It is a shame that the JQUI widgets don't work (properly) in JQM, but I guess the JQM dev boys are flat out firefighting, trying to get V1 released bug-free. After 1.0 is released I expect they'll turn their attention back to strategy.
@hornerf
Yeah, I find it strange that the JQM boys don't comment on these forum posts (not that I've seen anyway). I guess they are short on human resources and are strapped to the boards with R1.0. Thankfully there is a small community of developers that are here and have helped me out with some issues.
Leave a comment on mfread's reply
@homerf:... Always good to hear such compliments... Makes everybodys efforts in trying to answer questions in the forum so much more worthwhile.
Leave a comment on frequent's reply
This is an old post, but curious... is the experience of mixing JQUI & JQM any better currently?
Leave a comment on gulch's reply
jQuery Mobile was not designed to be compatible with jQuery UI. It was not a design goal, and a conscious decision not to make them compatible.
There apparently has been a change of thinking, and now with 1.4 there is supposed to be compatibility. How much compatibility remains to be seen. There were very significant incompatibilities, and not sure they can all be easily resolved, but that seems now to be a goal.
Prior to 1.4, forget it.
What I usually tell people about it is something like this:
"Some developers have gotten some jQuery UI widgets to work with jQuery Mobile, either partially or fully, with some level of effort from minor to extensive. If you try to do this, you are on your own. Let us know how it goes."
This goes, as well, for third-party widgets meant for jQuery UI. Some have actually been designed to work well with both - a good example is jquery.ui.map.
In all cases, you will need to seek-out jQuery Mobile-specific documentation for the widget.
Leave a comment on watusiware's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to toad99's question
{"z7411390":[14737000002792231],"z7664639":[14737000004893313],"z3323265":[14737000001694053],"z3253928":[14737000001880052],"z7739036":[14737000002797198],"z5049151":[14737000002798367],"z31993608":[14737000004893301],"z4997952":[14737000001690455,14737000001703446,14737000001701900,14737000001912378]}