Flexible Layouts: Challenge For The Future


This article is a guest post written by Dirk Jesse, the developer of YAML (Yet Another Multicolumn Layout), an (X)HTML&CSS framework which explains his motivation for YAML in the last paragraph of the article. This article is supposed to initiate the discussion about the need for more flexible layouts in modern web design and explain why flexible designs are still important — even despite the Full Page Zoom-functionality implemented in most modern browsers.

The new generation of web browsers — Firefox 3, Opera 9.5 and Internet Explorer 7 — provides a feature which seems to save a lot of work for web-developers in the future, namely the Full Page Zoom. Instead of allowing users to increase and decrease the font size on a given web-site, browsers now enable users to literally scale the rendered layout including visuals and background images. The whole design layout is scaled proportionally according to some adjusted zoom-factor, with all the elements of a page’s layout expanding equally. Consequently, every fixed, pixel-based layout becomes “scalable”; the content area always remains within the layout box it is supposed to be in and there is no chance of producing overlapping boxes as we’ve seen in the previous generations of web-browsers.

However, is the new zoom-technique indeed so advanced that we don’t need flexible layouts any longer? Just as this question is extensively1 discussed2 in the3 blogosphere4, it is extensively answered with “yes”. And there is a good reason behind it. The coding of a fixed layout is much easier and, when used properly, produces exactly the results a designer is willing to achieve. With fixed layouts, designers can ensure the exact positioning of each pixel (a dream of many graphics designers comes true!) and the user can adjust the size of the layout with a scaling zoom on demand. No wonder that it’s tempting to motivate the switch to fixed layouts. However, as professionals, we need to consider how reasonable it is from the professional point of view.

In the following let’s discuss why we strongly believe that this paradigm won’t lead web design to more user-friendly and accessible web-sites, why flexible layouts still remain important today and why they will become even more important in the future.

Where Full Page Zoom doesn’t help at all

The main difference between fixed (px-based) and flexible (%-based) layouts is the simple fact that flexible layouts can better adapt to user’s viewing preferences. With flexible solutions, the width of the layout depends on the viewport of the browser and can perfectly fill the viewing space without any manual adjustments from the user’s side. Fixed layouts can’t do that. Full page zoom, when applied to fixed layouts, enables users to manually adjust the design after it has already been rendered.

Another important aspect which is worth keeping in mind: Internet Explorer 6, probably the nightmare of every web-developer out there, has a market share of almost 40% — and it doesn’t support zoom at all.

According to w3schools.com, the larger and wider screen resolutions (larger than 1024×768px) will become a standard in the future.

More problematic is the overwhelming confidence of developers that the individual decision-making is better for users from the accessibility point of view. When applied to fixed layouts the web-developer delivers a clear message:

Dear users, your browser can zoom my fixed layout – so please help yourself if you want or need to!

From designer’s perspective with this argument it is tempting to switch to a more comfortable (fixed) design solution at expense of accessibility. Why should a user adapt his viewing preferences to a web-site? Shouldn’t a web-site rather adapt itself to the viewing preferences of its users? If you think about it for a second, you have the same situation as in a cloth store where you are offered cloth only in some very specific size. If the size doesn’t fit to you, it’s your problem, not store’s owner. And if you want to you can take a needle, some fabric and create the cloth of its own choice for free. That is not user-friendly.

Even more crucial is the simple fact that full page zoom isn’t really feasible in practice. Let’s assume that the designers has a fixed layouts with the width of 960px. To zoom it using a 150% scale factor and still browse the page without horizontal scroll bar, users need to have at least the screen resolution of 1440px and a browser opened in the full-screen-mode. Is it really a path for the Web to take in the years to come? As Nancib5 states, “problem is that sometimes the font on a page is friggin’ tiny without zooming it in, but zooming the page (with the images) doesn’t just make it more readable.”

Web developers often tend to argue that flexible layouts are too complex and with full page zoom every fixed layout is becoming scalable anyway. That’s right, scalable, but not flexible. Why should a browser correct the mistakes a developer or designer has done when creating a site layout?

