BlogmyQuery – BMQ

One thing about iOS browsers that can be pretty frustrating, both as a developer and as a user, is when you open a site on an iPhone or iPod Touch (not iPad) and want to enter some text in a text field or pick an option from a select menu. Very often the browser will automatically zoom in on the entire page a little when you tap the form control.

The intention is likely to be helpful and ensure that you can see the text you’re typing or the options in the select element. This is fine, of course. What’s annoying is that the browser doesn’t zoom back out once you’re done with the control, so you have to pinch the screen and manually zoom out. Not showstopping, but rather annoying. This behaviour seems to be the same for all browsers that use WebKit, which as far as I know means all iOS browsers except Opera Mini (which does not auto-zoom form controls).

For end users I don’t know if it is possible to avoid this, but for web developers there are a couple of ways.

Read full post

Posted in CSS, iOS.

Copyright © Roger Johansson

Every now and then I’m handed a design comp that has customised checkboxes and radio buttons. This used to make me think “Oh no, not again� because I simply didn’t know of a reliable way to customise these particular form controls.

Sure, if all you care about is replacing the browser default with a custom graphic it isn’t that hard. But if like me you’re also interested in doing so without degrading user experience, especially during keyboard interaction, you have a number of problems to deal with.

Fortunately the situation is a lot better now than it was a few years ago. My first attempts at custom checkboxes and radio buttons involved quite a bit of JavaScript trickery to toggle between different states of the buttons, and I never got it to work perfectly cross-browser, cross-input device. However, since recent versions of all major browsers support the :checked CSS pseudo-class, you can now leave it to the browser to handle the states and focus on the CSS. No JavaScript involved.

Read full post

Posted in Accessibility, CSS.

Copyright © Roger Johansson

Sometimes it’s useful to know if images are enabled in the user’s browser, so that you can adjust your CSS and/or JavaScript to make sure that important content is not hidden and that the page is still usable even if images aren’t loaded.

Steve Faulkner describes one example of such a scenario in Detecting if images are disabled in browsers – using an image to convey information that is also available in text that is positioned off-screen. In a CSS on + images off scenario, sighted users won’t get any information.

It’s often possible to write your markup and CSS in a way that avoids this problem, but it isn’t always practical. Hence knowing whether images will be displayed or not is helpful.

Read full post

Posted in Accessibility, CSS, JavaScript.

Copyright © Roger Johansson

Back in 2009 I wrote about a way of Line wrapping text in legend elements. It involved using CSS hacks or conditional comments to target Internet Explorer, which was the most problematic browser in this regard.

Well, it still is. All other browsers cooperate and let the text in legend elements line wrap by default. But Internet Explorer refuses, even the brand new IE10. But there is a fix.

Read full post

Posted in CSS.

Copyright © Roger Johansson

Trying to be pixel perfect on the Web is like begging to be frustrated. I try to not worry so much about a pixel here or there, but sometimes you just have to get complete control to make things look right.

Until recently I had never paid any special attention to the exact amount of whitespace some browsers create around textarea and input[type="text"] elements, but then I started implementing a design that required there to be exactly no whitespace around them. And I noticed that browser behaviour differs a bit here, so I needed to find a fix.

Read full post

Posted in CSS.

Copyright © Roger Johansson