Page MenuHomePhabricator

Devise a generic way for theme-agnostic stylesheets to adapt to the current theme
Open, LowPublic

Description

I would like it if there was a way to provide OOUI-theme-specific styles in regular ResourceLoader modules shipped with MediaWiki.

My use case is the DateInputWidget. It is styled specifically for the default WikimediaUI theme, and while it looks neat there:

It's looks out of place in Apex-theme using skins:

(That is actually not quite as awful as I was afraid, but still.)

Event Timeline

matmarex raised the priority of this task from to Needs Triage.
matmarex updated the task description. (Show Details)
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 16 2015, 12:56 PM

A very simple braindead way would be for OO.ui.Theme to add a CSS class like oo-ui-theme-apex to <body>, which could then be used in styles. It would mean that we'd unnecessarily ship the styles for all themes to all users.

A very simple braindead way would be for OO.ui.Theme to add a CSS class like oo-ui-theme-apex to <body>, which could then be used in styles. It would mean that we'd unnecessarily ship the styles for all themes to all users.

Simple way first and better way later?

Maybe an equivalent to skinStyles named themeStyles or something?

Simple way first and better way later?

Alright, let's.

Maybe an equivalent to skinStyles named themeStyles or something?

I'm not sure if we want to integrate OOUI into MediaWiki that tightly :/

Simple way first and better way later?

Alright, let's.

Actually, nevermind. I'm not currently going to work on anything that would need this functionality, and I don't want to create tech debt in case we change our mind tomorrow. Somebody else can add the five lines of code somewhere into OutputPage::setupOOUI() / OutputPage::headElement() when needed.

Are you specifically looking for a way to define different stylesheets (like module properties themeStyles would allow), or would scope resolution within a single stylesheet suffice?

E.g. We could make ooui variables available in less stylesheets provided by other core and extension modules that depend on ooui. Perhaps through the Less import directory path and then importing the theme's variables file.

That way it could dynamically adapt itself to the current theme by using only standard variables that all themes implement.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptMar 1 2016, 12:18 AM
Krinkle triaged this task as Low priority.Mar 1 2016, 12:18 AM
Krinkle set Security to None.
Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.
matmarex added a comment.EditedMar 7 2016, 4:26 PM

