Compat with jupyter's new HTML table style #15379

Closed
jorisvandenbossche opened this Issue Feb 12, 2017 · 15 comments

Comments

Projects
None yet
3 participants

See also discussion in jupyterlab/jupyterlab#961

With the upcoming notebook 5.0 release and in current jupyterlab, jupyter has a new (much better!) default HTML table styling. The only problem is that it fixes the width of columns hardcoded at 150 px.

IMO this is a problem. Not the default as such, but the fact that you cannot easily change this when you want to see long table content. The result is that when having cells/column names with long content (and sometimes you deliberately create such cells/column names), it is impossible to inspect those data with the default repr.
Only solutions are to inspect specifics such as df.values or df.columns.

Another consequence is that the pd.options.display.max_colwidth option becomes useless.

Possible way forward:

  • override the max-width for our html repr's to set it to 'none' (@TomAugspurger shows here that this is possible: jupyterlab/jupyterlab#961 (comment))
  • if we like the more narrow default, we can always decrease the default for pd.options.display.max_colwidth (currently 50 chars) at the same time. The the default looks similar to jupyter's one, but you have still the ability to adjust it with our options.

jorisvandenbossche added this to the 0.20.0 milestone Feb 12, 2017

The overriding can be done by adding the following style to each _repr_html_:

<style type="text/css">
  table.dataframe td, table.dataframe th {
    max-width: none;
  }
</style>

Other options could be:

  • see all data on hover
  • wrap longer cells

Another issue is that, IMO, we should keep some kind of wrapping long text in multiple lines, see eg the notebook here: http://nbviewer.jupyter.org/gist/epifanio/e82443b79c24ceb2d59ba49cad9a62d4 (from gitter).
Even if you can use pd.options.display.max_colwidth to set it to a really high number eg 1000, this is only useful if the long text is wrapped over multiple lines, and not on one gigantic line (as you would get with current jupyterlab/notebook master.

In the meantime, my proposal to remove the max-width in jupyter has been accepted, so we can close this issue!

We can still adjust our pd.options.display.max_colwidth default value of 50 if people like the less wide default look of the tables. (cc @TomAugspurger)

@jorisvandenbossche jorisvandenbossche modified the milestone: No action, 0.20.0 Feb 27, 2017

Reopening this because there are some other issues we have to think about as well. What I encountered now are the display of MultiIndexes:

Due to the right-alignment instead of left alignment, multi-indexed columns get a bit strange:

screenshot from 2017-02-28 16-07-58

Also multi-indexer rows are not ideal because the distinction between the levels is not always clear (the borders are gone, but the shading does not always differ depending on the number of rows in the level).

In this case, that is OK:

screenshot from 2017-02-28 16-08-18

But in the following the shading is the same (and certainly when having more rows in one level label, or different number of rows for different labels, it becomes difficult to see the border between the level labels):

screenshot from 2017-02-28 16-09-01

Contributor

TomAugspurger commented Feb 28, 2017

Good catch. Would we be better of vertical-aligning the row MultiIndex? We'll also want to check the interaction with index-level names (I'm getting caught up on things, should have more time to look myself towards the end of the week).

Level names are generally OK I think, see for example:

screenshot from 2017-02-28 16-55-33

The question is a bit if there is a general solution that improves this that we can propose to jupyter, or whether we try to solve this on the pandas side with some custom formatting.

Owner

jorisvandenbossche commented Feb 28, 2017 edited

For the row multi-index, vertical alignment to the top seems better:

screenshot from 2017-02-28 17-00-34

The strange thing is that I see <th rowspan="3" valign="top">A</th> for that row header, so we already included the notion that we want it to align at the top, only that does not seem to work.
-> EDIT: "The valign attribute of <th> is not supported in HTML5. Use CSS instead." So we could replace that with <th style="vertical-align:top"> if we only want to fix it specifically for the multi-index

I s there any option to disable the default styling .. basically i want to roll back to previous default settings..

Contributor

TomAugspurger commented Apr 13, 2017

For the MultiIndex issues (from the above comments), I opened an issue on the jupyter side: jupyter/notebook#2408 (and ideas what would be the best solution for the multi-indexed columns is also welcome ..)

@jorisvandenbossche jorisvandenbossche modified the milestone: 0.20.0, No action Apr 16, 2017

@TomAugspurger any ideas what we could do for the multi-index columns?
Easiest would be to switch back to left-alignment instead of right-alignment, but that would be a pity for normal frames without multi-index

Contributor

TomAugspurger commented Apr 18, 2017

@TomAugspurger any ideas what we could do for the multi-index columns?

Looking now. I think we'll need to adjust the generated HTML to add some classes to the ths in a MI.

Contributor

TomAugspurger commented Apr 18, 2017

I think if we left-align any levels, then we have to do them all.

screen shot 2017-04-18 at 6 25 58 am

Contributor

TomAugspurger commented Apr 18, 2017

This isn't too bad:

screen shot 2017-04-18 at 6 57 23 am

I'm going to play around with borders to see how that looks with right-alignment.

Contributor

TomAugspurger commented Apr 21, 2017

OK, putting together a PR now. Here's an example notebook comparing master and the PR https://gist.github.com/79f032afa4e498f86a9d59905d0f6fbd
You'll have to download it since nbviewer doesn't have the new styling.

Changes:

  1. MultiIndex column headers are all left-aligned (this is only for MI, single-level column headers are still right-aligned)
  2. MuliIndex row labels are top top-aligned

screen shot 2017-04-20 at 9 41 53 pm
screen shot 2017-04-20 at 9 41 59 pm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment