Wanted: Layout System

Published 15 years, 9 months past

(This is part of the Feedback on ‘WaSP Community CSS3 Feedback 2008’ series.)

Not surprisingly, there was a lot of community feedback asking for better layout mechanisms.  Actually, people were asking for any decent layout mechanism at all, which CSS has historically lacked.  Floats mostly work, but they’re a hack and can be annoyingly fragile even when you ignore old-browser bugs.  Positioning works in limited cases, but does not handle web-oriented layout at all well.

Why do we use floats for layout, anyway?  clear.  That’s pretty much the whole answer.  The unique in-flow/out-of-flow nature of floats means they interact with each other and with the normal flow, which means they can be cleared, which makes them useful.  Because with clear, we can float layout blocks around and then push other non-floated blocks, like footers, below the floats.

Positioning, of course, permits total layout freedom in the sense that you can put a layout block anywhere with respect to its containing block.  The downfall is that absolutely positioned elements are entirely out of the normal flow, so they can’t stay out of each others’ way like floats do, and you can’t clear anything with respect to a positioned element.  If there had been a position-clear or its equivalent from the outset, we’d never have bothered with floats.

(And if we can just add position-clear to CSS, that would be completely awesome.  It’s been done with JavaScript and it will most likely be done again and better.  It wouldn’t even be that hard to implement, at least for 99.5% of cases.)

All this is why the old “only use tables for layout” argument keeps coming up over and over: strip away the overheated rhetoric and obvious link-baiting, and you find the core of a real need.  Because as powerful as CSS can be, table cells do certain things very easily that CSS makes very, very hard.  Cells stretch vertically, keeping equal heights as a matter of their intrinsic nature.  They stay out of each others’ way, while still being allowed to sit next to each other and use any sizing dimensions.  They tie their layout to their parent elements, and vice versa.

There are no equivalents in CSS.  There have been various very clever attempts to replicate bits and pieces of those capabilities using CSS.  What CSS does, it does very well: if you don’t need equal-height layout blocks, then no problem.  If you do, it’s a massive pain.  Clever techniques provide substitutes, but can’t replace what tables already do.

And please, let’s put the whole “display: table-cell will grant those abilities through CSS” to rest.  Saying that is just saying “use tables for layout” with different words.  Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it’s arguably worse.  Using element names other than table and td to create layout tables, and then claiming it’s not using tables for layout, borders on self-deception.

Not to mention doing things that way means you’re doing your layout in a highly source-order-dependent fashion, which was one of the things about table layout we were trying to get away from in the first place.

So how do we get really powerful source-order-independent layout?  I wish I knew.  The Advanced Layout module has been sitting around for a while now, and even if you’re a fan of defining layout as ASCII art—which I find repels and appeals in equal measure, but that’s probably just me—there appears to be close to zero implementor interest.  So how do we get those abilities in a form that implementors will, y’know, implement?  I don’t know.  I don’t care.  We just need it, and have needed it for a good decade or so.  Without it, CSS is a styling language but not a layout language.  We’ve bent it into being something close to a layout language, which is nice but not really ideal.

Maybe CSS isn’t the place for this.  Maybe there needs to be a new layout language that can be defined and implemented without regard to the constraints of the existing CSS syntax rules, without worrying about backwards compatibility.  Maybe that way we can not only get strong layout but also arbitrary shapes, thus leaving behind the rectangular prison that’s defined the web for almost two decades.

I don’t have a concrete idea to propose here, because it’s not up to us any more.  A solution was worked out over the course of several years and then found wanting by the implementors.  Really, it’s up to the implementors to figure it out now.  I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they’ve defined something that works and they’ve all agreed to implement soonest.  I might even supply food and water.

And yes, I just advocated doing this outside the W3C process.  Why wouldn’t I?  The process has, in the last decade, not produced anything even remotely resembling an answer to this problem.  Time to try another path and see if it gets any closer to the goal.

No doubt someone’s going to spin this as “See, even noted standards zealot Eric Meyer now says CSS is flawed!”—only they’ll be wrong because this isn’t a now thing.  I’ve been saying this for years in interviews, in person, and in general.  Any time someone asks me what CSS is missing or should do better, the answer has always been a variant on “a strong layout system”.  I’ve been saying it for at least a decade.  So I’m not saying it now.  I’m saying it again.  And again and again and again and…

If I sound frustrated, it’s because I am, and have been for a good long while.  I’m not the only one.  It rankles to have CSS be, as Winston Churchill would have put it, the worst form of layout except for all the others that have been tried.

