But let’s talk about font sizes first. Or if you’re already up to date, jump to where I get to the point.

Relative font sizes

Over the course of the past few years, us webdevelopers have been told over and over again to use relative font sizes. A pixel is a pixel (well not really, but that’s beside the point here), and using them forces your visitor to try and read things in a certain size they may not be able to handle. So we use ems and percentages that scale along with whatever font size the user needs.

Most browsers have a default font size of circa 16px. If you have a sidebar for example that has a width of 160px, you could write exactly that, or you could use 10em – aka “10 times the fontsize this element has”.

Now if a visitor wants to see it all a bit more clearly and they set the font size to say 20px, you can guess what happens: the sidebar that had its width declared in pixels stays at 160px wide, but the one that uses em will now span 200px. The contents still fit in exactly as they did before zooming.

Responsive design

After the relative font size trend came the responsive design trend, and it’s still going strong. Where we got away with making pixel-perfect designs in times past, often served with a “best viewed in x screen resolution”, nowadays it’s all about adapting your design to the size of the visitor’s browser. And that’s where media queries come in.

Media Queries

Responsive design and media queries go hand in hand. In our stylesheet we query the device or browser size, and if it falls below (or above) a certain treshold, we apply some additional styles.

So we build a site in a big screen first*. Say it has two columns, one 640px (40em) wide for content and another one 320px (20em) for the navigation menu. Then we size down the browser until the site doesn’t look good anymore. In this case that’s at 960px, at which point the site is wider than the screen.

We add some styles in a media query for min-width: 960px in which we tell the browser to do things differently. We could put that navigation menu above the content instead of next to it, for example.

This all works quite well, but here comes the problem: this breakdown at 960px only works at a zoom level of 100%.  It has become a magic number.

* Some build for the small screen first and then size up, which has it’s own merits, but hat is a discussion that I don’t want to go into now.

Using relative media queries

Think of it, with the zoom of 125% like I use by default, all these relative elements get bigger. The font size is now not 16px but 20px. The sidebar grows to (20px * 20em = ) 400px. The content column is 800px. This means that the page will start breaking down at a width of 1200px (or 60em), but our media query doesn’t know that yet. Between the screen widths of 1200px and 900px, your site will not look good.

So to make a long story short, when you use media queries in pixels, you’re not being fully responsive. Using ems will make sure that your media query adapts itself to your font size or zoom level.

One comment (in two parts) I got on Twitter was:

What would breakpoints be relative to? Em would mean ppl with large font settings could get a layout meant for smaller viewports, wich could provide a suboptimal user experience. What would you suggest?

I disagree though. The whole idea of responsive design is to serve an optimal user experience, no matter the screen size. If I’m serving someone a layout that was built for smaller screens because they are zoomed, I’m not providing a suboptimal experience at all, I’m doing them a favor. Stubbornly showing them the bigger version even though it doesn’t fit in their screen would be providing a suboptimal experience, I’d say.

(This is why it’s also important to not hide content for smaller screens, just re-arrange it. Some website makers seem to think that “mobile” users need less content, but since you can never guess their intent anyway this is a bad practice in itself.)

Some additional notes

Zooming and font size

The ems in the media queries seem to be based on the browser’s font size, not on that declared in your stylesheet. Even if you set your font-size to 12px at the html element and then use relative sizes onward based on these 12px (as made popular by many reset stylesheets), the media query will use your browser’s font size of ~16px. What this means for websites with a “change font size” button that affects the document’s font size  I’m not sure. I have yet to test this.

The zooming that most browsers use nowadays is not just enlarging font-size, but making everything bigger. Come to think of it, it’s kind of strange that everything grows (even the pixel-based elements) but the media query’s pixels stay the same. Except in one case:

Internet Explorer

To my total surprise, IE9 seems to be the only browser so far that actually scales up the pixel-based media queries automatically when you zoom in. Kudos, IE9! Luckily, that doesn’t mean em-based media queries don’t work, so no worries. Use them for the other browsers and IE9 will still handle them equally well.

