When a form element gets focus on iOs the browser zooms in on that element. Very handy in unoptimized layouts where that element might be a few pixels high but annoying and unnecessary in a mobile optimized layout. You can disable this behaviour by changing the meta viewport value onfocus and onblur.
Here’s a simple jQuery example:

$('input, select, textarea').focus(function(){
$('meta[name=viewport]').attr('content','width=device-width,initial-scale=1,maximum-scale=1.0');
});
$('input, select, textarea').blur(function(){
$('meta[name=viewport]').attr('content','width=device-width,initial-scale=1,maximum-scale=10');
});

Notice the tiny difference between focus and blur: onfocus you set the maximum-scale to 1 and onblur it’s set to 10. You shouldn’t use the code above, Wilfred Nas and Mathias Bynens optimized it in the comments to this snippet:

var $viewportMeta = $('meta[name="viewport"]');
$('input, select, textarea').bind('focus blur', function(event) {
$viewportMeta.attr('content', 'width=device-width,initial-scale=1,maximum-scale=' + (event.type == 'blur' ? 10 : 1));
});

The browser starts zooming in but immediately zooms out again when the elements gets focus. I like that.

All browsers (except for Safari so far) have started to update their browsers more frequently adding more and more new exciting web technologies all the time: a new browser war with mostly winners so far. All these browser vendors are releasing very early versions to the public in order to get as much feedback as possible. For my own reference – and yours too, sure – here’s a list of these early versions.

• Opera Next can be run at the same time as the regular Opera
• Firefox has an Aurora version (far future, unstable) and a beta version (more stable). You can run them alongside with the help of the ProfileManager
• Chrome has some Canary Builds which can be run alongside your regular Chrome.
• Internet Explorer Test Drive versions are released on a regular basis and can run next to IE9 (on Windows 7 only)

In my talks and workshops about responsive web design and adaptive layouts I always take some time to take a look at CSS Zen Garden, since a part of building an adaptive layout is based on the same principle as the Zen Garden has been promoting all these years: the same content can be styled differently by using CSS. I always wanted to make a version of the CSS Zen Garden where a different layout is shown on every different resolution. I never built that thing because it would be way too much work for me, I’m not a very good coder.

Today I talked about this idea while I was giving a workshop. From that moment on Roy Tomeij, who was attending, was more silent than usual. Ten minutes later he interrupted me with this masterpiece. Ladies and gentleman, I present you the Adaptive CSS Zen Garden. Resize your browser window at your own risk!

Versions of Internet Explorer prior to number 9 can not style unknown elements without the help of JavaScript: by adding the unknown elements to the DOM you can style them like any other element. So if you want to use the new HTML5 elements you will need JavaScript to style your site. Most people will have no problem seeing your site but for those unlucky visitors with IE and JavaScript disabled (for whatever reason, there are lots of them), the experience can be horrible. Here’s a simple solution:

Serve your default stylesheet to all browsers except IE8 and lower. To those “browsers” you serve Andy Clarke’s universal ie6 css in a conditional comment. Then with the help of a simple javascript you immediately replace this css file with your default css file. Now those unlucky visitors will at least see a nicely styled easy to read minimal site. (View source on this page to see how it works)

I couldn’t think of a way to replace the fallback css before it gets loaded so the only negative side effect of this technique is that it uses an extra http request. I think it’s worth it: for me this JavaScript dependency was the only thing that kept me from using HTML5 elements.

I’m beta testing a new real time analytics app and it looks absolutely beautiful. A subtle design, a clear navigation, nice looking forms and some clever looking scrolling effects which remind me of framesets, just better looking. So far so good. I bookmarked it, imported the url into iCab on my iPad (my favorite browser for managing online apps) and logged in to change the settings while lying on the couch. This is where the happy part ends. I really tried to make this a positive article but I just couldn’t. Sorry.

Rant starts here

While working on an extreme css3 test- and show case I found out that there are some issues with the new css3 gradients. First of all, the syntax is harder to remember than the xhtml strict doctype but more importantly, since there are tools to generate these gradients, these gradients are a performance issue: scrolling can be sluggish. But still, somehow webdesigners want scalable gradients so I came up with an alternative solution: using a png in combination with background-size.

Sure this technique is not as flexible as the css3 notation, every change to the design of the gradient means firing up a pixel editor, building the new png, saving it, turning it in to a data-uri and copy pasting that code to your stylesheet. But if you’re sure about your gradient this is a fine way to build simple scalable gradients. I’m sure that with some clever slicing and tiling and with the help of multiple backgrounds more complex gradients are possible.

Now, browser support. This works in all modern browsers but it doesn’t work in older browsers like camino 1.6 and all versions of IE before version 9. If you agree that websites don’t have to look exactly the same in every browser you can easily hide the png for these browsers by setting its background-position-x to something negative and its background-repeat to no-repeat.

I read an article on Matt Wilcox’ blog about the whitespace adjacent to every inline-block element. I wondered if this whitespace has a default size. At first it looked like there’s no default size. I started some tests with a lot of inline-block elements, all with different letters and symbols in them. I contained these elements inside four containers, all with different font sizes. Here’s the first test I did.

More tests that don’t fail to follow

In most cases the alt attribute should be empty.

<img src="image.png" alt="">

There are two exceptions.

1. The image is a link
2. Without the image the content would be incomplete

orly?

Just a few minutes ago my wife complained about websites with white text on a black background. For her I made this simple grey-on-white bookmarklet which sets all backgrounds to #f5f5f5 and all colors to #666. The background of the body is set to #ebebeb to preserve some of the shapes of the original site (the real reason is I wanted to use #f5f5f5, a key I used a lot when I had a windows PC and #ebebeb, the initials of a good friend).

Here’s the code. As always, suggestions are welcome.
javascript:(function(){
var%20a=document.getElementsByTagName('*');
l=a.length;
while(l--){ a[l].style.color='#666';a[l].style.background='#f5f5f5';}
document.getElementsByTagName('body')[0].style.background='#ebebeb';
})();

Some pictures on Flickr are harder to bookmark on Ffffound than others. For some reason Flickr puts a transparent gif on top of the image. If you try to bookmark this image to Ffffound you actually bookmark the empty gif. I wrote a bookmarklet to hide that gif. Drag this link, My Ffffound, to your bookmark bar and hit it instead of the regular Ffffound bookmarklet, it just works like the original bookmarklet on other sites.

Details please