Background
Description:
Links signal to users the possibility to navigate to a different page, view or resource, when they click or tap on them.
We have the following color links:
- Blue (progressive): color for default links
- Red: reserved for links to (“new”) articles and pages without content.
History:
Commonly used component that exists in OOUI and is documented in the Design Style Guide; see links below.
Known use case(s):
- Abstract Wikipedia:
- Link within text block
- Single link
- Link in a table cell
- Red links in any article page: (more details here)
Considerations:
- Any changes in the links could affect the "navigational menu links" task T311270
User stories
- As a designer/developer I need to create blue links to use them as regular links in my projects.
- As a designer/developer I need to create red links to use them as new article or pages without content in my projects.
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: Links
- OOUI: Figma specs (component was not created in the OOUI demo)
- Vue: UserLink.vue in Wikibase
- WMDE version WMDE link
Codex implementation
Component task owners
- Designer: @bmartinezcalvo
- Developer: add the main developer's name
Design spec
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