Practice what you preach

While I’m writing all this, I’m aware that my website is not yet reflecting my stance, so go ahead, zoom in and see for yourself what’s going wrong. I have plans to re-write the CSS entirely, but there’s never enough time. You know how it goes.

Your thoughts?

Last of all, please let me know what you think. I might have overlooked some consequences of using relative media queries (although I tried to at least test for side-effects), or maybe the whole premise is broken, but unless you tell me so I’ll start using ems.

I can be found on Twitter and App.net, and there’s also a comment section below.

The post Why you should use ems for media queries appeared first on Stephan Muller.

I had never even heard of the Single Column View, so I did some research in what it is and how it works.

Single Column View

Apparently, Opera Mobile and Mini have a built-in feature that allows you to view a website on your mobile in one column instead of the default layout.

Two screenshots of Opera Mobile emulator showing the Jira homepage. Left is the default layout, right is the Single Column View.

This is especially useful for pages that are not optimized for mobile, as Opera will try to guess which parts of the site are the main blocks and places them all below each other and fitting them to your screen width, eliminating horizontal scroll.

It’s not the perfect solution, but especially for pages that would need a lot of zooming in and panning otherwise, it’s quite a decent alternative.

media=”handheld”

Obviously, when a website is optimized for mobile, there is no need for a single column view. Opera needs to check whether you’re already supplying your users with a mobile-friendly layout. The way they do this: they check for the “handheld” media type (both the <style media="handheld"> HTML element and the @media handheld CSS variant work). This means that as soon as you’re using any of those two, Single Column View won’t work on your site.

Apparently, on our desktop version (we do have a mobile version, with a link back to the desktop version) I used media queries to hide some banners if your screen is too small. One of these is a media query that checks for the “handheld” type. Even though those rules don’t do anything to optimize for mobile except hiding some banners, it destroyed the mobile experience of potentially thousands of visitors each day (depending of course on how many of those use the Single Column View).

In my case, I could easily get rid of the rule because the other max-width media queries already handled the job, but if you’re seriously using the handheld media type, make sure that your site looks okay in Opera Mobile and Mini because you’re denying your users a useful built-in usability tool.

On the upside though, I think the “handheld” media type is hardly supported anyway so not many people will probably use it. And even then, your site should be responsive nowadays anyway.

The post Enable Opera’s “Single Column” view on your site appeared first on Stephan Muller.

Because I wasn’t able to reproduce it in the browser, here’s an actual photo of a printed multiple select:

Multiple select input with overflowing content, printed from IE9

The only question on StackOverflow I could find about it only had one (unaccepted) answer with one upvote at the time. This didn’t bring much hope. I tried a couple of CSS solutions, but even giving it a negative z-index and putting a div with a background color and a higher z-index below it wouldn’t hide the overflowing content. Maybe there’s some very elaborate CSS trick to fix it, but instead I went for a jQuery solution.

The script does a few simple things: when called (and the browser is IE), it recreates the content of the <select multiple> but puts it in a <div> instead, transforming each <option> into a checkbox with a label. The checkboxes are hidden, but allow me to easily copy the selected state of each of the options.

A few simple CSS rules serve to recreate the look and feel of the multiple select element as possible. The script also copies the classes on the select onto the div, so that you’re able to style it a bit more.

The script

//jQuery required
$(function() {
  if($.browser.msie) return false;
  $('select[multiple]').each(function() {
    $lPrintableDiv = $('<div data-for="' + this.id + '" />').addClass($(this).attr('class')).addClass('printable');

    //update printable on changes
    $(this).after($lPrintableDiv).change(function($aEvent){
      updatePrintable($aEvent.target);
    });

    //run once on load
    updatePrintable(this);
  });
});

