Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tables probably shouldn't default to fixed width #2374

Closed
evilnick opened this issue Jun 7, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@evilnick
Copy link

commented Jun 7, 2019

I'm not sure if this is baked in to the style or part of the implementation where we use it, but using table-layout: fixed; doesn't produce great results for all but the simplest of tables (and even then has limitations).

Using a fixed width for the columns:

  • doesn't aid legibility
  • often causes table data to run over more lines than it should
  • is inefficient at using space (especially in reactive)
  • in extreme cases causes avoidable rendering errors

An example:

tables-001

This table pretty much illustrates all of the problems mentioned above. However, with standard, flexible column widths it becomes more readable, more efficient and less broken

tables-002

Yes, we can still try harder to make things in tables less wordy, but still a huge improvement

@lyubomir-popov

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2019

@evilnick table-layout: fixed is indeed baked into the 'base' css of vanilla. The reasons for this are:

• it makes styling tables a lot more predictable (a couple of articles on the subject - 1, 2 )

• it is faster. From mdn:

Under the "fixed" layout method, the entire table can be rendered once the first table row has been downloaded and analyzed. This can speed up rendering time over the "automatic" layout method, but subsequent cell content might not fit in the column widths provided. Cells use the overflow property to determine whether to clip any overflowing content, but only if the table has a known width; otherwise, they won't overflow the cells.

• it is particularly well suited to achieving very complex responsive behaviours. Two examples from maas:

  • the simple disk partitions table
  • the more complex, responsive machines table, which hides /adjusts column widths on multiple breakpoints, in order to to best fit the available space

• in a paginated or virtualised scroll table (as in maas), it ensures table columns don't change widths as new content replaces the initial content

To resolve all of the issues you mention, you just need to set widths on the <th>'s or <td>'s in the table's first row. You can do this in two ways:

• use grid column classes (the quick and dirty approach)
• use a css snippet, as in the disk partitions example above

Would any of these work for you? Or do you need a solution that doesn't require writing any css? If that's the case, maybe we can add a utility class or local docs css that overrides the table-layout property.

@evilnick

This comment has been minimized.

Copy link
Author

commented Jun 13, 2019

I appreciate you looking into this, and providing the rationale behind it. I do think however that most of those advantages are mostly for UI design, rather than readability of the content, particularly in a docs context where we are dealing with static content.
It is easy in some circumstances to insert a CSS snippet into our markdown to make this work better, but in the more general case, where docs are generated through discourse it is more difficult. The idea there is to make it discourse friendly and easier for more casual contributions, and it would be a bit unreasonable to expect those contributors to meddle with CSS in their posts. So I think a more general, docs-specific CSS would work better overall.

@pmatulis @degville any thoughts?

@lyubomir-popov

This comment has been minimized.

Copy link
Contributor

commented Jun 13, 2019

@evilnick good point about automatic conversions and casual contributors. I've made a pr that allows you to configure the default using variable $table-layout.

In addition, I've added a utility to override this:
• If $table-layout is set to 'fixed' (still the default), you can use 'u-table-layout--auto' to override it.
• if $table-layout is set to 'auto' (or anything else like 'inherit' etc) it adds a utility called 'u-table-layout--fixed'.

This is so regardless of the default, you still have access to the other option for special cases.

@evilnick

This comment has been minimized.

Copy link
Author

commented Jun 14, 2019

That's great, thanks!

@lyubomir-popov

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

@evilnick just a heads up, after some back and forth on the pr the name of the setting changed to $table-layout-fixed (values true | false)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.