Material-ui: [Table] Body, Header and Footer rendered in separate tables

[rafaelsales]

Problem description

Table header, body and footer rendered in separate tables.

From the source:

<div style={prepareStyles(Object.assign(styles.tableWrapper, wrapperStyle))}>
  {headerTable}
  <div style={prepareStyles(Object.assign(styles.bodyTable, bodyStyle))} ref="tableDiv">
    <table className={className} style={mergedTableStyle} ref="tableBody">
      {inlineHeader}
      {inlineFooter}
      {tBody}
    </table>
  </div>
  {footerTable}
</div>

Versions

• Material-UI: 0.15.0
  

  Description

When setting style for a column of table header and the same exact style is not specified in the corresponding table body column, the appearance breaks.

Rendering the header, body and footer separately loses the ability of letting the browser keep the columns across these sections well aligned.

[nathanmarks]

@mbrookes One might argue that this should actually be the default behaviour

[mbrookes]

@nathanmarks I'm not sure why it was implemented like that in the first place, but I'm sure there's a reasonable explanation.

I thought it might be to do with the fixed header / footer, but I believe that can be achieved without putting them in a separate table.

[zp1112]

how to make column width self-adaption? every column holds the sam width,which make some text long space enough but others lake of space.

[hugocaillard]

I'm pretty sure the implementation is partly responsible of the display bugs in Chrome (also in Canary, Opera etc).

• the size of the TableHeader doesn't adapt to the window width
• the border bottom stay fixed when the content height above the table changes

I wanted to record a demo but the doc is enough and others issues are open. #3957 #3687.

It works fine on Firefox and Safari (testing on OS X).

[rgstephens]

I don't follow the argument that this should be the default behavior. Seems like this should be classified as a bug.

[fzaninotto]

I also don't understand why not using the browser table renderer is considered a feature. Auto-expandable cells based on content is a must IMO. The <Table> component is useless with real content otherwise. I secretly hoped that 0.16 would fix this, but it appears that it doesn't.

For instance, in admin-on-rest, look at how the 'id' column takes too much space and the "post' column is too narrow:

Fixing this requires way too much boilerplate on userland.

Can you explain why this is a feature? If not, can we help fixing the bug?

[danieljuhl]

@fzaninotto I had the same width issue... <Table style={{ tableLayout: 'auto' }} ...> came to the rescue, incase someone else has the same problem. But fixedHeader={false} is required on <Table>, otherwise the columns want be aligned. So <Table style={{ tableLayout: 'auto' }} fixedHeader={false}>

[fzaninotto]

@danieljuhl Thanks, it works! This solves this issue IMO, but it should be documented more prominently.

[danieljuhl]

@fzaninotto I sure agree.. but glad it worked for you.

[oliviertassinari]

We have moved back to a single <table /> structure on the v1-beta branch. We can close.