function updatePrintable($aTarget) {
  var $lSelect = $($aTarget);
  var $lSelected = $($aTarget).val();
  var $lPrintable = $('[data-for="'+$aTarget.id+'"]');

  $($lPrintable).width($lSelect.width()).height($lSelect.height());
  $($lPrintable).html('');

  $($aTarget).children().each(function($lElm){
    $lVal = $(this).val();
    $lLabel = $('<label />').text($lVal);
    $lOption = $('<input type="checkbox" />').val($lVal);

    if($(this).is(':selected'))
    $lOption.prop('checked', true);

    $lPrintable.append($lOption).append($lLabel);
  });
}

 The styles

.printable {
    border: 1px solid grey;
    display: none;
    overflow: auto;
}

    .printable label {
        display: block;
        font: .8em sans-serif;
        overflow: hidden;
        white-space: nowrap;
    }

    .printable [type="checkbox"] {
        display: none;
    }

    .printable [type="checkbox"]:checked + label {
        background: #3399ff;
        color: white;
    }

@media print {
    select[multiple] { display: none; }
    .printable { display: inline-block; }
    .printable [type="checkbox"]:checked + label { background: grey; }
}

This will style the div just like a regular multiple select, and only show it when you’re in print mode.

And of course, here’s a jsFiddle demo for you to play around with. I commented out the display: none for the printable element so that you can see how it behaves as you update the selections. Comment out the second rule in the JavaScript to be able to test it in another browser than IE.

The post Make a multiple select box printable in IE9 appeared first on Stephan Muller.

I thought it might be a good idea to share them, until some better tools are built to find like-minded people, so here they are:

Andy Clarke (@malarkey)
Designer, speaker, author of “Transcending CSS” and “Hardboiled Web Design”.

Anil Dash (@anildash)
Blogger, entrepreneur and technologist. Generally has a lot of useful things to share.

Ethan Marcotte (@beep)
Web designer and developer, writer of “Responsive Web Design” (which started the whole RWD hype we’re currently in the middle of).

Jason Santa Maria (@jasonsantamaria)
Designer, creative director of Typekit and A List Apart, co-founder of A Book Apart.

Jeffrey Zeldman (@zeldman)
The Godfather of web standards. Also web designer, entrepeneur, writer of “Designing with Web Standards”, founder of A List Apart and An Event Apart, co-host of The Big Web Show.

Jonathan Snook (@snookca)
Web designer and developer, writer of “Scalable and Modular CSS”.

Marco Arment (@marco)
Web- and iOS developer, founder of Instapaper, co-founder of Tumblr.

Mat Marquis (@wilto)
Web designer and developer, part of the jQuery Mobile team. Also quite funny.

Michael Heilemann (@heilemann)
Interface designer, created the Kubrick theme for WordPress (the default theme on versions 1.5 – 2.9).

Peter-Paul Koch (@ppk)
Mobile platform strategist, browser compatibility expert, founder of Quirksmode.org

Roy Tomeij (@roy)
Front-end architect, entrepeneur, writer of “Modular Front-End”.

Bonus: a list of people possibly worth following but inactive on App.net right now. They might start posting interesting stuff in the future. Or not.

Chris Coyier (@chriscoyier)
Designer, founder of CSS-tricks.com, author of “Digging into WordPress”.

Dan Cederholm (@simplebits)
Web designer, author of several books on CSS, co-founder of Dribbble.

Dylan Wilbanks (@dylanw)
Web developer and UX designer, plays the part of “Moose” in the “Squirrel and Moose” podcast with cssquirrel.

Erin Kissane (@kissane)
Writer, editor and content strategist, wrote “The Elements of Content Strategy”. Former editor of A List Apart.

Luke Wroblewski (@lukew)
Digital product designer, writer of “Web Form Design” and “Site-Seeing: A Visual Approach to Web Usability”.

Matt Mullenweg (@photomatt)
Co-founder of WordPress.

Did I miss some interesting people? As always, let me know in the comments, on Twitter or on App.net!

The post 12 Web People you should follow on App.net appeared first on Stephan Muller.

A small disclaimer: app.net and its clients are all still very young, and a lot of changes are bound to happen in the near future. This is just an early comparison of apps that are still in their development stages. Updates on this post will follow.

Rhino

AppNet Rhino is the first free app I could find in the iOS App Store. As the app.net API itself is still very young and its web client dubbed “alpha” is still quite basic, so is Rhino.

The screens

There’s currenty four screens: timeline, mentions, global stream and profile.

Timeline in Rhino

Honestly there’s really not much more to the web client, so this covers most of what’s to do on App.net, but there is some things in these screens that I’m missing.

First of all, I can’t swipe between screens. Maybe this is because a left-to-right swipe on a post gives you more options (like replying and reposting, something I hadn’t found out until after i made that screenshot), but it’s still something I try to do out of habit. When swiping right-to-left instead it registers as a tap on the post I touched and tries to reply to it. Kind of annoying, but I’ll overcome.

Another thing that kind of bugs me is that the app loads on the global screen every time, and has to load it before I can go to my timeline, which is where I’ll want to be most of the times. A ‘default screen’ option would be nice.

What does what?

Also confusing at times is what is going to happen when you tap something. The first three posts in my screenshot have a yellow corner, meaning they’re part of a conversation. Tapping it will show the conversation, but it starts at the top showing the newest replies first. To read the conversation chronologically you have to scroll down and then read from bottom to top.

Tapping any of the posts in that conversation opens a reply-screen where only the person whose post you tapped is mentioned, but the reply still shows up in the original conversation, even if you’re not mentioning the OP. This might be just how app.net works but I found it rather confusing.

Tapping a non-conversation post will open a reply-screen that starts a conversation immediately, which is logical. That’s good.

Then there’s other people’s profiles. Basic as they are they’re pretty self-explanatory. Except for the eye-icon; it mutes the user. You’ll only learn that by trial and error. But maybe I’m nitpicking.

Profile in Rhino

Missing functionalities

What I’m missing most though are two basic functionalities: profile editing and search.

Search really is something that yet has to flesh out all across app.net. Even web client Alpha has just a very basic search page that doesn’t work anything as well as for example Twitters search. In addition there’s some third-party apps that will find some of your Twitter friends for you, but that’s about it.
Rhino however lacks a search functionality entirely. This is quite honestly a major drawback.

Editing your profile also isn’t possible. The settings icon on your own profile screen has some app settings but nothing about your actual profile. When I asked the developers they did insinuate that that’s in the works though. As I said, we can safely assume that everyone is still working on fleshing out all the basics at this point in time.

The good parts

When looking at developer Planet 1107′s timeline and the #rhino hashtag, it seems that the developers are keeping an eye on what people are saying. They responded quite swiftly to my questions too.

Another thing I like is the graphical design (apart from te UX). Basic as it is, it’s all very clean and clear and gives as much room for the most important things, the posts, as your screen allows. With the exception of the mute-button all the icons speak for themselves too.

Rivr

After using Rhino for two days I gave Rivr a try. I’d seen it in the app store but scrolled past it for some reason, until someone mentioned it in a conversation. Don’t let whatever made me scroll past it deceive you though, because this is one hell of an app.

The screens

When I first logged in it gave me one single screen, my timeline. There were just two buttons at the top: the three-stroke icon that’s quickly becoming the standard in app- and mobile webdesign for a pullout menu, and a plus sign to add a post with.

The first thing I did was try to add a post. Pressing the + does the same as swiping right-to-left: it shows a menu on the right side of the screen where you can choose different types of content to post.

Post type options in Rivr

That’s right, you can post text, photos, music, your location or apparently a mood. Along with each of the non-text choices you can still add some text.

The photo feature pleasantly surprised me. Not only does Rhino not support this at all, Rivr even lets you add some built-in filters. I’m not a fan of the whole Instagram hype, but it’s nice that it’s possible at all so people don’t have to switch to another app for that.

Photo filters in Rivr

What adding music does I’m not quite sure of. I was able to search for music, starting by default (but not limited to) what I was playing, but where did it get its information from? The post (as seen in the first screen) featured the name and artist of the song along with an album cover, but it didn’t do much. Unless it was trying to play it and my 3G connection just failed. I’ll have to test that on wifi.

The menu-button (or swipe left-to-right) opened up a whole new world for me: where Rhino has only four screen choices, Rivr gave me this:

Navigation menu in Rivr

Most of that speaks for itself. I probably won’t use the #rivr page a lot, but I can at least follow my own favorite hashtags under #Topics.

The settings page has a couple more options than Rhino too. It even lets me choose to open links in Chrome instead of Safari, that’s a very big plus for me.

What does what

The design of Rivr is quite intuitive. I had to take a closer look at each of the five post types I could enter, but apart from that it’s all very clear.

Also, actions are consistent throughout the app. Tapping a tweet always shows a menu with options like repost, favorite and view conversation. Swiping always shows the post menu or the navigation menu (depending on which direction you swiped). There are no surprises in the interaction, which is how it should be.

The bad parts

Where for Rhino I ended with the good parts, I think for Rivr I’ve been praising enough already.

So far I haven’t found any real showstoppers, but it does bug me that even here I can’t change my profile.

Also, the “pull down to refresh” action really seems a bit despondent, often making me repeat three times to be sure there actually aren’t updates.

Another thing I’m missing, even though it has a decent search, is a way to find new followers. Searching for “html” in users gave me nothing, so it’s not searching in people’s bios, but really what I’d like is just recommendations. I’m always looking for more front-end developers to follow, so a recommendation feature of some kind would be really nice.

And the winner is…

Even though I really didn’t expect any full-feature apps yet (hell, even Google needed several months to develop a good iOS app), Rivr has a lot of good stuff going on. Apart from the minor drawbacks I described, which I’ll definitely get over, it seems to have more than I could wish for.

After using the app for a few more weeks, and if App.net gets bigger and busier, I’ll probably have a few more features on my wishlist, but for now my choice has been made:

Rivr is the clear winner. I guess it won’t take long until Rhino and other apps catch up, but especially in the web- and app culture early birds get the worm.

Did I miss something? Do you disagree whole-heartedly? Would you like more details about certain features? Let me know in the comments, or on Twitter (@litso_) or App.net (@litso).

The post Rivr vs Rhino, a comparison of free app.net clients appeared first on Stephan Muller.

Here's a random example table from a site I've been working on.

Classes

Now say you want to align the columns with numbers to the right and give the final column a different background color. One of the ways to do this is to use classes on each of the table cells.

This isn't a bad solution per se, especially if you use semantic classes and not just class="align-right", but on big tables you end up with lots and lots of classes horizontally (for every cell that you need to style) and vertically (for every row, repeat the cells and their classes). I don't like that.

The <col /> element

Another solution is to use the <col /> element. By defining the columns in your table you can add CSS hooks to it in this way:

<table class="sales">
  <colgroup>
    <col class="month" />
    <col class="credits" />
    <col class="dollars" />
  </colgroup>
  <thead>
    <tr>
      <th>Month</th>
      <th>Credits Earned</th>
      <th>Dollars Earned</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>June 2012</td>
      <td>2,054</td>
      <td>$133</td>
    </tr>
    <tr>
      <td>July 2012</td>
      <td>1,580</td>
      <td>$89</td>
    </tr>
  </tbody>
</table>

(I left out a row for brevity)

Now you can use .month to style the first column, or if you only want to style the contents and not the header cells you can use .month td.

The problem? You can only style the border, background, width and visibility. Not even the text-alignment. Why? No idea, it shouldn't be too hard to implement other styles there as well, right? (Fun fact: IE6 does support all styles this way)

nth-child()

So that leaves us with one more solution: using CSS3's pseudo-classes. The nth-child() selector allows you to choose specific siblings of elements without the need for classes. For example, if you want to style the "month" column you only have to count to one:

