Change Details

## Summary Decision around CSS architecture for the shared library. Topic encompasses: CSS preprocessor (Less, Sass, CSS variables), conventions (BEM, utility classes, etc), design tokens, how styles should be exported, etc. ## Considerations ### Critical to unblock now #### CSS preprocessor * WVUI, other WMF team-specific libraries, and MediaWiki use Less, while WiKit uses Sass for reasons documented in [[ https://phabricator.wikimedia.org/T286951#7233145 | this comment ]]. [[ https://www.mediawiki.org/wiki/Requests_for_comment/LESS#Why_LESS?_Why_not_SCSS_/_Sass? | Historically (in 2013), the decision ]] was driven by better PHP implementation of LESS. ===== 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 [[ https://caniuse.com/?search=%40apply | @apply feature ]]) and nesting (coming to a browser you trust with [[ https://drafts.csswg.org/css-nesting-1/ | CSS Nesting module ]]), which for now and the foreseeable future are not possible without a PostCSS plugin. And a build step. #### Design tokens See T266688 for details and previous discussion, including [[ https://phabricator.wikimedia.org/T266688#6884221 | WMDE's evaluation of using JSON-based tokens ]]. --- ### Important but less urgent #### CSS Utility classes See T285880 for previous discussion and more links. #### Style scoping See T258774 for details on how WMDE approached this for WiKit. #### Relevant links --- ## Decisions #### Which CSS preprocessor will we use? #### What design token architecture will we implement? #### How will we follow up on important but less urgent topics? ####

## Summary 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. ## Considerations ### Critical to unblock now #### CSS preprocessor 1. **LESS**: WVUI, other WMF team-specific libraries, and MediaWiki use LESS. [[ https://www.mediawiki.org/wiki/Requests_for_comment/LESS#Why_LESS?_Why_not_SCSS_/_Sass? | Historically (in 2013), the decision ]] was driven by better PHP implementation of LESS. 2. **Sass**: WiKit uses Sass for reasons documented in [[ https://phabricator.wikimedia.org/T286951#7233145 | 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 [[ https://caniuse.com/?search=%40apply | @apply feature ]]) and nesting (coming to a browser you trust with [[ https://drafts.csswg.org/css-nesting-1/ | 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 T266688 for details and previous discussion, including [[ https://phabricator.wikimedia.org/T266688#6884221 | WMDE's evaluation of using JSON-based tokens ]]. --- ### Important but less urgent #### CSS Utility classes See T285880 for previous discussion and more links. #### Style scoping See T258774 for details on how WMDE approached this for WiKit. #### Relevant links --- ## Decisions #### Which CSS preprocessor will we use? #### What design token architecture will we implement? #### How will we follow up on important but less urgent topics? ####

## Summary Decision around CSS architecture for the shared library. Topic encompasses: CSS preprocessor (Less, SassLESS, CSS variablesSass), conventions (BEM, utility classes, etc), design tokens, how styles should be exported, etc. ## Considerations ### Critical to unblock now #### CSS preprocessor * WVUI,1. other WMF team-specific libraries**LESS**: WVUI, and MediaWiki use Lessother WMF team-specific libraries, while WiKit uses Sass for reasons documented in [[ https://phabricator.wikimedia.org/T286951#7233145 | this comment ]]and MediaWiki use LESS. [[ https://www.mediawiki.org/wiki/Requests_for_comment/LESS#Why_LESS?_Why_not_SCSS_/_Sass? | Historically (in 2013), the decision ]] was driven by better PHP implementation of LESS. ===== CSS Postprocessor or native 2. **Sass**: WiKit uses Sass for reasons documented in [[ https://phabricator.wikimedia.org/T286951#7233145 | 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 [[ https://caniuse.com/?search=%40apply | @apply feature ]]) and nesting (coming to a browser you trust with [[ https://drafts.csswg.org/css-nesting-1/ | 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 T266688 for details and previous discussion, including [[ https://phabricator.wikimedia.org/T266688#6884221 | WMDE's evaluation of using JSON-based tokens ]]. --- ### Important but less urgent #### CSS Utility classes See T285880 for previous discussion and more links. #### Style scoping See T258774 for details on how WMDE approached this for WiKit. #### Relevant links --- ## Decisions #### Which CSS preprocessor will we use? #### What design token architecture will we implement? #### How will we follow up on important but less urgent topics? ####