Task: Create theme maintainers team and see who is still wanting to help maintain themes

[joshgoebel]

Need to create a theme maintainers list so that theme maintainers who desire can keep their themes up-to-date.

The overall idea being that themes (like grammars) are never "one and done" that over time they require a (small) amount of maintenance to keep up with changes in the core library, grammars, theming in general, etc. Themes that have no owner/maintainer should possibly be moved into an old_themes repository/folder with a README that indicates they may not provide the best results compared to core themes.

Of course we'd love it if all themes were maintained and provided a great experience.

What kind of things require upkeep? See #2500, #2521, etc... plus the recent additions of property, punctuation, operator, and other prior and upcoming changes... but this issue is just trying to get everyone onto a team so I can more easily contact you. After that I'll focus on typing up a list of things you may want to consider when refreshing your themes to take advantage of recent changes and improvements.

Added by HLJS Team

• default.css
• mono-blue.css
• ascetic.css (Ivan)
• dark.css (Ivan)
• googlecode.css

Unmaintained

• androidstudio.css
• arduino-light.css (not with Arduino anymore, forwarded request along to Arduino peoples)
• arta.css (pumbur@pumbur.net) (email bounced)
• docco.css
• ir-black.css (vaskas@programica.ru) (email bounced)
• vs.css
• foundation.css - " Since Foundation has moved on substantially, I'm not even sure the existing theme makes much sense anymore. It would be best if someone recreated it anew."
• gml.css - (thumbs down on maintaining)

Base16

These should be auto-build from Base16 sources... see #3132.

• atelier-cave-dark.css
• atelier-cave-light.css
• atelier-dune-dark.css
• atelier-dune-light.css
• atelier-estuary-dark.css
• atelier-estuary-light.css
• atelier-forest-dark.css
• atelier-forest-light.css
• atelier-heath-dark.css
• atelier-heath-light.css
• atelier-lakeside-dark.css
• atelier-lakeside-light.css
• atelier-plateau-dark.css
• atelier-plateau-light.css
• atelier-savanna-dark.css
• atelier-savanna-light.css
• atelier-seaside-dark.css
• atelier-seaside-light.css
• atelier-sulphurpool-dark.css
• atelier-sulphurpool-light.css
• darcula.css
• dracula.css
• gruvbox-dark.css
• gruvbox-light.css
• solarized-dark.css
• solarized-light.css
• tomorrow-night-blue.css
• tomorrow-night-bright.css
• tomorrow-night-eighties.css
• tomorrow-night.css
• tomorrow.css
• zenburn.css
• ocean.css
• railscasts.css
• hopscotch.css (idleberg)

---

Reached out

• a11y-dark.css
• a11y-light.css
• agate.css
• an-old-hope.css
• atom-one-dark-reasonable.css
• atom-one-dark.css
• atom-one-light.css
• brown-paper.css (yur4ik7@ukr.net)
• codepen-embed.css
• color-brewer.css
• far.css - (majestic2k@gmail.com)
• github-gist.css
• github.css
• gradient-dark.css
• gradient-light.css
• grayscale.css
• hybrid.css
• idea.css
• isbl-editor-dark.css
• isbl-editor-light.css
• kimbie.dark.css
• kimbie.light.css
• lightfair.css
• lioshi.css
• magula.css
• monokai-sublime.css
• monokai.css
• night-owl.css
• nnfx-dark.css
• nnfx.css
• nord.css
• obsidian.css
• paraiso-dark.css
• paraiso-light.css
• pojoaque.css - perhaps atelierbram wants to help here? Pinged Jason Tate on Twitter
• purebasic.css
• qtcreator_dark.css
• qtcreator_light.css
• rainbow.css
• routeros.css
• school-book.css
• shades-of-purple.css
• srcery.css
• stackoverflow-dark.css
• stackoverflow-light.css
• sunburst.css
• vs2015.css
• xcode.css
• xt256.css

[joshgoebel]

@ericwbailey Are you still interested in ownership and maintenance of the a11y-* themes?

[joshgoebel]

@taufik-nurrohman Still interested in ownership and maintenance of agate?

[joshgoebel]

@gusbemacbe Still interested in ownership and maintenance of an-old-hope?

[joshgoebel]

@kanytu Still interested in ownership/maintenance of the androidstudio theme?

[joshgoebel]

@smellai Still interested in ownership/maintenance of the arduino-light theme?

[joshgoebel]

@atelierbram Still interested in ownership/maintenance of all the atelier-* themes that seem to be your namesake? :)

[gusbemacbe]

@gusbemacbe Still interested in ownership and maintenance of an-old-hope?

Can I see the repo?

[joshgoebel]

All the styles are in the same folder: https://github.com/highlightjs/highlight.js/tree/main/src/styles

[gusbemacbe]

Ah, I saw. Yes, @joshgoebel .

[gusbemacbe]

Yes, Josh, I'm.

[joshgoebel]

@voldmar Still interested in ownership and maintenance of zenburn theme?

[taufik-nurrohman]

@taufik-nurrohman Still interested in ownership and maintenance of agate?

Sure 👍

[joshgoebel]

@initbar Still interested in ownership and maintenance of xt256.css?

[atelierbram]

@joshgoebel sure I am ...

[ericwbailey]

@joshgoebel Yup. It'd be helpful to have a punchlist for changes once they happen, as I don't actively monitor this repo.

[kanytu]

@kanytu Still interested in ownership/maintenance of the androidstudio theme?

I'll no longer maintain this theme.

[voldmar]

@voldmar Still interested in ownership and maintenance of zenburn theme?

I guess I won’t maintain it. Sorry

[joshgoebel]

It'd be helpful to have a punchlist for changes once they happen, as I don't actively monitor this repo.

Yeah, once I have a team together I can CC the team directly on things that might be relevant, etc... or ask for feedback. Right now there is no way to even notify someone that their theme might need an update, etc.

[joshgoebel]

@angelolloqui Still wanting to own/maintain the Xcode theme?

[joshgoebel]

@Nicolas01 Are you still wishing to own/maintain the VS Code 2015 dark theme?

[joshgoebel]

@jdiamond Still wishing to own/maintain the vs.css theme?

[joshgoebel]

@redguardtoo Still wishing to own/maintain the Srcery theme?

[joshgoebel]

@thingsinjars Still wishing to own/maintain docco.css theme?

[joshgoebel]

@DiVAN1x Still wishing to own and maintain the routers.css theme?

[joshgoebel]

@gavsiu Still wishing to own and maintain the Ocean Dark theme?

[joshgoebel]

@RocketMan Still wishing to own/maintain nnfx/nnfxdark?

[joshgoebel]

@ourmaninamsterdam Might you still be interesting to own and maintain the Codepen Embed theme moving forward? I see you had the original commit.

[joshgoebel]

@Hirse Might you still be interesting to own and maintain the Stack Overflow themes moving forward? I see you had the original commit. Also if you're interested in owning any of the other themes without a home, let me know. :) Should be minimal effort over time.

[vast]

@vast Looks like Idea is yours also? :)

Yep. I'll continue supporting it. No problem.

[simonmysun]

@simonmysun Might you still be interesting to own and maintain the Grayscale theme moving forward?

Sure.

[joshgoebel]

@atelierbram If we just pull in all your themes via https://github.com/atelierbram/base16-atelier-schemes instead of maintaining by hand does that solve that?

[visoft]

@visoft Might you still be interesting to own and maintain the Railscasts theme moving forward?

Sure

[Nicolas01]

@Nicolas01 Are you still wishing to own/maintain the VS Code 2015 dark theme?

Hi @joshgoebel , I am sorry but I don't have time to maintain the VS Code 2015 dark theme for the moment.

[Hirse]

@Hirse Might you still be interesting to own and maintain the Stack Overflow themes moving forward? I see you had the original commit. Also if you're interested in owning any of the other themes without a home, let me know. :) Should be minimal effort over time.

Sure. I can also take over the GitHub theme unless you have someone for it already.

[joshgoebel]

@Hirse Do we still need GitHub and Github Gist? I looked and after the recent changes they look almost identical to me?

[MedvedTMN]

@MedvedTMN Might you still be interesting to own and maintain the ISBL Editor Light and Dark themes moving forward? I see you had the original commit.

Yes, I would be interested

[joshgoebel]

CC @highlightjs/theme-maintainers

#3139 pulls in ALL official Base16 themes via the automated build from https://github.com/highlightjs/base16-highlightjs. Any manual ports of Base16 themes (listed at the top of this thread) have been removed in favor of the new canonical auto-builds. For some themes this may result in visual changes. Just to name one I took a look at Gruvbox Dark and while it was using the same Base16 color palette as the canonical Gruvbox dark - they were all over the map in their application (ie, not applied according to the Base16 spec as far as I could tell).

If this has truly detrimental effects on any themes (that perhaps were perhaps higher-fidelity before) this can be reviewed on a case-by-case basis to decide what to do. After the current slate of PRs are reviewed a alpha1 release of v11 will be released that includes these new changes.