.sales td:nth-child(1) {
  color: red;
}

Or if you want to align both the heading and content cells that contain numbers to the right:

.sales tr :nth-child(2),
.sales tr :nth-child(3) {
  text-align: right;
}

There's a lot more to the nth-child than just this. You can use counters to select every nth element: :nth-child(2n+1) selects every second element, starting with the first, :nth-child(-n+3) styles only the first three elements, and if that's getting too confusing don't visit nthmaster.com, because I've only barely scratched the surface.

The downsides

Of course there's some minor downsides to this method. First of all, it's not supported by IE8 and lower. I know, that's still a problem, but Microsoft has been getting better at pushing their browser updates so I expect it won't even be too long before IE8 won't have to be supported anymore. Or you can just use Selectivizr.

Another downside is that it gets a little harder to maintain. When you have to add a column to a table, you'll have to re-count instead of just adding a <td> with a class. If you know your tables are going to change a lot, maybe stick to classes for now.

All in all though, for projects where I know the HTML doesn't change much and I'm not too bound by supporting older browsers, I tend to use these pseudo-selectors more and more.

If you feel like playing around a bit more with these rules, see this awesome Pseudo-class selector tester and the aforementioned nthmaster.

The post Styling table columns with nth-child() appeared first on Stephan Muller.

So far I’ve added just a few basic rules in media queries based on where my site broke down when resizing the window (not on standard phone screen sizes, see this blog post). Over the next few days I’ll still have to tweak and fix some things and test on more devices (and especialy Opera Mini/Mobile) but at least I’ve made the first step.

Future, here I come!

The post On the way to Responsive appeared first on Stephan Muller.

function getElementByAttributeValue(attribute, value)
{
  var allElements = document.getElementsByTagName('*');
  for (var i = 0; i < allElements.length; i++)
   {
    if (allElements[i].getAttribute(attribute) == value)
    {
      return allElements[i];
    }
  }
}

In case of multiple elements with the same attributes this will only return the first one.

Example

Sometimes I use elements like <header role="masthead"> in my site to be able to style the site's header (masthead) differently than other header elements, for example post headers. To select this element in JavaScript I'd now use:

var headerElement = getElementByAttributeValue('role', 'masthead');

The post Get element by attribute value (plain Javascript) appeared first on Stephan Muller.

One problem I kept encountering was that of using display: inline-block. In all modern browsers this is supported, and often it’s a lot more useful than using floats. The problem once again though is IE7′s support for it.

For some reason inline-block only works in IE7 when the element has a native display value of inline (like <a>, <span> and <strong>).

What does work however is forcing the mysterious hasLayout property on the element by using a CSS property that invokes this effect. The most commonly used one is zoom: 1, which doesn’t change anything to the element except force it to get hasLayout.

Finally, to make the element appear like an inline-block in IE7 force it to display: inline (and the hasLayout property will do the rest of the work).

One way to target only IE7 is to prepend a CSS rule with an asterisk (it’s the only browser that will accept this property, all the others will ignore it.

So your code will become:

.my-inline-block {
	display: inline-block;
	zoom: 1;
	*display: inline;
}

Of course, if you use the HTML5 Boilerplate you will already have a way to target IE7 specifically:

.lt-ie7 .my-inline-block {
	display: inline;
	zoom: 1;
}

The post Display: inline-block in IE7 (CSS hack) appeared first on Stephan Muller.

So, I scoured the web for lists of Dutch stopwords, and combined those to make a Dutch version of the plugin. I’d like to make an internationalized version that contains multiple word lists, and I may do so in the future, but for now here’s just a Dutch version of the SEO Slugs plugin.

Download SEO Slugs Dutch for WordPress.

The current list counts 131 words, but suggestions and updates are always welcome of course (in the comments or to @Litso_). To see a working example of this plugin visit denkeensna.nl

The post SEO Slugs Dutch – Remove Dutch stopwords from your Blog URLs appeared first on Stephan Muller.