Change Details

## Background NOTE: //When creating a component task, please try to fill out the entire Background section. The rest of the task description can be populated later.// - **Description:** Create a CSS/LESS only implementation of Codex components (maybe just a subset of them) - **History:** This is an approach that has been followed by many other design systems; it will help Codex to cover use-cases where using Vue (or JS at all) would not be appropriate - **Known use case(s):** Allow teams who have performance or security constraints to achieve visual consistency with the design system without using JS/Vue - **Considerations:** Can we avoid duplication by having the CSS "components" share styles with the Vue components? Would it make sense to publish a `codex-styles` package that contains LESS mixing, which then gets used in the Codex Vue components? ### User stories - As a developer of a feature that cannot use JS for performance or security reasons, I'd like my UI to have visual consistency with the wider design system. I'd also like to be able to simply re-use pre-defined styles that look and behave correctly instead of having to write them myself. ### Previous implementations These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component. - **OOUI:** The OOUI PHP work is relevant here --- ## Codex implementation ### Component task owners - Designer: //add the main designer's name// - Developer: //add the main developer's name// ### Design spec // Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below. // A component spec sheet has not been created yet. | Component spec sheet | --- ## Stage 1: Minimum viable product (MVP) MVP includes basic layout, default states, and most important functionality. ### Acceptance criteria - [] Determine what MVP includes for this component and document this in a subtask. Assign task to designer. - [] Design MVP. Once complete, assign task to developer. - [] Implement MVP --- ## Stage 2: Additional states, features, and variants This might include a disabled state, framed/frameless designs, transitions, supporting different use cases, etc., which will be captured in separate subtasks. ### Acceptance criteria - [] Document design and implementation of additional states and features in individual subtasks - [] Complete each additional state/feature subtask --- ## Stage 3: Refinement This stage includes any final touches or bug fixes needed before the component can be deemed complete, which will be captured in separate subtasks. ### Acceptance criteria - [] Finalize docs: open and complete a subtask for any additional demos that need to be added or documentation that needs work - [] Meet accessibility standards: open and complete a subtask for any necessary accessibility improvements - [] Meet internationalization standards: open and complete a subtask to fix any i18n bugs - [] Complete testing: open and complete a subtask for any additional unit or functional tests that are needed

## Background - **Description:** Create a CSS/LESS only implementation of Codex components (maybe just a subset of them) - **History:** This is an approach that has been followed by many other design systems; it will help Codex to cover use-cases where using Vue (or JS at all) would not be appropriate - **Known use case(s):** Allow teams who have performance or security constraints to achieve visual consistency with the design system without using JS/Vue - **Considerations:** Can we avoid duplication by having the CSS "components" share styles with the Vue components? Would it make sense to publish a `codex-styles` package that contains LESS mixing, which then gets used in the Codex Vue components? ### User stories - As a developer of a feature that cannot use JS for performance or security reasons, I'd like my UI to have visual consistency with the wider design system. I'd also like to be able to simply re-use pre-defined styles that look and behave correctly instead of having to write them myself. ### Previous implementations These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component. - **OOUI:** The OOUI PHP work is relevant here

## Background NOTE: //When creating a component task, please try to fill out the entire Background section. The rest of the task description can be populated later.// - **Description:** Create a CSS/LESS only implementation of Codex components (maybe just a subset of them) - **History:** This is an approach that has been followed by many other design systems; it will help Codex to cover use-cases where using Vue (or JS at all) would not be appropriate - **Known use case(s):** Allow teams who have performance or security constraints to achieve visual consistency with the design system without using JS/Vue - **Considerations:** Can we avoid duplication by having the CSS "components" share styles with the Vue components? Would it make sense to publish a `codex-styles` package that contains LESS mixing, which then gets used in the Codex Vue components? ### User stories - As a developer of a feature that cannot use JS for performance or security reasons, I'd like my UI to have visual consistency with the wider design system. I'd also like to be able to simply re-use pre-defined styles that look and behave correctly instead of having to write them myself. ### Previous implementations These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component. - **OOUI:** The OOUI PHP work is relevant here --- ## Codex implementation ### Component task owners - Designer: //add the main designer's name// - Developer: //add the main developer's name// ### Design spec // Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below. // A component spec sheet has not been created yet. | Component spec sheet | --- ## Stage 1: Minimum viable product (MVP) MVP includes basic layout, default states, and most important functionality. ### Acceptance criteria - [] Determine what MVP includes for this component and document this in a subtask. Assign task to designer. - [] Design MVP. Once complete, assign task to developer. - [] Implement MVP --- ## Stage 2: Additional states, features, and variants This might include a disabled state, framed/frameless designs, transitions, supporting different use cases, etc., which will be captured in separate subtasks. ### Acceptance criteria - [] Document design and implementation of additional states and features in individual subtasks - [] Complete each additional state/feature subtask --- ## Stage 3: Refinement This stage includes any final touches or bug fixes needed before the component can be deemed complete, which will be captured in separate subtasks. ### Acceptance criteria - [] Finalize docs: open and complete a subtask for any additional demos that need to be added or documentation that needs work - [] Meet accessibility standards: open and complete a subtask for any necessary accessibility improvements - [] Meet internationalization standards: open and complete a subtask to fix any i18n bugs - [] Complete testing: open and complete a subtask for any additional unit or functional tests that are needed