If you try to use negative margins and increase the width of the container (like some fixed-width grids are doing) the browser breaks down. In the example above you’d need to increase the width of the container to 105% and redo the computations for the grid boxes. The grid boxes will have a 2.5% left/right margins and a width of 21.25% (105%/4 – 5%). The math becomes more complicated for 16 column grids or for nested grids. I tried it but the browsers do not behave consistently so, even if you are willing to struggle with the math, I don’t think this is a viable solution.

Stepping back from this problem I realized that the complexity of this problem is generated by the desire to have the left margin of the first column exactly aligned to the left margin of the container and the right margin of the last column exactly aligned to the right margin of the container. But if you stop and think about it, when you want to use a fluid grid/layout you’re not working with a, lets say, 960pixels wide container. So, even if the container is the BODY tag you still need some kind of left/right margin so the content doesn’t touch the margins of the browser window.

Since you must have those margins you can use those margins to help you with the problem. Let’s say, inside the BODY tag, you only have a 4 column fluid grid, each column being 25% in width. That is perfectly possible in any modern browser. Since the first and last columns in the grid must have a left and right margin, so that their content don’t reach the window’s margins, you must make sure that the content of the columns will have left/right margins. That can be achieved easily via CSS using child selectors. All you need to make sure that the columns will have only block-type elements. Which that happens most of the time; there are very few occasions when you have text or inline elements in columns)

This is a WordPress blog and the side bar contains only block type elements with class “widget” and the main area contains only block type elements (headings and divs for the articles) so it’s easy to see how a fluid layout (75% for the main content and 25% for the sidebar) can be achieved on this blog.

The only caveat with this approach is that, since the content of grids will have a left/right margins relative to the grids container you must make sure that the rest of the children of the container must employ the same margins.

But enough with the theoretical mumbo-jumbo. I’ve created a set of LESS mixins that can help you create fluid grid/layouts. Check out the project page.

Without further ado, here’s the WrappingFactory.

Do you know any similar campaings? I’m interested in ebooks, audiobooks, video training sessions.

Andy Clarke, in his “Hardboiled CSS” book, talks extensively about how a website shouldn’t look the same in all browsers, going so far to deliver only a basic stylesheet for IE6. Many designers and developers, myself included, agree with his reasoning.  But just like myself, other developers have been trying to find the holy grail of responsive design, the responsive grid even though that contradicts Andy’s reasoning. I mean, we are willing to give IE6 users an experience significantly reduced compared to other users, right? So why would we even attempt to cater for people that have, for whatever reason, their browser window set to, let’s say, 944 pixels when their monitor is 1024 pixels wide when most of the people on that screensize have their window maximized and we can safely use a 960/980 pixels grid? I bet these users are fewer than IE6 users. The same goes for people that have their browser window set to a size that is not a common screen width.

Andy Clarke says we should let go of trying to achieve designs that look the same in all browsers because not all browsers are created equal. But not all browser windows are created equal so we shouldn’t try making fluid grids either. Or we should. But just not using the traditional approach anyway.

First solution: Think outside the grid!

The Fluid Baseline Grid creates truly responsive grids but only because it’s not a grid as we are used too (12/16/18 columns) but because it limits the grid to 3 equal columns for which the browser math is more exact and the gap between the last column’s right margin and the right margin of the grid container will always be acceptable. And if you really want to have perfect alignment you can have the 3rd column float to the right.

As long as you stop thinking “I have a 16 column grid, the left side will have 4 columns and the right will have 12 columns” you can achieve flexible grids. Your responsive design will look like this

instead of

This way, later on, if you need a 3 columns row in the #main section you can have the 3rd column right-aligned with the main content no matter what the actual size of the browser window is (that is, until a media query may be used to display those 3 columns one after another). This accuracy cannot be achieved with any of the flexible (and classical) grids I have found. If you know one let me know.

Second solution: Think outside the window!

Outside the window it’s the screen. No, I don’t mean to start writing your media queries based on the screen width but to assume that the browser window is maximized and design fixed-width layouts for specific screen resolutions. I have to mention Andy Clarke with his excellent project, 320AndUp.

Doing fixed width layouts you can achieve pixel perfect precision but you will not have a fluid and flexible grid. Consider the following scenario: a user has a 1280 pixels monitor but his browser window is set to 960pixels. Using the 320AndUp screen size breakdown the user will use the 768 pixels style-sheet and you will deliver a fixed width design (let’s say 750). That user will have 105 pixels of empty space around it’s design but it will be a pixel-perfect design, different boxes will be aligned perfectly. You can still have your 16 column grid and make it (sort of) responsive too. I think it’s a small price to pay.

From this point of view the Simple Grid project is an almost perfect solution. The only caveat is that it’s not semantic but for that we have the Semantic Grid.

I’ve created something quickly to show my approach to solving this problem. It’s a rough draft but I think it has all the ingredients to become a viable solution. I will set up a GitHub repository for this as soon as I test it more thoroughly.

Recently the Filament Group, the company supporting the Jquery UI, boasted the creation of Boston Globe using responsive techniques. Looking at the BostonGlobe’s website I’ve seen the “right” technique is used: images are placed inside containers and CSS is used to style the container while the image is set to 100%. This is not good in my opinion.

There’s a lot of discussion today about the “mobile context” and some people are trying to dismiss the mobile context because we can’t make “sound” assumptions about it. This is true, but the thing is we can make “justified” assumptions. First of all we can assume that we won’t be working with “:hover”. So all those nice javascript tooltips must be replaced with something else. We can assume that if a user sees a picture displayed in a 200×200 box it would be better to serve him/her a 200×200 picture. We can assume that if there’s something we want to hide via CSS it would be great not to serve that piece of content.

Other people have been thinking about this issue too. Luke Wroblewsky is one of them. I’ve found his article after coming up to the conclusion that a good solution would require to use the server while searching if people actually found a solution. Understandably, I didn’t. While on the client-side developers have CSS and Javascript as common languages for sharing ideas, the server-side world is more like Babylon. I don’t know any exceptional PHP programmer that is very good with CSS3 and viceversa and I don’t know exceptional programmers concerned about the website’s design or UX, and I think that’s another reason why there the “responsive web design” problem hasn’t been tackled from the server-side perspective yet and remains a monopoly of the client-side developers.

There are 2 contexts to be considered while considering responsively delivering a piece of content over the web

1. The device context. This includes screen resolution and size, browser features etc
2. The page context. An article image can be placed on a main section of the page or on a side bar, a sidebar that can become a footer at a different screen size

If you don’t use a responsive client-side solution and deliver only one design independently of the device context your server will know the page context so you will be able to deliver the right image. But you will deliver the “right” image for the wrong device content. Alternatively, if you use only a responsive client-side solution you will deliver the “wrong” image for the right device context.

You can’t escape the server if you want a good solution to the problem posed by the multitude of devices currently available all over the world.

In a next article I will try to present a solution. I already that it won’t be easy to implement because of the multitude of frameworks available on the PHP world so I will try to lay out first the concept and workflow so the solution be implemented using other server-side technologies.