Page MenuHomePhabricator

Provide WikimediaUI Base's tokens in Wikimedia Design Style Guide following skins
Closed, DeclinedPublic

Description

Provide WikimediaUI Base's design tokens formed into Less variables in skins to enable front-end developers to make use of basic cross-foundational design properties in skin and extensions.

It contains agreed-on style values (also called design tokens: background-colors/colors from color palette, font families, borders, opacities, box-shadows, etc.) that are part of Wikimedia Foundation user interface theme of Design Style Guide in order to provide a consistent interface regardless of what front-end framework / library contributors and developers are using.

What to accomplish:

  • Provide one place for fundamental design properties shared in themes and extensions in order for possible design adaptions across Foundation products
  • Provide standardized way for developers to make use of those fundamental design properties in the products, without caring about copying and comparing hex codes, pixel sizes and other stylesheet values.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Volker_E raised the priority of this task from Lowest to High.Feb 7 2017, 3:12 AM

Ideally, a consumer should import this by doing

@import "wikimedia-ui"

So when adding this we should ensure that
$wgResourceLoaderLESSImportPaths points to a folder that contains wikimedia-ui LESS styles.
Theming can work by importing wikimedia-ui and overriding but we don't need that right away. Let's get this into core asap so we can start consistently using this and capitalise on all the good work that @Volker_E and @Ladsgroup. Ping me when a patch is up!

Change 345220 had a related patch set uploaded (by VolkerE):
[mediawiki/core@master] Provide WikimediaUI Base variables in core

https://gerrit.wikimedia.org/r/345220

Copying over from the patch set for better documentation:

@Jdforrester-WMF, 4 Apr 11:21

@Jforrester Because this file should be easily understandable and usable without having to read through OOUI-only Less variables like for example the sizing ones. In the common scenario, you'll include this file and define further variables for your product on top of these fundamental cross-organization shared ones.

My point is that this file should be updated in the same process that updates the version of OOUI, and be mastered along with that, rather than changed independently.

VolkerE Apr 4 11:42
Syncing those releases makes sense, but having it as part of OOjs UI is not helpful IMO. As this file is also consumed outside of OOjs UI contexts and needs to live in its on repository.