Or if you want to see just the new themes changes now see #3139.

[atelierbram]

@atelierbram If we just pull in all your themes via https://github.com/atelierbram/base16-atelier-schemes instead of maintaining by hand does that solve that?

@joshgoebel I guess it will be OK

[idleberg]

@joshgoebel I'm the author of Hopscotch and both Kimbie and Paraíso themes. I'm open to maintaining them in the future.

[joshgoebel]

@idleberg Awesome.

• Hopscotch has moved to Base16. (I saw your name on it there so I assume it's the same).

Just out of curiosity is there a reason why you haven't released Kimbie and Paraiso as Base16 themes?

[idleberg]

Just out of curiosity is there a reason why you haven't released Kimbie and Paraiso as Base16 themes?

While those themes were built using base16-builder, they doesn't necessarily follow the Base16 style guidelines (I simply don't remember). The same might be true for the other Base16 templates for highlight.js – IIRC, the guidelines were defined after the templates for highlight.js were first created. Back then, some version of the Monokai theme was used as a “rosetta stone” to define the template. So to answer the question whether the Base16 themes follow the style guidelines depends on somebody else, other than @chriskempson and me, updated them later on.

[joshgoebel]

Thanks for the background.

The same might be true for the other Base16 templates for highlight.js

I think you mean "schemes"? That's what Base16 calls themes... "template" means the actual "destination"... such as now we actually have a Highlight.js template - which turns Base16 schemes into something workable for us. [edit: but perhaps we had one long ago just it wasn't saved anywhere - or there are actually multiple templates and I just don't know where they are, lol]

the guidelines were defined after the templates [schemes?] for highlight.js were first created

Ah, I hadn't considered the history, that Highlight.js might predate Base16?

whether the Base16 themes follow the style guidelines

Unless someone steps up to go thru every theme one by one (which doesn't seem likely)... I'm going to assume the Base16 "spec" is canonical. So going forward the Base16 themes we bundle will all use our official template and will adhere to the Base16 guidelines. In the cases where this vastly alters the appearance of themes that did not follow the guidelines before the prior behavior will be considered a bug - and the new behavior the fix.

In cases where a specific theme maintainer steps forward because their theme has been mangled by this decision then we can deal with that on a one off basis. It's possible that (now original) theme could then be restored or renamed or something... not sure.

The only original Base16 theme I've left (for now) is Nord which (for right or wrong) contains a zillion per-grammar style alterations. So right now you can find both styles/nord and styles/base16/nord.

While those themes were built using base16-builder

Oh wow this just registered with me... damn it'd be nice to see that template somewhere. :-) I had to start from scratch.

[tajmone]

While those themes were built using base16-builder

Oh wow this just registered with me... damn it'd be nice to see that template somewhere. :-) I had to start from scratch.

If I remember correctly, the base16-builder uses the newer scheme conventions (v0.8.0–0.9.1), which was added later on. The problem is that most Base16 schemes in the wild still use the older (original) convention (including many new schemes published independently). For this reason, in my project I opted to stick to the original scheme, even though it carries less information, so that I might use the classic Base16 schemes out of the box.

Just be aware of this before switching tools and scheme versions.

[joshgoebel]

You're king of losing me a bit.

If I remember correctly, the base16-builder

I don't know what "the base16-builder" is... there is a different builder for every language... but in theory they all do the same thing (follow the builder spec)... so perhaps you meant "a builder"? Your use of "the" just makes me wonder if you're talking about something else I don't know about.

uses the newer scheme conventions (v0.8.0–0.9.1), which was added later on.

I don't know what you mean here... to me the scheme conventions is just how the data is codified... where as what we really care about are the style conventions I would think... and I can't find any info on that prior to version 0.2. The builder conventions (the version numbers you reference) just describe how the builder itself outputs files, etc...

The problem is that most Base16 schemes in the wild still use the older (original) convention (including many new schemes published independently). For this reason, in my project I opted to stick to the original scheme, even though it carries less information, so that I might use the classic Base16 schemes out of the box.

I'm afraid I truly have no idea what you mean when you say "older (original) convention" or "original scheme"... could you link me to something or be clear how an older scheme differs from a newer one if we're not talking about style conventions?

[tajmone]

The builder is an official tool, which supports different base16 versions:

https://github.com/chriskempson/base16#builder-repositories

These different Base16 schemes and builder versions differ in the way data is stored in the YAML/JSON file, where later versions use some different key naming conventions, and also introduce new key/values (e.g. other color representation beside the hex triplet, like RGB, etc.).

It all boils down to were you'll be loading your base16 YAML/JSON scheme definitions, and whether they adopt the older or newer data convention.

[idleberg]

I think you mean "schemes"?

Yes, that's correct.

there is a different builder for every language

The base16-builder is a Ruby script (later replaced by a PHP script) that takes the schemes and applies them to a number of templates. Early versions of the builder contained templates mostly, but not exclusively, maintained by @chriskempson. Later on, he encouraged third-party templates to live in their own repositories, however they can be linked into base16-templates-source (the same goes for schemes)

It's probably helpful to take a look at the Base16 eco-system. Let me also mention that there's a third-party Base16 builder for NodeJS.

Ah, I hadn't considered the history, that Highlight.js might predate Base16?

That wasn't the point. I don't know if @chriskempson had his styleguide in mind when he started Base16 (and his own templates). I'm pretty sure that it didn't exist when I started making templates and schemes for it. It must have been around the time when the switch from the Ruby to the PHP builder was made, when the styleguide was made public.

[joshgoebel]

These different Base16 schemes and builder versions differ in the way data is stored in the YAML/JSON file

Well, I've never even heard of JSON for Base16... is that pre 0.8? (I only care about input format - obviously one could write a JSON template, though not sure why we'd care about that - we need CSS) Everything I've seen is YAML. I did review all the specs (from 0.8) onward and the only differences I see seem to be that the templates support more variables over time. In all cases the YAML scheme definitions remain exactly the same... I just forked and updated the Node builder, wrote a Highlight.js template and then used the builder to compile all schemes in https://github.com/chriskempson/base16-schemes-source.

We use only hex, so in that regard the 0.8 spec would be perfectly fine...

It all boils down to were you'll be loading your base16 YAML/JSON scheme definitions, and whether they adopt the older or newer data convention.

Just using base16-schemes-source and the node builder and it all "seems to work"... but perhaps I'm missing something.

[joshgoebel]

I mean some of the schemes themselves are all over the map... but I don't know what we can do about that... no accounting for taste... and unless there is a prior style guide where the base#s used to have an alternative meaning (such that we could version control and build them differently) I'm not sure what could be done about that anyways?

[joshgoebel]

It's probably helpful to take a look at the Base16 eco-system.

I'm not sure what you're directing me to exactly. I've read the website and the GitHub readme, and the style specs, the builder specs (0.8 onwards), the scheme specs, etc. I've written a template, written a scheme, forked and updated a builder. I think/hope I have a high level overview of things... I think perhaps I'm missing some nuance or history...?

[idleberg]

I don't think the schemes need to be questioned, I also don't think they have ever changed (there might have been additive changes). The real question is whether the Base16 template for highlight.js is a correct implementation that respects the style guideline. I'm talking about the template that existed since the early 2010s and that most themes are probably based on. If your own template follows the Base16 styleguide, I'd stick with that – even if that means breaking changes for some of the themes included in highlight.js. There is no point using the Base16 label for something that is not. The question then is, what happens to older themes that implement Base16 incorrectly.

[joshgoebel]

The real question is whether the Base16 template for highlight.js is a correct implementation that respects the style guideline.

Well, I think it's a passable start for sure... though I'm open to feedback. :-) I posted a side-by-side over in the issue on the subject and we don't exactly match the sample (I'm not sure we should), but it's close. Obviously it's easy to update the template and rebuild the themes as improvements are made.

---

OH. And boom, FINALLY understanding. :-) You're referring to https://github.com/chriskempson/base16-builder/tree/master/templates/highlight.js

I had no idea such a thing existed as it's not documented anywhere nor included in base16-templates repo... I'll have a look as this offers a point of comparison with the NEW template I just made.

[joshgoebel]

There is no point using the Base16 label for something that is not.

Right that's my thinking. If "xyzzy" is a well known Base16 theme then if we include it it should have expected Base16 behavior - and be built using our Base16 template. The question I think becomes if we want to "augment" base16 somehow, but perhaps we just avoid doing that. And if older actual Base16 themes aren't very "base16-y" then that's their problem and they should be updated IMHO. :-)

The question then is, what happens to older themes that implement Base16 incorrectly.

Do you mean the included Highlight.js themes? They die. Unless the author/maintainer swears by their behavior in which case it gets more complex. :)

If you mean older Base16 themes in the Base16 project then as I said above: if older actual Base16 themes aren't very "base16-y" then that's their problem and they should be updated IMHO. :-)

[samiaab1990]

@samiaab1990 Might you still be interesting to own and maintain the Gradient Light and Dark themes moving forward? I see you had the original commit.

Hi-sorry it's been a while, but yes I'm still interested