Displaying Tables within a Responsive Framework

When responsive design frameworks came along, the first thing they did was to dispense with absolute table structures and replace them with relative positional divs. This means that robust tables are slightly more difficult to create and manipulate / style within a responsive framework, than they ever were within tabular HTML.

The standard WYSIWYGs still have table formatting, but the scope of this is significantly diminished / limited - and in fact quite different considerations need to be made for responsive as you need to factor how your table will appear at diferent screen resolutions / break points.

You need to consider the lowest common denominator first really - in how will your table/s display on a relatively small portrait screen of a mobile phone. This largely means the highly complex table structures of old are out, and whatever you do needs to be somewhat simplified for the current paradigm.

You have 4 main choices when deploying tables in responsive, as per the following:

1: WYSIWYG with % Columns

Affino uses the TinyMCE WYSIWYG editor, and those who used this for HTML sites will notice how a number of the styling settings / options have disappeared in the current iteration. Yet it is still fairly straightforward to do basic tables, as long as they are relatively simple. It obviously depends on the context of a table and in particular the column headings and content, if similar to the table in the above visual- you can probably run to as many 7 columns and still comfortably display them on a mobile screen. If however there are long column titles and / or the content is made up of words, then your limit is probably only 4 or 5 columns. If table is using German or Icelandic compound words, then columns will be even wider.

I fairly recently completed the Affino System Security Rights help guide with a series of 4-column tables, which Affino Customers can view here: Security Help Guide

Any styling can be fiddly though, as can entering column and row attributes - in many ways this is easier with the ’view code’ function on TinyMCE where you can just edit, copy and paste the raw HTML - much quicker than right-clicking and setting variables per individual cell.

2: WYSIWYG with Fixed Pixel Dimension Columns

If the table is obviously going to be longer than 4-7 columns, then it’s not worth doing the table as responsive, as it will try to flow down within the space - meaning that long rows are reduced to stacks of columns - and you can no longer compare parallel rows as before (which is often the main purpose of tables). The solution here is to craft some CSS to enable a horizontal scroll bar - so that the table is entered fully as a static container but you can scroll right and left to view the entire table within the smallest viewport - with the parallel rows in tacts. In terms of site builds, this will be an additional cost typically. The above table in the visual is set up in this manner, with a horizontal scroll bar at its base.

The original reference can be seen on: Icelandic District Courts site

3: SVG Scalable Graphics

Recent years have brought us Scalable Vector Graphics or SVGs - which stay sharp and crisp - big and small. Meaning that in many instances the easiest solution is often just to use a vectorised format of the whole table, numbers and all. You can guarantee quality and uniformity of display across all devices, with the minimum of pain. Do note that larger and more complex graphs will simply have too much density of information at the smaller sizes - so won’t be practically legible. So SVGs don’t solve every scenario. If you want a fully interactive table with lots of columns, it’s likely it will need to be custom developed.

4: Custom Code

For complex and tabbed tables, these have to be custom coded, and will involve a lot of testing across platforms and devices. Certainly the most expensive and time-consuming route to go, but if you want customers to be able to click on and select actual numbers from the table, then your only workable option would be a custom coded table. Obviously maintenance of these can be costly too - depending on how this has been scripted. You could also consider deploying a more application-centric solution whereby a dedicated interface is created to handle tables, or the source data can be uploaded via CSV / spreadsheet.

The core styling would need to be embedded into the framework of the display interface, and there would be obvious limitations in this approach too. So it really depends on how much you want this sort of thing, and how much you are willing to pay to get it.

Quick and Dirty Approach

The methodology I tend to apply is that if the Table format is simple enough (few enough columns), I will do it on the WYSIWYG with % columns applied, otherwise I will make use of SVGs. If the source table is to too big and too complicated for a small screen, I will simply abstract / extract key points / data comparisons into an executive summary and leave the table out entirely. There are of course other variations available - changing formats at different breakpoint sizes for instance, but these are overly complex and more time-consuming to put into place and maintain.

When Things Go Wrong

For examples how tables can cease to be functional at lower breakpoint sizes. the Icelandic Power Station resource - Veitur - gives a useful lesson. If you view on desktop and simply reduce you browser width to a small mobile phone screen equivalent, you can see the column stacking issue I mentioned above, which to all intents and purposes renders the primary table display format useless.