These are handled in the same way as long variable names, they truncate with an ellipsis and then expand on hover.

Oh yes I missed it.

Actually, no that's totally out of date now haha. Thanks for reminding me I should update that

edit: realized I should have said what I'm actually using - I'm using this:https://jupyterbook.org/features/page.html

Besides variable names, we probably need to somehow handle overflow for variables that have a long list of dimension labels.

These are handled in the same way as long variable names, they truncate with an ellipsis and then expand on hover.

I opened a PR and included a small test. It can probably go in while we work on a more complete testing infrastructure.

To verify proper escaping, we could validate the generated HTML as XML: https://stackoverflow.com/questions/13742538/how-to-validate-xml-using-python-without-third-party-libs

This could be a good use case for Hypothesis. Or you could manually build a dataset with variables of every dtype.

I looks like we'll need to fix a couple of issues (the channel coordinate looks weird), but maybe it is not related to the front-end.

I am opening a PR. I didn't escape dtypes and this dtype is <U5 which html does terribly with

Cool!

I guess this post about how you use notebooks in your blog is still up to date?

I looks like we'll need to fix a couple of issues (the channel coordinate looks weird), but maybe it is not related to the front-end.

Besides variable names, we probably need to somehow handle overflow for variables that have a long list of dimension labels.

this is awesome! I was so excited about it that I updated my little blog post with the latest xarray master https://predictablynoisy.com/xarray-explore-ieeg

I was a little sad at the gigantic repr that came out of my DataArray, and now it is nice and tidy html!

Thanks @jsignell (and all). I'm really jazzed about this.

Thanks a lot @jsignell ! It is great to see this merged finally!

Should we expand the .data section of the DataArray HTML repr by default? That would look a little more consistent with the text repr.

Awesome. Thanks @jsignell Let's leave dark theme compatibility for a future PR.

It isn't too hard to get it working with dark theme, but requires slight tweaks to the colors to align with those provided as vars by jlab.

Yes it looks nice!

Ok I think it's fixed now

Hello @jsignell! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers:

Comment last updated at 2019-10-24 15:59:14 UTC

I'm on 1.1.4 in chrome. Let me check firefox

Mmm this still looks weird on my side:

Which version of jupyterlab are you using?

Yeah to make it work with the dark theme we'll need to use the jlab css variables I imagine. I think it can be merged with dark mode not supported.

Fixed the jlab alignment issue. The issue was that jlab has different default css.

+1 for merging this turned off by default, with a plan to switch it on once we're tested it on more datasets and platforms

On Thu, Oct 24, 2019 at 8:27 AM Deepak Cherian notifications@github.com wrote:

@dcherian commented on this pull request.

In xarray/core/options.py https://github.com/pydata/xarray/pull/3425#discussion_r338641677:

@@ -98,6 +102,9 @@ class set_options:

   attrs, ``False`` to always discard them, or ``'default'`` to use original

   logic that attrs should only be kept in unambiguous circumstances.

   Default: ``'default'``.

• • display_style: display style to use in jupyter for xarray objects.

• Default: classic. Other options are html.

⬇️ Suggested change

• Default: classic. Other options are html.

• Default: 'text'. Other options are 'html'.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/pull/3425?email_source=notifications&email_token=AAJJFVQMQKGXPGUFEMZ3ZRTQQG5HNA5CNFSM4JDFFVJKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCJDVXPI#pullrequestreview-306666429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJJFVWYZ27FZ76RZ422M4LQQG5HNANCNFSM4JDFFVJA .

I've noticed an issue with the alignment of attributes in jupyterlab (1.1.4) (Firefox 69.0.3):

I'm taking a look at the jlab css.

I'd would rather wait before turning on html display by default. I'd be fine doing so on the next major release if until then we make sure that the rendering will look reasonably good in most front-end situations.

For example, it will really need better integration with jupyterlab dark themes (see below) and would potentially cause issues elsewhere too (nbsphinx, etc.). But we should probably figure that out after this PR is merged.

I've noticed an issue with the alignment of attributes in jupyterlab (1.1.4) (Firefox 69.0.3):

It looks good in the classic notebook.

I would be fine having this be on by default now. Or, we could keep it off until the next major release (0.15).

@benbovy just to make double sure, you are happy with this new feature being off by default right?

So maybe one more rebase will do it?

nope, it still fails. However, that failure is definitely not related to this PR (it fails to install because the referenced PR in cftime was merged in the meantime).

Well, I rebased. Hopefully it'll pass now. I consider this done unless someone wants more docs or more tests.

I am 90% sure this failure is unrelated. Maybe I should rebase now that #3436 has landed?

Oh. The dask version in ci doesn't have _repr_html_. I'll add a version checker to the test.

Otherwise I think all that is left is adding docs. Also I want to confirm that this should be an experimental feature (off by default).

I added some tests. I can add more if anyone has a test case that they want to be sure is covered.

Or maybe "text" and "html"?

Hopefully "html" will eventually become the classic display :)

Ok I am going to write some tests now. I updated the gist. Do people like the names "classic" and "html" for the display_style options? Another option would be "classic" and "rich".

~~Oh I was looking at bytes not len.~~ I didn't have .encode('utf8')

It looks like the html_repr for rasm is 38kb .

How are you measuring this?

I see: ```

len(rasm.repr_html().encode('utf8')) 19624 ```

