Page MenuHomePhabricator

Decide on CSS Architecture for shared component library
Closed, ResolvedPublic



Decision around CSS architecture for the shared library. Topic encompasses: CSS preprocessor (Less, Sass), conventions (BEM, utility classes, etc), design tokens, how styles should be exported, etc.


Critical to unblock now

CSS preprocessor
  1. Less: WVUI, other WMF team-specific libraries, and MediaWiki use Less. Historically (in 2013), the decision was driven by better PHP implementation of Less.
  2. Sass: WiKit uses Sass for reasons documented in this comment.

CSS Postprocessor or native

  • Note that CSS variables, a pure CSS option, are not supported in IE11 – see also T286947 for shared components lib and T285045 (for Wikit).
  • The other big wants in the room are mixins (CSS @apply feature) and nesting (coming to a browser you trust with CSS Nesting module), which for now and the foreseeable future are not possible without a PostCSS plugin. And a build step.

Under these preconditions, neither a postprocessor nor native CSS seem to be a viable option for our environment right now.

Design tokens

See T288383 and its subtasks.

Important but less urgent

CSS Utility classes

See T285880 for previous discussion and more links.

CSS class naming

T255100 Consider CSS naming convention/methodology as coding guideline for Wikimedia projects
T259203 Clarify CSS naming scheme on combined components in WVUI

Style scoping

See T258774#7269395 for details on how WMDE approached this for WiKit.


Which CSS preprocessor will we use?

Design Systems Team proposal: Use Less or Sass. We have a preference for Less since it's supported and used in MediaWiki and across WMF extensions, but acknowledge that the two options have very similar feature sets.

What design token architecture will we implement?
How will we follow up on important but less urgent topics?

Design Systems Team proposal: If we have extra time we can discuss options and gather opinions at the summit. Then, we can either use the biweekly Front-End Standards Group meetings to discuss these topics further, or schedule a special meeting with those who are interested.


Participants at the summit decided to move forward with the creation of a new shared library from scratch (not WVUI or Wikit). A task force with representatives from key teams at WMF and WMDE will spearhead the creation of this new library and will make decisions around CSS architecture as part of that work. It may be possible to rely on PostCSS and new features of the CSS spec itself for desired features, rather than needing to continue depending on a specific pre-processor like LESS or SASS.

Event Timeline

AnneT added a subscriber: Volker_E.
AnneT added a subscriber: AnneT.
AnneT updated the task description. (Show Details)

@AnneT the google doc linked in the description

while WiKit uses Sass for reasons documented here (see point 14)

is not public. Can it be made public, or the relevant reasons posted publicly here please?

The decision for SASS was made as it was determined to have more overall gain and fewer drawbacks. Specific reasons include:

  • It is the default recommendation of vue-cli.
  • It is the weapon of choice for implementation of the latest bootstrap and foundation
  • SASS is already in use in the WMDE stack
  • Several WMDE projects are actively using SASS
  • SASS is more widely used and so is a way to lower the entry barrier for new volunteers/non-mediawiki devs

Note that vue-cli is agnostic on the preprocessor, no recommendation there. Internally it uses PostCSS!

On wider usage, popularity here a Google trends comparison of Sass, LESS and PostCSS.

We're supporting LESS in MW core with ResourceLoader and it's our widely used standard – in core, extensions and other Foundation repositories like Design Style Guide or Developer portal.
Even though I personally have preferred Sass for its syntax and some features like @extend, the differences between LESS and Sass are minimal for most part.

egardner updated the task description. (Show Details)