Roadmap discussion

[malberts]

Version 3.2.0 (next unreleased)

• Milestone: https://github.com/ProfessionalWiki/chameleon/milestone/3
• Echo support #90
• Remove all MW 1.35 hard deprecations (the ones with Notices when $wgDevelopmentWarnings = true)
• Last (minor) version to support MediaWiki 1.31? (EOL: June 2021)
• Other minor bugfixes?
• ...

Version 3.2.x (future)

• Remove all MW 1.35 soft deprecations
• ...

Version 4.x (future)

• Milestone: https://github.com/ProfessionalWiki/chameleon/milestone/4
• Drop MW 1.31 support

Future

• Bootstrap 5? (Released in May 2021)
• ...

[malberts]

I don't know if this is the right place, but can we use this to discuss a rough roadmap?

I think most of my initial points are obvious (and feel free to add to it).

Just one specific question: What is the plan for MediaWiki 1.31? Does it get one last release and then we no longer care about it? Or do we explicitly remove all 1.31 workarounds and keep only 1.35+ logic?

[JeroenDeDauw]

What is the plan for MediaWiki 1.31? Does it get one last release and then we no longer care about it?

Sounds good to me. Requiring 1.35 for new releases is reasonable at this point.

Dropping MediaWiki compat should not be done in a patch release. Indeed, perhaps it should only be done in a major release. That is what we figured out for SMW, as described at https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/docs/RELEASE-POLICY.md#release-policy

[despens]

I am glad to see some development activity on Chameleon! My suggestion would be to address 3 things about Chameleon:

• Chameleon, or the Bootstrap extension it relies on, does not seem to merge the Bootstrap styles with LESS styles created by Mediawiki, but rather loads the Bootstrap stylesheet after the stylesheets generated by Mediawiki. Using the styles inspector I can see that many styles, like the default font family, are defined twice, first with Mediawiki defaults, and then via Chameleon. This can lead to pages first being rendered in default style, and in a fraction of a second later in the Bootstrap style, especially when the internet connection is not so great. It also makes it difficult to write styles because you might run into cases where SCSS alone doesn't cut it and you have to add !important quite a bit. This is especially difficult with regular in text link colors. — Maybe this could be unified more?
• Some very practical bootstrap features that require manual activation via JavaScript (thinking of popovers) do not seem to be activated by Chameleon. That would be a very nice thing to have though.
• Colors and variables: Link colors are hard coded in Chameleon to be a "darker" variant of the color defined in LocalSettings. This took me forever to figure out :wink:. I wonder if this is a Bootstrap feature or a choice of Chameleon, but CSS variables are hardly used, instead variable values are "rendered" in CSS. This is making the design process a bit cumbersome, because it is not possible to just change the CSS variables in the browser developer tools. Instead, the complete CSS has to be recompiled, which consumes considerable time. Would it be possible to have as many variables as possible compiled to CSS variables? I think all major browser support CSS variables since 2016.

[malberts]

Thanks for the feedback @despens. A few quick comments from my side:

• SCSS + LESS
  • Merging the generated CSS (or even SCSS and LESS) is going to be very difficult. You would need a very smart CSS preprocessor to reduce the rules. Either way, if such a thing is practically possible it would actually have to be handled by MediaWiki when it spits out the combined CSS.
  • Possible solution: make all MW stylesheets opt-out in Chameleon so that you can choose to not load them (something similar to the recently added External Link Icons support which just adds in some default MW CSS)
• Bootstrap components
  • It might be better to offload such things to the BootstrapComponents extension
  • I know it was just an example, but even Bootstrap doesn't auto initalise popovers
• Colors/Styles
  • I'm busy making the base _light theme replaceable, thereby removing some of Chameleon's opinions (e.g. if you just don't want them, or if you use Bootswatch)
  • I guess CSS variables were never really used due to legacy browser support (Chameleon has been around for many years)

[despens]

Thank you @malberts for your explanations.

Regarding SCSS vs LESS, I know it's probably unrealistic, but would using the same CSS pre-processor as Mediawiki make a difference? Otherwise it would probably be desirable to skip the CSS output of Mediawiki, but only in certain name spaces, because some features and extensions are reliant on Mediawiki stylesheets being present (such as Wikibase).

I have tried the BootstrapComponents extension, but it works on a very different level. Perhaps the only way to do it is to use Chameleon's raw HTML feature to load another JavaScript file that initializes whatever Bootstrap features required. Otherwise I wouldn't see harm in an option that would just activate all Bootstrap features that need to be initialized. They can anyway only be used in complex templates.

[s7eph4n]

There is some rudimentary support for loading modules in the Bootstrap extension, but I never got around to make it properly work. Styles are usually only loaded once and then cached anyway, so Chameleon just does a 'Load all', which loads the standard Bootstrap modules, but no 'frills', like Popovers (as @malberts noted).

Edit: So maybe some configuration variable e.g. $egRequiredModules for the Bootstrap extension would be the way forward?

[Leader-board]

Would GitHub Discussions (https://docs.github.com/en/discussions) be better for this purpose?

[JeroenDeDauw]

I have not used that feature yet but curious to see how it works. Enabled for this repo now, so knock yourselves out: https://github.com/ProfessionalWiki/chameleon/discussions

[malberts]

I'm going to convert this issue to a discussion and then we can see how it goes.