jQuery Forum

Hey Guys.

I've stumbled across a minor problem relative to fixed/persistent footers and transitioning.  I'm testing on IPhone only for now.  And this might only happen on iphone considering it's related to scrolling the browser beyond it's boundaries.

Anyway, if you add a fixed and persistent footer to the page:
<div data-role="footer" data-position="fixed" id="siteFooter" data-id="siteFooter" data-transition="none" data-tap-toggle="false">

Then, if you scroll the browser up (which is down with the thumb) past the address bar at the top then navigate to another page ...

For about 1 second on the next page you see 2 footers and one of them is about 100 pixels above the bottom of the browser.  I'm guessing until JQM can run their normal min-height resizing in javascript, the footer that's in the ui-page element appears to be in the wrong place.

Anyone have any idea how to fix this one?  Just creates a crappy experience on transitioning.

Steven

Hey Everyone.

JQM grades Android 2.1-2.3, 3.2, 4.0, and 4.1 at an A level.  But, don't the devices have a huge impact on that?  I have my application working well with iPhone 4 hardware and higher (any OS 4 and higher).  But, as I start to get my hands on some Android devices I'm seeing alot of things not working.

HTC (Verizon on Wifi - Sense 2.1, Android 2.3.4)

1. The click delay doesn't seem to work so scrolling the window activates everything (I give the device a 6 out of 10 on scrolling capability while testing on the JQM demo site)
2. With a list inside of a collapsible, I have to click about a full thumb width above the list item or it clicks both of them (alot of times I can get the ui-active class added but it doesn't actually fire the anchor - like the click doesn't delegate correctly unless it's from the inner most element or something)
   
3. The rounded corners and box shadows look atrocious
4. Sometimes when an input has focus it doesn't actually popup the keyboard - I have to click it again

Samsung Galaxy S3, Android 4.0.4

1. When expanding collapsibles, everything below the collapsible heading and body doesn't get rendered correctly.  Reminds me of uncleared floats.  Tapping anywhere on the screen repaints and fixes.
2. Popups don't work for me at all (thought they work on the jqm demo site) so it must have something to do with the fact that I've CSS centered dialogs rather than letting JQM deal with it.  The popups are there because it lets me interact with them they are just invisible!
   

There are a bunch more things here and there that I could nitpick.  And my real questions are:
1. How do you really test a decent variety of Android devices?
2. Should some of these really have A grades considering that they barely work?

Steven

Hey Guys.

I'm doing a bunch more device testing here and there and I notice a pretty good lag in page transition from the time the spinner disappears (i.e. the .ui-loading class removed off of HTML) and the actual paint of the page.

I'm testing on an IPhone 4 (not 4s) with 5.1 installed.  I do have some script on these pages, but I've removed it all and I'm getting the same lag.  The markup for each of these pages is about 10k and I do have a persistent footer bar.  My transitions are left default which is fade.

Basically, I'm running this from localhost and on internal wifi, so I'm a little lost as to what to try next.  From the time of click until the time the next page paints is usually between 4.5 and 6 seconds.  But, the spinner goes away almost instantly usually which tells me the ajax requests are done instantly.

I don't see a similar delay when I look through sites on the jqm gallery.  Though, it seems that almost all of those sites are running on 1.1.1.

Anyone have any idea what's going on from removal of ul-loading and the actual page show?  Any ideas as to what might be hanging that for 2-3 seconds?

Also, I had a side question about why JQM is running script on every transition to add the min-height to the page element.  Obviously, it's to have it be the full height of the viewport.  But, that's not necessary on newer devices!  Height: 100% works fine as long as it's containing elements (body and html) are also height 100%.  I see alot of bugs around the height of the page being calculated slowly and the white strip you get at the bottom until the script can catch up.  Doing this in CSS might also make persistent footers render cleaner (stay at the bottom of the page) for browsers that support fixed positioning.

Thanks for the info.

Steven

Anyone wondering if the JQM team has any plans on supporting/gracefully degraded the html5 required property on form fields?

I use alot of popup forms here and there and having a built in tooltip for required fields (or other failed validations) would kick ass.

That could be something like this:

<input type="password" id="password" data-validation-message="Please enter a password with more than 6 characters, 1 number and 1 capital letter" pattern="^.*(?=.{7,})(?=.*[a-z])(?=.*[A-Z])(?=.*[\d@!#$%^&*+-=]).*$" />

Field validation is somewhat tricky in the small confines of the mobile world.

:)

