notebook
notebook copied to clipboard
Should `custom.css` equivalent be supported?
Problem
Notebook v6 allows users to customize CSS styles by including custom.css
; this was requested for JupyterLab too: https://github.com/jupyterlab/jupyterlab/issues/2102 but it seems that the issue got closed without a real solution for users who don't know TypeScript and just want to add a few tweaks. Some users seem to have expectation that it will just work in JupyterLab too jupyterlab/jupyterlab#12318 and others would like to customise their CSS programatically, the way https://github.com/deathbeds/jupyterlab-fonts allows them to do so.
Proposed Solution
- maybe
custom.css
should still be 1-1 supported in future Notebook 7? - maybe we could have a simple styles editor in Settings, either:
- using "CSS-in-JSON" approach as in https://github.com/deathbeds/jupyterlab-fonts, or
- just making a textarea allowing to paste plain CSS and be done with it?
I really don't know the solution, but just wanted to bring it up so that it is not forgotten about and maybe stimulate some discussion.
Thanks @krassowski for opening this.
This is also slightly related to jupyterlab/jupyterlab-desktop#274 and https://github.com/jupyterlab/jupyterlab/issues/3928.
wheee custom style! you know i love it.
custom.css should still be 1-1
Seems like custom.css
should probably just be made to work. It's a foot gun, but has a relatively limited blast radius (maybe just a few toes).
jupyterlab/jupyterlab-desktop#274
I'm pretty no comment
about adding any kind of DOM shims to make specific old styles work... if anything, a migrator script could potentially suggest some things, but that's like turing-complete level madness.
Also any extension authors that were shipping a custom.css
should not be encouraged to do so, and be duly slapped on the wrist for taking choice away from users and the other extension authors invited into a users' ~
.
To that end, it's a toss-up whether {sys.prefix}/.../custom.css
should be honored, at all: seems we'd not want to encourage any "winner take all" behavior by extensions... sysadmins would still have /etc/jupyter
, but ~/.jupyter/custom/custom.css
and crazy old {cwd}/custom.css
should be the preferred and documented location.
If I was doing it again, I'd imagine a custom.css.d
which then had a sane way to order the CSS imports... but as it wasn't a <7 feature, no point in adding it, and likely better off leaving it as-is as a purely user-with-a-hammer serviceable thing, not a concierge experience.
simple styles editor in Settings
Again, as it's not a feature of <7, seems like looking for more features that are indeed already met by extensions... if anything, jupyterlab-fonts
could be rebranded (maybe jupyterlab-styles
) and moved into contrib
, and encouraged as a pip
install, and potentially included in one of the contrib metapackages.
My concern with treating -fonts
as anything more than that is JSS isn't a standard (any more than, say, VDOM, etc.) and doesn't really have a mime type, much less a schema:i defy anyone to write a regex for "valid JSS+plugins selector".
It's still quite easy, fun, portable, and relatively safe to write CSS in %%html
cells... or generate cool stuff with HTML
and string manipulation. One can even write compound selectors that hit on e.g. nbconvert/nbviewer/Lab DOM... have done more than a few truly abominable things with reveal.js that way.
If there was an in-app editor, it would need LSP-level support, and not require nodejs.
@krassowski For reference, there is an old (bit-rotted) jupyterlab-custom-css
extension here: https://github.com/wallneradam/jupyterlab-custom-css
@krassowski For reference, there is an old (bit-rotted)
jupyterlab-custom-css
extension here: https://github.com/wallneradam/jupyterlab-custom-css
@psychemedia were you able to try that extension with some version of JupyterLab or on Binder?
Do you think this could address this issue? If so it can then be worth putting some efforts to update it, and maybe move it to https://github.com/jupyterlab-contrib.
@jtpio I don't recall using that one (though I may have tested it when it first appeared and then forgot about it). I also played with https://github.com/educational-technology-collective/etc_jupyterlab_cell_properties that lets you set properties on a cell by cell basis.
If there was a way to easily propagate cell tags to DOM class attributes for both markdown and code cells (and code cell outputs), at various levels of the cell HTML structure), and a simple custom css editor, it would make end use innovation around notebook content rendering so much easier.
As to the extension rather than a simple file: I suddenly twigged onto a workaround of creating and building a complete extension that does nothing other than copy over a CSS file. This puts it beyond the reach of lots of folk but it seems to work.
Seems like
custom.css
should probably just be made to work. It's a foot gun, but has a relatively limited blast radius (maybe just a few toes).
Yes, give me the foot gun please :)
I want a CSS file relative to the project I am working on, so an "advanced setting" or whatnot in which you can input a filename or pathname. A textbox in which to paste CSS is not needed nor would it help if you're using different CSS for different projects.
Styles in %%html have a sort of delayed rendering effect, result in an unwanted output block you have to ignore or hide, and aren't possible in markdown files.
Probably it would be fine to add the {{ base_url }}/custom/
handle to Notebook 7 by default, or behind a flag, just for custom.css
.
For those who like to have a look at implementing this for 7.0, the classic notebook defines the handler on the server and links the extra stylesheet as follows:
https://github.com/jupyter/notebook/blob/64e7c061e0273150d6e471ead34a84216220a796/notebook/templates/page.html#L17
I guess the approach for Notebook 7 would be similar.
Just wanted to mention that I'm taking a look at this now!
Thanks @RRosio!
I began a draft PR for this issue, https://github.com/jupyter/notebook/pull/6841, but I am running into an error as the styles are not being applied. I'm working to resolve this issue, but would appreciate any feedback thus far..
- Closing as fixed by #6841