There is no simple API call or DOM property to tell you if the user has zoomed in on their mobile browser. That doesn’t mean it’s impossible to determine, it’s just not one simple call. If you need to figure out the zoom level, here’s how.
var zoomLevel = document.documentElement.clientWidth / window.innerWidth;
You’ll need to divide the clientWidth of the document by the innerWidth of the window. This will give you a factor that is greater than one if the user has zoomed in their browser. With that factor you can adjust measurements as need to compensate for the zoom.
In the following example, I have a dialog that I normally want to be 800px by 400px. If the browser window is smaller than those dimensions, I want the dialog to fill the available space. To take the idea one step further, I want my dialog to always fill the available viewport even if the user has zoomed in their browser. To accomplish this I use the zoomLevel described above to adjust the width and height of the dialog whenever it happens to be larger than the available viewport.
The example is at http://jsfiddle.net/BrianRichards/kubZa/. To test the example in a mobile browser, go to http://jsfiddle.net/BrianRichards/kubZa/show/. This URL removes the iframe that jsFiddle normally uses around content.
In the previous post, I let my dislike for labels on the left be known.
One common rationale for using left labels has to do with saving vertical space. Another method I often see is using placeholders/watermarks as labels. This can make for clean looking forms, but if not done properly can lead to both accessibility problems as well some confusion when filling out the form. If you leave out the label tags in favor of placeholder approach, users with screen readers may have difficulty determining what value belongs in the field.
Even if you have labels (either rendered as the placeholder or moved offscreen), navigating the form can be difficult because once you’re in the context of an input, many sites will clear out the placeholder. This means that a user tabbing through the form must always look ahead and remember what the next value should be. This can be helped by leaving the placeholder visible until the user starts entering data. This is the approach Twitter takes on their sign-up form.
I started playing around with an alternate approach that keeps the label visible when the field has focus. It slides the label temporarily up over the field while you’re typing. I used jsFiddle to create a sample.
Unfortunately, this approach still hides the label when you leave the field so you can loose context by not seeing the label. So in the sample, it could be difficult to tell what the value really represents.
This was an interesting idea to prototype out and it may have some uses, I still prefer labels on top of the fields.
I’ve never been a fan of form fields with labels on the left. I’ve always preferred labels on the top because I think it’s easier to read and much easier to localize. I would suggest Luke Wroblewski’s Web Form Design book for it’s excellent chapter on labels and label placement. It contains some nice guidelines, along with some eye-tracking data to back them up.
Recently I did run into another reason I don’t like left labels. Many of the new mobile browsers do something helpful when filling out forms (this relates to zoomable pages that aren’t designed to be width=device-width), they will zoom in and center the form field with focus as you’re working through a form. This means that in many cases left labels can’t be read without panning the page for each field. One more reason to stick with top labels.