I'm still worried about size, but minifying the css and even minifying the html did not make a big difference. It looks like the html_repr for rasm is 38kb .

Here's what we're currently looking at!

Codecov Report

Merging #3425 into master will decrease coverage by 1.09%. The diff coverage is 23.12%.

```diff @@ Coverage Diff @@

master #3425 +/-

========================================= - Coverage 96.16% 95.06% -1.1%
========================================= Files 65 66 +1
Lines 13436 13587 +151
========================================= - Hits 12921 12917 -4
- Misses 515 670 +155 ```

| Impacted Files | Coverage Δ | | |---|---|---| | xarray/core/options.py | 97.91% <100%> (+0.09%) | :arrow_up: | | xarray/core/dataset.py | 95.89% <20%> (-0.23%) | :arrow_down: | | xarray/core/formatting_html.py | 21.05% <21.05%> (ø) | | | xarray/core/common.py | 91.92% <42.85%> (-1.29%) | :arrow_down: | | xarray/convert.py | 100% <0%> (ø) | :arrow_up: | | xarray/plot/facetgrid.py | 96.73% <0%> (ø) | :arrow_up: | | xarray/plot/plot.py | 96.38% <0%> (ø) | :arrow_up: | | xarray/backends/rasterio_.py | 96.85% <0%> (ø) | :arrow_up: | | xarray/plot/utils.py | 97.74% <0%> (ø) | :arrow_up: | | xarray/core/resample_cftime.py | 91.48% <0%> (ø) | :arrow_up: | | ... and 37 more | |

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update b0c336f...3a9edae. Read the comment docs.

We probably should be careful to use html.escape() pervasively to protect against malformed data. We can trust user code, but probably should not trust all data -- it should be safe to load and view arbitrary netCDF files in xarray.

I just gave this a try in Chrome / Google Colab. It's looking great!

Here's the rasm dataset. It weighs in at exactly 20 KB!

The alignment of "Dimensions" line does looks a little off -- would that be easy to fix?

There's also a strange alignment thing with the three circle icon in array repr, which maybe could be moved to the right side?

The css is now ~300 lines and it gets injected everytime the dataset is rendered. I'm not sure if that is considered too long and if it is I don't quite know what to do about it.

You could consider running the CSS through some sort of preprocessing tool to minify it, e.g., to remove all the spaces. But my guess is that it's probably fine.

It would be informative to measure the size of the output HTML encoded as UTF-8 bytes for some example datasets. For context, a simple line chart from matplotlib is ~20 KB when saved as a PNG image. Anything in that ball-park would be OK, up to perhaps a few hundred KB for really big datasets with lots of variables.

Ok I think I've addressed all the comments. I just updated the gist with the latest output. Tomorrow I'll start adding tests. The css is now ~300 lines and it gets injected everytime the dataset is rendered. I'm not sure if that is considered too long and if it is I don't quite know what to do about it.

Is there ever a situation in which dimensions would be expandable? It seems like it is hard-coded to collapsed.

I don't think it would ever be expanded. The collapsed icon is just there for visual consistency.

Is there ever a situation in which dimensions would be expandable? It seems like it is hard-coded to collapsed.

I am trying to generalize the css to reduce the length.

I just updated the gist with these changes: - got rid of alternating data colors in preview - fixed icon alignment in row, and rest of data in row - got rid of some not-useful spans - changed from underline to bold for index coords

Yeah the data preview is also shifted vertically.

Just one small issue in the gist with the vertical alignment within a variable row, and the height of the icon container (I'm using Firefox):

This is really nice @jsignell !

I'd really like to hear back from @benbovy about whether the fiddle css is more uptodate.

We did a lot of experiments, even some after starting the implementation in #1820, so I admit this is quite messy. I also did some clean-up and tweaks directly in that PR, so unfortunately there is no fiddle of reference that exactly corresponds to what's in here. Sorry for that!

The html/css in this PR is the cleanest one, I think.

The latest fiddles (for Dataset) are these two ones:

• https://jsfiddle.net/Lmqq7yzz/9/
• https://jsfiddle.net/1g04ykum/ (@shoyer's try for handling long variable names)

the only thing that looks funny to me is the alternating black-gray text coloring

In the HTML repr, the width of the space character is less large that for the monospace font used in the text repr, so I originally used this trick to better distinguish between the values in the inline data repr. Now that each value is encapsulated in it's own span, we could tweak the padding instead (or both... I don't have strong opinion on this).

This looks fantastic! Really great to have you working on this!

Some specific feedback:

1. Yes, I agree it would be nice to align the Attributes text, maybe this could make use of an HTML table?
2. Maybe bold would look better than underline for coordinates that are dimensions? I find the underline makes text a little hard to read. Happy to leave this up to you, though.
3. On my Ubuntu desktop, the "+" icon is bright yellow, which I'm guessing is not what was intended. Maybe it would better to stick with the three circle "data" icon?
4. What happens if there is a really long variable name? I had a version of the jsfiddle that expanded names when you hovered over them.

Julia, it's fantastic to see you working on this! Thanks so much!

Yeah I agree that is a strange part of the original PR. The version in the fiddle doesn't do that, so I'd really like to hear back from @benbovy about whether the fiddle css is more uptodate.

Honestly this is looking super good and ready to merge already!

Thanks @jsignell

The only thing that looks funny to me is the alternating black-gray text coloring below:

I don't really like how the attrs look without the alignment of keys and values. I will think about how to make that more legible