By settingtable-layout: auto, we get full-width table for wide-format displays (vs. a left-justified, fixed-width table) without squishing columns on narrow-format displays.

table-layout: auto:

table-layout: fixed:

@ellisonbg Thoughts?

Looks great - two question?

1. What if the table wouldn't otherwise take up the full width (only a few cols). Does theauto setting stretch it to full width?
2. What if the table has many many cols? Does this setting try to squish all of them into full width or will it start to scroll horizontally?

Also, in JupyterLab, we are using Material Design colors for everything (in particular the greys). Are we doing that here as well?

• Here's an example of 2 columns and 20 columns respectively:
  
• notebook uses Bootstrap, so we have Bootstrap variables at our disposal. For this PR, I just used the hex for the zebra-stripe color in JupyterLab.
• I updated theborder-width forthead.

Hmm, the 2 cols case in wonky. Unless there is a way to limit the width, let's use the fixed approach that we did in JupyterLab.

Also being a pure style change, we could probably backport this to the next 4.x release...

@Carreau ?

Also being a pure style change, we could probably backport this to the next 4.x release...

-1 on backporting a big visual change to a minor release, even if the change is good.
I like to make the parallel : Visual Design is the API between the screen and the user brain,
and tend to favor consistency over improvement.

It's also, I think, a recipe to get questions during tutorials like "I don't have the same thing how do I get that".
And we've seen that with matplotlib 2.0 which is an easy thing to remember. Style changed on Major versions, which is easy to remember.

That's just a preference though.

+1 for the change otherwise,
myguess is that a well chosen ":hover" on rows can be of great help onwide screen, but that's true from JupyterLab as well.

I would alsostrongly recommend to readthis piece of news

Q: So how do you get people [to upgrade] with urgency?
A: Change the wallpaper.
...
The theory was that [people] will say, "Whoa, this is a big deal," [...]and they will abandon their old and busted build with the horrible bug and install the new hotness.

Ok, I will remove that last commit and I agree about backporting.

@Carreau Sorry, I didn't see your comment! I understand your point about holding off until a major release... According to ourrelease policy, UI changes are reserved for major releases. However, I am comfortable releasing this with 4.3 as it changes a non-interactive UI (vs. something interactive, like the menu or toolbar). Given the Windows blog post, we should save the shiny new table for a rainy day 😋.

Regarding:hover, here's a quick stab at it using a lighter shade of theselected cell indicator color:

I think it's a nice feature to have whether the table is very wide or not.

@ellisonbg What are your thoughts about the hover and backporting given@Carreau's thoughts?

My only concern about waiting for 5.0 is that release may take a while to get out. Two reasons: i) in the past we have planned on doing that at the same time as JupyterLab 1.0 and ii) there have been Ui changes in master that will require a lot of UI/UX/design review and testing.

But in general, I do think that pushing major design changes in point releases isn't great. Would love to get@fperez take on that.

In terms of a hover, I am open to it. But let's merge this PR without it and then play with different hover styles in JupyterLab to see what makes sense.

My only concern about waiting for 5.0 is that release may take a while to get out [...] in the past we have planned on doing that [5.0] at the same time as JupyterLab 1.0

And that's exactly the reason Idon't want to backport. There have been a number of things we said we wouldn't do (like make JupyterLab only an extension) exactly to push notebook 5.0forward.
I also saw that thenotebook_server was forked fromnotebook which IMHO is too early, and one more reason to neglect the current notebook.

Backporting starts to become hard, and I'm in favor of saying that if you want things out, then some cycles of the developers of JupyterLab should be spent on making 5.0 a reality. I don't have much time to help@gnestor and I don't want to bother him more. PLus with 4.x growing and 5.0 on it's way + JupyterLab, the testing of each branch by developer is quasi-null. Which increase the risk of bugs.

Also, for example 4.x doesnot have the ability to order file by date in the dashboard which is well beyond time to release. So while I can't prevent you from backporting things to 4.x, I'm exceptionally going to start putting the strongest -1 on backporting to 4.x until 5.0 is out, starting with this.

In terms of a hover, I am open to it. But let's merge this PR without it and then play with different hover styles in JupyterLab to see what makes sense.

Agreed.

Ok, merging this, if we decide to backport it we can still do it later.

I like the new table style, but is themax-width setting really right?

I havea notebook with an innocuous table in it:

field name | contents-----------|---------left | impulse responses for the left earright | impulse responses for the right earfs | sampling rateapparent_azimuth | directions of sound incidence (in radians)

For comparison, this is how it is rendered right here on Github:

With the new table style, it looks like this:

I don't see a reason for limiting the column width in this case. Without themax-width setting, it looks like this:

I don't think my cell contents are exceedingly wide.
I understand that in some cases the column width has to be limited, but I think in this case it's not the right thing to do. If anything, there should be line breaks, but making part of the content invisible seems strange ...

Should the width probably be limited in auto-generated tables (likepandas data frames) and not limited in handcrafted tables in Markdown cells?

@mgeier the issue is that in the wild it is very common to have tables that have dozens or even hundreds of columns. When that shows up, not having themax-width is really painful.

However, you do make a really good point about tables in markdown. Those are handcrafted and would usually be smaller. I would be fine if we add some conditional CSS to remove the max-width on those. Can you submit a PR or at least open an issue targeted at the 5.0 milestone? Thanks!

Issue on JupyterLab:

jupyterlab/jupyterlab#1436

@ellisonbg Done:#2008

I can't set a target milestone, I've just mentioned it in the text.

Sorry I can't actually implement this, I have too much in my pipeline already.

How can I display tables with the old style? There must be a way to do it...

something has changed, the notebook just became slower for me and less convenient with this new style.

The changes were all made tohttps://github.com/jupyter/notebook/blob/master/notebook/static/notebook/less/renderedhtml.less in#1776. To switch back to old styles, you can manually edit this file or if you're running from a clone of this repo, just revert the commit in#1776.

We are open to suggestions as to how to improve the table style 👍