Change Details

## Open questions The following open questions should be answered by this spike. ### 1. Which components will we plan to implement as CSS-only components? Thus far, we have discussed limiting this to a small set of components for which a CSS-only implementation will still be useful even after we have SSR available within MediaWiki. We've identified these components from mediawiki.ui: - anchor `a` - `form` - `label` - `button` - `input[type="text"]` - `input[type="search"]` - `input[type="radio"]` - `input[type="checkbox"]` - `select` (limited in design to only a few properties on the `select` box itself, no icons, no menu customization) - icon (debatable) ...as well as potentially including loading indicators like Skeleton and ProgressIndicator (spinner and bouncing dots). After discussing this with the web team, we've identified a set of priority components: - SearchInput: 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. - 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. - 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. #### To do - [x] Discuss with the Web team which components will be needed for the ArticleTools work so we can determine a priority set of components - [] Finalize the list of initial components to implement ### 2. How will we implement CSS-only components? We have identified 2 options: - Output Codex CSS, at least for the specified components, as a separate package so styles can apply to any markup with the appropriate classes - Release Less mixins, similar to the Link component, which can be applied to any markup as the implementer sees fit We will build a prototype of the second option using a group of components with a range of complexity (probably button, radio, and select). If needed, we will also build a prototype of the first option. #### To do - [] Build a prototype of the Less mixin components solution for a small set of components - [] Review it as a team and determine if we want to also prototype out the other option ## Acceptance criteria - [] [[ https://docs.google.com/document/d/1y6DMlrqIy0bQzAc7kdkgROs0VIlSQL3PoF0LbheVnjg/edit#heading=h.vlvz8k1kr1aj | Spike output doc ]] is complete and shared with DST - [] DST has provided feedback and aligned on scope, timeline, owner(s) - [] {T321351} description has been updated - [] Known subtasks have been added to T321351

## Open questions The following open questions should be answered by this spike. ### 1. Which components will we plan to implement as CSS-only components? Thus far, we have discussed limiting this to a small set of components for which a CSS-only implementation will still be useful even after we have SSR available within MediaWiki. We've identified these components from mediawiki.ui: - anchor `a` - `form` - `label` - `button` - `input[type="text"]` - `input[type="search"]` - `input[type="radio"]` - `input[type="checkbox"]` - `select` (limited in design to only a few properties on the `select` box itself, no icons, no menu customization) - icon (debatable) ...as well as potentially including loading indicators like Skeleton and ProgressIndicator (spinner and bouncing dots). After discussing this with the web team, we've identified a set of priority components: - SearchInput: 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. - 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. - 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. #### To do - [x] Discuss with the Web team which components will be needed for the ArticleTools work so we can determine a priority set of components - [] Finalize the list of initial components to implement ### 2. How will we implement CSS-only components? We have identified 2 options: - Output Codex CSS, at least for the specified components, as a separate package so styles can apply to any markup with the appropriate classes - Release Less mixins, similar to the Link component, which can be applied to any markup as the implementer sees fit We will build a prototype of the second option using a group of components with a range of complexity (probably button, radio, and select). If needed, we will also build a prototype of the first option. #### To do - [] Build a prototype of the Less mixin components solution for a small set of components - [] Review it as a team and determine if we want to also prototype out the other option ## Acceptance criteria - [x] Spike output doc is complete and shared with DST (saved in the description of the epic task) - [] DST has provided feedback and aligned on scope, timeline, owner(s) - [x] {T321351} description has been updated - [x] Known subtasks have been added to T321351

## Open questions The following open questions should be answered by this spike. ### 1. Which components will we plan to implement as CSS-only components? Thus far, we have discussed limiting this to a small set of components for which a CSS-only implementation will still be useful even after we have SSR available within MediaWiki. We've identified these components from mediawiki.ui: - anchor `a` - `form` - `label` - `button` - `input[type="text"]` - `input[type="search"]` - `input[type="radio"]` - `input[type="checkbox"]` - `select` (limited in design to only a few properties on the `select` box itself, no icons, no menu customization) - icon (debatable) ...as well as potentially including loading indicators like Skeleton and ProgressIndicator (spinner and bouncing dots). After discussing this with the web team, we've identified a set of priority components: - SearchInput: 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. - 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. - 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. #### To do - [x] Discuss with the Web team which components will be needed for the ArticleTools work so we can determine a priority set of components - [] Finalize the list of initial components to implement ### 2. How will we implement CSS-only components? We have identified 2 options: - Output Codex CSS, at least for the specified components, as a separate package so styles can apply to any markup with the appropriate classes - Release Less mixins, similar to the Link component, which can be applied to any markup as the implementer sees fit We will build a prototype of the second option using a group of components with a range of complexity (probably button, radio, and select). If needed, we will also build a prototype of the first option. #### To do - [] Build a prototype of the Less mixin components solution for a small set of components - [] Review it as a team and determine if we want to also prototype out the other option ## Acceptance criteria - [] [[ https://docs.google.com/document/d/1y6DMlrqIy0bQzAc7kdkgROs0VIlSQL3PoF0LbheVnjg/edit#heading=h.vlvz8k1kr1aj | Spike output doc ]]x] Spike output doc is complete and shared with DST (saved in the description of the epic task) - [] DST has provided feedback and aligned on scope, timeline, owner(s) - [x] {T321351} description has been updated - [x] Known subtasks have been added to T321351