I was thinking of something like themeStyles, yes, although I guess making the theme name for current skin available as a Less variable would also work (there's a couple of ways in Less, involving mixins, to switch on variable value).

matmarex claimed this task.Jul 12 2016, 9:15 PM

Change 298637 had a related patch set uploaded (by Bartosz Dziewoński):
mw.widgets.DateInputWidget: Add Apex-theme-specific styles

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

Krinkle renamed this task from Devise a way to provide OOUI-theme-specific styles in regular ResourceLoader modules to Devise a generic way for theme-agnostic stylesheets to adapt to the current theme.Jul 19 2016, 7:05 PM

Proposal:

  • Define a set of standard variables (and maybe some functions/mixins) that will have default values that individual skins (or their OOjs UI themes) can override.
  • Provide a way to import that from any less module (e.g. make that part of the current skin/theme available as public import path).

For example:

Defaults in mediawiki-core:/resources/src/mediawiki.less/theme/defaults.less. Importable as @import theme/defaults.less. An empty file that just imports this would be at mediawiki-core:/resources/src/mediawiki.less/theme/theme.less.

By default, if a skin registers no OOUI theme and no custom theme file, @import theme.less will import that. Otherwise, it will resolve to the current skin's theme file.

Assuming we'll make OOUI's defaults are equal or a superset of what MediaWiki standardises, skins that register an OOUI theme (SkinOOUIThemes) won't need to do anything. Other skins can provide their theme file via a new config (e.g. SkinThemeDir: { skinname: path } or something).

matmarex removed matmarex as the assignee of this task.Jul 20 2016, 6:49 PM
matmarex removed a project: Patch-For-Review.

That sounds nice, but I am not convinced that it will be sufficient to express the stylistic differences even between the two built-in themes (Apex and MediaWiki), much less any third-party ones (if anyone ever creates them). :/

@Krinkle I like the proposal, in one little note: I think it's overkill to have both, defaults.less and theme.less. theme.less seems sufficient to me carrying the variables.

@Krinkle I like the proposal, in one little note: I think it's overkill to have both, defaults.less and theme.less. theme.less

I suggested having both as otherwise it would greatly complicate versioning and future changes. If we start with 2 variables and then later "add" another (btw, what would "add" mean without a default), all skins would need to implement it, otherwise we can't safely reference it anywhere without risking fatal errors.

@Krinkle Ok, but that would refer to the mediawiki.less/default.less only, not to a theme, or? As it are Less variables, if a theme doesn't implement it, it would fallback to the default.less if it's not available in theme/theme.less?!

Restricted Application added a project: UI-Standardization. · View Herald TranscriptSep 14 2016, 7:03 PM

At M82 @Jdlrobson wrote:

@Volker_E What's the problem with having resources/wikimedia-base.less which is a copy and paste of the current distribution of your wikimedia-base repo (in absence of being able to use a package manager) - we do this for jquery and other files?
mediawiki.ui/variables.less can import from the new file to keep its contract but move us away from using that.
e.g. @mediaWikiVarible: @wikimedia-ui-variable
I will happily help migrate us away from mediawiki ui variables if that's what's needed but I worry about having all these places to look...

The problem is in my current understanding, that we shouldn't necessarily provide a WikimediaUI theme as default for MediaWiki from a software product point of view. Two related issues are problematic from my point of view:

  • The bundling of MW to Foundation use cases, where a default (empty) theme is a more-free out-of-the-box state.
  • A lot of problems that we're solving on the technical side are also resembled on the UI/presentational side and it's hard to come up with another default variant aside of WikimediaUI, given our scarce resources. Exemplified at the color palette M82, a useful production-ready accessible alternative palette is technically very hard to achieve.
Volker_E moved this task from Backlog to Accepted on the Front-end-Standards-Group board.

Change 345440 had a related patch set uploaded (by VolkerE):
[mediawiki/core@master] Provide theme-agnostic style variables

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

Volker_E moved this task from Backlog to Doing on the OOUI board.Apr 7 2017, 12:19 AM

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

Renewed proposal below, based on feedback from later comments and in-person with @Volker_E last week.

Goal

The end-result is that any Less stylesheet loaded by ResourceLoader can do @import 'mediawiki.theme.variables'; and that would provide theme variables associated with the current MediaWiki skin. The skin in turn may delegate to something else, like wikimedia-ui-base, or OOUI, or perhaps even derived from other libs' (eg. Bootstrap).

Take note here that ResourceLoader modules by design, already vary by skin, with existing features such as skinStyles, skinScripts, getLessVars($context), and getStyles($context) all varying by skin.

Implementation

Currently, ResourceLoader instantiates Less_Parser with a mostly empty ImportPaths array. (Albeit extendable via the deprecated wgResourceLoaderLESSImportPaths, T140807.)

My proposal is to make ResourceLoaderFileModule dynamically add one entry to this array based on the current skin.

The skin would declare (perhaps via skin.json) where its mediawiki.theme file(s) are.

At run-time, from the perspective of a random style module, import paths could end up as follows:

[
 "/resources/src/mediawiki.less/", # mediawiki.mixins, mediawiki.theme, mediawiki.theme.default
 "/skins/Vector/mediawiki.less/" # mediawiki.theme
]

MediaWiki core's mediawiki.theme.less file would be an empty placeholder proxying default, for cases where the skin does not register a theme file. The default file would be the place where we declare the "standard variable" names, a bit of documentation, with generic (unpinionetad) value as default (perhaps like a CSS reset, or with initial and inherit keywords).

core/.../mediawiki.less/mediawiki.theme.less
@import "mediawiki.theme.default"

Vector's mediawiki.theme.less file would shadow this file with its own, which could look like this:

Vector/mediawiki.less/mediawiki.theme.less
@import "mediawiki.theme.default"
@import "wikimedia-ui-base"

Other skins could potentially place direct variable assignments here instead.

Standard variables

The part I'm not yet sure of is which variable names we're going to define in the theme file. In other words, which variables should be standardised as shared across skins.

  • (master) wikimedia-ui-base.less defines 106 variables.
  • (master) oojs-ui/.../blank/common.less defines 7 variables.
    • (master) oojs-ui/.../apex/common.less defines 7 variables and 43 additional.
    • (master) oojs-ui/.../wikimediaui/common.less defines 7 variables and 111 additional.

I'm gonna leave that for during Code Review for now. I guess when we write this we should start with a single use case in mind that we can use to test it with (e.g. a particular place in core or an extension where we want to use a skin-dependent variable that we can also agree on can be set by multiple skins).

Restricted Application added a project: Performance-Team. · View Herald TranscriptMar 30 2018, 1:17 AM
Imarlier moved this task from Inbox to Radar on the Performance-Team board.Apr 2 2018, 8:22 PM
Imarlier edited projects, added Performance-Team (Radar); removed Performance-Team.

Change 434211 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] [WIP] resourceloader: Add skin-based 'mediawiki.variables' import for LESS

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

Change 434212 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] mediawiki.variables: Add @font-family-sans

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

Change 434214 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/skins/Vector@master] Implement mediawiki.variables for Vector

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

Change 434215 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/skins/MonoBook@master] Implement mediawiki.variables for MonoBook

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

Change 434213 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/core@master] mediawiki.variables: Add @border-radius-base

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

Change 434212 abandoned by Krinkle:
mediawiki.variables: Add @font-family-sans

Reason:
Combined with Icf86c930a3b5524254

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

Change 434213 abandoned by Krinkle:
mediawiki.variables: Add @border-radius-base

Reason:
Combined with Icf86c930a3b5524254

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

MtMNC added a subscriber: MtMNC.Mar 18 2019, 8:02 AM

Implementing SkinLessVariablesImportPaths would be valuable for Theme (https://www.mediawiki.org/wiki/Extension:Theme). For example, v4 of the Refreshed skin relies heavily on a custom set of LESS mixins. If Refreshed could give extensions easy access to those mixins through ResourceLoader, writing custom themes for Refreshed would be much easier.