Page MenuHomePhabricator

[WtC-M2] Create reusable custom variables for layout and spacing
Closed, ResolvedPublic5 Estimated Story Points

Description

Problem

We have the need to keep reusing a set of styling variables for layout spacing that use em and rem units. Codex doesn’t provide equivalent tokens for these.

The values were originally created as WiKit tokens (see spacing tokens and layout tokens), and used in the layout of both our quality tools and the Special:NewLexeme page. We could create custom variables to replace these WiKit tokens in the individual styling file(s) relevant to each product, but that option would cause redundancy and overhead.

Solution

Since these spacing values are shared across domains, we could create them as CSS variables and collect them in a shared stylesheet file. To enable the distribution of these variables, they should either need to be in a gist file or exist in a dedicated repo.

Considerations
  • The variables should be created in a language agnostic way. Our quality tools use Sass, while Special:NewLexeme uses Less.
  • In the context of the Mismatch finder, the files that include inline variables, discrete values or WiKit tokens for spacing that need replacement are:
  • Please note that this task is about replacing spacing variables used to space layouts and page areas (i.e. all values in em and rem). For consistency with other components, custom elements like LanguageSelector should use Codex tokens for internal spacing (in px).
Acceptance criteria
  • We (re)create a set of variables for internal and layout spacing that use our preferred units
  • Any Wikidata product can reuse these variables, regardless of the selected pre-processor
  • WiKit layout and spacing tokens used to style the Mismatch Finder app are replaced by our new reusable custom variables
  • Current layout and spacing values remain unaltered after the replacement

Event Timeline

Heads-up to @ItamarWMDE and @karapayneWMDE for their kind review. Feel free to update directly if needed 🙏🏻

Sarai-WMDE renamed this task from [WtC] Create reusable custom variables for layout and spacing to [SW] [WtC-M2] Create reusable custom variables for layout and spacing.Nov 8 2023, 11:08 AM
Sarai-WMDE renamed this task from [SW] [WtC-M2] Create reusable custom variables for layout and spacing to [WtC-M2] Create reusable custom variables for layout and spacing.Nov 22 2023, 10:18 AM
Sarai-WMDE updated the task description. (Show Details)

Task Breakdown Notes
After further discussion, we believe the scope of this task is not reflected in its description. Creating this as language agnostic custom variables system requires more investigation. We are stalling this task until further discussion is possible.

@Sarai-WMDE @Arian_Bozorg

As discussed today, at this stage there is no need to create a npm package. We can simply create a single file in a repo (or even a gist) and use the raw content link when we import it into our codebase. Simply creating these as pure CSS variables should suffice.

Task Breakdown Notes:

  • The requirement for this to live in its own repository is a soft requirement as long as the variables are CSS variables, and they live in their own separate file (we can still refer to a raw CSS file from a repository for inclusion in other HTML or CSS).

All AACCs are met and no spacing alteration were detected, so the task can be considered done.

Nevertheless, I need a little help to make a decision regarding the following: As part of this task, all WiKit tokens were replaced by the new variables, but there are still some discrete spacing values in rem and em units in app.scss (lines 75 to 84, line 234...). The different token replacement tasks (T352314, T352304, T352311) mention that discrete values should also be replaced by Codex tokens, but this wasn't clearly listed as an acceptance criterion. My apologies for that. The majority of the files still contain discrete values of all sorts (spacing, color, sizes, etc), so my question is: should I create a separate task to replace all the pending discrete values that require so, or should we tackle these as part of the existing tasks? What is your preference @noarave, @guergana.tzatchkova, @HasanAkgun_WMDE?

for simplicity's sake I would lean towards a separate task that will be separately prioritized.

A separate task to replace discrete values was created: T355520