fixed column widths about elm-sortable-table

[MatthiasWinkelmann]

Isn't that something that belongs in the CSS?

[ericgj]

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]

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.

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.