Flexible layouts are hard to control? That’s not true!

Whenever designers argue against flexible layouts they tend to use the following argument:

In flexible layouts the text flows in the width when expanding the browser window, making the content hard to read. This text flow is hard to control.

Wide text flow is definitely not a nice thing to offer your visitors. However, text flow doesn’t need to flow in the width when the browser window is expanded. To achieve attractive flexible designs one can use the properties min-width and max-width. Of course, Internet Explorer 6 doesn’t support both of them — just as it implements both hasLayout-model and the Float-model incorrectly. However, this is not the reason to not use floats for your design layouts, right?

To simulate max-width and min-width you can use various workarounds (JS Expressions6); and to simulate min-width you can even use a pure CSS-solution7. But what happens if the user’s browser doesn’t support JavaScript? Well, in this case a flexible Layout without max-width doesn’t necessarily destroy the layout, although the text flow may be too wide. But this is what the Progressive Enhancement is all about, so this is not that problematic.

How to find an ideal width for a flexible layout?

Let’s consider how wide the layout should be for an optimal flexible layout:

  • Layout width: use width:auto or any %-value to make sure that the layout makes use of the available width of the browser windows automatically.
  • Minimal width: use some px-value (e.g. 760px). This lower bound should be used for all pixel-based layouts, so the content remains readable when displayed in the minimal screen resolution.
  • Maximal width: use an em-value (e.g. 90em). Thus the text flow doesn’t grow in width in an uncontrollable fashion, but remains constant for various screen resolutions. Side effect: the maximal width is scaled according to the font-size of the browser.

Also keep in mind that we, designers, don’t really have the design layout (whether fixed or flexible) under control as the presentation of our layouts depends on the browser, font size adjustments, operating system, alternative user-stylesheets etc.

The Holy Photoshop Mockup

The most frequent argument used to motivate the fixed layout solution is the fact that customers are confident that a perfect Photoshop mockup would look best when displayed 1:1 in user’s browser. Indeed, it is hard to explain to the customers that flexible solution, although looking differently in different context, has some advantages. After all, if the design doesn’t look as expected on senior project manager’s wide screen laptop, then this is not something the customer would agree on.

However, following customer’s decisions blindly you neglect your professional responsibility to develop accessible, user-friendly web-sites. It’s your duty to complement your customer’s wishes, compromise and seek for the best possible solution for users and not for the senior manager. A quick argument that a user-friendly solution which doesn’t look best at some specific configuration would bring more satisfied customers and consequently more money in a long run usually suffices.

Vivabit.com9: transparency, patterns and background images can lead to impressive and flexible results.

The end-result layout isn’t supposed to be used as a nice screenshot for one single portfolio. It has to serve users’ needs and enable them to get to the content of the site as quickly and as painlessly as possible. Take your time and go through some of the layouts presented in numerous CSS-showcases. In way too many cases the attractive pixel-based design breaks down completely when the browser window is resized or the content is scaled. A Photoshop Mockup isn’t necessarily easy to convert into a flexible design layout, however it is definitely worth consideration. Transparency, patterns and background images can lead to impressive and flexible10 results.

In most cases we design web-sites not to present some design, but to let the design help users to achieve some objectives such as finding the information they are looking for. Graphics-heavy flexible layouts are not easy to achieve and require planning, patience and confidence that the results are worth it. However, these efforts improve user experience and make the design medium-independent.

Mobile Browsers – Why flexible is better

Mobile Web layouts as well as its small and big problems are a topic which is worth a single discussion. Just one year ago my old mobile phone could access the Internet, however it was extremely hard to browse web-pages, read them and navigate. With the improved user interface of iPhone it has completely changed. Mobile web-browsers (e.g. Opera Mini or Safari on the iPhone) have dramatically improved over the last two years — at the moment it is almost natural that they render web-pages without any considerable display errors.

My iPhone has no problem displaying flexible layouts in the landscape format or portrait format; in fact it automatically adjusts them to the best format which fills the whole iPhone window. At the same time I often experience problems when loading fixed layouts — from time to time they need to be zoomed in to fill in the whole browser window.

What holds for mobile devices holds also for printing devices. Ironically, nobody really argues about the advantages that flexible layouts for print layouts manage to deliver. Flexible design allows to use portrait / landscape – formats for optimal printing.

The decision for flexible layouts against fixed layouts doesn’t only improve the accessibility on Desktop-PCs, but also creates robust and flexible medium-independent layouts which can be easily adapted to any output devices. After all, with flexible rules (relative measure units, minimal margin and padding, alignment etc.) instead of fixed rules (px) rendering engines can better consider the properties of the used media.

The future, the unexplored land

As mentioned above, the mobile Web is becoming more and more important. Are we now going to optimize layouts for 640×480 or 800×600? The screen resolutions are increasing, the prices for high-resolution displays are decreasing. At the same time the physical resolution of devices as well as the spatial printing resolution (dpi). Consequently, the absolute size of one pixel decreases. No wonder that pixel-based definitions are becoming less expressive.

The gap between low-resolution displays and high-resolution displays hasn’t bridged over the last 10 years. On the contrary: the gap has increased dramatically. Web-sites are viewed in hundreds of possible screen resolutions while each user may have his own preference for the viewport of his browser. This consideration alone explains how important flexible design layouts are today and how important they will be in the future. Consequently, fixed layouts won’t make the cut in the future as designers will need to consider more and more different devices to optimize the design for. What we need in web design to come to grips with all this variety are dominating relative measurement units.

Flexible Layouts with YAML


YAML12 (“Yet Another Multicolumn Layout”) is an (X)HTML/CSS-framework which was developed especially to meet the requirements of flexible and user-friendly design layouts. Since June 2007 YAML is available in English and provide an extensive documentation. Most CSS-Frameworks like Blueprint CSS13 or YUI Grids14 offer designers a predefined system of CSS-classes to create grid-based layouts visually. To create a layout designer needs to create a HTML-structure of the site and to assign CSS-classes to containers. The rest is automatically taken care of.

YAML takes a different route. The Framework supports the development of grid-based layouts as well as the development of the grid system – with the emphasis on flexible layouts. If a designer wants to create a grid-based layout he can use the basic skeleton with three columns, header and footer. Each element can be removed or adjusted to user’s needs. The actual design, the positioning of the columns, is done using CSS-definitions (and not HTML-structure as it is done in other CSS-frameworks). The benefit for designers: with YAML one has better options for defining his own system of classes, using any measurement units and getting clean code.

Based on the HTML-structure of YAML, the framework includes layout presets which already prevent IE-bugs; thus the framework makes it easier for designers to create a layout which works in both modern and older browsers. Layout examples15 provide an overview of what is possible with YAML and may deliver some ideas for your future layouts. Apart from that, YAML offers a set of flexible grid-components which you can use to create columns within columns and thus design a more complex but flexible Grid-layouts.

YAML Example17: a demonstration of YAML’s flexible grids.

Consider the example above. BluePrint CSS has a demo-page18 which displays a layout created with Blueprint CSS. And this19 is the result of the very same template created using the flexible grid-elements of YAML. The scaling works even in IE 5.5, including min-width and max-width.

Apart from layout design, YAML also delivers style sheets for print layouts, as well as components for horizontal and vertical navigation. YAML definitely requires some time to climb the learning curve: the tool offers a variety of functions and user-friendly flexible layouts are definitely not easy to build.

The concept of YAML is, however, well documented in the online- and PDF-documentation and my provide beginners and professional with a good introduction to the framework. For practical purposes you can also use YAML-Builder20, a handy tool for visual development of YAML-based CSS layouts which allows you to put the containers of the layout visually together via drag-n-drop. The valid HTML- and CSS-code is generated automatically on the fly.


  1. 1 http://nancib.wordpress.com/2008/06/15/what-have-i-got-against-firefox-3/
  2. 2 http://nancib.wordpress.com/2007/12/20/an-opposing-view-on-the-firefox-3-zoom-issue/
  3. 3 http://www.glazman.org/weblog/dotclear/index.php?post/2008/02/08/fullzoomchanged-event
  4. 4 http://nancib.wordpress.com/2007/12/20/an-opposing-view-on-the-firefox-3-zoom-issue/
  5. 5 http://nancib.wordpress.com/2007/12/20/an-opposing-view-on-the-firefox-3-zoom-issue/
  6. 6 http://www.cameronmoll.com/archives/000892.html
  7. 7 http://www.dustindiaz.com/min-height-fast-hack/
  8. 8 http://www.vivabit.com/
  9. 9 http://www.vivabit.com
  10. 10 http://www.vivabit.com/
  11. 11 http://www.yaml.de/en/home.html
  12. 12 http://www.yaml.de/en/home.html
  13. 13 http://code.google.com/p/blueprintcss/
  14. 14 http://developer.yahoo.com/yui/grids/
  15. 15 http://www.yaml.de/fileadmin/examples/index.html
  16. 16 http://www.highresolution.info/webdesign/sandbox/yaml_grids.html
  17. 17 http://www.highresolution.info/webdesign/sandbox/yaml_grids.html
  18. 18 http://files.bjorkoy.com/blueprint/tests/parts/sample.html
  19. 19 http://www.highresolution.info/webdesign/sandbox/yaml_grids.html
  20. 20 http://builder.yaml.de

