Roadmap discussion

[malberts]

Version 3.2.0 (next unreleased)

• Milestone: https://github.com/ProfessionalWiki/chameleon/milestone/3
• Echo support Echo Notification System support for chameleon 2 and 3 respectively #90
• Allow removal of default theme: Add initial theme support #253
• Improve docs for some variables that were non-overridable due to the default theme
• Remove all MW 1.35 hard deprecations (the ones with Notices when $wgDevelopmentWarnings = true)
• 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 (EOL: June 2021)

Future

• Bootstrap 5? (Released in May 2021)
• Mustache-based templating? https://www.mediawiki.org/wiki/Manual:How_to_make_a_MediaWiki_skin#Mustache
• ...

[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 😉. 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.

[malberts]

My plan is to cut the new 3.2.0 release by the end of the month. The current PR's are the last I'm going to be looking at for this upcoming release. The main aim was to improve MW 1.35 support and to fix a couple of issues. I don't want to add many new features now unless they are required to address other bugs.

Some of the open enhancement issues shouldn't be too hard to implement and I might look at them later, but for now none of them are urgent.

Are there any objections to the above? Or specific issues that might still require attention?

[JeroenDeDauw]

I think a really key feature for Chameleon, and perhaps the thing that holds it back the most, is a good default layout.

Right now after you install Chameleon you basically are forced to further configure it. That is a pain, and it leads to more pain down the road when you upgrade Chaneleon. A really solid standard that people can just enable and forget about would be fantastic.

[s7eph4n]

I thought standard.xml is activated by default? At least that's supposed to happen and should work out of the box, no config necessary.

[s7eph4n]

The "good" part can be discussed, obviously. :D

[malberts]

standard.xml does load by default with no config. I think the "problem" is more that it is a dated design (my opinion). The question then is what design would be considered more of an expected default in the MediaWiki world?
I can think of 2 options:

• one of the navbar-based layouts (AKA a typical, generic Bootstrap design)
• a sidebar layout (like Vector and Medik)

I started playing with a sidebar layout and here is a rough Medik-inspired version:

It's obviously far from done.I need to add additional styling and a few new config options on some Components in order to get it almost the same.

[s7eph4n]

Agreed. Calling it "standard" was probably not a good idea in the first place. Navbar (or similar) seems to be what most people opt for.
Never got around to creating a vertical-navbar/sidebar layout, mainly because of the effort required for modifying components, but it's been on my list more or less since the beginning. I really like your version. The icons look a bit all over the place on the horizontal navbars/toolbars. They look much better arranged like this.

[kghbln]

Indeed, the current "standard" design is a bit dated.

Even though the sidebar layout is probably something more people expect from MediaWiki since all default skins of MediaWiki use the sidebar layout (Vector, Monobook, Modern, Timeless (with two though)) we are "just" talking about the desktop view here. The mobile view has a navbar layout I guess in all cases even if you have to use Mobile Frontend to get it working.

Thus I personally lean towards the navbar layout by default since this is moreover what people are used to from previous releases of Chameleon. Still a layout with a sidebar view to switch to easily without lots of voodoo will be very good to have.

[Fredrilj]

Jeroen De Dauw has a point; The Chameleon cannot be used out of the box because the template layouts do not meet today's standard of what is considered an OK design. For me, who is not a developer or designer, this meant I had to take into account the development of a new design when considering which skin to choose. It became a threshold to teach myself to define a layout in XML, so I ended up with skin Tweeki for the current project, which has an easier path to customize the layout. For future projects, I hope to be able to use Chameleon. Many thanks to Morne Alberts for all he's contributions to make Chameleon a solid skin and the best alternative to MW's standard skins. ons. 26. mai 2021 kl. 01:17 skrev Jeroen De Dauw ***@***.***>:

…

I think a really key feature for Chameleon, and perhaps the thing that holds it back the most, is a good default layout. Right now after you install Chameleon you basically are forced to further configure it. That is a pain, and it leads to more pain down the road when you upgrade Chaneleon. A really solid standard that people can just enable and forget about would be fantastic. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#252 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGK2LO7X5TJVHUI6743QN2TTPQV2JANCNFSM45N622EQ> .