search

ProfessionalWiki / chameleon

Provides a highly flexible and customizable skin using Bootstrap 4
https://www.mediawiki.org/wiki/Skin:Chameleon
Other
115 stars 63 forks source link

Add more default mapping of colors #369

Open yaronkoren opened 1 year ago

yaronkoren commented 1 year ago

The colors within the specified Bootstrap swatch are not as well used within the Chameleon skin as they could be. An obvious example is OOUI widgets, like form buttons - these do not get their colors changed, though I think they should. Another big example, throughout many of the special pages, is background colors - many elements keep their default very-light-gray background color, though this too should instead come from the swatch.

yaronkoren commented 1 year ago

I've discussed this with a few people, and I now think it would make more sense to make this an addition to the Bootstrap extension, rather than to Chameleon, so that it would be usable with any skin (e.g., using Bootstrap's "standalone" mode). Presumably anyone who uses the Bootstrap extension would want as many page elements as possible - like OOUI buttons - to match the swatch that they picked, regardless of the skin they are using. Any thoughts?

malberts commented 1 year ago
I agree that all UI elements should look consistent. This goes further than just colors, though. Things like padding, border radius, etc. One example is the OOUI button which turns lighter on hover and gets an internal outline on focus. Bootstrap buttons (by default) turn darker and focus gets an external outline: Normal Hover Focus
OOUI Screenshot_20221216_084348 Screenshot_20221216_084359 Screenshot_20221216_084618
BS Screenshot_20221216_084440 Screenshot_20221216_084511 Screenshot_20221216_084640

IMO ideally this gets implemented as a custom OOUI theme: https://www.mediawiki.org/wiki/OOUI/Themes#Custom_themes

Currently the MediaWiki + Bootstrap/Chameleon CSS is already quite large. When you have a custom OOUI skin it just loads different CSS. But if you add the Bootstrap overrides as additional (S)CSS, then you're loading parts of the OOUI CSS twice (i.e. default + override).

The trouble with a custom OOUI theme is that it has to be "compiled" and it uses LESS, so you cannot directly integrate your (Bootstrap) SCSS with OOUI's build process. Also, the OOUI version is specific to each version of MediaWiki. I don't know how flexible you can go with using a mismatched version when it relates only to the OOUI theme (this doesn't touch the bundled OOUI Javascript). So potentially if you want to support 3 versions of MediaWiki then you'll have 3 different custom themes. If you want to build a custom theme that does not require rebuilding on the user's side, then you definitely want to look at using CSS Variables (https://getbootstrap.com/docs/4.6/getting-started/theming/#css-variables).

If you decide to go the additional (S)CSS route, instead of building a custom OOUI theme, then you can integrate with the rest of your SCSS directly, but then you have to weigh up the additional CSS size cost. I don't know if modern desktop browsers really care, maybe mobile browsers do, but there's also the theoretical cost of having more CSS rule overrides.

yaronkoren commented 1 year ago

@malberts - thank you for this detailed response. You're right that getting OOUI elements to line up with the Bootstrap swatch involves more than just changing one background color - ideally it will not be too hard to map all the necessary parts of it.

I had not thought about creating an OOUI theme from Bootstrap. It seems like it's a possibility, even though it requires compiling - the instructions could just tell the admin to run some compile script if they install a new swatch or change the existing swatch. That would work, no?

I'm no expert in this, but I don't think OOUI is still changing that much with each version of MediaWiki - at least, not basics like the set of CSS classes used for each widget. It seems pretty stable - all the more so now that OOUI has become sort of "deprecated": it's not actually deprecated yet, but the long-term plan is to move over to the Codex library, based on Vue.JS, and I think all the development energy has moved over to Codex. (Which means that Codex too would have to start getting supported, but I don't think it's that urgent for now.)

Anyway, making an OOUI theme might be preferable, but I also think just overriding the CSS could be a good-enough solution - I don't think the extra CSS would add that much bulk. And of course there is all the non-OOUI stuff - like setting the colors of the "selected" rows in "action=history" - which would have to be done with overrides.

malberts commented 1 year ago

the instructions could just tell the admin to run some compile script if they install a new swatch or change the existing swatch. That would work, no?

It probably won't be that easy, or at least that script will have to do a lot of work. You need to checkout the OOUI git repo, have Node/NPM installed on the server, then run grunt commands.

making an OOUI theme might be preferable, but I also think just overriding the CSS could be a good-enough solution

Yeah at this point whichever method results in something actually happening is going to be the best route.