At this point, I have been working on FactView for a while and I have learned a
great deal more about web applications, particularly in the display of
information from a database of some type. I have also dealt with some browser
compatibility problems that have made the goal of consistent layout a difficult
one. In the end, I solved that by just making sure that there was an elegant
fallback for older browsers. Today, though, I am going to talk about Tables.
In displaying the data in FactView, I opted to use tables, since the data is
pretty much doing selected dumps of information from the database. When having a
large dataset, though, it is helpful to have some form of manipulation for it as
well as being able to see as much information as possible while still allowing
easy access to other functions of the application. Unfortunately, this is
something that is not supported under any current HTML specification, which to
me does not make much sense. Manipulating tables in this way has to be one of
the most common functions applied to tables. Now, I know that some will argue
that interactive elements are outside the scope of what HTML is supposed to be
able to do, that sorting and filtering require manipulation of nodes in the DOM.
Of course, you would be correct, but with all of the elements introduced in
HTML5, I do not think it is such a stretch to include functionality like this.
To enable sorting on my tables, I found a JQuery plugin called TableSorter.
This script was very robust in how it sorted data, sorting a column of all
numbers as integers, sorting a date column in chronological order, and strings
in alphabetical order, as you would expect. Other sorting methods that I looked
at were not able to give consideration to the type of data being sorted (so 11
might be sorted before 1).
The only problem I ran into with it was that it gave no consideration for child
rows. In some of the data tables that I was displaying, there were rows that
were associated with the row above them and contained a subtable with
information relating to the element in the parent row. The visibility of these
rows was toggled with a button in the parent row that changed the CSS to include
display: none for the child row. TableSorter did not include any way to
indicate the parent-child relationship and as such, sorted the child rows in
with the parent rows. I then found a modified version of TableSorter
that included support for child rows by allowing you to declare a class that
designated a row as a child row. Sorting then skipped that row so that it would
be kept with its parent.
Other table manipulations did not prove to be so easy. First, I tried to find a
script that created floating headers such that header row of the table is always
visible, even when the table is scrolled down. In this way, large data sets are
more readable. Unfortunately, the prevailing technique for doing this is to make
a new "fake" header on top of the real one that is positioned absolutely so that
it is always at the top of the table. This would work ok, if not for the
TableSorter script. The new floating header prevents the user from clicking on
the real header, which is how TableSorter worked. Other JavaScript table
frameworks seem to have a similar problem. While I can get filtering or sorting
or floating headers, I cannot seem to find a combination of scripts that works
together correctly. Hopefully, this sort of thing will be added to the next
iteration of HTML.