Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add more default mapping of colors #369

Open
yaronkoren opened this issue Nov 29, 2022 · 4 comments
Open

Add more default mapping of colors #369

yaronkoren opened this issue Nov 29, 2022 · 4 comments

Comments

@yaronkoren
Copy link

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
Copy link
Author

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
Copy link
Contributor

malberts commented Dec 16, 2022

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
Copy link
Author

@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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants