issue_comments

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

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.

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.

Yes it looks nice!

Mmm this still looks weird on my side:

Which version of jupyterlab are you using?

+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'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).

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).

Or maybe "text" and "html"?

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

It looks like the html_repr for rasm is 38kb .

How are you measuring this?

I see: ```

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

Here's what we're currently looking at!

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.

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.

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!

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: