##A Call for Ideas
I did not mean for this to be so long, but I am asking for ideas.
I was sort of following another thread about styling table elements when I thought that I would refresh myself on how Freeway handles data tables, being this is the age of html5 and semantics, and that I have now spent quite some time writing such tables by hand and then inserting them into Freeway as Markup Items.
I don’t think my standards are onerous-- all that I really require from a data table is that it (1) follow some basic rules for html semantics (yes, data tables are semantic structures) and (2) that they can be styled in the same css ways as the rest of Freeway allows. Unfortunately, Freeway tables still don’t meet these two criteria.
Like page sections, html5 data tables can be sectioned as well. You have the
<thead> section-- for a row of header cells, the
<tbody> section-- for rows of data cells, and the
<tfoot> section, for footer content.
The problem begins with Freeway only supporting the
tbody section of tables. While you can indicate a row of cells as a “header”, Freeway writes that row of header cells (
<th>) into the
tbody section, thus failing the basic semantic structure.
All three sections aren’t necessary for every table… but if the user indicates a header row, then that row needs to be in a
thead element is all I’m saying. The ability to also designate a
tfoot row-- while maybe not an earth-shattering feature-- is also not a step too far in helping users to build rich and meaningful websites.
Another missing obvious semantic element is the table
<caption> element. This is useful for a short but descriptive title for the table. Currently, I can insert it as code into the row Markup of the Inspector, but I think Freeway could do a better job of it.
Another very useful semantic table tool is the
summary table attribute. Think of it as the
alt tag for tables. Currently, it can be manually added via a table’s Extended Style feature.
###Table Styles equals Inline Styles
When you apply any styling to any part of your Freeway data table, the only position Freeway will generate css styles for it are on the inline style attribute… of each and every element. Not that there’s anything invalid about css code in the inline position, but seriously… why would anyone write code that way as a matter of practice? A hundred table cells, each individually coded exactly the same is a crime towards css.
Then there’s the whole fixed measurement thing… tables and table elements can be described in much the same way we are now describing
divs or html elements, yet Freeway is still stuck with fixed non-zero numbers. Coupled with inline styles, and users are stuck with the worst case scenario. No wonder I switched to writing tables by hand. (Not to mention forms).
###Paragraphia, or insanity of the p tag
This is probably one of those topics that will be debated until the end of time, but I am of the opinion that a table cell is no place for a paragraph. If it takes a paragraph to describe the data, then it ceases to be tabular data and the table becomes a layout device.
##What to Do About it?
Okay, I’ve outlined the problem and vented a bit (thank you). Here’s what I tried and the code it produced…
###Semantic Table Action
This action does a simple but terrific job of creating the
tfoot elements when needed, even placing the Freeway row of header cells in the right place. Optionally, it can also remove the auto-paragraph tags from the cell structures. The only thing it doesn’t get right is the position of the
tfoot element in the resulting code-- I think the specs have changed on that since Walter made this action. But as long as I don’t need the table footer, everything else works just fine.
###Remove Dimensions Action
Since I had efficient Tag styles set up to handle my table’s appearance, all I needed was a way to remove the “default” inline table cell styles-- cell width, cell height and vertical text alignment. The most successful action for this was the Use External Stylesheet Action, which I already use to establish the reset.css for the page. Ticking the box labeled “Delete Embedded Styles” removed the inline table styles, but also nuked any other styles deliberately left in a valid position. Too heavy handed for me.
So I turned to the Remove Dimensions action, which I’ve used on
img elements previously. It was localized to the table styles and worked great, considering it only affects the height and width style properties. The remaining
vertical-align style property was removed from the inline position then rewritten to an external sheet, adding an
id attribute in its place. So, one gob of code mess gets exchanged for a different gob of code mess, still not an ideal replacement for handwritten tables in my opinion.
But if anyone has a better idea out there, I’d love to hear it. Here’s an example of how I wish the finished code would look–
freewaytalk mailing list
Update your subscriptions at: