Skip to content
This repository has been archived by the owner on Nov 9, 2022. It is now read-only.

Responsive Table: Linearized Table #164

Open
loganfranken opened this issue Nov 26, 2012 · 5 comments
Open

Responsive Table: Linearized Table #164

loganfranken opened this issue Nov 26, 2012 · 5 comments

Comments

@loganfranken
Copy link
Contributor

Implementation ticket for the extension for Entity/Table that would provide for a Linearized Table on smaller viewports.

Research for this extension started in #71

@ghost ghost assigned loganfranken Nov 26, 2012
@loganfranken
Copy link
Contributor Author

Moving to next milestone

@ebollens
Copy link
Contributor

This has been moved back to milestone 0.1.07.

@loganfranken
Copy link
Contributor Author

I'm working on prototyping this out.

Looking at our options, I think this Responsive Table jQuery plug-in (or code based on it) is the best option:
https://github.com/JPustkuchen/jquery.webks-responsive-table

It converts a standard table to a definition list (dl, dt, and dd). I don't love the dependence on JavaScript, but I don't see a better (non-hackish) solution in pure CSS.

My plans so far are to activate this behavior by adding the linear class to a table entity.

The one tricky piece is that it's difficult to determine when the table has reached a point of overflow from the user's perspective. I think it would be most straightforward to set the table to collapse at one of the breakpoints ($breakpoint-xsmall) and then fine-tune with the following conditions:

  • If somehow the table element has exceeded the width of its parent element, then activate the linear version
  • Allow developer to configure per each table (possibly via data- attribute)
  • Allow developer to configure the aforementioned base breakpoint for linearization

@ebollens
Copy link
Contributor

I propose the class name linearized-collapse

@ghost ghost assigned loganfranken Sep 18, 2013
@ebollens
Copy link
Contributor

ebollens commented Oct 9, 2013

@loganfranken to provides more details regarding:

  • where should we start?
  • what should be plan to do eventually?

@hyperboy raises (and all agree) that we should target CSS-only solutions to start - that keeps the DOM structured and avoids the problem @lnicks raised

@loganfranken loganfranken removed their assignment Feb 18, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants