CSS should be more consistent with "classical" JLab for now

[fperez]

trafficstars

Describe the bug

context

Since this is a new renderer that we'll want to get buy-in from the community for, my suggestion would be to first keep the CSS/layout changes to an absolute minimum, focusing only on implementing support for new features of MyST that extend beyond what the default renderer offers.

Only once we reach parity on all core features + support for the unique MyST ones, should we explore in earnest modifications to the rendering behavior.

bug

These aren't strictly bugs, but I will list them here for starters. I'm happy to track this elsewhere/differently if it better fits the team! In all these screenshots, the left shows the "classic" JupyterLab renderer, with the mystjs 0.1.3 renderer on the right. Both are using JLab 3.6.1.

• Code cells use a different/smaller font.

• Missing outline around active cell.

• Too much vertical space used. I think it's mostly due to extra vertical whitespace around headings, though there's also other font choices that have an impact, such as larger fonts for headings. I actually happen to like those, but I imagine they could be controversial, so again, perhaps better staged for later discussion separate from the core features of the renderer.

• Style changes in rendering of inline unformatted text:

• Same, but when that text is in a heading:

• Changes to rendering of code blocks. I actually like these a lot, so I'd be tempted to consider them "pure improvements" (esp. the addition of the little "copy" button, which I love). But perhaps in the interest of making this as easy to adopt/discuss with the community for adoption first as a "better renderer" we should keep the differences to an absolute minimum, and discuss rendering updates separately:

Reproduce the bug

All these can be seen with 0.1.3.

List your environment

No response

[rowanc1]

This is great, thanks for taking the time to put all the screenshots together 📸 -- I will have a think about how best to do this, we are relying heavily on a different css system (tailwind) and need to see how to merge it with Jupyter's -- this is possible, and how I did the links (i.e. use the JupyterLab css variables). I will take another look as well at the CSS guidelines.

[fperez]

Thx for being receptive @rowanc1! I'll keep using this issue to track all CSS-related small things, but LMK when any one of them is distinct enough to warrant breaking it out and I'm happy to do so. Else I'll just add new screenies here as I run into things.

[fperez]

One more (screenshots taken separately as I can't get the anchor links to appear in both at the same time, since I need to hover). Anchors...

"Classic":

MystJS:

[rowanc1]

The anchors should be partially addressed in https://github.com/executablebooks/myst-theme/pull/4, currently not using a ¶, but did add that option in the component a few days ago!

[tavin]

I've encountered some perhaps related buggy rendering in connection with headings:

The first heading level element is changed to h1, and moved above any preceding content.

After that, h2 level elements get so much extra vertical margin/padding they end up taking more space than if they were h1 level.

The screenshot is from jupyterlab 3.6.1 and jupyterlab_myst 1.1.1.

[rowanc1]

Thanks @tavin -- the code is currently pulling out the first cell title to create a frontmatter block. I think this is probably unexpected behaviour as you were surprised, I will turn that into a bug in mystjs and get it fixed.

Thanks again for these comment on the styles, I want to take a more in-depth pass here soon to get things inline with expectations!

[tavin]

Hi @rowanc1 nice the heading/frontmatter issue will be fixed. In the meantime I've just learned that adding yaml frontmatter is a pretty decent workaround, thanks to your answer.

Now the top margin on the h2 level elements seems to be unrelated and indeed a CSS issue, in fact an explicit margin-top:2em coming from a myst style.

[tavin]

@rowanc1 @fperez taking a stab at normalizing things: #114

[rowanc1]

Quite a few fixes from @tavin coming in for this in various places! Thanks for all your help @tavin.

I have picked up your changes in #114 and made an additional push for more Jupyter-classic styles in #116. With that coming in, I think this addresses all points (and a few others) raised in this thread. The only exception to that right now is the code-renderer, which still has the shadow/border/copy-button - that requires a deeper change.

[fperez]

BTW - if those are actually more work to remove, I'd prioritize other work over "fixing" the code renderer :) Other than being different, I actually find it to be a net positive overall (both æsthetically and functionally), so perhaps we fry other fish first!

[rowanc1]

Many of these changes have been released in v1.1.3. Thanks @tavin @agoose77 and @fperez for the help in documenting the bugs, and jumping in to get this over the line! 🚀

@fperez looking forward to a new round of screenshots/improvements to make (either here or in a new issue!). I think one of the major next things is to get inline HTML fully working, and that will expose more things as well.