Comments (138)

  1. Agreed. But my issue is that they are trying to define layout systems without understanding what designers actually want to do, and how that maps to best-practice HTML authoring.

    Give me math, variables, and constants. Give me positioning relative to a specified element. With those things I can make my OWN layout solution. Implement a grid system, and all independent of mark-up order. None of the proposed layout solutions address the basic problems we have.

    I’ve written about this a lot. All I know is the WG right now has no answers that are acceptable. And I agree about display:table.

    My own thoughts. http://mattwilcox.net/archive/entry/id/1031/

  2. Thanks for expressing your frustration far more clearly than I could… somehow, that makes it all feel better.

  3. Yes, dammit, yes. Great post, and there needs to be more call for this. As much as I love the fun CSS3 features like multiple backgrounds and box shadows, and as cool as webkit’s transformation and rotations are, what good are they when we have to jump through crazy hoops to get a layout even close to what we’re interested in?

    Also, is the CSS3 grid system any better? Haven’t investigated it yet, but it seems pretty interesting. Of course, no implementations yet. Can’t help but feel that that may be due to its primary editors being Microsoft employees.

    Come on guys, at least try to come up with some kind of implementation. Use your vendor prefixes, make up some property names, just show us you care!

  4. I’ve always thought positioning in CSS was awkward; and I can only think of hack-case scenarios where I’ve ever absolutely positioned something. Using floats definitely feels hack-y too.

  5. Meant to say webkit’s “transformations and animations“.

  6. Sorry Eric, I don”t normally disagree with you but in my opinion this is wrong:

    And please, let”s put the whole “display: table-cell will grant those abilities through CSS” to rest. Saying that is just saying “use tables for layout” with different words. Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it”s arguably worse.

    What reasons do you believe that to be correct? Using divs instead of table elements means that you”re using a non-semantic element for layout instead of abusing a semantic element. Yes, I know the whole summary=”” accessibility recommendation but honestly most people don”t. Beyond that you keep the other obvious benefit of CSS layout – the ability to change it without changing the underlying HTML.

  7. >I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room

    You know what, you’d probably get a fair amount of buy in from the browser teams themselves. And if not, I reckon there’s anough of us who want this feature to storm their respective buildings and force them into that room.

    I really want a layout system.

  8. During times like this, the complexity of creating a decent layout via CSS feels like job security to me. It separates me from everyone else as a skill only I can do.

    I was also thoroughly disgusted with the community embracing display: table so quickly as well. I’ve also noticed A LOT of chatter lately regarding going back to tables and it’s starting to get annoying –

    http://www.dzone.com/links/tables_vs_css_css_trolls_begone.html
    http://www.dzone.com/links/the_cult_of_div.html
    http://www.dzone.com/links/why_css_should_not_be_used_for_layout.html

    Like you, I’ve often dreamed of breaking out of the grid on the web and having divs shaped like circles, wrapping text accordingly or various other shapes via CSS.

    I guess I can live with floating for now, overflow: auto is new my best friend.

  9. @Robin: Using display: table means you’re stuck with a “source-order-dependent” design. That means if you want column 1 to be where column 3 is, you need to go into Dreamweaver, and manually change the source order, which really, is unacceptable as a solution.

  10. I’ve always thought that at least some of the disconnect comes as a result of CSS being text-based, while graphic designers work visually. This is at least partly why there are still designers using tables for layout: tables are a grid and designers understand grids. Graphic designers do not necessarily understand why a float won’t clear or why you can’t just center something, etc. Try teaching CSS to someone coming straight from the print design world and the problems become painfully obvious.

  11. I’m with Robin. The source order dependency is a legitimate problem. But saying a DIV with style “display: table-cell” is the same as a TD is just wrong, completely ignoring the importance of markup semantics beyond CSS.

  12. Robin, I take that position largely because of the source-order dependence Neal mentioned. I used to have the same problem with floats, at least until Alex Robinson published his “One True Layout” technique and let us use floats to do layout largely independent of source order.

    As far as I’m concerned, from a layout point of view (which is what this is about), when you assign table-box roles to elements for layout, you’re using tables for layout. CSS doesn’t care about the element names, only the display roles that have been assigned. The display roles’ names indicate what they’re meant to do, and what the display roles mean. display: table-cell means you’re creating a table-cell box. If you’re using that for page layout, and not to construct an actual data table (as you would need to do in a non-XHTML XML), then you’re using tables for layout.

  13. I don’t know if the CSS Grid System module is better, Alexis, mostly because that module is woefully underspecified. As in, it introduces a few key pieces but doesn’t flesh them out very much. so it’s hard for me to tell if it’s a really good idea, the beginning of a good idea, or a bad idea. I thought about referencing it in the post and then dropped it for that very reason.

  14. @Neal:- You can thank books like ‘Everything You Know About CSS is Wrong‘ for the frighteningly quick uptake from authors using the CSS Table Model. IMO, porting the Table Model into various display values seems to me to be a very half-arsed solution, which has some very obvious restrictions; a model that was designed purely for tables and not as a layout model, as the name suggests – to me, this doesn’t seem right.

  15. With regards to the display: table-cell statement. I agree with Robin and Scott. The source order dependency is a legitimate problem. But saying a DIV with style “display: table-cell” is the same as a TD is just wrong

    What about a span, with an anchor inside with the following CSS – span a {display: block} – this doesn’t make the markup invalid, as you’re changing the style and not the meaning of the element. The same applies to marking up a list, as a list, but styling them in to blocks with table-cell.

    Anyway, I agree that position-clear would solve many problems, but doesn’t necessarily solve (does it need solving?) “rectangular prison” you mentioned. Creative design and code already alleviate much of that, although the recent trend has been towards grids.

    I agree with Matt Wilcox, that, along with easier and more versatile layout system, that “math, variables, and constants” need addressing. Also, support for multiple backgrounds on elements, which will help more creative designs. Most of all is support for decent typography, with easier, better implementations of fonts, weights and kerning. I think these should be prority (along with layout) ahead of say CSS-animations which are the realm of JavaScript (and rightly-so I think), which are gaining traction.

  16. Thanks for this one Eric, I couldn’t agree more with you!

    I personally think CSS IS the language for layout as that is the basis of presentation and not behavior; albeit this could be construed as structure, but we don’t want to go back to tables like you said!

    The link to the different layout approaches, while each is good to know about it seems something actually anchored to the language itself, like the Advanced, is better!

  17. If you want “math, variables and constants” in your CSS, then have a look at SASS. It’s not dynamic and we can’t serve SASS to browsers, but you can currently have some of those features and use it to build your CSS. I think it’s a nicer syntax to boot, once you get past the indentation structure.

    +1 for everything you wrote here Eric,

    (On a related note, why has nobody ever implemented alternatives for CSS, why are we stuck with “text/css” and “text/javascript”? Why not “text/sass” and “text/ruby” for example?)

  18. Floating layouts is a brittle approach, and is not what floats were initially intended to provide.

    Unfortunately, Gecko 1.8.1 removed support for inline-block.

    Fortunately, Firefox 2 (which used that version of Gecko) has seen a dramatic drop-off in usage, while Firefox 3 (using Gecko 1.9 in which inline-block support was added back) has seen matching adoption.

    http://www.w3schools.com/browsers/browsers_firefox.asp

    Inline-block doesn’t solve every layout problem, but it certainly avoids some of the hacks involved with floating, and gives access to vertical alignment, which is probably the gripe I’ve heard the most from those in support of layout with tables.

  19. While not an answer, this is why I’m imagining frameworks such as blueprint and 960grid have emerged. They help relieve some of the pain of the css learning curve.

  20. Absolutely, Eric! We need a true layout system for the web, and we need it yesterday. Or rather, we need it ten years ago.

    I think the best bet would be to create a separate layout module, independent of semantic markup in HTML and independent of the style rules in CSS as well. That would raise fewer backward compatibility issues, I think. Browsers that don’t understand the new layout standard would simply see the linearized form of the page.

  21. As far as I can tell there is interest from at least three vendors in the flexible box model used in e.g. XUL but implemented in a prefixed way (and presumably slightly incompatible ways) by Gecko and WebKit, but nobody has been found willing to work out all the details and write down a specification.

  22. Matt Wilcox has it spot on.

    After years of using CSS, I finally came to the conclusion a few years ago that a simple layout and style-oriented display language with the ability to do arithmetic, drawing, attach specific rendering code to specific DOM objects, and define macros on which you can build your own layout abstractions would have been the best solution. Then you’d have enough power to completely separate presentation from semantic markup.

  23. Pingback ::

    i'm happy to say im going back with designing with some tables - TalkPHP

    […] layout blocks around and then push other non-floated blocks, like footers, below the floats. Read full article… __________________ The man who comes back through the Door in the Wall will never be quite […]

  24. Hola. Well, you’ve just mentioned the reason I never bother with positioning too much. Absolute positioning does the task for me:


    div#content
    {position: absolute; left 50px; top 120px;}

    …period. I don’t care whether you see it too on your left or not. If it is displayed properly on a 800×600 screen resolution and a 1200×768 screen resolution, it is enough for me. I place the footer at the last part of the article, and that’s it.

    Heptagrama is an example of that. Here you can see its CSS and print CSS.

    Hope this helps.

  25. I not sure that I agree with this requirement fr a layout engine. I too have heard this argued over and over again, that what CSS lacks is a layout system (of any kind) but I’m not sure that the web actually can have one. I was always of the understanding that the reflow of a HTML page was one of it primary strengths as an interface/page layout system, as it doesn’t matter the dimensions of the screen, the browser can safely reflow the page in a manner to display it to the best of its ability. Hence the use of floats.

    For example, in our ideal layout engine, we would have the ability to display two images of a fixed width side by side without any reflow. Now if the total combined width of those two images is greater than the width of your mobile phone, you’re going to get scroll bars.

    I’ve never understood why people have such a problem with CSS. I you are struggling to implement your design using CSS, then maybe your design is inappropriate for the web? Maybe, just maybe, you are trying to shoehorn your print/fixed layout mentality onto a dynamic, liquid reflowing string-of-text display format.

    I would love to hear why people think the inherent features of HTML and CSS are a flaw.

  26. After years of using CSS, I finally came to the conclusion a few years ago that a simple layout and style-oriented display language with the ability to do arithmetic, drawing, attach specific rendering code to specific DOM objects, and define macros on which you can build your own layout abstractions would have been the best solution.

    This may be an unpopular suggestion, and (even in my own opinion) a flawed one, but XSLT can do a lot of the things you’re asking for. The primary failing of XSLT is the horrendous learning curve.

    But the failure of XSLT to be adopted by mainstream web developers is, I think, informative: a solution that attempts to do too much only makes a difficult process (developing web front-ends) more painful. Instead any layout solution (whether CSS-based or not) must be simple, focused, and elegantly flexible.

  27. @Dan Wilkinson:
    With all due respect, as a programmer-turned-web-developer instead of a designer-turned-web-developer, I see the opposite being the problem: designers wishing to implement their visual design in software (yes, I consider websites to be software) without any knowledge of programming.

    This is a bit of a glib response, but fairly honest. Part of the reason web layout is in this confused state currently is that the original development of WYSIWIG layout tools treated web design like desktop publishing.

  28. @Alex Burr

    Hear hear! It’s designers who cannot design for the web that is the real issue here, and to be honest, since the first day some used a table for layout, it’s always been that problem.

  29. Has anybody proposed something like Xt’s Form widget? All of the Form’s children size themselves, and they specify attachments to other widgets, or to the edges of the Form. So a 3-column layout, with a header and a footer, would be something like this:

    Form: { header: {top-attachment: parent,
                     left-attachment: parent,
                     right-attachment: parent},
            footer: {bottom-attachment: parent,
                     left-attachment: parent,
                     right-attachment: parent},
            left: {left-attachment: parent,
                   top-attachment: header,
                   bottom-attachment: footer},
            middle: {left-attachment: left,
                     right-attachment: right,
                     top-attachment: header,
                     bottom-attachment: footer},
            right: {right-attachment: parent,
                    top-attachment: header,
                    bottom-attachment: footer}}

    It’s simple to understand, it’s resolution-independent, and it’s really powerful. (The above is a fairly trivial example. By the time you add offsets, which can be constant or proportional, it becomes pretty impressive.)

    The only catch is that you have to do a topological sort (two, actually; one in the X dimension and one in the Y), and you can get dependency loops. In Xt, that used to yield error messages; in a Web context, you’d need something saner—maybe break the loop by choosing an attachment to discard.

  30. Maybe I am missing something but why not just do it the way QT does? You have a horizontal container, a vertical container, and spacers (things you put between things in a horizontal or vertical container that pushes them, for alignment).

    Just add this to CSS and we’ll be good, as far as I can tell.

    I really do hate CSS layout, too.. as it is. Get mad at me but I don’t even think i like separating functionality from presentation, anymore.

  31. Sometimes I want to use the table model for layout for the benefit of sighted users without screwing over my non-sighted users. Forms for me a good example; label on the left, input on the right just like in a table, but I actually want the markup to be a p containing a label and an input because, you know, that’s the actual content.

    And tomorrow I might want it to be label-above-input (display:block on the label, thanks).

    So, no, display:table is respectfully not the same as using tables for layout. It is a far, far better situation for designers and a much better tool for certain use cases.

  32. Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it”s arguably worse. Using element names other than table and td to create layout tables, and then claiming it”s not using tables for layout, borders on self-deception.

    This statement begs the question: What is wrong with using tables for layout? It seems to me the problem is using HTML for layout; using CSS to generate layout tables seems to me to be exactly how the Web is supposed to work, assuming table layout primitives are the best tool currently available for the layout goals you are trying to achieve.

    I too long for better layout tools built into CSS, but for the moment many designers (particular beginners seeking to assemble their first three-column layout) will be much better served by CSS tables than by floats.

    Not to mention doing things that way means you”re doing your layout in a highly source-order-dependent fashion, which was one of the things about table layout we were trying to get away from in the first place.

    Again, you are begging the question. Source order is not the bugbear you make it out to be, and certainly isn”t a showstopper. As presented in recent research, it is not in fact a serious accessibility issue.

    Once again, I too hope for true separation between content and presentation, and for that reason I agree with the direction you wish to head in, but that doesn”t make what we have now useless.

    I believe that CSS tables, once IE8 achieves sufficient adoption, is a 90% solution with very few drawbacks for a great many web designers.

  33. Simple answer: do all you web development in Flash. Skip HTML as the backwards useless “open standard” that it is. Can you think of a single other useful “open” standard? Linux? Nope, noone with any brains uses it. ODF? Nope, again noone with brains uses it for anything serious. Same goes for just about every other open standard. It takes a company like Adobe, Microsoft or Apple to define a useful product and set the standard. If web developers just for once stopped whining and complaining about standards and instead just adopted the best tools for the job, things would be a lot simpler.

  34. Really, it”s up to the implementors to figure it out now. I personally would like to just lock the browser teams from Microsoft, Mozilla, Opera, and Apple in a room and not let them out until they”ve defined something that works and they”ve all agreed to implement soonest.

    Why hasn’t anyone done this? Well, the obvious answer is because we’ll end up with a design-by-committee solution that no programmer will even want to touch. It’s really tricky to get standards to the perfect point where implementers, programmers, and users are all happy with the end result. My opinion is that the optimal solution will happen when a very few people are put in charge of the final solution, but implementers’ and programmers’ requirements are heard and incorporated.

    You have to ask yourself: why doesn’t LaTeX have any of these problems?

  35. We need to abstract layout and content more from the browser so that a multiple of solutions can blossom, even, god forbid, if we need to compile before viewing.

    The reality is that html/css comes from a text view, PDF/Postscript from a graphic layout view, and Flash from an interactive and animation view and we need all three to somehow work together in some cohesive whole. Maybe web markup needs to evolve closer to Flash (despite the heretical sound of it) with some sort of method to describe things in exact terms, fix the state problems of bookmarking, and basically get something that is omnipotent and contextual.

  36. XBL (when it is available) would cure some of your pain. Reordering content is one of its anticipated uses.

    You could deliver semantic content and use XBL to re-arrange it and style it as you like (though not as much as XSLT).

  37. Part of the fundamental problem is that CSS is trying to cover for two vastly different audiences: the curious amateur and the professional designer. The reality is that each needs different tools and each has different skills and understanding.

    I agree we need a second language that is a lot more complex, that speaks to designers in a language they understand, because it should be for them. CSS as it stands can remain the same for the curious amateur.

    The CSS specs themselves do not rule out a second style language, leaving the field open.

  38. And please, let”s put the whole “display: table-cell will grant those abilities through CSS” to rest. Saying that is just saying “use tables for layout” with different words. Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it”s arguably worse. Using element names other than table and td to create layout tables, and then claiming it”s not using tables for layout, borders on self-deception.

    Could you support this screed, please? How is keeping markup separate from presentation the same as mixing them? Claiming that rendering something as a table is the same as marking up the content as a table belies a lack of personal experience with robot programming. “It’s arguably worse”? So make the argument!
    Sure, source order for CSS columns, in many situations, would be suboptimal, but that’s really more of an argument for <div src="…">.

  39. @Alex_Burr
    Your response goes beyond glib, into PITA territory. I stand between the sea and the sand (I sit in both worlds) and quite frankly, the designer shouldn’t need to know anything about reflection or other intricate programming practices.

    Design is one of the oldest vocations and there are many lessons that have been learnt, forgotten, relearnt, reforgotten, and learnt again. Much of design is communication to the audience without the audience realising it is going on, and there is a strong tie to the psychology field. Designers have very different skills from programmers, and they need those skills to do what they do. Designers don’t need to also have programming skills.

    The issue isn’t of skills, the issue is that CSS does not contain the language and ability that designers have long used across many media (print, newspaper, granite, marble, sand stone, glass, cave wall). The system is a mis-match. Hardly surprising considering those who wrote CSS were maths and physics geeks with no real design background.

  40. I’m in complete agreement with Scott Reynman’s comment, and I’m disappointed to see you write a blog post that says all the ways tables are just right for layout, and solve critical problems like equal-height blocks, and then denounce “display: table” as being just as bad as –for no apparent reason. If you want to argue that “display: table” is inadequate because it does not provide source-order-independent layout, then make that argument. It’s a good argument. Don’t propagate this “CSS tables are inherently evil.. because they’re tables… for layout” crap, especially if that’s not what you meant.

    You’re quite capable of writing intelligently on these topics, reading an incoherent rant like this, from you, is very frustrating. Like, the paragraph stating “There are no equivalents in CSS” and the one arguing that “display: table-cell … is just saying ‘use tables for layout’ with different words” are contradictory. If there is no equivalent in CSS, then the CSS you’re arguing against can’t exist. Right?

    Now, an article detailing the pros and cons of various layout systems, both in existence and proposed, and explaining what would be required of a really good layout system—that would be a very useful post, and a very interesting discussion. Please write that. Because such a discussion would greatly benefit the CSS community: designers, implementors, and working group alike.

  41. Nice, fantasai. If I say I’m disappointed to see you write an incoherent comment, does that mean I can dismiss your frustration?

  42. Richard, I prefer to assume that commenters here don’t troll on purpose, but what in my entire professional history makes you think that I’d be receptive to blithe dismissal of open standards?

  43. I didn’t think you’d be likely to agree with me, Kevin, but if it makes you feel any better I’ve felt this way about CSS table layout for years.

    Yes, years. I’ve never been happy with source-order-dependent solutions; I remember sitting in a diner in Stanford in 2002 or so explaining to Tantek why floats for layout sucked, because they were nailed to source order. I floated (ha HA!) the idea of properties like one that let you list IDs in the order they should be laid out—sort of a source-reordering property. I think I even called it ‘float-order’. I developed ways to do any-order floated columns using extra an div that wrapped two of three columns, completely missing the whole concept that Alex Robinson eventually published in “One True Layout”. I hated every hack I devised and every hack I used, but I used them because to me, source order matters.

    I care about source order not solely for accessibility, though that has been a concern, but also for search engine optimization and for ease of comprehension in non-CSS environments. I always have cared. Odds are I always will.

    As for my position that CSS tables are tables for layout by another name, I’ve stated my position, and clarified it in an earlier comment. Nobody has to agree with it. Even if everyone does agree with me, it won’t matter, because you’re right: CSS tables will be a widely used solution. I’ll probably use it myself, when the circumstances permit.

    I just hope it doesn’t kill off whatever pressure there has been for coming up with a really robust, sophisticated system.

  44. I agree with you, Bob. Completely.

  45. The source order dependency is a legitimate problem. But saying a DIV with style “display: table-cell” is the same as a TD is just wrong.

    Only I didn’t say that. I said that using CSS to create tables is using tables for layout. Not table markup for layout. Tables. As in, table boxes, hung together as a collection of cell boxes and row boxes in a table box. Look at the display value names: table-cell, table-row, table. How is having elements generate those boxes not creating a layout table? Do the semantics of those value names just not apply?

    I get that there’s a difference between markup and display boxes. Honestly, it’s a little bit disappointing that so many people so quickly assumed that I don’t.

  46. The display roles” names indicate what they”re meant to do, and what the display roles mean. display: table-cell means you”re creating a table-cell box. If you”re using that for page layout, and not to construct an actual data table (as you would need to do in a non-XHTML XML), then you”re using tables for layout.

    But you wouldn’t use CSS to create a data table, you’d use HTML table tags. To me, the CSS table display properties are clearly named for their presentional qualities, not for what semantics they impart to an element. If they’d been named something like display: horizontally-inline-equal-height-box, would it still be the same as using tables for layout?

  47. Pingback ::

    Too long..

    […] recently saw this post by web design god Eric Meyer, and it really cleared some things up for me regarding CSS.  I […]

  48. @Kat B, I figured my entry could be a bit of a PITA.

    To be a bit more PC, I think the “ease” of entry into web development puts a need on designers to work in an alien world, forcing them into a universe of conditional logic and property inheritance. I agree that this is unfair and some “bridge” tools are necessary.

    However, it does work both ways. Many programmers-cum-web-developers are in the opposite situation, having to learn layout, typography, color, and other design concepts to get a final working product. However a “passably” designed web application is somewhat easier to create from this end without help, but most of the engineering crowd is not going to come up with anything gorgeous.

    The issue on the inside of the industry is too little collaboration in the workflow. How many web projects are one-man-shows? Something’s gotta give in that situation. That model would never work in the desktop software world.

    I maintain that the best situation is a three-person-job: one is the designer (handling icons, vector art, color, typography, and layout), one is the programmer (handling business logic, database connectivity, platform, etc), and one is in the middle to merge the design with the function (specializing in CSS, HTML, XSLT, etc).

    Many folks (myself included) would love to live in that middle layer. Plus it frees the designer and the engineer to do whatever they please without having to fully understand the other’s language.

    This person needs a layout solution!

  49. What about the Float-less CSS layout?

    Is the use of lists to make a layout a bad idea? :\

  50. As a person using CSS daily, I will agree with you Mr.Eric. But I think, the W3C standard committe should see things from a different perspective, by considering browser usage scenerio. Hope in CSS3+, we can expect a better framework, I don’t want to stand aginst W3C.

  51. I’ve been thinking about this problem for well over a year and trying to really get to the root of what people are asking for. @John Stracke is heading down the right path but not completely there.

    Keys to moving forward in my mind are resolution independent and algorithmic relationships. I was sitting in my office one day and heard someone say “Yay they are adding display: table-cell” and I was wondering why we decided to move back towards tables. Here is what people want but aren’t saying: Give me a way to define or not define relationships between two elements.

    Right now we have two options. We can have tables in which the table cells have a predefined relationship or we can have the div method where the divs have no real concrete relationship other than source order.

    What it seems to me people are asking for is more of a display:grid. Where I can have have two blocks and I can say Block A height must equal Block B’s height and the relationship is mutual. So if you put too much content in A, B grows and vice versa.

    But why stop at only these types of relationships? Why not let us express new relationships like growth in increments. Designers when laying out pages or documents have a grid. It is an increment of pixels or whatever that elements in the layout fall in line with. It makes the document much easier to read and parse visually.

    Why can’t I say: Block A you grow at increments of 50px in height because that is my grid size?
    What can’t I say: Block A you grow at 2x the rate of block B in width.
    Positionally why can’t I say: Block A is always (x)px off of the top right edge of Block B where x = Block A’s height?

    Under the current model, it seems like this would work by creating another type called display: grid and display: grid-node. Where grids can have relationships and can contain other grids. This way if I put too much content into one grid node all of the nodes can react in real time based on the relationships I have predefined. So if someone puts way too much text in an area the space can adjust in a predefined manner. If a client puts in a picture that is too large for an area. It could react accordingly. If I drag a grid inside of another grid the whole grid could turn into something visually different.

    If we made it this far.. I would move that the grid be based solely in memory with no markup in the html at all. Where you defined the grid-node the content was to be flowed into and all that was in the html document was pure content.

    In this way I see a new layout language/syntax forming.

    I hope that all came out right and made sense. *takes a deep breath*

    Would love to hear some feedback on this.

  52. Standards are only nice when you can apply them into situations where they make your life easier. And since we are very easily frustrated by the current implementation of said standards, I think it’s only fair that we say: “Screw standards”.

    But at the end of the day, I think most of us here – myself included – are very capable of making nearly every layout a designer can throw at us into a website that works on all modern browsers, is search engine friendly, usable, and actually validates, too.

    And isn’t that just why our jobs exist in the first place?

    Where I work, programmers have a hard time understanding floats, the quirks different browsers have, why margins and paddings sometimes work differently, et cetera. If all that were made obsolete, and there actually would be a decent layout system in place, then most of our jobs would lose their value.

    Who would need a “frontend developer” when any programmer can understand the simple basics behind a design. Hell, the tools they already use, all the frameworks out there, might simply implement this so they can programmatically create a layout.

    Luckily for me I have some added value (designing stuff mostly, javascripting secondarily) besides the whole “I know browsers” thingy, but I’m quite happy with the current situation.

  53. Pingback ::

    Daddy is whacked | Amasijo

    […] Eric’s Archived Thoughts: Wanted: Layout System. […]

  54. XHTML is, mainly, linear. It’s a hierachical classement of information, but still it’s a LINEAR hierarchical classement. The relation between elements are expressed by the hierarchical relationships.

    Layout is mainly 2 dimensionals, and can even be 3-dimensional at times.
    A element has two main caracteristics: his position and size in the layout, and the relations between those 2 caracteristics with other element’s caracteristics.

    The way took by CSS to take this in account is to invent the “flow” concept: each block element take the WHOLE width, and are put one under the other. The position is related to the preceding block, and the “second” dimension problem is resolved by a default (“take the whole width”).

    No way to do a full layout with this, of course.

    Then, you have mainly two ways to escape this:
    – You can put things out of the flow (positionning absolute)
    – You can put things “float”.

    With the first solution, you have full control on the position, but as the element is out of the flow, they can’t have relationship with other elements (thus overlaping problems, no way to take in account width or length of others elements, and so on…).

    With the second solution, elements are still on the flow, so they can take in account the caracteristics of others elements (the “clear” argument of Eric). And now, the “take the full width” rule is relaxed, meaning that elements can be but side of other flow elements.
    BUT, the float elements are restricted to strict rule about their position, the main one being that they HAVE TO TAKE IN ACCOUNT the source order: a float declared after another float can’t be put higher, etc.

    What CSS needs to make a good layout system is not so hard, really. It really boils down to satisfy the two main criteria about layout: being able to control the POSITION and SIZE, in the TWO dimensions, and being able to control the RELATIONSHIP of those caracteritics with other elements.

    The first one is done with position absolute. The second one is hinted by the flow and floats rules, but should maybe be reinvented. As Matt Wilcox (first comment) say: “Give me math, variables, and constants. Give me positioning relative to a specified element.” This is a things that has already be resolved in ALL technologies that allow to create UI. Be it with Cocoa and Interface builder, Java and Swing layout, or Flex and MXML definitions.

    So I wonder why this hasn’t be solved yet. Am I thick and have I missed something? Have I missed a technology or a CSS trick that allow to do this? How could it be so hard to add variables and caracteristics references to absolute position?

    I really wonder.

  55. I’m disappointed in Fantasai’s response to numerous things with CSS3. I understand that it’s a tough job and there’s a lot of things to balance on the subject as seen from a variety of users. But, frankly, I find the continual WG viewpoint that everything _must_ have use cases annoying when the problems discussed are on a far more fundamental level than an individual use case. And I find it insanely annoying that despite years of designers asking for certain things, the WG simply _will not_ budge from it’s position, for reasons that remain, to me, entirely unfathamoble.

    I don’t give a rats ass how hard something is for the technicians to implement. As an author, as a language, CSS needs fundamental features the WG are unwilling to provide. And I don’t buy the “it’s hard” argument anyway. I fail to see how implementing variables, math, and DOM traversal can possibly be so hard considering there’s web technology doing it already (JavaScript). We live in a world where my PC can simulate molecules interacting. But we can’t have width : 100%-20px;

    Don’t buy it.

  56. FWIW, I’ll add my voice to those who are disappointed by your views on display:table-*. This anti-table hysteria has really gone too far. The argument that using table HTML markup for layout is wrong has a lot of merit. The idea that that argument applies to using table-like layout characteristics with divs (or whatever) does not. The vast majority of web sites *are* laid out like tables!

    IMO, the primary reason tables got a bad rep was because they were abused and nested to excessive degrees. Current practice now seems to involve an equivalent number of nested divs, with the addition of vast amounts of CSS hacks and whatnot to achieve the same effect. I do not consider that progress.

  57. I completely agree with. Using display:table is a return to the conceptual approach of using table elements for layout. Obviously the semantic meaning of the elements used is different but we’re just going back to excessive markup and a dependence on source order.

    Personally, I feel that the CSS3 grid positioning module looks more promising, offers the potential for a lot of flexibility, and far preferred to the advanced layout module. But for some reason there is no real drive for the proposed layout modules to be expanded on, refined, or tested for practicality. It’s rather bizarre given the importance of a robust and flexible way to construct layouts.

  58. I totally agree with the your comments on table-CSS, I’ve said similar things. The accessibility, control and non-CSS environments will keep me using a negative-margin-float layout until something better is created.

    I’m also not convinced by the ‘layout is hard’ argument, except perhaps because we have to handle the baggage of not having a layout system. It’s already been implemented in JavaScript.

    Many of the bizarre and obscure float / positioning bugs that we find simply wouldn’t occur if we weren’t hacking them so much to create CSS layouts.

    The CSS3 layout module (or whatever it’s eventually called) needs to be the foundation that we then use current CSS with. Being able to create basic column layouts and grids is all(!) it needs to do, we’ve then got margins, floats and relative positioning within those areas.

  59. @Andrew Gregory, part of the argument is semantic:

    Tables != Grids :: Illustrations != Graphs

  60. As @kylegl mentioned, a lot of these layout issues have been solved in other UI design technology. Being a web developer, most of my experience with “other” UI technology is with Flex, and I find its layout model to be pretty solid. Flex has constraint-based layouts: any container can be constrained (from any side, or the center) to be a certain distance (% or px) from it’s parent, including height. It’s basically absolute positioning done right. This opens up vast possibilities with layouts, far more than we have today, and equaling or bettering what can be done with tables.
    I ask an honest question: why can’t browser makers implement something similar with CSS?

  61. I don’t see the problem in the grid/layout. The problem is in the content. Print designers have the same needs, layout and structure. They have a finite X and Y grid system based on the physical characteristics of the media they print to. If the content runs long they need to trim the story, play with font kerning etc to make it fit.

    Web designers want it both ways, elegant layouts and dynamic content, oh yea, re-sizable fonts and liquid layouts too. All this unpredictable content is why we don’t use absolute position for everything. Seems like we want our cake and eat it too.

  62. Pingback ::

    Maquetación con tablas CSS, ¿si o no? | Webmaster Libre

    […] demasiado no podía juzgar. Pero hoy me entero vía CSS Tricks de que gente tan importante como Eric Meyer pone en entredicho esta idea por poco semántica y por volver a dejarnos atados al orden dentro del código fuente para mostrar […]

  63. @Sean Landry: the difference is that the print publishers are displaying in a fixed font size. In the Web world, you have people who use small fonts so they don’t have to scroll as much, and people who use large fonts so they don’t have to squint as much.

  64. I think one idea has been skipped over here: Does layout really belong in CSS?

    Wouldn’t it be easier and more logical to add this concept to HTML5, something like the old Netscape <mulitcol> tag (used to do multi-column text, still supported by Firefox)? There could be a containing tag with child tags that specify, with an attribute, the width and display order? It will be very similar to what we do now with float and div’s.

  65. Eric Meyer wrote: “If I say I”m disappointed to see you write an incoherent comment, does that mean I can dismiss your frustration?”

    Yes. :) But dismissing my frustration doesn’t mean dismissing the comment itself. By all means, if it’s incoherent, ask for clarification. I will be waiting patiently for the clarification I requested to yours. ;)

  66. Eric Meyer wrote: “How is having elements generate those boxes not creating a layout table?”

    It is, exactly, creating a layout table. Nothing more, nothing less.

    “Do the semantics of those value names just not apply?”

    Only insofar as they define the size and position of the boxes. Is that what you meant by “semantics”, or did you mean something else?

  67. As I was reading this article I was wondering when you will mention XSL ;-). It has almost everything that I was always missing in CSS: variables, templates, even loops and sorting that allows reorganizing data as you wish. Someone above mentioned that XSL is harder to learn than CSS, well maybe if you want to do something weird with your page, but in most cases you could use simple HTML and here and there insert:

    …
    Can you imagine the simplicity and flexibility of such layout? With XSL in hand you can throw away all boxes and draw you page freely including actually changing it to SVG! Imagine how semantic could a page like that be and how easily customizable would it be!

    But leaving my dreams for a moment…

    I agree partially with Robin (Comment #6) about tables – tables in layout are evil because of their semantic role. Still in most cases you can’t really use display:table and the rest unless you add some extra elements (e.g. to use as them as rows), which in fact makes layout quite fixed.

  68. Ups… Text missing above after “in most cases you could use simple HTML and here and there insert:”
    <xsl:call-template name=”main-menu”/>
    <xsl:call-template name=”user-menu”/>
    <xsl:call-template name=”categories-menu”/>
    …

    (didn’t though it will parse XSL too.)

  69. I’ll enter and put my 2c in.

    First up, this comes across as:
    we need a layout system because what we have isn’t good enough but we can’t quite create the functional requirements needed to make it!

    Right, now I’ve got that out of the way… a big part of the frustration comes from the design world grappling with programming. At the end of the day, that’s what translating a pretty picture into a usable interface requires. While there may be *better* ways of doing it, you still can’t escape that fundamental flaw (for designers).

    I’m waiting and watching. What we’ve got now is good – far better than what stood before – but we can always do better.

    So I’ll leave a question for you, eric, and your readers. What are the functional requirements you desire in your layout system?

  70. Pingback ::

    Linkdump for February 18th at found_drama

    […] Wanted: Layout System Uh… What he said? Why do we use floats for layout, anyway? clear. That’s pretty much the whole answer. The unique in-flow/out-of-flow nature of floats means they interact with each other and with the normal flow, which means they can be cleared, which makes them useful. (tagged: via:fogus css floats webdev html essay ) […]

  71. My 2 cents.

    I have been doing web design in my spare time since 1995-ish.

    I was really, really excited when CSS came out. I became a zealot.

    But when I was doing my wife’s site, it took me a few hours to get the layout fairly close to what she wanted. She changed her mind (as wives do) and I was looking at a few more hours. Then she took over and (to my horror) she rewrote the whole site in tables. Then she challenged me to rewrite it exactly the same with CSS and I just left it there.

    Reading through the comments I kept thinking back to the perl saying “Simple things should be simple, difficult things should be possible”

    I think that CSS has failed there and Neal G (with respect) has the wrong idea – job security is not what CSS should be about. CSS should be about enabling creativity and moving life forward, not about being superior to the poor people out there who battle to understand how ‘div’s and ‘float’s and ‘clear’s all work together.

    Basically, tables work – they may not be the best way of doing things but they are the way that works. There has to be a better way of doing things … but simple designs should be simple to implement.

  72. If source order is the objection to CSS tables, why not compromise with a hybrid approach? Major page regions like sidebars, content, and footer can be floated and cleared as usual in any order that you want. CSS tables can then be used to solve thorny layout problems within those particular regions, so long as doing it that way doesn’t foul up the logical reading/viewing order of the page.

    It seems to me that getting bent out of shape about misuse of CSS tables is kind of like railing against screwdrivers because someone could use one to facestab people and steal their wallets. You can also use screwdrivers to build houses for the homeless, fix broken toys for orphans, and build scratching posts for adorable fuzzy kittens. Just because a tool can be horribly abused doesn’t negate its utility when used properly.

    Our front-end design and development toolbox is so limited already that it strikes me as misguided to reject, for ideological reasons, a tool that could be very helpful if used with restraint and forethought.

  73. fantasai wrote on table layout: “If you want to argue that “display: table” is inadequate because it does not provide source-order-independent layout, then make that argument.”

    I’ve made that argument on the WSG.

  74. Blah. There we go again.
    CSS is for _presentation_, how difficult is to grasp that? You can use floats, display:table-anything, whaterver you please to get the presentation effect you want. And no, CSS bears no semantics.
    Eric, why are you surprised that people think that you cannot tell the difference?
    These are your words: ” Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it”s arguably worse.”
    They are wrong. You may not like the approach, but that does not make you right.
    Though it would be interesting to see, what makes it worse.

  75. And thus I have (re-)learned my lesson: which is to never, never, never, never talk about tables and layout without first ensuring that every single statement is framed and clarified so that it can’t be taken in any way other than its true intended meaning, as opposed to in ways that sabotage the entire goal.

    Which is impossible. So, basically, never.

  76. @Eric Meyer – The zealousness of the standards movement’s “dont use tables for layout” biting you on the ass here I think.

    I know what you mean, and I agree. The points are that display:table has no functional difference from using a real table with the one and only exception being the semantic consiquence being dropped. All the other problems remain: dependence on mark-up-order, mark-up purely for the sake of presentation, heavy coupling of mark-up to style rather than abstraction.

    I wrote about all that a couple of months back when the “hey, everyone use display:table” rubbish that was getting promoted: http://mattwilcox.net/archive/entry/id/1030/

    And here I argued about the requirement of CSS to borrow from programming languages: http://mattwilcox.net/archive/entry/id/991/

    I’ve given up thinking anyone with any influence at the W3C will listen to this sort of stuff. The way this stuff gets continually dismissed by the CSSWG I’d have thought I was crazy if it wasn’t for other designers thinking like myself.

  77. @Matt Wilcox:

    Sounds like the solution would be to get more of those “other designers” to participate in the WG and proffer specs.

  78. I agree, but I also have a REAL solution that I have posited to REAL designers sitting next to me – and they agree that this is the solution they have been looking for. And as I use more and more CSS, I am more and more convinced this is the solution too. So here is the solution to all of CSS’ woes: The ability to declare elements in relation to each other by both class and id. The reason we use float is because we want one element to be adjacent to another element. In other words, we abuse float for something other than its intended purpose, which is to float content (text) around a block (usually an image), not float one block around another block.

    We need the ability to “attach” one element to another in relation to each other. Possibly including the ability to “attach” an element in relation to a parent element – including the bottom of the browser window – how ridiculously easy would ‘attach-bottom-left: 0 window bottom-left 25%;’ be? (Example is attaching the bottom left corner of the element to a position relative to the bottom-left corner of the browser window – not terribly useful, but should show how much thought I’ve put into this).

    I want my #content div to not get shoved down to the bottom of the page just because the #left or #right div is “too wide” by two pixels – yeah, that’s mostly IE but I’ve had it happen in Firefox too. I want the left side of #content attached to the right side of #left and the right side of #content attached to the left side of #right. No float needed and the #content can be in any order (ideally first). I could put ad placements last in the source code and have it show up in the content with the content floating around it (no more waiting for some sluggish ad server to respond before users can read the content). Example for ad placement within content: ‘width: 300px; height: 250px; attach-top-left: 0 #content top-left 250px; float: left;’ would place a 300×250 box ad 250 pixels from the top-left corner of #content and content is floated around it. The most important part of this is that the div would be able to be placed anywhere in the source code.

    These are simple examples. But almost everything frustrating with CSS involves floats and display attributes. If we could just attach two elements together and know they will display the same just using CSS, how simple would layout become? Something to ponder anyway.

  79. So much noise, and only a few pearls of wisdom… it seems quite clear that the problem is the lack of the ability to define relationships between elements: position and size.

    Shouldn’t be so hard to implement in JS as a stop-gap if there is an actual well-thought-through standard (I’m discounting W3C’s CSS ALM… it’s too funny to be taken seriously). That should see browser implementors take notice.

    Thanks for the rant, Eric. Something good might come of it…

  80. Adam wrote: “If source order is the objection to CSS tables, why not compromise with a hybrid approach?”

    Thanks Adam. I was just about to gouge my brain out with a screwdriver until I real your thoroughly reasonable suggestions.

  81. C’mon Eric, that’s totally overreacting. It’s like responding to an editorial critique by saying “Oh, you don’t like my writing style. I’m never writing anything ever again!” I think the lesson you should take from this is to spend some time revising your posts while you’re not in a ranty mood, and to focus on whether the message you want to send is clearly represented. Having one person pedantically pick apart your sentences is one thing. This many people misinterpreting your post should tell you that you messed up in your original explanation. In this case I’d say it’s not a function of your sentences, but rather the flow and transitions through the entire piece.

    There’s a lot of potentially useful things in your post. There’s frustration in your post. There’s questions. There’s unmet requirements. There’s acknowledgement of things that work well. There’s critiques of what’s available. Take these, put them together with Joel’s question, and do a little thinking. Explore those things a little deeper. I have yet to see a really insightful, in-depth, and thoughtful discussion of the needs and requirements of CSS layout and how to meet them. You’re in a really good position to create that. You’re deeply involved in the design community. You understand its problems, and you feel its pain. You understand the technology, and you know its limitations. You have a grasp of visual design, of accessibility, of flexibility, of good web page architecture. You have both deep and broad connections through the web developer community, and you can encourage a meaningful conversation.

    Even in the Working Group, I see a handful of solutions, each of which solves some aspect of the problem, but I don’t see much of a cohesive vision. And part of that, I think, is because there’s no common vision of what’s required nor of how important each requirement is.

    So I suggest you use this blog post as a starting point. Clarify your questions, dig around for some more, explore the topic with your readers. Take on my request and close the loop.

  82. After reading over everyone’s suggestions and answers to the CSS layout problem my official vote is let’s roll with the Advanced Layout Module. I’ve read it over and it appears to solve the source-order-dependent problem other solutions fail to solve. I also like the idea of using XSL although using XSL always feels like using a nuclear bomb to kill a bug.

  83. I’m a designer and I want simple variables & conditionals etc in my CSS, along with a decent, source-independent layout system.

    Lets face it people, sooner or later we’re going to start doing this in jquery-style javascript.

    We’ll treat non-JS browsers as the Netscape 4/IE5/IE6’s of the world, and get on with it.

    Waiting for vendors to implement an unknown solution to a difficult problem *and* for that solution to get widespread adoption will take decades.

    We have javascript (and more to the point, jquery and other frameworks) right now. If someone with the genius of John Resig (& everyone else) can make all the wonderful things jquery can do as simple as a few lines of easy-to-read code, then how much of a stretch is solving the layout problem? (As Eric points out, javascript solutions to various problems already exist and will keep reappearing.)

    My gut reaction to such a thing is “No, unclean!” but really, if someone writes a jquery plugin for it today, then there’s a designer-friendly, cross-browser solution right there ready to go.

    I know, I know, much easier said than done, but by no means impossible, surely.

    Right now it feels like there has been a few tentative toes dipped in the water, but we’re waiting for the nod from on high to give it the go-ahead, lest we jump in first while everyone points and laughs ;)

    Are there big stumbling blocks to such an approach? Let’s solve them.

    I do think in the long term thought needs to be given to good solutions that can be implemented soon(ish) so they’re widely adopted in years to come.

    But what better way to try them out in the mean time than to get behind a javascript version now?

  84. Can someone explain to me why there’s so much hostility toward the CSS3 Advanced Layout Module? I’ve given it a once-over; while it’s arguably pretty weird, I found it more rational than the baroque methods we use now to achieve decent layouts with CSS. Why the hate? Did I miss something horrible in my (admittedly quick) review of the spec?

    Aarem wrote: “Thanks Adam. I was just about to gouge my brain out with a screwdriver until I read your thoroughly reasonable suggestions.”

    No problem, Aarem. Just doing my part to prevent unnecessary screwdriver lobotomies.

  85. Pingback ::

    Start a fu-biz. « Manujarch’s Weblog

    […] Wanted: Layout System (meyerweb.com) […]

  86. How is having elements generate those boxes not creating a layout table?

    It is creating a grid of boxes. But, guess what? That’s been working well for hundreds of years. Not all of us need to use the conceit of a circular or triangular text layout. There will never be a separated layout language that can handle a John Hodgman book or a Dmitri Martin act.
    Throwing out something that will work for 90% of us because it cannot be used for things that, let’s face it, are more about presentation than content anyway, is just out-of-touch.

    I get that there”s a difference between markup and display boxes. Honestly, it”s a little bit disappointing that so many people so quickly assumed that I don”t.

    I don’t get how we might have gotten that impression…

    Saying that is just saying “use tables for layout” with different words. Turning a bunch of divs or list items or whatever into table-role boxes is no better than just using table markup in the first place, and it”s arguably worse.

    Oh, right.

  87. Pingback ::

    Re:morse.nl | Wanted: Layout System

    […] by Paul H. Wanted: Layout System Eric Meyer elaborates on why we need a better layout mechanism for web content (whether it be via […]

  88. Nice article.

    Thought i was the only one missing a layout-system for the web that just works the way it should be without the flaws of floats…

  89. What if we go back and really look at the idea of separate stylesheets for screen, print, and handheld?

    That takes care of most of the CSS layout problem: screen could be all absolute sizings and positioning, and users can (full-screen) zoom if they want. Handheld and print designs would be mostly linear, so positioning and layout is pretty manageable (and they could be used by people with vision impairment who can’t read 14px characters and can’t get a bigger monitor).

  90. I think where we need to start is with an agile approach.
    It would be great if these standards bodies and vendors could get together with the unwashed masses and build out a backlog of high priority needs to fix. Put together user stories, have a community of designers and developers prioritize the stories and have some smart developers build a reference implementation to get things going.

    “As a designer I need to be able to show text inside a circle in order to …”

    is better than saying “It’s borked, fissit!”, which happens regularly with both software and web development.

    Along with that list of user stories maybe we list current technologies that cover the story but are inadequate in some way. If the web standards bodies and vendors were all on the same bugzilla/trac/jira/wiki and paying attention to all the screaming going on out here then maybe we’d make some progress.

  91. @fantasai “I have yet to see a really insightful, in-depth, and thoughtful discussion of the needs and requirements of CSS layout and how to meet them.”

    It has to be independent of the source. It has to be able to know about style relations between non-semantically related elements.

    Those are the two requirements of any future layout system if we want to preserve the web stack’s purity (ie., HTML is for semantics and not to be littered with crap for presentational purposes; JavaScript is for interaction behaviour and not patching up HTML and CSS because CSS isn’t good enough).

    I’ve been over this time after time, and yet no-one at the W3C seems willing to accept the fact that the only viable flexible solution to layout issues is to give CSS the ability to inspect the properties of other objects (to achieve stylistic links for non-semantically linked elements), to place elements relative to other non-ancestor elements (to remove the dependence of source order for presentational effect), and mixed-unit/variables (for creating our own grid systems). All that the W3C seem to ask for is a specific “use case senario” – we’re on an issue way more fundamental that that. I’m not talking specific use cases, I’m saying the fundamental essence of how CSS works right now is flawed and incapable of delivering the capabilities designers want without us corrupting the web-stack.

    We do not want or need another layout Module. The problem with CSS layout isn’t the lack of a Module for layout, it’s a lack of the basic tools CSS needs to achieve layout. You can’t shoe-horn our layout requirements into some ASCII Art like the Advanced Layout Module tries. You can’t shove everything into a non-flexible grid. You can’t say “display:table” is a layout solution, because it is not (Eric, myself, and a dozen others have argued why this is; and frankly I’d like to see experienced web designers opinions taken a bit more seriously than they seem to be by the engineer types in the WG).

    The problem is this: It’s not possible to provide a generic solution to layout problems. Our layout problems are not generic. They are specific to our designs. So we need the tools in the core of CSS to make our own layout solution.

    Please read http://mattwilcox.net/archive/entry/id/1031/ ; you can likely skip down to “What are the design implications of how CSS works?” and take it from there. And if you’re more about trying to understand the “style separate from structure” issue please find a spare ten minutes to cast your eye over http://mattwilcox.net/archive/entry/id/991/

  92. I agree strongly with Matt’s comments.

    It’s the difference between giving us a bucket full of building blocks and a model car kit. The working group gave us table-layout, so now we can make designs that look like they were made with html tables…and that’s about it unless we start misusing that feature. We actually need CSS to be comprised of fundamental core pieces, like the ability to place elements relative to non-ancestor elements (without changing our HTML source order).

    He’s right — we don’t need a layout module and we don’t need overly-specific solutions to replicate specific design techniques like HTML tables, we just need the basic building blocks that we can use to build anything we can imagine. Really, CSS so far has done a pretty good job of that, but CSS3 looks like it’s straying from that idea.

  93. Seems, that I’m the new kid on block here, but why does it have to be ONE way? Why is it that every other successful industry has somehow learned that binding yourself to one solution or philosophy is what makes that industry eventually fail. It’s the dynamic of change in web design that makes this industry so fascinating and desired.

    How is it that the print world managed to come up with world wide standards, but still keep that dynamic in place and how (oh how) is that the WORLD WIDE web is still arguing so passionately that it sometimes dissolves business relationships?

    I like the use of “display: table-cell” not because I am a part of some ultra-winged plot to dummy up the web, but because I have to earn a living and it will make the process easier for me to do the work I get paid for done in less and with less frustration.

    I’m sure someone, at some point will figure out a consensus, but until then my mantra is and will forever will be…Do what it is necessary to get the job done right for your clients to be happy they paid you…

    While there is yet to be a right solution…right is what works…for now!

  94. I agree with Matt, but I also have something to add:

    The problem with being asked for use cases is that they’re at too high a level, it’s too easy for a single use case to be dismissed as not common enough to justify the effort in making it possible.

    What we should be doing is what has already been done for algebra, relational databases and programming languages. Find out the fundamental axioms that work together to form the basis of a layout complete grammar. Just like there are 6 basic operations that must be possible in order for a database language to be considered relational, we must define the basic building blocks of layout that must be possible in order to allow all higher-level constructs.

    This isn’t an undertaking that should be limited to html, the basic requirement is this: For any structured document there must be a way to achieve any derived two-dimensional layout including the ability to define how it reshapes under different window sizes and zoom levels. Basically, if a DTP can do it, the web browser should be able to do it.

    No ifs, no buts, no moaning about rendering performance. Find a syntax and implement it, scrap CSS completely if need be. The web is growing and evolving at an incredible speed and if the building blocks of pages and layout aren’t based on thorough mathematical reasoning (like the other fundamental building blocks of computing) then the capability of the browser will quickly fall short of the requirements of the user.

  95. float / position:absolute / display:table …

    If layout was a ‘nail’ then the 3 methods above are ‘shoes’.

    That’s right. We’re currently hammering in nails with shoes. It kind’a works but is a bit weird. You end up with the nail not fully in, and it could wreck a perfectly nice shoe which – as most of you will already know – should actually be used for wearing on a foot (often over a sock).

    I WANT A BIG SHINY LAYOUT HAMMER!

    Some great comments above. Shame about some of those pedantic offerings that have unsurprisingly crept into responses. They should help minimise page scrolling by just not bothering :P

  96. If your beef with the table display types is source code position, I think it makes sense for implementors to address that shortcoming…

    Of course, this idea probably suffers from problems with incremental rendering. But that said, I think the spec should allow you to define what table (as defined with display: table;) an element defined with display: table-cell; belongs to. Such as assigned-to-table: .some-selector; and then also, what position in that table that element should take, like table-cell-position: x y;.

    But then we’re back to the implementors actually discussing the problem and actively seeking a solution to it, and now, not in ten years.

    Personally, I find that positioning does what I want to do much of the time, though that has it’s shortcomings as well. My biggest complaint with that is that an absolutely positioned column cannot cause its parent’s height to grow in height dynamically in response to that column’s content, but there again, it seems like limitations like that could be fixed easily with more configuration options for CSS.

    Many people, however, are perfectly fine and comfortable with tables, and I think that says a lot to that method’s flexibility and viability as a layout mechanism. So, why reinvent the wheel? Why not keep what works so well with that but at the same time, find a way to fix what doesn’t work.

  97. Did some thinking on the idea of a layout-complete grammar. As far as grammatical changes, it doesn’t seem like there’s much that needs to be changed. Wrote up some basic thoughts on how it could work

    http://bellsouthpwp2.net/k/i/kinematicf/General/lss.txt

    where the weakest part is the extended flow language. It’s more about just being allowed to define rules in this way.

    It doesn’t attempt to address a lot of the specific code limitations that may be a problem, as I’d think it better to let others pick it apart in that regard. But I’m still interested in how well you think this could describe what’s being asked for.

  98. Good words. Mirrors my thoughts for the past decade nearly exactly as well – of course, a lowly like myself couldn’t utter such things around the ‘standardz krew’. Anyhow, while at university a few years back I worked on a system I called wrpl (pronounced whirple). The basic idea was:

    div#left {
    left: 20% center; // 20% from the left margin of page based on center of object registration
    width: 200px;
    }

    div#right {
    left: (#left.right + 20px) left; // left edge of #right sits 20px from the right edge of the element #left
    width: 50%;
    }

    The basic idea was expressions – which I believe Microsoft have implemented already – so that you can use properties of DOM objects. You would define a base element with constant properties e.g. 20px, then define everything else relative to that base element.

    I even worked on webkit trying to implement it – I got a very basic system working but ran out of time/interest/enthusiasm.

    CSS positioning just feels clunky – it feels like it was never actually *designed* to be able to position things. I still don’t understand why DOM properties can’t be accessed from within CSS, nor can expressions like 100% – 1px be evaluated…

  99. jQuery have planned an implementation on absolute positioning any element relative to any given element.

    http://wiki.jqueryui.com/PositionTo

    This is exactly the sort of thing that’s needed in CSS. There’s a good reason the jQuery guys are making this – and that’s because CSS needs it, but doesn’t do it.

    I have a horrible thought that in the next few years, in order to advance web design, we’re going to start relying on JS for presentation. Not for enhancement, but for basic presentation. I hate the thought, but I love the possibilities.

  100. I have a horrible thought that in the next few years, in order to advance web design, we”re going to start relying on JS for presentation. Not for enhancement, but for basic presentation. I hate the thought, but I love the possibilities.

    That’s what I’ve been saying for six months. It’s what I was saying in the post, when I linked to the Inman Position Clearing JS and said it’ll be done again.

    CSS will be extended by JS. People will scream about it. It will happen anyway. The only question, so far as I can see, is whether these JS solutions will enhance CSS or completely eclipse it.

  101. Over the last five years working as a graphic designer, I have – through the valley of the shadow of death – migrated to web design and development. I came from css-styled tables, and have for the past few months been trying to make head-way with css-styled div layouts. But F*&# its a mission getting your elengantly succint, pixel-perfect PSD layout to look the same accross all browsers…

    I couldn’t agree more with Eric. Its got nothing to do with styling and everything to do with LAYOUT. I like the idea of divs. Hate laying them out. I think that the sentiment that designers-trying-to-be-developers is the problem is simply, rubbish. The call for CSS-styled layouts came out of a design sensibility that many developers lack. Tit for tat – Enough of that fight. Hey, some of my best friends are developers. Ha ha.

    I like the technical aspects of applying an awesome visual to the box model, but its getting tired.

  102. Pingback ::

    Eric’s Archived Thoughts: Wanted: Layout System at Matthew Kempster

    […] Eric’s Archived Thoughts: Wanted: Layout System […]

  103. Pingback ::

    Linkdump for February 18th | Game Blog

    […] Wanted: Layout System Uh… What he said? Why do we use floats for layout, anyway? clear. That’s pretty much the whole answer. The unique in-flow/out-of-flow nature of floats means they interact with each other and with the normal flow, which means they can be cleared, which makes them useful. (tagged: via:fogus css floats webdev html essay ) […]

  104. @Eric

    I remember that post. It’ll happen, certainly, and it’ll be a step backward for accessibility and the separation of semantics/display/behaviour. But, the W3C have forced the situation by spending the last decade completely ignoring the basic, oft-repeated, requirements of web designers; consequently ensuring that CSS as a language is incapable of performing the tasks required of it.

    Even if the sort of things discussed here were to make it into CSS3 today, it’ll still fail to effect the real world, because browser support would take another half-decade to get to a point where programatic CSS could be relied upon as a client-side feature. The CSS WG pissed about too long, we can no longer wait for them or the technology to catch up with requirements. JS will soon be used for basic layout, and once it is there will be no migrating away from it and back to CSS should CSS ever acquire the features it needs. The habit will have been formed.

    I’ll be writing a blog article on this topic soon.

  105. @Matt Wilcox

    You know, I’m not entirely convinced it would take so long, *if* the standard were written properly. For example, it would *need* a reference implementation and a large series of real-world tests such as the Acid tests to confirm compliance.

    Browser guys are getting on the game a lot more these days – even the IE team are coming to the plate.

    After all, you can’t exactly blame MS for stagnating CSS – it’s not like anyone *else* has got it completely correct yet… ;)

  106. @Keith I think, given a solid spec instantly (which is a good year even if we were being wildly optimistic), it’s still take a couple of years for all the browser manufacturers to implement. Which is fine, except in two years were still going to be dealing with ie6, let alone ie7, and ie8. None of which would support these fancy new things. Hell, none of those support border-radius even. And that’s a solid spec already.

    It will be at minimum 6yrs from implementation in a mainstream browser before we can rely on any css property. That’s not too back if it’s just decorative, like text-shadow, but it’s dead and gone for layout. No client in the real world will accept a layout that is radically different on IE. That’s not going to change soon.

  107. And please, let”s put the whole “display: table-cell will grant those abilities through CSS” to rest. Saying that is just saying “use tables for layout” with different words.

    One could argue that changing a hyperlink to display: block is just as bad, because links are inline by nature and one would changing the nature of the element by making it a block-level element. Following that train to its full extent, CSS is useless, because every design tweak controverts a natural tendency of an element; that’s the whole point of CSS.

    There are really only three reasons I don’t use display: table-cell for layouts: 1) I generally avoid grid layouts for stylistic reasons; 2) display: table-cell-based designs rarely work properly cross-browser, especially with IE6; and 3) display: table-cell-based designs often lead to divitis.

  108. Very late to this party, but I just have to mention this…

    Having suffered greatly at the hands of IE v4-8.x I am really, REALLY not usually one to speak kindly of anything Microsoft, but in the past year I’ve been assigned to work on a few Windows Presentation Foundation (WPF) apps. WPF uses XAML, a declarative markup language that’s also used by Silverlight, for layout, and I’ve got to say… their layout system is a pretty wonderful thing: very easy control of fluid sections (alongside fixed elements or set in proportion with other elements), excellent min/max height & width control, vertical centering, several types of included layout panels for specific uses, a means to write your own custom panels, source-ordering the main sections any way you like… It really is a pleasure to develop layouts this way. We could do FAR worse than to push the browser vendors to adopt the basics approach and syntax of the XAML grid system.

    In fact, if Silverlight could 1) render text a little better 2) make text selectable and 3) make text scalable via the browser’s normal font size controls, I’d really want to use it for all kinds of web sites, even without any of its motion graphics capabilities. Those three items are, unfortunately, total show-stoppers for many of us.

  109. Does anyone know why the CSS3 clear-after property was abandoned?

    http://www.w3.org/TR/2002/WD-css3-box-20021024/#the-clear-after

    This should have been implemented ages ago

  110. Pingback ::

    From the Matrix to Glue - the next CSS layout

    […] this great post proposing a new matrix based layout system for CSS which in turn was a response to Eric Meyer’s cry for a new layout system. The author has proposed a “matrix” based system which in theory is beautiful but […]

  111. I´m a little scared. I did webdesign for 2 years about 7 years ago : using tables (yes) to mimic the grid, and coded asp with it.

    Now that i´m grasping CSS, I start to read it isn´t the heaven I dreamed about.

    You want to know what would be good to designers? to deploy a web page as you would print to pdf from illustrator or indesign or whatever.

    yes, everything keeps moving, technologies, programming languages… but the core of layout a webpage, the grid, the design principles will remain the same.

    So, i´m not really interested in css3 shadowing system, if the essential layout tools dont work: I design my pages in illustrator, slice them and try to make them look the same in safari/mozzila/opera/ (ie) .

    I guess in the future we won´t have to worry about that. Or everything will be flash / advanced aftereffects or apple motion, or illustrator will deploy websites

    thnx for the post

  112. htmlayout[1] has special custom CSS attribute named ‘flow’ that defines layout manager used inside container:
    Values are: vertical | horizontal | horizontal-flow | vertical-flow | grid.
    That defines full set of layout managers used in Java but is purely CSS thing. Combined with flex units [2] it creates exceptionally flexible system of layouts in CSS and yet keeping all elements in position:static.

    [2] flex units: http://www.terrainformatica.com/htmlayout/fspu.whtm
    [3] the flow: http://www.terrainformatica.com/htmlayout/flow.whtm
    And screenshots: http://www.terrainformatica.com/htmlayout/screenshots.whtm – pretty much all samples use flex and flow.

  113. I created a Java Swing layout manager, based on canonical grids, called DesignGridLayout. The resulting forms are always visually correct.

    DesignGridLayout

    It also has a novel Builder (design pattern) style API, which makes form construction (in code) trivial.

    Implementing the layout algorithm you need in code is cheaper, faster, and more robust than coercing a box model or constraints engine to behave rationally.

    Other visual design patterns will require other algorithms and implementations.

    (Eventually, someone, who has a great deal more tolerance for pain than myself, will reimplement the DesignGridLayout idea for HTML + CSS using JavaScript.)

  114. “Try teaching CSS to someone coming straight from the print design world and the problems become painfully obvious.”

    I agree, Dan, unless you’re an old-time typesetter who used tags that were not unlike html (CSS-style formatting was possible as well). When I first learned to code for the Web after years creating layouts & setting type in Quark, it was a real blast to the past and quite congenial. Well, when CSS implementation got up to speed, anyway . . .

  115. Adding to Nick’s XSLT suggestion:

    It’s too bad XSL-FO was designed (primarily) for print output … but, like XSLT, it has a killer (and not in a good way) learning curve.

    K

  116. Pingback ::

    elucid(blue) » The Standards of Tomorrow Are Obsolete Today

    […] later? And that doesn’t even touch on the power variables would give over layout controls. We need a layout system, and CSS is not […]

  117. Maybe a bit of a radical idea here, but maybe what’s needed is not a ‘layout system’, but a ‘template system’.

    What might be nice is if you could predefine a bunch of templates that can be used anywhere on your site (like a master page to use the .net example). These files (why not make them individual files?) would have a simple xml based syntax that consists of… tables! Hey, everyone knows tables, they know how to use colspans and rowspans etc..

    So in your ‘actual’ html file, you’d have a tag called (for example) ‘content’, with an attribute of ‘template’ that pointed to your file. That file would naturally be cached by the browser and loaded. Within your content tag, you’d have multiple ‘section’ tags with IDs that correlate to a table cell in the template. These section tags would just have ordinary content that the browser would dutifully drop into the correct place of the template.

    You get source order independence, the free use of tables (they’re just used as a rendering crutch), lean-as-you-like markup, funky new reusable and cacheable templates. Defined in a nice simple easy to comprehend markup.

    And also there’s no reason why you couldn’t have multiple ‘content’ tags in your page that implemented different templates.

    Ok, minor change of the HTML 5 spec, but I like it.

  118. Pingback ::

    Tim Anderson’s ITWriting - Tech writing blog » CSS: a long wait for the aha moment

    […] noticed that the aforementioned Eric Meyer is increasingly critical of the language. In his post Wanted: Layout System he writes: Maybe CSS isn”t the place for this. Maybe there needs to be a new layout language that […]

  119. I would like something like tables, call them containers or grid-something-or-other which is used for layout. Then you tag your content (this is a photo which shows blah blah blah and this bunch of text is the body of the page and this is the navigation, etc). Tagging the content should solve any accessibility issue right? What we need is a bulletproof layout system. Accessibility is easily solved by tagging content (and tagging content would also allow your content to be poured easily into a mobile version of your site, etc). The only thing this wouldn’t solve is complete separation of content and presentation, but I don’t believe that’s worth worrying about. When you change the design the practical reality is that you are most likely also changing the content to serve the design. Design and content are strongly linked. And if your content is database-driven, it’s separated by default, so why worry about that aspect?

  120. RE: Comment 10 by Dan Wilkinson.
    As a Graphic Designer of 25 years, this comment hits the nail on the head. I am studying the Certificate in Web Design (I know I’m a late starter eh!) at NZ Open Poly. As I delve deeper into the world of Browser ‘hacks’ and floating elements it just gets more tedious, it isn’t design it’s compromise, the real basic of a designer’s job is layout. Eric Meyer’s post has summed up all the things I’ve actually been thinking about and all the frustrations I’m having at the moment and spelt it out. Phew! I’m just pleased that as a relative newbie to Web Design I’m not ‘missing’ something about CSS and am not alone in wanting a different/better way of laying out my pages. After working in the Newspaper industry the module 3 layout technique actually makes good sense to me – shall we all get behind it and try and make it a reality then ?
    Cheers
    Ali

  121. OK, nothing special I have to say, just that as a graphic designer just getting into web design, it sure would all be easier with a layout system.

    Learning all this HTML stuff and trying to know how CSS creates style sure is confusing. I’m not really even very well versed in any of it and to be quite honest, I’m shocked to realize that there is no system for layout on the web.

    With as much money, time and effort as people put in to creating the web and using it, it truly is remarkable how many overall conflicts there are in this stuff!

  122. Pingback ::

    Ready for use: CSS3 Template Layout | Fyrdility

    […] by Eric Meyer’s Call for a layout system as well as his suggestion that many CSS features can be made to work using JavaScript, I went to […]

  123. Pingback ::

    Too long.. - A Geek’s Life

    […] recently saw this post by web design god Eric Meyer, and it really cleared some things up for me regarding CSS.  I […]

  124. Would something along these lines be anything resembling reasonable?


    div {
    position: free-float;
    top: 2em;
    left: 2em;
    }

    Works like float, in that any siblings (and their descendants) must flow around it, but instead of the simple, binary float left or right, it can float in any direction, a specified distance.

    Works like position: absolute, in that any other free-floated elements may obscure (or be obscured) based on z-index.

    Works like position: absolute (and unlike position: relative), in that the final position is calculated with respect to its containing block.

  125. Pingback ::

    CSS positioning with vertical spacers | Josef Richter

    […] results, but you would probably choose different tool if you could… The community, including Eric Meyer and Shaun Inman obviously longs for a real layout […]

  126. Pingback ::

    Is CSS 3 over-baked? - CSS3 . Info

    […] every prolific John Resig weighed (as did Eric Meyer) in the past on the CSS 3 specification and the template layout issues that many have with the […]

  127. If I had one modest wish. I’d wish for height:100% to work in useful way. Just like it did for tables in quirks mode.

  128. Pingback ::

    Icosidodecahedron - The Web Blog of Michael Kozakewich

    […] I retraced my steps: After reading that, I went to his blog. His latest entry at the time was a link to the blog of Eric Meyer, who pined about the need for a new way to lay out documents. His second link pointed […]

  129. It’s been a year now since this article was posted. I have put together a proposal and sample Chrome implementation of a CSS layout extension described at http://blogs.eforceglobal.com/dkarisch/archive/2009/07/16/536.aspx.

    I think it meets or even exceeds the requirements that you and the responders to this post are demanding.

  130. The CSS Scripting Layout Model that I mentioned above is able to emulate an HTML table and improve upon it by reducing the total area required. please see…

    http://blogs.eforceglobal.com/dkarisch/archive/2010/03/15/544.aspx

    As I state in the blog… “Scripting renders CSS layout a more open system whereby any developer the world over can contribute new techniques for content layout.”

    If “people were asking for any decent layout mechanism at all, which CSS has historically lacked” then why not CSS Scripting as an answer?

  131. I’ve seen the world of web development start from nothing but command-line authoring and server-side scripting, using Pearl, CGI and other archaic scripting languages. Netscape and HTML was about 6 months away from launching and anybody who was lucky enough, like me, to have the tools and dollars to play, was designing, developing and programming websites (marketing and e-commerce) with a few tools and lots of creativity. Anything and everything was possible and after Netscape was launched, IE followed and slowly the proprietary “rainman” of AOL and other Apps started to disappear. Our limits where our imagination and the developer and the “Tech Giants” seemed to work hand in hand. It was the mid to late ’90’s and everything seemed to be moving forward and up! Today, 15 years later, we seem to have grown to wide (horizontally), offering variations of the same old thing without a real “NEED”! Open-Source and FREE everything is a nice thought, but if you weigh the PROs and CONs and their potential effect on the Web, just think if Google decided to pull the plug on 1 line of code, the highly used link to the googleapi for jQuery. How many sites would crumble? What if all the LAMP Platform-based CMS’s turned fee or subscription-based…what would you do? We have globally become addicted to Social Networking with Facebook, Twitter, LinkedIn, YouTube, etc., but as an industry, we are NOT “Social” at all! I can go to the top 100 web development sites and the only way to talk to ANYONE is via a FORM???? We have gone back 20 years in Customer Service? So is it any surprise that we can’t just open our computers and build a website without struggling with such silly issues if it should be Fixed, Liquid, Hybrid, Grid-based, etc. Will it break if I do it this way? Should I use “reset” in my Style Sheet by Eric or this other one that is 50 lines of code? Eric’s frustration is mine to power of 10! Yes, tables had limits, but this was the underlying core or framework of the site. It’s rigid ways compared to today had its purpose because there are more important apps, web-based or not to sell product (e-commerce), CMS (to manage and syndicate content), etc., etc. I’m sure this generation thinks all the CSS creativity is cool, but if that’s true, why are there so many, and growing, articles and postings on the “Holy Grail Layout” as if it’s the “life-line” that holds the Internet together. I used to publish and most many Technology and Internet Articles, but around 5 years ago, I stopped posting and kept writing to see vs. write on how the Web will progress. I thought it would be an interesting exercise and I now have compiled about a 1000 articles and other stored/tagged related media covering over 100 Categories. I think if I dumped it into a WordPress Blog, it would probably take up around 10 Huffington Post Websites, but I’m still contemplating if the world of Blogs will last or will there soon be a complete overhall, taking the World Wide Web in a brand new direction. I hope the take away is that I have been passionate about the Internet, Technology and Interactive Design for over 20 years and I believe that it’s a great time to be a web developer and online entrepreneur, I just hope that “ALL THE TALENT OUT THERE” will shift gears and think “bigger and broader”, which means NOT CSS…or at least not how to make a better layout…Best to All and Happy New Year!

  132. Pingback ::

    The Wonderful World of CSS Tables (For Layouts!) | Keith Pickering Design

    […] Here is a post by Eric Meyer regarding the use of CSS tables for layouts. It’s from way back in 2009, but this is how a lot of people feel, even to this day: […]

  133. What happened to WYSIWYG web editors? A web designer must now know code in order to create a web site because that is exactly what CSS is. Sink, swim or float are your only options as a designer. Four years later (it’s now 2013) this commentary still holds true and like the other readers I agree with the new frustrating coding that a designer is required to know.

  134. Pingback ::

    How to select html nodes by ID with jquery when the id contains a dot? | Ask & Answers

    […] not start talking about how tables are not made for lay-outing. I’m verry aware of the value and shortcommings of CSS and try hard to use it as much as […]

  135. Just really really curious: this was written almost seven years ago. What would you say the answer is today, that is: what would you recommend as the best/less worst CSS layout system TODAY? Thanks

  136. That’s a really good question, M., and one that probably deserves its own blog post. But in TL;DR format: flexbox is very good, and grid layout is about to be mind-blowingly great. So TODAY: flexbox. Using it for overall layout is still a mild hack, but not nearly so terrible a hack as, say, floats or tables.

  137. “a really good question, M., and one that probably deserves its own blog post”

    I look forward to that post then! :-)

    ” flexbox is very good, and grid layout is about to be mind-blowingly great.”

    Just to be sure: in the sentence above flexbox is this, of course: https://css-tricks.com/snippets/css/a-guide-to-flexbox/ and by “grid layout” you mean this http://www.w3.org/TR/css-grid-1/ right? Thanks.

  138. Correct, M.