#theme Form elements into tables

The improvement is very obvious with long lists of checkboxes like the module selection of the coder module. However, for shorter forms like role selections with just 4 roles, the stripes on the table really make it look like there is a correspondance between items in the same row, which is not the case.

Whether this is implemented as a table or with CSS, I would remove the stripes. Otherwise, +1 for this feature.

I don't think there are currently enough use cases in core for this UI pattern yet. It's difficult to implement effectively in generalized ocntexts, because the length of each item might be more thant 33% of the width of the container, meaning that they would wrap oddly and perhaps disorientate the user. Or perhaps not fit at all resulting in ugly overlaps.

Further, tables are not the semantic element for this, so IMO a CSS layout is necessary. A CSS layout also deals with the above issue in a more flexible way than a table can.

I agree with flubruit about the zebra stripes; It messes up the grouping; We don't want users thinking the first three items are related to each other any more than they are related to the three items on the next row.

I do think the idea makes sense in coder and possibly other places, like selecting taxonomy terms from a medium-sized vocabulary.

I am in support of this feature. As I said in the linked feature it's better to support this specialized case which is used often than trying to support the whole table thing. Converting a core form or two would be good to see how the API is used / works / etc

Good point on the code in core that is not used by core.

I don't think theme_table should be removed. Semantically, tables should be used for tabular data like admin/content/node or the user permissions page, where everything in the same row has something in common, everything in the same column has something in common, and things in different rows and columns to not have those things in common.

The unsemantic use of tables also makes it less accessible and usable for users without mice, text readers and screen readers. Correct semantic use of tables (i.e. tables for tabular data) does not become less accessible; instead it makes it tabular data MORE accessible for users without mice, text readers and screen readers.

I would go for no stripes here, since they would serve no purpose; the elements in the table are not logically groupable, so stripes won't help the user understand what to do or how to read the elements. Horizontal stripes are really only useful in large tables, and only because English (and most languages) are read and aligned horizontally (rtl or ltr, as opposed to top-to-bottom), so finding the vertical separation / grouping can be difficult in large datasets with no horizontal separators (e.g. stripes).

See: #335122: Test clean HEAD after every commit and http://pastebin.ca/1258476

I think this needs an implementation in core before it can be reviewed properly, either that or a simpletest, or both.

tagging

I've created a patch that can put a form into a table. It is available here: http://drupal.org/node/528932

This thread is a duplicate of http://drupal.org/node/80855 (Make theme_table() renderable array compliant). Suggest one looks there for further discussion.

Sorry, this should probably be flagged as a dup.

theme_col.patch queued for re-testing.