*Summary*
Currently, CellTable resizes naturally based on its content, which usually isn't the desired behavior. Columns change widths on each page based on the new contents, which looks bad when paging through a table. When clicking on a Cell to go into edit mode, the Column will resize to fit the editable input. We need to give users more control over the column width. Both of these issues can be seen in the Showcase sample (try paging and clicking on somebody's first name). http://gwt.google.com/samples/Showcase/Showcase.html#!CwCellTable Technical Details There is one cross-browser approach that allows users to specify a width for some or all columns and still lets the table resize naturally in a predictable way: - Set the table-layout to fixed - Set the table width to 100% (optional) - Set the width of some or all columns using the col tag The following native behaviors are consistent across all browsers. In all cases, the default behavior works very well. - If the widths of all columns are set, the width becomes a weight and the columns are resized proportionally - If the widths of some columns are set, those columns are fixed and the remaining width is divided evenly over the other columns - This allows one or more columns to take the remaining width - This also means that the width is divided consistently, not based on the content - If the table's width is too narrow to fit the specified column widths, the table will overflow - The width in the col tag is basically the hard minimum width - Columns that do not have widths are invisible if their is no room for them We also want to support a table with a width other than 100% (ex. no width specified or a fixed pixel size). However, if the table width is not specific and table-layout is fixed, columns are 0px wide (invisible) by default, which is not a good default use case. In practice, we must do at least one of the following for columns to be visible: - Set the table width to 100% (or some other size) - Set the width of all columns Proposal Column Widths I propose that we add an interface ColumnWidths that returns the desired width of the specified column. The default implementation will have a map of Column objects to the desired width. CellTable will have a method to setColumnWidths(ColumnWidths). This works for both fixed layout and non-fixed layout (normal) CellTables. interface ColumnWidths { /** * Get the desired width of the specified column. * * @param index the index of the column * @param column the Column * @return the width as a string (ex. 200px) */ String getColumnWidth(int index, Column<?,?> column); } class DefaultColumnWidths { void clearColumnWidth(Column column) { map.remove(column); } String getColumnWidth(int index, Column<?,?> column) { return map.contains(column) ? map.get(column) : null; } void setColumnWidth(Column column, int width, Unit unit) { map.put(column, width + unit.getType()); } } class CellTable { ... // Update the column widths. *void refreshColumnWidths();* // Set the column widths. void setColumnWidths(ColumnWidths); ... } Users can use the DefaultColumnWidths implementation, or they can implement their own version. For example, a user defined ContentColumnWidths could base the column width on the content in the table. This approach ties the column width to the view, not to the Column itself, so users can use different widths for mobile and desktop views. Fixed Layout In addition, we need a way to set the table layout to fixed instead of the default of auto. The main difference is that with "auto" layout, a column will never truncate contents; it will expand as needed, even exceeding the specified width. With "fixed" layout, the content will be truncated. Also, if the table width's is set with auto layout, the column sizes are based on the content and are unpredictable. Auto layout is useful when the table data is static (or at least does not page). Fixed layout is preferred when paging, or when you don't want the column width to change automatically every time the content changes. Fixed: truncate cells, divide extra table width evently over columns (predictable) Auto: never truncate cells, divide extra table width based on cell contents (unpredictable) Most users will want a fixed table layout so the specified column widths are taken as more than suggestions, but they may not know that because its an obscure DOM style property. I propose that we add overrides to setColumnWidths() that take a boolean to indicate fixed/auto table layout and a table width parameter. The default method will set the table layout to fixed. NOTE: If we just add a simple boolean setter to toggle between fixed/auto layout, users may not discover it and wonder why their ColumnWidths don't work as expected. class CellTable { ... // Set the column widths and set table layout to fixed, but don't change the table width. void setColumnWidths(ColumnWidths); // Set the column widths and table layout, but don't change the table width. void setColumnWidths(ColumnWidths, boolean isFixed); // Set the column widths, table layout, and table width void setColumnWidths(ColumnWidths, boolean isFixed, String width); // Set the column widths, table layout, and table width void setColumnWidths(ColumnWidths, boolean isFixed, int width, Unit unit); ... } ScrollingThe next feature to add to CellTable is a scrolling content area with a fixed header and footer. This proposal works because we can separate the header/data/footer tables into three seperate tables and still line them up reliably. Unsupported FeaturesMaximum Size We will not support a maximum size on columns because not all browsers support the max-width style attribute. Mix Fixed and Proportional Distribution In the proposal above, you can fix the width of some columns and distribute the remaining width equally over the remaining columns, but you cannot distribute the remaining width proportionally. This isn't natively supported and would require active layout, which isn't worth the performance cost. Users could implement a version of ColumnWidths that supported this by providing new ColumnWidths every time the table is resized. User Resizeable Columns Under the above proposal, we will not support user resizable columns where the user can click and pull a column header to change its width. The calculations that PagingScrollTable use to support this requires the user to specify the width in pixels (the above proposal allows relative sizes) and requires expensive active layout that causes performance issues. It should still be possible for users to build on top of the above proposal, but it isn't a feature we plan to add to CellTable. Thanks, John LaBanca [email protected] -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
