elm-sortable-table icon indicating copy to clipboard operation
elm-sortable-table copied to clipboard

fixed column widths

Open ericgj opened this issue 9 years ago • 4 comments

HTML table columns are a pain, as we all know. The default is they expand to fill the content, regardless of width styling. This is often not what we want. The recommendations for fixing column widths that I could find (and here and there) recommend setting table-layout: fixed, and that

If you change this to fixed, the table and column widths are set by the widths of table and col elements or by the width of the first row of cells.

Emphasis mine. Here is the dilemma: the first row of cells is thead > tr > th, and customizing those cells is difficult in this library. (It's easy enough to set widths of the tbody row cells, but the browser ignores these.) Essentially, it is impossible to set fixed column widths using this library without overriding your config.customizations.thead function. And yet, it does seem like this is a basic feature that should be supported without quite so much pain.

My thought for an interface is

myConfig =
    Table.configWithWidths
        { toId = .id
        , toMsg = SetTableState
        , columns = 
            [ (myColumn1, "25%"), (myColumn2, "15%"), (myColumn3, "60%")
            ]
        }

where:

configWithWidths : 
    { toId : data -> String
    , toMsg : State -> msg
    , columns : List (Column data msg, String)
    } 
    -> Config data msg

and then threading that through a customizations.thead function that sets the width on the th elements. (Or instead of untyped widths, have unit types for px, %, em, etc. similar to elm-css.)

What do you think?

EDIT: I'd be happy to open a PR. I have it working externally.

ericgj avatar Dec 04 '16 23:12 ericgj

Isn't that something that belongs in the CSS?

KarlAmort avatar Dec 07 '16 06:12 KarlAmort

In my opinion, no. But even if you do want to put it there, you run into the problem that it's hard to write CSS rules to apply to particular header cells, since they aren't classed or otherwise distinguished. You end up with rules like .my-table thead > tr > th:nth-child(0){ } , .my-table thead > tr > th:nth-child(1){ }, etc., which is then of course very annoying when you want to insert or move columns around.

ericgj avatar Dec 07 '16 13:12 ericgj

In other words the underlying issue is how to set attributes on the header cells without having to override the default thead function? This is just a motivating case for that.

A generic solution might be to change the Config type to

type Config data msg : 
    Config
        { toId : data -> String
        , toMsg : State -> msg
        , columns : List (Column data msg, List (Attribute msg))
        , customizations : Customizations data msg
        } 

and passing a list of attributes down to the customizations.thead function instead of just the onClick (i.e., the onClick plus the constant attributes supplied by config):

type alias Customizations data msg =
  { tableAttrs : List (Attribute msg)
  , caption : Maybe (HtmlDetails msg)
  , thead : List (String, Status, List (Attribute msg)) -> HtmlDetails msg
  , tfoot : Maybe (HtmlDetails msg)
  , tbodyAttrs : List (Attribute msg)
  , rowAttrs : data -> List (Attribute msg)
  }

Then the public API wouldn't have to change, besides the signature of the thead function, which is pretty low-level anyway.

ericgj avatar Dec 07 '16 17:12 ericgj

Having the same problem. Setting attributes to header cells is a very, very common use case.

Every function that returns a column should take a list f attributes to apply to its th.

ghost avatar Feb 09 '17 23:02 ghost