Styling cells through metadata?

FYI, there is a PR for JupyterLab open right now that is about adding a data-tag-FOO attribute to a cell DOM node if the cell is labeled with the tag FOO: https://github.com/jupyterlab/jupyterlab/pull/8410

So that would mean every tag is essentially exposed as an attribute in the DOM?

I also note that that PR is a JupyterLab specific one (I tend to just work in vanilla notebooks…).

For styling purposes in notebooks, automatically passing a tags as class attributes, perhaps prefixed (eg tag-FOO) could be interesting, because it then starts to make the UI display programmable/customisable by the user via CSS and extensions that detect particular (class) tags.

It could presumably also make cell tags act like block cell magic invocations?

@jasongrout
I’m confused by your explanation of that PR; the code says

  if (this.model.metadata.has('parameters')) {
      this.node.setAttribute('data-parameter-cell', 'true');
    } else {
      this.node.removeAttribute('data-parameter-cell');
    }
  }

which unless I’m missing s/t huge, seems to rely on the presence of a parameters metadata key and not tags, am I right ?
even so I’m having a hard time seeing how this applies to a random name like FOO

For the sake of clarity, I would personally argue that we pick some sort of consistent naming; if the side effect on the DOM are additional attributes, why not use the attributes metadata key, or maybe data-tag-attributes if indeed the added attribute is data-tag-FOO ?

Because as much as I can appreciate the simplicity of re-cycling something already used like tags, it feels confusing to use parameters here that seems a little to come out of nowhere, no ? unless it’s already used indeed, I’m just a user and probably not a very representative one :slight_smile:

Please read the review of the PR, where we discuss proposed changes to bring it in line with my explanation above. The code in that PR right now does something different and hasn’t been updated.

@psychemedia thanks for referring to your 2 extensions, particularly the empinken one that very much looks like what I’m after !

being like you more of a classic notebook user, I guess as a way forward I’ll need to either

  • go the quick and dirty way and use you code as a starting point for my own ad hoc use case
  • or post a pr in the classic notebook to somehow mimick what’s being done in jlab; which at this point is not super clear to me yet

in any case, I have just a quick question though about the need for dealing with codecells and textcells differently
I mean here


the purpose being only styling here, could the prompt case not be handled using only css ?

Yes, essentially.

Right. I was just posting here as a solution explored by one of the Jupyter frontends.

Yes, that’s the idea.

I’m not sure what you mean here. Block cell magics are about running code in the kernel, this is about annotating DOM elements in the frontend. Those concepts aren’t implicitly connected.

thanks for clarifying, and sorry to have botched it; will re-read it thoroughly :slight_smile:

@jasongrout it sounds like there’s some discussion in that PR that could help guide the broader conversation about tag standards and how they relate to things like the DOM, “kinds of cells”, etc. Thanks for sharing it!

Do you see any value in trying to have a “standards conversation” around tags, or do you think it’s still at a point where each project can make their own decisions? I think it’s not a big deal now, though I worry about 1-2 years from now if there are lots of notebooks with “jupyterlab-only metadata” or “vscode-only metadata” etc.

I’d like to relate this with the splitcell extension - the one that allows to get cells to take only half of the width

this extension has always had a rather annoying bug; copy and paste a split cell, the resulting copy will show on a 100% width; toggle the cell twice to see it come to 50%; the reason for twice is, the data model has been copied alright but the repercussion of the metadata tag (spit_cell uses cell_style) does not happen during copy/paste

with something like what’s being proposed here, the code for splitcell would become more trivial; and it would work better

provided of course that the specification has it that changing the metadata tags (if that’s what we go for) gets the core to trigger repercussions in the DOM; that’s my expectation, is that a reasonable one ?

@parmetelat My code is likely far from optimal and is definitely not intended as “production code” (not my skill set…):wink: It’s typically evolved rather than designed; some bits may be split out explicitly in “scaffolding” / spaghetti code as I try to simplify a problem, articulate to myself what I think I want to achieve, or consider alternatives to s/thing I’ve already achieved, before getting round (or more likely, not) to refactoring. I’m generally playing with end user ideas of the application achieved howsoever, rather than worry about the code, and generating really quick and crude sketches, not finished work. The code itself is just essentially doodles, and repos are pages in my sketchpad. Rather than use things like wireframe design tools to mockup possible extensions, I tend to hack code to creating half working prototypes that I can point to and say: it’d be good to have something like that, but done properly…:wink: The code is there essentially as a thinking tool to help me explore a user interaction idea.

understood

I was only asking because I wanted to make sure that the ideas considered elsewhere in the thread, to add attributes in the cells depending on its metadata, were not doing a distinction b/w code and text cells, and I wanted to make sure there was no fundamental reason to do so in your case either, is all :slight_smile:

Yeah, there was no good reason other than perhaps I was originally exploring, or reserving the right to explore, different approaches for each cell type.

The tagstyler extension makes no distinction. On my to do list is to combine the two extensions and probably follow the tag approach…

Did this PR or related go anywhere? [https://github.com/jupyterlab/jupyterlab/pull/8410]

The issue you referred to appears to have been closed as stale, and another issue linked as the “moved to” thread also appears to have stalled?

There is a possibly related extension at Files · master · Rafe / celltag2DOM · GitLab but I’m not sure if it works with current JupyterLab releases; similarly the GitHub - wallneradam/jupyterlab-custom-css: Add custom CSS rules for JupyterLab which I think in principle would work with the celltag2dom extension to give no developer users a route to being able to tag cells and then style them?

(I really struggle to make sense of JupyterLab extension code and dev environments were any fixes required; the activation energy to try to even get started is just way too expensive for me right now:-(

Did you ever get anywhere with an extension to style notebook cells based on cell tags in a JupyterLab or RetroLab UI? The lack of such a feature continues to be one of the blockers to me moving to JupyterLab for teaching and learning purposes, where we make heavy use of extension styled notebooks based on tag attributes.

If you would like some pointers on where to look to implement this yourself as an extension, you could look at my jupyterlab-imarkdown extension. This extension provides its own NotebookPanel.IContentFactory, which it uses to override the behaviour of the Markdown cell.
This extension does several things, so there are several JupyterLab plugins in index.ts. You only need one to provide your custom factory. You can use the extension cookie-cutter to get started, and inherit directly from NotebookPanel.ContentFactory for your factory, (see jupyterlab-imarkdown/index.ts at 4a564a75ac85240670e4166c36fbbe3a865cb32e · agoose77/jupyterlab-imarkdown · GitHub)
You could subclass all of the cell types in your own factory, and listen to the cell model for changes to the metadata. This could then be used to add or remove classes, e.g. the MARKDOWN_CELL_CLASS added in MarkdownCell

2 Likes

Hiya @psychemedia

sorry for the super late answer to your question, which did not hit my radar at the time:

The answer is no; I’m on exactly the same page as you seem to be, in that a) there are many things that draw me back to the classic notebook even though I know the whole community is pushing towards jlab, and b) I feel totally overwhelmed when it comes to jlab extensions :wink:

@parmentelat I’m still stuck on progress w/ JupyerLab too…

FWIW, I’ve been exploring alternative routes recently, as described here.

thanks for the tips @psychemedia

@parmentelat I made a start trying to dig into a tags2classes extension here. Next step is to add styling by getting a CSS file in there too.

1 Like

Hi @psychemedia
thank a lot for writing all this down !

for the record, if others are interested in the full read, @psychemedia’s blog starts here - (it took me a while to figure out, the next and previous links appear at the very bottom)

as a question to the community: is this html structure something that can be relied on to stay stable in the future ?

1 Like