Skip to content
This repository has been archived by the owner on Sep 6, 2018. It is now read-only.

fixed column widths #12

Open
ericgj opened this issue Dec 4, 2016 · 4 comments
Open

fixed column widths #12

ericgj opened this issue Dec 4, 2016 · 4 comments

Comments

@ericgj
Copy link

ericgj commented Dec 4, 2016

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.

@MatthiasWinkelmann
Copy link
Contributor

Isn't that something that belongs in the CSS?

@ericgj
Copy link
Author

ericgj commented Dec 7, 2016

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
Copy link
Author

ericgj commented Dec 7, 2016

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.

@ghost
Copy link

ghost commented Feb 9, 2017

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.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants