Skip navigation
Currently Being Moderated

responsive tables

Mar 13, 2013 10:37 AM

hi,

I'm going to be converting a site to responsive and there is a schedule of events on the site that's in a table, so I've been researching how to accomplish getting a table layout into responsive mode.  I've read a lot and looked at tutorials and thought I'd ask here what folks are using for their data that has to be in a table layout.

Thanks in Advance.

 
Replies 1 2 Previous Next
  • Currently Being Moderated
    Mar 13, 2013 10:51 AM   in reply to debibrighthope

    Percentage width Tables are tough to pull off in FluidGrid Layouts because they  always remain as wide as content dictates them to be.

     

    One approach is to create 3 tables with IDs: one for mobile, one for tablets and one for desktop/laptops.  Then using media queries add display:none to those IDs you don't want to appear on target devices.

     

    Alternatively, you might be able to use Definition Lists for your events.  I like Definition Lists because they are more flexible than tables and you wouldn't be repeating content as above.

    http://www.maxdesign.com.au/articles/definition/

     

     

     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 10:51 AM   in reply to debibrighthope

    What is different about a reponsive table than a reponsive <div>?

     

    You would still need to set the table width as a percentage width like:

     

    <table width="80%" cellspacing="0" cellpadding="0" border="0">

    <tr>

    <td width="25%">Data</td>

    <td width="25%">Data</td>

    <td width="25%">Data</td>

    <td width="25%">Data</td>

    </tr>

    <tr>

    <td>Data</td>

    <td>Data</td>

    <td>Data</td>

    <td>Data</td>

    </tr>

    </table>

     

    And just like any other responsive design IF the browser window gets too narrow for the original data information table to be displayed nicely you'll have to find another way of laying it out  then hide the original table and show the alternative one in your media queries css.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 10:52 AM   in reply to Nancy O.

    Nancy O. wrote:

     

    Percentage width Tables are tough to pull off in FluidGrid Layouts because they  always remain as wide as content dictates them to be.

     

     

     

    Nancy O.

     

    You can create alternative solutions and hide and show them at set break points, right?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 10:55 AM   in reply to osgood_

    Yes, but then you have a repetition of content in your markup.  That's why I try to avoid using tables in Responsive Web Design.

     

     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 10:55 AM   in reply to debibrighthope

    For actual tabular data, I use tables.

     

    You can control the size of cells and what-not with css, then make changes in the media queries of a responsive design to get them to fit on smaller screens if needed.

     

    Usually when people ask about tables, they're not asking about actual tabular data (like a spreadsheet) but lines of images stacked like a table. For anything other than tabular data, I use <div> tags and the float:left or float:right css attributes to give a table-like look and reflow according to the browser window width.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:01 AM   in reply to Jon Fritz II

    Jon Fritz II wrote:

     

    For actual tabular data, I use tables.

     

    You can control the size of cells and what-not with css, then make changes in the media queries of a responsive design to get them to fit on smaller screens if needed.

     

     

     

    The only problem I see is if a table of data is wide then it has nowhere to go once the viewport is reduced to phone size. In that senario you probably would have no alternative but to find an alternative way of laying out the tabular data, whether that's in another table or some other container is a problem to be solved.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:05 AM   in reply to osgood_

    Definition Lists to the rescue.

     

     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:08 AM   in reply to osgood_

    I agree fully Osgood.

     

    Generally for a "the table is too big" situation, I would put it into a scrolling <div> so the width is good on the smallest device. Maybe put in a "click here to view the entire table" link to a page with an unmodified table or something.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:09 AM   in reply to Nancy O.

    Nancy O. wrote:

     

    Definition Lists to the rescue.

     

     

    Nancy O.

     

    Maybe.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:14 AM   in reply to Jon Fritz II

    Jon Fritz II wrote:

     

    I agree fully Osgood.

     

    Generally for a "the table is too big" situation, I would put it into a scrolling <div> so the width is good on the smallest device. Maybe put in a "click here to view the entire table" link to a page with an unmodified table or something.

     

    Be a bit of a nightmare for the end user though in a scrolling <div> if the data needs to all be viewed at once? Humm how can one view the entire table on a smartphone if its too wide, link or no link?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:15 AM   in reply to osgood_

    Brilliant. So, the <dt> represents each row of the table, and the <dd> within a <dt> are the cells within that row? Do you have an example page, Nancy?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:20 AM   in reply to MurraySummers

    MurraySummers wrote:

     

    Brilliant. So, the <dt> represents each row of the table, and the <dd> within a <dt> are the cells within that row? Do you have an example page, Nancy?

     

    What happens when the <dl> gets too narrow. If it turns the tags inside to the next line that could scramble the information to the point it makes no sense or hard to read

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:21 AM   in reply to osgood_

    I just meant a page with only the table, no design elements, so they can scroll, zoom or whatever to their heart's content without a design to "break".

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:23 AM   in reply to Jon Fritz II

    Jon Fritz II wrote:

     

    I just meant a page with only the table, no design elements, so they can scroll, zoom or whatever to their heart's content without a design to "break".

     

    OK, better than nothing I guess

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:28 AM   in reply to MurraySummers

    There is no limit to how your definition lists can be styled. 

    http://jsfiddle.net/NancyO/gaXMx/


     


     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 11:32 AM   in reply to Nancy O.

    Nancy O. wrote:

     

    There is no limit to how your definition lists can be styled. 

    http://jsfiddle.net/NancyO/gaXMx/


     


     

    Nancy O.

     

    Yeah but that's not data is it, I mean real data is rows and columns, that's just an address which would work well in reponsive regardless whether it is in a <dl> or <p> or whatever.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 13, 2013 5:23 PM   in reply to osgood_

    OK then another example.  Use whatever you wish for data.

     

     

    <!doctype html>
    <html>
    <head>
    <meta charset="utf-8">
    <title>Definition Lists</title>
    <style>
    dl { float: left }
    
    dt {
    background: #000;
    text-transform: uppercase;
    font-weight: bold;
    color: #FFF;
    text-align: center;
    padding: 12px
    }
    
    dd {
    color: green;
    border: 1px dotted silver;
    margin-left: 0px;
    padding: 12px;
    }
    </style>
    </head>
    
    <body>
    <h2>Pseudo-Table with Definition Lists</h2>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    <dl>
    <dt>heading</dt>
    <dd>some content</dd>
    <dd>some content</dd>
    <dd>some content</dd>
    </dl>
    </body>
    </html>

     

     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 5:29 AM   in reply to Nancy O.

    Nice. Thanks!

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 5:55 AM   in reply to Nancy O.

    Its a nice example in a situtaion which requires limited data. Increase that to 12 cols and 30 lines and then try and follow what is going on once some real data has been entered when the browser viewport is decreased

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 5:57 AM   in reply to osgood_

    It responds very nicely to decreased browser viewport widths, actually - did you try?

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 7:31 AM   in reply to MurraySummers

    MurraySummers wrote:

     

    It responds very nicely to decreased browser viewport widths, actually - did you try?

     

    Yes, I also went one stage further by adding real data and more columns and rows. As I said its ok for limited data but try and follow what's going on when the tags turn as the viewport decreases when double or tripple the data is added.

     

    I guess if that happens then a decision has to be made as to whether to include the tabular data for smartphones.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 8:06 AM   in reply to debibrighthope

    debibrighthope wrote:

     

    I would need more rows/cols for sure... and the data for this particular site is crucial as it shows the times, places and who is playing at various locations for the music festival and can't be left off the mobile device version.

     

    Why not just set up a month <div> area - April, May, June,

     

    Then along the top 1st 2nd 3rd 4th 5th, include the days of the month that the gigs fall on and put the information into tabbed panels

     

    So on a desktop you could have 3 rows of 4

     

    Jan, Feb, Mar, Apr

    May, Jun, Jul, Aug

     

    On the tablet it would repond down to

     

    4 rows of 3:

     

    Jan, Feb, Mar

    Apr, May, June

     

    and once it gets down to smartphone

     

    I guess you could have 6 rows of 2

     

    Jan, Feb,

    Mar Apr,

    May, June

     

    OR 12 rows of 1

     

     

    Jan,

    Feb,

    Mar

    Apr,

    May,

    June

     

    I guess the music festival only lasts for a day or maybe two but you could use time-spots - 10am-2pm  - to replace the month names.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 9:24 AM   in reply to osgood_

    I think also consider having a separate site completely for mobile users - redirect if mobile to a subdomain, e.g., m.example.com.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 10:06 AM   in reply to MurraySummers

    MurraySummers wrote:

     

    I think also consider having a separate site completely for mobile users - redirect if mobile to a subdomain, e.g., m.example.com.

     

    Yeah, sounds good to me.

     

    By the way I must congratulate you on the responsive design you were involved in for this site: http://www.wayneautomation.com/

     

    Looks to me like it could have taken some time to sort out.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 10:49 AM   in reply to osgood_

    Thanks. That was a very instructional site to build. The theme was pretty excellent to work with and it all came together nicely. Responsive sites are alot of work, honestly....

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 10:54 AM   in reply to MurraySummers

    MurraySummers wrote:

     

    Responsive sites are alot of work, honestly....

     

    I can tell. Think I would have found some excuse and backed away from it myself.......can't take the stress it brings at my age.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 11:08 AM   in reply to debibrighthope

    ...I'm kind of opposed to separate mobile sites

     

    Even when it's the best way to present your information?

     

    I'm all for principle, but I'm pragmatic as well. This is a really good approach, I think.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 11:12 AM   in reply to debibrighthope

    Honestly, I think Definition Lists would serve you well with this.

    My first example on JS Fiddle is the format I would use.

    http://jsfiddle.net/NancyO/gaXMx/

     

     

    Good luck!

     

     

    Nancy O.

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 11:24 AM   in reply to debibrighthope

    debibrighthope wrote:

     

    With that said here's a link to the schedule.  http://www.americanrivermusic.org/schedule.php ..there will be the names of the bands playing next to the time:location areas. 

     

    That shouldn't be too difficult. I thought you were talking about some complex data table which might have extended across the majority width of the viewport

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 14, 2013 11:33 AM   in reply to debibrighthope

    "...I just personally find it frustrating to have a "mobile only" site."

     

    In some cases it is necessary, primarily with very large and very old

    sites. For a new site, or a makeover of a small-to-medium size site,

    there is usually no reason to make a dedicated mobile site. Responsive

    design is not difficult. What complicates it is when you use systems

    like Adobe's Fluid Grids, modernizer.js, and a convoluted grid

    framework. The people who go that route are the ones who typically say

    that responsive design is difficult

     

    A basic responsive structure can be coded in under an hour by anyone

    with decent CSS skills.

     

    --

    Al Sparber - PVII

    http://www.projectseven.com

    The Leader in Responsive Tools for Dreamweaver

    Extending Dreamweaver Since 1998

     
    |
    Mark as:
1 2 Previous Next

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points