0

There's a general consensus that using tables for layout in HTML should be avoided. But there are exceptions to every rule. I am designing an SPA (single page application)—with pages that resemble the layout used by a desktop application.

Obviously HTML isn't well equipped for these types of pages, but I have little other choice. Implementing these layouts with DIVs is pure hell, requiring a mix of CSS tricks, hard-coded values and even JS calculations on resize events. I've recently asked this question about implementing these layouts using a grid framework.

But then I stopped to reconsider whether a table-based layout might be appropriate. The typical criticisms don't seem to apply to the unique case of an SPA:

  • Separation of content from layout—Since an SPA is not really content (it's just a skeleton with AJAX filled data), this argument doesn't apply. This is just an interface; I don't expect Google to index it.

  • Tables are less maintainable—Not in this case. The CSS hell you have to go through to implement this with DIVs has a much higher maintenance cost.

  • Tables are slower to render—Of course, but the complex layout we would be creating using alternatives would require even more calculations to render than tables. Heck, we usually compensate for the inherent limitations using JS resize events. It would be much more efficient for the browser to do this natively inside the rendering engine.

In light of these arguments, are table-based layouts appropriate in the specific case of SPAs, or am I failing to consider some other important factors? Is there an even better option?

Community
  • 1
  • 1
talkol
  • 12,564
  • 11
  • 54
  • 64

1 Answers1

1

People used to be wrong about tables. Many people, who knew nothing, pushed for non table layout, event though it didn't make any sense at all at that time, especially when there was still ie5+6 to worry about. There were many misconceptions, eg. that google cares about semantic code. It never has, and it never will, because people get it wrong, and you can not account for it.

However, now, finally there is an actual reason not to use tables:

Media Queries and responsive Design

In responsive design, if you have 2 columns, it makes sense to drop one column to the bottom on small screens. For example, several columns can become a single column on a phone screen.

You can not do this with tables.

This, in my opinion, is the single most important problem with tables. Most other arguments are nothing more than mental masturbation.

There are other layouts, like masonry (see e.g. http://masonry.desandro.com/), which I think would be hard to achieve with tables alone. But for the classical problems of full height columns, tables were the right solution, even though most people preferred horrible workarounds, adding a ton of fragile markup and css just to fake a table.

Now, however it's different, as a table doesn't give you the flexibility you need for responsiveness.

ATJ
  • 309
  • 2
  • 10
user1721135
  • 6,864
  • 8
  • 34
  • 63
  • Great point! Indeed responsive design is harder to do with tables. But, in most of my SPA cases, I don't intend anyone to use them with a mobile device. These are "applications", you can't work with them if you don't have the screen real estate. I usually detect with JS that the screen is too small and show some error or warning message. I don't expect the regular MS Office to work on your iPhone :) – talkol Jul 31 '13 at 08:18
  • "dont intend mobile" - this can turn problematic soon. People want EVERYTHING on their mobiles, even SAP. – user1721135 Jul 31 '13 at 08:21
  • I know and agree, but some things simply require a larger screen. Consider using photoshop or developing (coding) in your favorite IDE. You don't expect these professional tools to work on mobile.. – talkol Jul 31 '13 at 08:22
  • It depends if the app is just for you or you want to market it. If its really an IDE then ok, but a photo edditing web app, may as well be responsive, its not out of question at all. – user1721135 Jul 31 '13 at 08:26
  • I plan to market my SPA, but it's more of a SAS model. In the future, I would like to add mobile support, but this isn't a required feature in the beginning. Just like 90% of desktop apps don't offer a mobile counterpart for convenience. You want to work with my application, wait until you arrive at your office :) – talkol Jul 31 '13 at 08:27
  • 1
    its more important to get the beta out then play with css all night :) – user1721135 Jul 31 '13 at 08:30