Page MenuHomePhabricator

[SPIKE] Decide which CSS-only components to build and in what order
Closed, ResolvedPublic3 Estimated Story PointsSpike


This spike covers determining which CSS components to build for the MVP implementation and long-term.

Previous implementations

  • OOUI: The OOUI PHP work is relevant here
  • mediawiki.ui is of concern. Former and current modules
    • button: buttons are one of the most used mediawiki.ui components, especially by the Web team. However, the majority of uses are for icon buttons, which means we need...
    • icon: another heavily used mediawiki.ui component. Complicating factors: the Codex Icon component isn't easily converted to css-only, and Web needs mobile styles for buttons (e.g. larger touchpoints), which may belong in Codex or may belong elsewhere.
    • anchor a
    • form
    • label
    • input[type="text"]
    • input[type="search"]: the best thing we can do to unblock the Web team at the moment is reduce the maintenance cost of TypeaheadSearch. We can do that by releasing mixins for SearchInput (and potentially a few other styles needed for the server-rendered version of the search input in Vector). See T322077.
    • input[type="radio"]
    • input[type="checkbox"]
    • select (limited)

Other components of interest

  • Message: messageBox is well-contained and generated in a predictable way, plus the styles are fairly simple and easy to share via a mixin (or maybe even just design tokens). This would make it a great initial test case.
  • Loading indicators:
    • progress bar
    • progress indicators
    • skeleton

Acceptance criteria

  • DST works with other teams to determine which components would be best to build as part of MVP
  • DST documents this and opens subtasks for MVP implementation, at least

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Restricted Application changed the subtype of this task from "Task" to "Spike". · View Herald TranscriptNov 15 2022, 11:19 PM

For icon, I think we'd probably have to write PHP code that reads the icons.json file from Codex and outputs <svg> tags with the appropriate contents. Some of these building blocks already exist in ResourceLoader\CodexModule::getIcons(), for the others we'd need to port the resolveIcon() and shouldFlip() functions to PHP. If we do that, I think writing a PHP version of CdxIcon is very doable. (Supporting browsers that don't support inline <svg> tags hopefully wouldn't be necessary, but if it is, it should be doable using a similar technique as what ResourceLoader\ImageModule uses currently.)

Decide which CSS-only components to build and in what order

Based on the proposed implementation path under consideration (see, I think the answer to this question is: All Codex components will get a corresponding set of stand-alone CSS styles, and this will happen as soon as we re-organize the library into sub-packages that can be built as separate modules for use in ResourceLoader.

Some components like Icon or Select may need special styling for the non-JS implementation, but in most cases we will just re-use the existing styles – we are just making them available independently from the component JS inside of MediaWiki.

egardner changed the task status from Open to In Progress.Dec 9 2022, 6:02 PM
egardner triaged this task as High priority.
egardner set the point value for this task to 3.
egardner claimed this task.