## 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:** Skeletons are loading indicators that take the approximate shape of the UI elements they are acting as a placeholder for.
- **History:** There are two main tasks and threads that should be taken into consideration when tackling the definition of this pattern: {https://phabricator.wikimedia.org/T280842} and {https://phabricator.wikimedia.org/T266028}.
- **Known use case(s):** Skeleton loaders are currently used in production in the following scenarios: Within Growth's Newcomer homepage suggested edits modules (or cards), as loading indicators for images in Wikipedia articles (only in Minerva), as loading indicators for the main search's menu item thumbnails in Minerva.
- **Considerations:** This pattern should be approved by design team before being introduced in our design system. Its place among other progress/loading indicators (T266028) and usage recommendations should also be properly defined.
### User stories
- As a designer and developer, I want to be able to reuse a skeleton animation to visually indicate to users that UI content is loading.
### Previous implementations
These artifacts are listed for historical context. The figma spec, linked below, is the source of truth for the new component.
- **Design style guide:** Pending. See T280842
- **OOUI:** -
- **Vue:** -
The most relevant implementations of skeleton loaders are in MobileForntend and Minerva skin (using the class `.image-lazy-loaded`), and GrowthExperiments project (`.se-card-image.skeleton`, `.se-card-extract.skeleton`, `.se-card-pageviews.skeleton`).
---
## Codex implementation
### Component task owners
- Designer: @Sarai-WMDE
- Developer: //add the main developer's name//
### Design spec
WIP. 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
### Acceptance criteria
- [] Document design and implementation of additional states and features in individual subtasks
- [] Complete each additional state/feature subtask
---
## Stage 3: Refinement
### 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