↑ Back to top Tweet itShare on Facebook

  1. 1

    I’ll try it out. I have tried Blueprint and like using it. Does using these frameworks make us lazy and not need to keep up with our own CSS knowledge?

  2. 52

    I read the YAML thing thinking… this is HTML… not YAML. Where’s the YAML. :-)

    I’m going to create a new CSS framework and call it Perl – cuz that’ll make just as much sense.

  3. 103

    Steve Meisner (way short of heaven)

    June 27, 2008 2:46 pm

    Great stuff. We have to bring the info to the masses, and there is always a new and better way. I’ll send this along to my boss – ha.

  4. 154

    Camilo Oliveira

    June 27, 2008 3:42 pm

    BTW, Smashing Magazine now has centralized layout.

    For big resolutions I prefer left aligned, with text column increasing space until still user can be a pleasure reading. Isn´t better?

    And very interesting article. I liked it very much.

  5. 205

    wow i just found out about FF 3’s new zoom and had the same thought as this article, glad i saw it here, cleared my questions! thanks smashing

  6. 256

    Why did smashingmagazine.com just switched from a flexible layout to a fixed one?

  7. 307

    I disagree. If you write enough css/html code you know the common internet explorer bugs, learning a framework will only slow you down and impede learning. It isn’t like learning a javascript framework. Plus, those “grid” based frameworks are not semantic and not in tune with web standards, likewise, if the XHTML itself remains the same and the user only changes the css something is wrong in the equation.

    I won’t even go into why using XHTML period isn’t a good idea…

  8. 358

    @Dirk Jesse

    I disagree. If you write enough css/html code you know the common internet explorer bugs, learning a framework will only slow you down and impede learning. It isn’t like learning a javascript framework. Plus, those “grid” based frameworks are not semantic and not in tune with web standards, likewise, if the XHTML itself remains the same and the user only changes the css something is wrong in the equation.

    I won’t even go into why using XHTML period isn’t a good idea…

  9. 409

    Excellent post!

  10. 460

    Vitaly and Sven,
    The new Smashing Magazine layout is a wonderful improvement you’ve made to the site. So much easier to read… Thank you for the resources you provide.

  11. 511

    Mucio Rodrigues

    June 29, 2008 3:02 pm

    Excellent techniques

  12. 562

    this is just a test to see how this site handles a comment

  13. 613

    It’s certainly an interesting resource, but since most users (even to date) don’t even know they can resize text size I’m not too worried about the zoom feature either.

  14. 664

    yeah, i think the zooming feature is completely overrated in this article, nobody will really use it. only bad designed pages like the enormous portals created years ago might need additional zooming, but that’s really an exception.

    now, small portable computers need zooming as well, but it’s a better option for them to simply scale the whole output, so that the original layout of the developer isn’t affected at all.

    i’m regularly shocked about non-existent abstraction levels in HTML/CSS developement. it’s like writing a big application only in assembler. that’s stupid and error-prone. there’s a reason why developers built abstraction layers around assembler-code, for example C or more modern variants like .Net or Java. it makes life easier, code much better and the development process much faster and secure. every new abstraction layer brings tons of new possibilities that weren’t possible before. check yahoo pipes, a perfect abstraction example.

    it really scares me to see what happens when designers say: “pros don’t need frameworks, they know what they do”. this is just plain wrong. its so ignorant it hurts.

    like programmers already learned decades ago, nobody writes assembler code anymore. even if it’s obviously much more flexible than any abstraction of it (a programming language) – it’s impossible to debug the code properly or cooperate with another programmer.

    using layout oriented frame-works is a good start, but html developement is still a mess like no other. even the weirdest C code is easier to read and maintain than a simple webpage “project” with html, javascript and css. it’s time for much more abstraction in that area.

  15. 715

    Lots of talk but no serious arguments, imho. Been making sites for 10 years now, always sticking to the standards. I’m also a great fan of WCAG and other initiatives for people with disabilities, and from my perspective liquid layouts don’t have much to do with making their lives better nowadays.

    It is possible to make a 100% friendly fixed layout anyway and – as I see it – it is more desired by users themselves (in case of people 60 y/o and more e.g. it’s more about 800×600 fitting layouts – polls say – which may, but doesn’t have to mean liquid). I don’t feel comfortable when a site changes in front of my eyes while the browser’s window is being resized. That’s confusing. I want all site elements to keep their position when I play with browser’s window.

    Of course there are pros and cons. Personally I think it’s ok to build a site with the text-column adjusting to window’s width, just like here, but it wouldn’t make a real difference, if smashingmagazine.com had fixed width, would it? There is a point for mobile devices, but take a look at iPhone and other newest mobile devices – what we’ve got there? Zooming the whole site! :) Why? Because IT IS giving a better user-experience, for it’s THE USER who’s got the control – not us deciding for him in the name of “caring” ’bout his lack of skill in his browser usage. Imagine a situation when what you want is only a part of the site visible (e.g. some text) in the browser window while the rest of the screen is used by some application you work with while reading the text – e.g. you’re translating something from a site and you got both – a browser and MS Word opened. Liquid design wouldn’t let it happen or it’d make it harder ’cause the text’s gonna change its layout and you’ll have to scroll in addition, or in worst case – you won’t see the whole part you want at all. I think browsers are something external while sites are something internal we give to browsers so they can interpret it and give users control at. What flexible layouts do is linking one with another and forcing the user to accept this unnatural dependence.

    The argument that we – pros – should not forget ’bout our duty to take care of everyone is pointless – I’d call it a blind purity, because there are other standards and solutions out there to provide to REALLY make a difference for those, who need it.

    Talking of “pointlessness” – so is the t-shirt analogy:

    >> T-shirts aren’t stretching to fit our bodies – we’ve got fixed sizes to choose between :-)

  16. 766

    Thanks for sharing these wonderful pieces of art.

  17. 817

    (Why wasn’t I informed ’bout the char-limit of the comment still being able to write as much I want, so now I lost the ending + I’ve been redirected to the main page instead of this article after approving the comment? – I thinks it’s a great example of must-take-care-of-for-user-experience-sake things to really think of.

    OK, there’s the second part, I haven’t really lost it – thanks to the back button ;-)

    – and there’ll always be someone for whom there is no size of a particular shirt available – it’s a matter of target. It’s impossible to make an universal site right now or it has to be a text-only one, or pretty uncreative other way. There always will be someone who can’t view it properly or the way he needs under some circumstances. What we can do is minimize that possibility by sticking to the web and usability standards. THERE’S NOTHING WRONG ’bout liquid designs, but suggesting that it’s the only right solution is just untrue.

    Standards evolve, browsers evolve, so is the disabled (this way or another) people experience. As for me, making the design liquid is more a matter of taste, of what kind of designs you do, rather than a matter of usability. It’s been once but it’s not anymore A REAL tool. The direction is already set. In my life I’ve never done a liquid layout (just one partially liquid due to an ad-system presence), however I plan to do one for one of my nearest projects according to the character of the content and the target audience, we’ll see. It’s more about the feel rather than a true advantages right now.

    You can always give a font-resize feature and make sure your layout doesn’t screw up when it’s used. No JS? Then we get back to the whole point – the very browser that’s responsible for functions we can’t really fully provide. Flexible width is a way, but only one of many. Still, it’s a short one.

    So run highways – just make sure guys your sites are accessible and consider liquid layouts as a design’s feature you may implement or not, a solution that might help but it may harm your project as well. Harmonize your creativity with user experience, but don’t limit it when there’s no real need to.

    I believe both – fixed and flexible widths are fine, but it’s more about the project rather than the user.

  18. 868

    I agree with h-a-r-v completely.

    And while h-a-r-v had the grace to not take it this far – I will say this article is horse manure and not worth the pixels it uses.


  19. 919

    I agree with Connor. Each layout method has its place. Text-heavy sites like blogs can benefit from a flexible layout. But if the content is graphically rich, having a flexible layout can damage the flow of what could be best laid out with a grid.

    Text flows. Images don’t. The layout should support the content.

  20. 970

    Mateo Tibaquirá

    June 30, 2008 12:55 pm

    Thanks for your hard work Dirk!

    I’m playing with YAML from some time ago and it’s great! We already have a Theme Framework based on YAML to engage the Theme Development on my favorite Web Application Framework (Zikula)

  21. 1021

    Here’s my vote for retaining the 1024 size as a sort of standard: it’s enough room to get most everything you need in (with exception of course), but it’s not a colossal pain in the butt for people on small screens.

    What the w3c didn’t take into account was:

    1. people with big screens PROBABLY don’t browse maximized
    2. there’s a resurgence of small screen devices (iphone, eeepc, etc)

    I expect to see #2 substantially on the rise in the next 3 years. Not thinking about those users woudl be a big mistake.

    On a related note, Opera also has a ‘fit to width’ feature that’s really handy for broken sites, overly large sites, etc, that forces content into a pseudo-liquid layout w/o breaking it too much. Very cool and handy.

  22. 1072

    I have to disagree with you, h-a-r-v, on two bits. When I resize websites, I do expect them to stretch along with my content. Maybe I’m a bit of an old-timer, but when the Web was first created, everything was fluid. Or maybe it’s because I browse Wikipedia too much. Or maybe it’s because I’ve been more exposed to webapps that use flexible layouts. I guess it’s just a matter of what you’re used to, but I’d just like to say that the web is not print.

    I also don’t see a fluid layout as a form of nannying the user and deciding what he likes best – It’s simply another design method.

    Of course, my disagreement with h-a-r-v raises yet another problem: different users expect different things. How do you solve this?

    I’d like to point out a never-used feature in Firefox that allows for stylesheet switching (It’s View > Page Style). You could have a “fixed.css” and a “liquid.css” file for different situations. My design allows one to set a fixed layout just by setting the width of a wrapper div, so for me, it’s only one line. That said, it may not be practical for everyone else.

    My opinion on this “debate” of fixed v. fluid however? Fluid layouts are not the answer for everything (nor are fixed layouts). If your site has pictures, fluid layouts are not the best choice. If your site has lots of text, fluid. Unfortunately, many developers seem to only be able to develop for fixed-width layouts, so maybe that’s where all this hostility comes from. I personally advocate a semifluid method (set the width of your layout to, say, 85%) so that it doesn’t look hideous at huge resolutions, yet it’s good for small resolutions.

    I also looked at YAML (the CSS “framework”) and I found it, like other CSS “frameworks”, to be overly complicated. I ended up just cannibalizing the Blueprint framework to my specifications (I liked its preset typography, so that’s gotta be worth something, right?).

  23. 1123

    Is it possible that, while the more flexible layout may be perceived as the best approach for the future, this approach may be a bit over stimulating for the more basic online surfer?

  24. 1174

    Can someone please give me a few links to those Fluid(/Flexible) / Fixed icons that people use on their websites as buttons to switch the layout style

    I can’t find one ANYWHERE!

  25. 1225

    “The main difference between fixed (px-based) and flexible (%-based) layouts is the simple fact that flexible layouts can better adapt to user’s viewing preferences. With flexible solutions, the width of the layout depends on the viewport of the browser and can perfectly fill the viewing space without any manual adjustments from the user’s side. Fixed layouts can’t do that. Full page zoom, when applied to fixed layouts, enables users to manually adjust the design after it has already been rendered.”

    Who on earth uses zoom just to make a page take up more screen real estate?

    Why do you zoom? To make it bigger. Why? So that you can read it more easily or from a distance. Having a flexible layout immediately gives the impression that zooming it will lead to horizontal scrolling (a fate worth than death), ergo flexible designs are not user friendly (they will not even try to zoom it even if they would like to.

    With the exact same arguments that you make you could easily say that having a flexible design means that the user would have to resize their browser window to satisfy their needs. How dare decide that 70% within min and max limits are the prefered way to watch your content? Your clothing analogy fails, hard. Better would be to say that as a customer you don’t like the design of the cloth. You can’t redesign it in the store therefore the user-friendlyness of the cloth is poor… Or not. The user just has to accept your design – or leave it, just as he/she would have to accept your logo, your images, your text etc. You can’t be too flexible or your whole page would be in your users imagination – completely differenet for every user, I’d like to see anyone designing that.

    Compared to zooming it’s much more time consuming to resize a window. And as stated above, you don’t zoom to make the page take up more space…

    Just because you can make a flexible design that scales well doesn’t mean that thats something to strive for.

    I don’t defend fixed designs as a designer – I defend fixed pages as a user, there are very few pages with flexible design that I think benefit from it. And when I do designs I always make them from the user standpoint, not a care in the world for that fixed designs would be the easy way out.

    Sorry, this comment became more agressive than I intented. I don’t diss flexible designs just because their flexible, not at all. But I reacted strongly on some of your claims that I couldn’t disagree more with. And in general, I truly prefer fixed designs. Partly because so few make good flexible designs – but just as much because as a user I see absolutely no need for it.

    Also, I’ve yet to see a well designed page, fixed or flexible, not to render well in opera mini…

    Making a good scaleable layout sure can be hard and you are setting the bar quite high (especially compared to todays pages), then why compare it to badly fixed designs?
    Arguments like this quote:
    “problem is that sometimes the font on a page is friggin’ tiny without zooming it in, but zooming the page (with the images) doesn’t just make it more readable.”
    are completely irrelevant.
    Anyone doing a front page that can be described as that will do at least just an equally poor job of doing an flexible design.

  26. 1276

    Why is it that none of the examples scale above a width 1280px?

  27. 1327

    Wouldn’t it be easier in all respects to just do these in Acobat pdf

  28. 1378

    “I also don’t see a fluid layout as a form of nannying the user and deciding what he likes best – It’s simply another design method.”

    I think you’ve answered yourself pretty well :-) It was the whole point of my “speech” and the two arguments I raised considered only some part of users and were against the thesis that fluid designs are the only right ones to use or will be in future. Of course expectations may vary but it’s us – designers – deciding for the user what kind of interface he’ll.. face. Site character and its target audience are – as for me – two key factors to determine such choice. That’s all. Cheers!

  29. 1429

    Take a look at http://www.rnib.org.uk/wacblog/news/rnib-surf-right-toolbar-beta-version-available/ – pulls all the accessibility functions in IE into one place…

  30. 1480

    The important thing is to respect the user’s preferences: normally, these will be the browser’s default settings, but when they have been altered this will be for accessibility reasons. Readers should be able to navigate to a website and start reading: they shouldn’t have to rezise text. Therefore, the correct way to establish a layout is to use ems: a width of 35ems at a font-size of 100%-150% will fit on an 800X600 screen. Until the 800X600 screen is redundant, designers should make sure these users are catered for.

  31. 1531

    Y.A.L.A. Yet another lame article..
    I am very unclear as to why anyone who can write XHTML-CSS would waste valuable time using a framework. The article was good (even though this has been written about before).
    The advertising for the writers framework is where I got lost.
    If you are blabbing about your sites on your Iphone well I got an inside scoop for you.
    The whole world is not going to be on an Iphone.
    Do not forget the N-95 and the Blackberry.

    Not impressed with this article.


  32. 1582

    Before I even got to reading the last reply I was already thinking the same as Adam. Surely developing the web for mobile devices is in a way similar to the fact that the majority of the internet using world are using IE6 as a browser, yet most web designers will design for a better browser and try to work around IE’s limitations. In the same way, why should we suddenly make huge sacrifices and changes to designs that hardly anyone will see via an iphone or any other mobile device. I have a N-95 and I’ve tried using it online viewing websites designed for mobile phones and I think they still suck!

  33. 1633

    Not at all Flexible nor Fluid!
    Com’on – real flexible layout would incrementally change the amount of columns within it’s ‘article’ grid, letter-count after zoom or typo-resize (min/max per line), rearranging the whole grid and framework according to the users viewport.
    Also, the user should have the opportunity to stretch column (frames) width/hight and resizing images.

    But great article BTW ;-)

  34. 1684

    Nice article, unfortunately there is only a few designers that really care about the benefits of flexible layouts. but there was always one meager problem in flexible layouts: “white-space“. the two examples that you have presented above are both very hard to read I really can’t decide were to start to read. as you may know by now the new layout of the sitepoint.com website is designed in fixed width because of this problem (read reasen No. 4 here). I think we need to find some innovative ways to find a solution for this problem.

  35. 1735

    i landed here cos i was looking for a way to make fluid Blueprint layout…i think i’ll try YAML then…

  36. 1786

    Yassin wrote, “the new layout of the sitepoint.com website is designed in fixed width”. No, it isn’t — it’s flexible. (Or maybe it got changed since the time you wrote).

    I also find flexible designs very useful. At least, I can adjust a page designed like that to my needs. However, with a page designed in a fixed way that has small font size and narrow columns, increasing font size often leads to having too few words per line.

    And using full page zoom often leads to horizontal scroll bars by the time I get to font size at which I can read comfortably. So, I am very glad Firefox developers have restored an ability to increase/decrease font size only in version 3.x. (They dropped it, at first… fools).

  37. 1837


  38. 1888

    Nobody mentioned that YAML has some strict limitations unless you are ready to buy commercial license.

    “Condition: For the free use of the YAML framework, a backlink to the YAML homepage (http://www.yaml.de) in a suitable place (e.g.: footer of the website or in the imprint) is required.”

  39. 1939

    Anthony Alexander

    June 7, 2009 12:27 pm

    Wow, humans, what’s with the bs? All you need to know first is whether you want the page aligned left, right, center, or mixed. Once that’s done adjust the gutter. After that, it’s a choice of which method you want to employ (pure css of javascript). Every other poitn concerning this topic is just self gratifying back patting. I have always built my pages to be flexible, I thought this was the standard, but to my horror, Photoshoppers had decided on a min width. Losers.

  40. 1990
  41. 2041

    Yaml is the best framework. I build my own website with yaml under shop-web-online.de/

  42. 2092

    Clearly you missed the point. Users are viewing the web with a myriad of user agents and viewing methodologies (control + scroll, screen dragging, etc,). Designers/developers must keep up and frameworks such as YAML fit the bill, are easy to use, and save considerable design and development time.

    This article is not YAML documentation. The documentation (as well as examples) is available online and expands on the authors points.


↑ Back to top