Hey Guys.

Would it be bad practice to use the telephone input type for fields like credit card numbers to have the keypad popped on IOS devices?  I realize they could still enter dashes and other special characters.  It's just a much better experience to get GIANT numbers to type in as you're tying numbers.

Anyone think that's a bad idea?

Could this cause a problem on degraded devices or does it just fall back to text?

Thanks,
Steven

Hey Guys.

I've started experimenting a bunch with the 1.2 dialogs and popups.  On my iPhone 4 running 5.1, it takes about 1.5 seconds on average to open dialogs.  This is pretty consistent with any dialog no matter how much UI it contains.  Also, I get the same behavior whether it's a button with data-rel="popup" and the anchor pointing to the popupid or just a $('#mypopup').popup('open').

I always turn off the transition and almost always have postionTo set to window.

I haven't done really ANY digging yet.  Just wanted to see if you guys who are much smarter than me have any info as to the delay.  I'll try to profile it just a bit and puke out some timed numbers as to the duration between the click event and the onafteropen of the popup.

Thanks for any help.

Steven

Hey guys.

I just noticed this in case someone ever tried to do the same thing.  I have a dialog for logging into the application and in some cases, I pop it up immediately upon arriving on a page.

The page specific JS I'm using is in the middle of the page (not the head or anything) and all of the script is wrapped in a one call listening for pageshow on document:

$(document).one('pageshow', function (event, ui) {
    var $popupLogin = $('#popupLogin');
   
    if ($popupLogin.length > 0) {
        setTimeout(function() {
            $popupLogin.popup('open', { history: false });
        }, 500);
    }
});

So, notice the silly 500 millisecond timeout in there before opening the dialog!  Without that, the positioning of the modal fails completely and it ends up half way down the page.

Short story ...

If you open a model as a page is rendered, you need some kind of tiny timeout in there.

By the way, this modal is nothing special just this:
<div data-role="popup" id="popupLogin" data-theme="a" class="ui-corner-all" data-position-to="window">

Steven

Hey Guys.

As all of you know, listviews are vitally important in jquery mobile sites.  Well, I'm a little stuck here because of an issue that I think is kinda wrong....

When you add a data-theme to a ul/ol that's data-role="listview", it adds a ui-btn-up-[X] to every single list item.  So, what if I want list items to not behave/look like buttons?  Our clients continually ask what the point of the swatch text styling is if button styles are always going to override it.  I have no answer at this point because listviews are dominated by the button classes.

Why don't listviews have a data-content-theme and add the ui-body-[X] class to the list or list items?  That would let the text cascade and buttons in listviews have their own styling.

Another problem this creates is when you put collapsibles inside of list items.  You almost HAVE to add a data-content-theme to a collapsible (at least an inset one) or the open state won't look right with the rounded corners and such.  When you do that, you've now have completely different styles for the text inside of the collapsible body than anything in the listview but outside the collapsible.

And, there are a few bugs in 1.2 with inset collapsibles inside of listviews.  Ex: rounded corners don't get applied to the first span inside of the anchor which acts as the collapsible trigger (makes the light top border which creates the shiny affect stick out past the corners.  (To remedy you must add: .ui-collapsible-inset .ui-btn .ui-btn-inner { -webkit-border-radius: inherit; border-radius: inherit; } ).

Alright, I could go on and on.  Thanks for any suggestions if anyone has any.

Steven