Nerd.

Last night I asked on app.net if grids and typography are the basis of good design. Stuart Robson answered:

content > typography > layout > paint (usability is ‘a given’)

When I saw this post I realized that this is the exact same thing as the so called Web Stack. HTML is understood by the simplest browsers, typography is seen on the smallest screens, layout is delivered to browsers that understand mediaqueries and fancy things are shown to browsers that understand the necessary CSS3. It’s a pretty logical order when you think of it, it makes perfect sense.

Later on in this same discussion Stuart wrote:

it’s funny that ‘now’ we’re only realising it rather than it being paint/layout/typography then content.

This post made me realize that this is the Photoshop Stack! This is the exact way we’ve been working all these years. The reason Photoshop is not suitable as a web design tool is not only because it forces you to think in exact formats instead of ratios. The main reason is that it forces you to think in the exact opposite way of how the web works! Now I understand why so many visual web designers don’t understand web design. And now I can explain it to them.

And I found out that Saturday night is the right moment for good discussions about web design.

Most software has some defaults. This means that some preferences are set when you open the application for the first time. When the person or team that made the software didn’t really think about what default to set, we speak of silly defaults. When the team did think about it though, and made the best choice possible we speak of smart defaults. But when marketers alone decide what should be the default we speak of evil defaults.

Developer relations teams do great jobs. The people from Mozilla, Opera, Chrome and others who travel around the world showing – mostly to front-end – developers what’s possible with our amazing new web technologies are an important part in spreading the knowledge. But I always wonder why the focus is on developers only. Why don’t browser-evangelists* focus on designers, marketers and UX-people instead? Traditionally these are the people who decide what’s being built, not the developers. If these people don’t know that new exciting things are possible, how can we expect them to create new exciting things? Adaption will be much quicker when we influence the decision makers directly.

The focus on front-end developers is understandable, they need to know how things work. But we should really start looking at back-end developers as well. I did a workshop about responsive design and progressive enhancement for back-end developers a while ago and I was shocked by the complete lack of knowledge about HTML and CSS. These people build the backend for websites and web apps, yet they have no idea about the underlying principles. They don’t know how people actually see and use their work.

I think the web would benefit much more right now if we didn’t just focus on ourselves but started spreading our knowledge to other disciplines as well.

I’ve been doing this for years in the company I work at, I’ve been explaining the web to clients and colleagues. I think it’s time to explain these things to others, outside my company as well. So here it is: do you need somebody who can explain how the web works, technically, on your non-technical event or conference? Don’t hesitate to contact me.

UPDATE: Ron Kersic shuffled some words around from my post above which reminded me of the fact that I am extremely front-end focused myself. Now if somebody could do the same with design, UX and marketing…

UPDATE: Christian Heilmann answered that Mozilla doesn’t just focus on one group and he also jokingly pointed out that you can’t focus on 5 groups. Which is true for a person, of course, but it’s probably not impossible for a team.

* Can we please choose another word instead of evangelist? It sounds religious. UPDATE: Joost de Valk explained that in principle evangelist is not a religious word.

Whenever I see a list of mobile browsers there’s always one browser that I miss: the browser that’s inside the Twitter app. Or any other app that people use to connect to their social networks. In my case, the built-in browser in TweetBot is the browser I use most by far. I click on most links people tweet and I buy lots of things in that browser when people recommend it. People with Android devices seem to be surprised whenever I say this, so I assume apps on Android don’t have a built-in browser. But apps on iOS definitely have them and they are used quite often. You should probably test your sites in these apps too since their viewports tend to be different.

UPDATE: The easiest (and the best) way to prevent iOs from zooming when a text field receives focus is by setting the font-size to 16px. (or better, by using the browser’s default font-size). A much harder solution is explained below. I don’t recommend it, just use the default font-size instead.

WARNING: This technique causes some serious issues on some Andriod devices. On some devices the keyboard is never shown, on others the keyboard is shown when you tap the field again. Until there’s a proper solution I would advice not to use this script.

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

This post is outdated

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