Volker_E added a comment.
Thank you @Sarai-WMDE for the insights and the detailed write-up of WMDE's token approach. At the Foundation and its web products we went similar ways a while ago, mostly being able to exchange variable (WikimediaUI Base <https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia-ui-base/>) with tokens 1:1 when looking at the WMDE goals <https://docs.google.com/presentation/d/1Oze04iKqgBhk9cVgWL_mTkwyPAgFskHApEisa6mpIiI/edit#slide=id.g9d54c66c78_0_8> of having a - **consistent**, - **single source of truth for design**, - in a **set of predefined, centralized and traceable design decisions** Additionally we also provide the advantage Lacks of current way here is in contrast to WMDE yet: - “It’s in the tokens or it does not exist” We've been nearly completely putting all “rich” CSS values in OOUI's WikimediaUI theme into variables, with only exceptions `0`, `inherit`, or resets to default values. But we haven't put more than base/alias variables and a small number of component variables into WikimediaUI Base yet. From an resource-budgeting/maintenance overhead concerned perspective, but also from an implementors point of view I see a big issue with the component-level tokens: - There is a lot of repetition and aliasing between the global/alias token level (example provided in Wikit ADR) and component tokens. F34161792: image.png <https://phabricator.wikimedia.org/F34161792> The repetition (!DRY) is time-consuming and maintenance intensive. For every new component a large set of component specific variables has to be defined. Additionally it doesn't save from one of the biggest risks with tokens, the abstraction. Imagine a global token would be changed, with component tokens you'd have a third inherited level of abstraction, that is out of clear view when impacted by such higher-level change. Therefore **I'd strongly recommend to go a CSS way of implementation**. **From general to specific: Use only aliased base/alias variables when applicable or define component-level tokens when specifically needed.** Thinking of a handover where the component design would still include all tokens needed, but switch between base/alias and component specific ones. This way would also ensure not to invent too many new ones and provide an extra sanity check on design/implementors side as every new component token definition should let people stop and consider the decision for a moment. And possibly lead to more consistency across the interface altogether. The technological agnosticism of JSON might be of small interest for usages in apps, but we'll also have to assume that Cascading Style Sheets or derived pre- and post-processors are remaining a relatively simple central technology for providing style definitions. And even when apps are asking we could implement with a JSON translation of the currently in CSS <https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia-ui-base/+/refs/heads/master/wikimedia-ui-base.css> and LESS <https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia-ui-base/+/refs/heads/master/wikimedia-ui-base.less> available variables on the Foundation side. TASK DETAIL https://phabricator.wikimedia.org/T266688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Volker_E Cc: Michael, AnneT, Pginer-WMF, raja_wmde, ItamarWMDE, Sarai-WMDE, Aklapper, Volker_E, caldera, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, JGirault, Scott_WUaS, Niedzielski, abian, Wikidata-bugs, aude, Prtksxna, Lydia_Pintscher, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