@Jdlrobson Apr 4 11:46
To add to what Volker has said, the reading team is heavily dependent on prototyping right now. These prototypes [1], are not built in OOjs UI and we need to keep them consistent with all our other products. For this reason alone we are using the base css file Volker is providing. Our apps team are also interested in consuming it.
Part of the headaches we are having right now are trying to keep mediawiki UI consistent with OOjs UI (we don't have time or resources to port mediawiki ui usages to OOjs UI at the moment and even if we did that is not going to be an instant fix). I'd like to see OOjs UI and mediawiki ui becoming consistent and I see this as a necessary step towards deprecating mediawiki ui.
This change seems uncontroversial and a good step to making the reading teams life easier.
[1] e.g. https://github.com/jdlrobson/weekipedia/blob/master/package.json#L73

@Jdforrester-WMF Apr 4 11:51
I'm lost. How is adding yet another part of MediaWiki UI (this file) "moving away from MediaWiki UI"? I too want to see MWUI and OOUI's MediaWiki theme look as identically as possible ahead of switching tools over, but this new file isn't used by MWUI and doesn't inherit its values from OOUI's MediaWiki theme, so I don't understand how it's meant to make the current mess easier?

@Jdlrobson Apr 4 12:42

I'm lost. How is adding yet another part of MediaWiki UI (this file) "moving away from MediaWiki UI"? I too want to see MWUI and OOUI's MediaWiki theme look as identically as possible ahead of switching tools over, but this new file isn't used by MWUI and doesn't inherit its values from OOUI's MediaWiki theme, so I don't understand how it's meant to make the current mess easier?

I think your idea of hierarchy is different from mine?
wikimedia-ui base is inherited by oojs ui
wikimedia-ui base is inherited by mediawiki ui
wikimedia-ui base is inherited by react based prototypes in reading web
etc..

  1. Our React prototypes cannot inherit from OOUI.
  2. If MediaWiki UI inherits from this file, then it is easier for mediawiki ui to be replaced by OOjs UI as a lot of the inconsistencies between the libraries are resolved.

@Jforrester-WMF Apr 4 13:06

wikimedia-ui base is inherited by oojs ui

When did that happen? I think that's totally wrong and should be reverted. OOUI MediaWiki theme is the top-level item here. When was this discussion?

@JGirault Apr 4 13:41
I believe OOUI should import wikimedia-ui-base, and not the other way around.
Although OOUI is our recommended/official UI library, it should remain up to any developer around the world to build an extension with another preferred UI library. Because, why not?
Also, depending on the situation, one developer may want to import these variables and still want nothing to do with OOUI. Kartographer is a good example: we are importing these base variables in order to override mapbox.js default style. As a developer it is currently a burden to import wikimedia-ui-base variables within an extension, and this patch solves it entirely.
As the project evolves, we are trying to rely on OOUI (even more so, by converting leaflet controls to OOUI buttons). But still, as a developer I always try to keep a project as minimal as I can. If I don't have an easy access to a variable, I may just hardcode it.
Portals is another good example: for various reasons we have wanted the project to remain minimal and the size of libraries and assets minimal, thus OOUI is not a library we needed. We only need to share the style definition.
I believe it is up to the developer (and I'm thinking, not just within the Foundation) to choose the right UI library for his project. They may choose OOUI in most cases, but realistically not all of them.
For instance, off of wikimedia-ui-base, one volunteer can start a simple wikimedia-ui-bootstrap boilerplate that I'm sure would be fantastic to build a simple webapp or quickly prototype something.
I believe it is up to us to enable developers the best we can. If we can offer these variables and enable more developers and not introduce any burden, why wouldn't we?
Finally, I don't understand why OOUI would redefine these variables or be the master version, instead of importing them like anyone else, and overriding them when necessary?
Make wikimedia-ui-base be the master version of these variables and make it available in core seems to enable everybody.

@Milimetric Apr 7 12:17
We also have plans to use https://github.com/wikimedia/WikimediaUI-base in our projects going forward (eg. Wikistats 2.0). I strongly support centralizing at least our standard style in WikimediaUI-base and using that from any dependent project.
No best practice or architectural sensibility that I have would enable me to argue otherwise. I'm not really sure why this is controversial, actually.

Jforrester Apr 7 12:40
The problem is that this code is fundamentally a lie.
"WikimediaUI repository provides stylesheets with variables containing Wikimedia Foundation wide user interface basic style values." – but these values aren't inherited by any bit of OOUI or any non-OOUI tool.
When https://phabricator.wikimedia.org/source/wikimedia-ui-base/ is used by the agreed front-end library (OOUI) then it can (and definitely should) be pulled through in that versioned release process. Doing things ad-hoc that maybe-kinda work is pure tech debt.

@Krinkle Apr 10 14:30
According to the proposal in the task I believe this is supposed to be in OOjs UI and (maybe) in skins/Vector (depending on whether we want Vector to define its variables directly based on WMUI or by proxy of setting them via the current OOjs UI theme variables), but not in core?

Responding to a few comments here:

@Jforrester-WMF Apr 4 13:06

wikimedia-ui base is inherited by oojs ui

When did that happen? I think that's totally wrong and should be reverted. OOUI MediaWiki theme is the top-level item here. When was this discussion?

We've had this discussion already several months ago and were (PMs across verticals, developers & designers) from my understanding clear to say in our current technical environment we can't make all Foundation products use OOUI's MediaWiki theme variables, nor is it the best idea, as it has a lot of OOUI specifics simply not usable for this very basic helper variables.
I support the other comment about wikimedia-ui-base in need to be pulled through into OOjs UI MediaWiki theme. But we need to start somewhere. So that's my debt not having provided another patch with its usage in MediaWiki theme, but only other exemplified usage first.

@Krinkle Apr 10 14:30
According to the proposal in the task I believe this is supposed to be in OOjs UI and (maybe) in skins/Vector (depending on whether we want Vector to define its variables directly based on WMUI or by proxy of setting them via the current OOjs UI theme variables), but not in core?

The major shortcoming I see with this and I don't have a solution for, is, that extension developers would be excluded from using the variables, which is opposing the unifying leverage of this approach.
It makes total sense from all the points collected to have it as separate repository being included in non MediaWiki core based products or prototypes, but not providing it to extensions/solutions (like MediaViewer, like RCFilters) limits its use massively and negatively.

On the opposite side, it's also understandable to not have it as core part as we would like to provide a default and not a Wikimedia focussed out-of-the-box experience.
If we're assuming that we're in Wikimedia land and OOjs UI is installed in those instances and extension developers can access those variables with a fallback to default vars, that seems like a reasonable connection. That bridge is the part in question then.

The problem is that this code is fundamentally a lie.
"WikimediaUI repository provides stylesheets with variables containing Wikimedia Foundation wide user interface basic style values." – but these values aren't inherited by any bit of OOUI or any non-OOUI tool.
When https://phabricator.wikimedia.org/source/wikimedia-ui-base/ is used by the agreed front-end library (OOUI) then it can (and definitely should) be pulled through in that versioned release process. Doing things ad-hoc that maybe-kinda work is pure tech debt.

@Jdforrester-WMF , should we raise a phab task to get WikimediaUI into the Mediawiki theme in OOUI? There is no fundamental issue there, right?

@Jdforrester-WMF , should we raise a phab task to get WikimediaUI into the Mediawiki theme in OOUI?

Yes. We'd also need to make that the canonical source of truth for the "WikimediaUI" variables, but that's pretty trivial.

@Jdforrester-WMF , should we raise a phab task to get WikimediaUI into the Mediawiki theme in OOUI?

Yes. We'd also need to make that the canonical source of truth for the "WikimediaUI" variables, but that's pretty trivial.

I am not sure what you're referring to when you say that. Could you clarify in the subtask?

I don't care where the thing lives.. I just need to access it. I'm a little worried about the tech debt accumulating as a result of not having a shared definition file (many files are not using variables but copy/pasting the values. Maybe we can get this resolved during the hackathon?

I don't care where the thing lives.. I just need to access it. I'm a little worried about the tech debt accumulating as a result of not having a shared definition file (many files are not using variables but copy/pasting the values.

This.

I don't care where the thing lives.. I just need to access it. I'm a little worried about the tech debt accumulating as a result of not having a shared definition file (many files are not using variables but copy/pasting the values.

This.

T165652: Package and publish WikimediaUI to npm

Change 372904 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/core@master] resources: Provide the WikimediaUI LESS config vars for all OOjs UI users

https://gerrit.wikimedia.org/r/372904

Change 372904 merged by jenkins-bot:
[mediawiki/core@master] resources: Provide the WikimediaUI LESS config vars for all OOjs UI users

https://gerrit.wikimedia.org/r/372904

So this is now directly available to OOUI users. I'm wary of adding Yet Another ResourceLoader Module for just these variables, because (a) RL module bloat is a performance issue and (b) I worry of making a commitment to providing this that way for a while which we might not want. What's left to do before this can be marked Resolved? Actual inheritance and use in legacy code like SpecailSearch.php and frameworks like MWUI?

So this is now directly available to OOUI users.

Yep, within oojs-ui themes (which are in the oojs-ui repository, presently), wikimedia-ui-base is available for importing.

And the OOUI "wikimediaui" theme, does this, and assigns several of its OOUI theme variables based on wikimedia-ui-base variables (example).

I'm wary of adding Yet Another ResourceLoader Module for just these variables, because (a) RL module bloat is a performance issue and (b) I worry of making a commitment to providing this that way for a while which we might not want.

Agreed. This shouldn't be registered as ResourceLoader module. It should be provided through the Less import path in a way that is dynamically constructed in by ResourceLoader based on skin and/or ooui config.

What's left to do before this can be marked Resolved? Actual inheritance and use in legacy code like SpecailSearch.php and frameworks like MWUI?

Replied at T112747#4093591.

Jdforrester-WMF changed the task status from Open to Stalled.Jul 18 2018, 10:23 AM

This is stalled until @Krinkle provides a way forward.

This is stalled until @Krinkle provides a way forward.

The plan I drew up in Barcelona with Volker, requires T112747 to be solved first. (Already linked as subtask).

Change 573028 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Intermediary solution for @import 'theme/wikimedia-ui-base';: duplicate/move the file to 'core/resources/src/mediawiki.less/theme' until a solution to import the original is implemented.

https://gerrit.wikimedia.org/r/573028

Change 573062 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Consistently follow the CSS variable naming convention with font variable names. Document the fonts.

https://gerrit.wikimedia.org/r/573062

The patch imports wikimedia-ui-base.less to core.git/resources/src/mediawiki.less/wikimedia-ui-base.less for the time being.

Once this 2-year long discussion is concluded, the wikimedia-ui-base.less file can be moved to its final location. Should the @import 'wikimedia-ui-base'; line change, it will be easy (<10 commits) to replace those.

Change 573403 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Enable importing wikimedia-ui-base.less in skins, extensions (intermediate solution)

https://gerrit.wikimedia.org/r/573403

The last patch is a stupid simple one-liner import. No changes to the tooling, no copy, nor move.

Change 573403 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Enable importing 'wikimedia-ui-base.less' in skins, extensions

https://gerrit.wikimedia.org/r/573403

Change 579857 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Provide theme-agnostic style variables

https://gerrit.wikimedia.org/r/579857

Change 579858 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Separate wikimedia-ui-base.less resource from OOUI into its own folder

https://gerrit.wikimedia.org/r/579858

Volker_E renamed this task from Provide WikimediaUI Base's base.less in MW core to Provide WikimediaUI Base's base.less in Wikimedia Design Style Guide following skins.Mar 16 2021, 11:56 PM
Volker_E updated the task description. (Show Details)
Volker_E removed a subscriber: Demian.
Volker_E renamed this task from Provide WikimediaUI Base's base.less in Wikimedia Design Style Guide following skins to Provide WikimediaUI Base's tokens in Wikimedia Design Style Guide following skins.Mar 17 2021, 12:25 AM
Volker_E changed the task status from Stalled to Open.
Volker_E updated the task description. (Show Details)

Change 579858 abandoned by Ladsgroup:

[mediawiki/core@master] resources: Separate wikimedia-ui-base.less resource from OOUI into its own folder

Reason:

The author has been banned indef from our tech spaces and the patch has not been touched for really long time.

https://gerrit.wikimedia.org/r/579858

Change 573403 abandoned by VolkerE:

[mediawiki/core@master] resources: Enable importing 'wikimedia-ui-base.less' in skins, extensions

Reason:

Has been achieved with better architectural decisions in I3a8c89d8558022077

https://gerrit.wikimedia.org/r/573403

Change 345220 abandoned by VolkerE:

[mediawiki/core@master] [WIP] Provide WikimediaUI Base variables in core

Reason:

The successor of WikimediaUI Base, Codex design tokens, has been achieved to be provided under better architecture in I3a8c89d8558022077

https://gerrit.wikimedia.org/r/345220