There is a distinct need for the ability to present tables of information that work responsively across all device widths. There are a lot of potential solutions to this problem, but we should deliver a simple and effective widget that adapts a standard HTML table to fit.
Make tabular data tables responsive by hiding and showing columns based on scren width and adding a chooser to let users control what columns they are viewing. See Filament Group’s responsive table script which could serve as a starting point for this effort:
We could refine the class system used to identify which columns to hide at various widths.
essential = cannot be hidden, seen at all breakpoints
core = shown above smartphone widths (>500px)
optional = shown at desktop widths (>900)
extra = show above very wide width (1,200px)
We could use a priority numbering scheme (1-4) instead of words and the number and actual breakpoints are still TBD. We need something sensible and simple and can explain how folks can extend this as needed.
The plugin would hide columns according to the classes added by the developer. The plugin also generates a checklist of column names based on the TH text node that allows the end user to select what columns to see. We'd need to generate this button that opens the checklist popup or attach the popup behavior to a user selected ID so they can choose where the picker opens from.
@toddparker, @wilto - feel free to use the version I did (tableview), since it's based on Filaments responsive column plugin plus JQM listview.
I also did a version that integrates with datatables. I can email you a link if you want to have a look (app still off limits). Or wait until I get a sample page done on the weekend to upload to Github
@frequent - very cool. I'd like to compare notes on this plugin with you for sure. Did you adapt the FG script or write your own? I was thinking about doing something less complex for the first release - just hiding and showing columns, but the filter is a neat feature too. Is this on GitHub?
@toddparker - no code on Github yet. Repo has stars and issues though :-D
I pretty much followed the code on Filament example and just replaced elements with JQM widgets. So I'm following the same logic as in your provided link.
For the datatables version, I partially replaced datatables optional JqueryUI with JqueryMobileUI and then ported the functions from tableview into a post datatable- handle. So first datatables adds all the functionality, then JQM enhances the table. Works nice.
Give me a few hours, I will try to bring the code up to JQM 1.2, add some notes and commit.
Awesome. Be cool to have you pull out just the column hide/show and chooser (using popup?) alone since that is the core of what we want to do. If the other pieces like search are abstracted into extensions to the table, that would be awesome to see - did you just adapt the listview filter for that?
filter is an extension - just like the listview filter extension. Chooser is still a custom-select (did this way before popup).
I have updated my demo to the latest JQM (new page: here and pushed the commented code to my tableview repo).
This version is close to the version I'm currently using (with datatables). I have changed the custom select to native selects on my site, but for the new demo I changed native selects to popup, so you the widget now uses popup for the column toggles by default. I also JQM gridded the top and bottom wrappers.
There is a bunch of stuff in tableview which you probably don't need/want (filling the wrapper slots, auto adding a selectable-checkbox-column ...). I have labelled the js/css in the code, so you can just pick what you like.
The tricky stuff also should more or less work - tricky being responsive columns with multi-row table headers (more than two will be too difficult to toggle) and table header cells usually having non-JQM classes in which case the original responsive example doesn't work.
multi-row table headers
What I haven't added yet is a wrapper-div around the table and slot elements. Without this, the plugin will run into trouble if more than one tableview is in the DOM. I also still need to add the code for the select (vs popup) toggle menu and get the zebra function to work (odd/even theming table rows).
Let me know if you have any questions.
@toddparker - on a sidenote:
The tableview filter extension is 99% the same as the listview filter extension.
I'm basically only changing names and switch between LI / TR elements. Maybe the listview filter extension can be made into a general filter extension, so it can be used across widgets vs. having almost duplicate code for filtering lists and tables?
@frequent - this is really great. Thanks so much for posting this up, well give this a review and pull out what we need.
We've been hashing out the design and API for the RWD table and this is the most minimal version that I think we can do as a starting point:
Please feel free to weight in or even edit this -- just post a link to the newer version. We can always add things like the filter later, but this would be a good rev 1.
@toddparker: nice, already had a look. Give me a day or two to get my other stuff out of the way, then I will have a look in detai.
@toddparker, @Wilto, @uGoMobi
ok. My 2cents:
added the files and dependency includes for the "tables" branch. The …
…demo is not yet functional, but includes the assets from @maggiewachs' responsive table (Filament Group). Next steps will be to rewrite this code to use @toddparker's proposed API, and any other refactoring that makes sense. Addresses #5093
I agree with @frequent about auto-closing the popup. I think it'd be nice to keep it open while in use. I'm also curious if we think we need a popup plugin dependency here, as it'll add a bit of weight.
Agreed on the number of priorities too, though I admittedly don't know what would be appropriate. It seems like a more simple system of having just high and low priority items would be enough for most cases.
As for theming, I'm still unsure about the role of the plugin and whether it makes sense to offer themed table styles at all, or just general show/hide behavior. The row styles feel more like a general table style that one might use in their website without jQM's helps, so I'm unsure if it's related to the "responsive table" widget. The less CSS boilerplate we add, the easier it'll be to configure the table to look different per website, and then our widget handles the hard part without doing all that much, visually. Our docs styles should style the table attractively but I'm not sure whether those styles should be part of the framework CSS at all.
Per the final bullet, The table isn't functional yet, so that makes sense :)
@scottjehl: sure does :-)
If native multi selects are widely supported, we could try that instead of popup but I have a feeling that could leave a bunch of devices with a bad experience. We can add a button to close the popup but it adds the need to expose options for the text string and maybe theme and I've been trying to avoid all these options. Worth looking at.
I intentionally proposed a fair amount of priorities to give people a way to finesse breakpoints without editing media queries. The more levels, the more finer grained the width breakpoints can be so people can just use the ones they want and skip the intermediate ones. I don't think we can avoid baking media queries in on this one. Open to suggestions here.
Theming is tricky but since we don't offer sorting or other integrative rows features, slapping a ton if classes everywhere just seems heavy. It's a table, not a grid. We could offer options to theme TH and TDs but default to not applying these classes. In addition to adding overhead by adding classes to every cell, it opens up a pandit as box of feature requests - how doni set row or column hover states, etc. seems easy enough to add the classes in the markup and avoid all the JS config and overhead. I'm ok with just having row stripes and lines as demo features to show how to do it and keep the table very simple. What we have now is pretty close to Twitter Bootstrap's table so we can see if we want to do more or less from there.
The key thing were doing in the first version is auto hiding columns based on width and providing a way to give users control if what they see. All the other stuff could be added later.
Let's keep hammering this stuff out.
Good stuff, Todd. Thanks.
There's a functional rough pass of the responsive table in the tables branch now.
Let's chat in the AM about how it's shaping up.
Looking good! The tap out to close the column popup seems like a nice, simple solution.
Latest commits to the tables branch include both modes mentioned above and they're both written as extensions.
My plan tomorrow is to do some accessibility testing to see how the labels currently act in screenreaders, and if they're not ideal, I have a few ideas to try instead.
This page shows prototypes of both table modes in action:
Example showing some custom styles to make the stacked version look nicer:
both very nice! Wish I was that fast in "hammering" stuff...
@toddparker and I have pretty much finished the first draft of the table plugins and documentation. You can check out the latest in the https://github.com/jquery/jquery-mobile/tree/tables branch.
The scripts for these plugins can be found in that branch's js/widgets folder - there are 3 tables scripts in all.
It's not currently updated with today's changes, but the branch preview is here as well: http://jquerymobile.com/branches/tables/docs/tables/index.html ( @johnbender any chance we can refresh that?)
We're open to feedback on option naming, as well as anything else that stands out.
The one outstanding code issue I'd like to fix is the setTimeout used at the end of the columntoggle plugin extension. Maybe someone would have ideas for another way to get it to properly refresh at load, so we can remove that workaround?
@scottjehl Hi Scott,
Just some very quick 1st feedback...
On FF16.0.2, when the screen is wide enough for the full table to be displayed, the "Rating" heading appears with a strange underline (let me know if you need a screenshot). This does not happen in Safari (Mac OSX)
Then, I would probably replace ID with id and TH with th (all still in a <code> </code> block ), for consistency with the rest of the docs.
Finally, in the sentence: "In reflow mode, you want to pick at minimum width at which the entire table will fit comfortably...", should the first at be replaced with a (so the sentence would read "In reflow mode, you want to pick a minimum width at which the entire table will fit comfortably")?
Otherwise, It's all FANTASTIC!
Great new widget, have been following it every update.
One small feedback in the docs within the Reflow mode basics page; in the preview code you use <b class="ui-table-cell-label">Year</b>. Please change the <b></b> to <strong></strong>.
Is it correct that only the iPhone example image popups out?
EDIT: just looked at the source, and I think the links in the popup are not correct set.
Anyways, great work!
Can you explain your reasoning for using strong here? These elements are purely for visual aid and are not exposed to any assistive technologies. In this case, I believe we've used b in accordance with HTML5's recommendation: stylistic offset.
Using the b tag actually makes sense here, semantically. b conveys that the text is stylistically offset from the surrounding text, without implying any additional importance—I admit it’s a pretty dubious sort of “semantic meaning,” but so says the spec.
By using b, we’re allowing the semantics of the parent th and td to define the contents of the b tag, unmodified. By using strong we’d effectively be saying “EVERY HEADING IS VERY IMPORTANT,” which is unnecessary. That may be the case in individual use cases, but we don’t want to assume it across the board.
I see that dotted underline under rating and that's because we have a abbr wrapped around that element and FF must style it differently. We could add an override for that, but I'm not sure if that's a good idea. It does give you hint there is more info if you hover over.
I just check in changed to use TH, TD, and ID in running text
I just fixed all the popups on the phone comparison page, nice catch.
We're using b on purpose at @Wilto explains.
@scottjehl @Wilto @toddparker
I just read the specs and you're correct in this situation.
In HTML4 <strong> meant ‘strong emphasis’. Now in HTML5 it's meaning is 'importance'.
changed the check for table cell visibility to check if display === t…
…able-cell, because this is happening before pageshow and the :visible check will always be false. Now the columntoggle menu is updated properly at init. addresses issue #5093
fixed the logic for calculating the nth-child selector. Addresses #5093
Ok, with those two fixes, the logic now seems solid. Still need to clean up the docs, but please help us test an provide feedback and ideas for demos!
I am very happy with the arrival of the new widget.
It can be very useful in many cases.
However, I have a point, there are two modes very interresting (reflow method and Column toggle mode), but there is a third possible.
Based on an idea by David Bushell : "The tables change orientation on small screens. A horizontal scroll or swipe is used to view more data. The table head is always visible." Here is an example : http://dbushell.com/demos/tables/rt_05-01-12.html
What do you think?
@forresst - thanks for the link. That is a nice pattern and we gave that some thought when prototyping possible solutions. Ultimately, we decided that approach wasn't going to be compatible with enough of our target platforms and were concerned that when the technique failed, it could render the content inaccessible. If you we're building a hybrid app for just newer iOS or android, this is a nice pattern. Maybe in a future release when CSS support is better, we can look at adding this.
@toddparker OK thank you for your answer.
We just landed this feature in master:
Closing as fixed.
Love this new widget. When I played around with it, I realised that in some cases it woud be great to be able to let the choice of columns be persistent, using cookies probably. There's no option to switch persistence on, so I figured I'd solve it myself using a 'changed'-event on the popup, but this event is not exposed.
Have you given any thoughts to either of these approaches? Hope I am not too late, now that it is in master.
Great work, thnx!
@jaspergrannetia - don't the checkboxes expose a change event?
I'll look into that. Thnx for the tip.