Should extensions include a baseTheme or a HighlightStyle ?

v6
1

If you are building an extension that adds a new element to the DOM adds a new tag to the syntax, and you want to be able to style that element using both stylesheets and Highlight Styles, should the extension include the default styling in a base theme or a Highlight Style?

It seems like the advantage of using a base theme is that it allows you to provide different styles for light and dark themes. Are there other reasons to use a base theme instead of a Highlight Style?

const cssClasses = HighlightStyle.define([
  { tag: tagName, class: "my-selector" },
])

const baseTheme = EditorView.baseTheme({
  ".my-selector": { backgroundColor: "red" } 
})

// css
// .cm-editor .my-selector { ... }

const myStyle = HighlightStyle.define([
  { tag: tagName, backgroundColor: "red"},
])

// css
// .my-selector { ... }
2

A highlight style is only for syntax highlighting, so it doesn’t seem to apply to the situation you’re describing.

3

Sorry, I had a bit of brain lapse there. I’m working with markdown language extensions. The question should have read: “If you are building an extension that that adds a new tag to the syntax …”. (I’ll edit the original post to eliminate the confusion.)

4

Then, to style the tag, you have to define your own highlighting style. I guess in a situation where you’re providing an extension that does this but don’t know whether the editor is going to be light or dark-themed, the current system doesn’t really help a lot. Will take a look at that sometime soon.

5

Thanks.

The current system does offer a work around: you can attach a css class to a Tag using a Highlight style and then create a base theme to provide default styling for the tag that will accommodate both light/dark themes. But it sounds like that isn’t how you intended things to work. Is your preference in a scenario like this to have everything handled by a Highlighting Style? Are base themes intended only for elements outside of the syntax?

6

I’m considering moving to a system where highlight styles always assign classes, and themes are responsible for styling those. That would address this and generally simplify all this a bit. But since it’d be a breaking change it will have to wait until 0.20, so I’m not sure when I’ll land it.

7

Thanks for the update.

In the new system, will class names be automatically generated or will we still be able to name them (and rename existing classes) using HighlightStyle.define() ?

8

I spent a while designing an approach where highlighting is more CSS-based, but found that CSS’s inability to cleanly express hierarchical relations leads to very messy, verbose class output (class="cmt-literal cmt-literal-string cmt-literal-string-docString"), and decided to stay with the current system.

So attached patch adds a feature to HighlightStyle that allows you to target it to a specific theme type.

9

@marijn is themeType support going to be released at some point? (I also see themeType is mentioned in the docs but latest 0.19.7 still doesn’t have it)

10

I’ve tagged 0.19.8

1 Like