The MVP spec sheet has been created for blue and red links. I've added it in the task description and you can also find it here. I've added some open questions in the task, once they are resolved I will update the spec sheet if needed.

I think it would be helpful to understand how folks would use a Link component in Vue-based applications.

Do we need a "component" at all, or could this just be handled with an appropriate set of styles? Maybe the component is only used for a specific kind of link – hyperlink appearing within a paragraph of text for example (as opposed to icons/buttons/menu items that may still end up being <a> elements in the DOM).

Regarding red links, blue links, etc – some of this is MediaWiki-specific behavior. A red link still goes to an empty page on MediaWiki, with a prompt to the user to create the page. These links are used to visually indicate gaps in knowledge and invite contributors to fill them in.

So far we have been designing Codex to be independent of MW (Components/styles to not rely on or assume the presence of skins for example). Does it make sense to talk about a "red link" outside of a MediaWiki context? There may be non-wiki sites that eventually use Codex (like the Foundation's Toolhub app) – would such a site ever need to display red links?

If "red link" behavior is specific to MediaWiki (and I think maybe it is), we should proceed carefully here. Maybe a consumer of these components would need to provide their own way of determining whether or not a given Wiki page exists (which probably involves making a client-side API request if the link was not generated server-side; this has performance implications if there are a ton of links on a page). In that case, we should design the Link component so that the red link functionality is optional and not active by default.

For internal/external links the situation is a little bit simpler; it would be easy enough for a Link component to perform an automatic check to determine if the target URL had a different hostname than that of the current page, and show the external link icon if so. But this is probably something we'd want to allow the user to enable/disable via prop.

TLDR; links are a very fundamental part of web UIs and we should think carefully about where/how a Link component would be used. Maybe we just want styles instead.

Another thing regarding "red links":

Do we want to name it "Destructive" to follow the same nomenclature as we have in buttons?

I think red links need to be clearly differentiated from "destructive" styling. Clicking on a red link does not delete a page; instead it takes the user to a placeholder page for a given title and prompts them to start editing. So the meaning is totally different

The use of red to indicate "missing content" is a historical thing in MediaWiki that long predates our design system.

In T313507#8116257, @egardner wrote:

Another thing regarding "red links":

Do we want to name it "Destructive" to follow the same nomenclature as we have in buttons?

I think red links need to be clearly differentiated from "destructive" styling. Clicking on a red link does not delete a page; instead it takes the user to a placeholder page for a given title and prompts them to start editing. So the meaning is totally different

The use of red to indicate "missing content" is a historical thing in MediaWiki that long predates our design system.

@egardner I know Red links are not for destructive actions as destructive buttons are. I think we should always define the same names for all our set of intents/flavors components and we have some options to follow this:

1. Progressive/ Destructive: it's the name we have in other components as buttons and also the ones defined in our new color tokens, so the logical thing would be to follow this nomenclature (although I know destructive for these Red links is not the best name)
2. Progressive/ Danger: what if we replace destructive name with danger in all our components and color tokens in order to use it for more destructive elements, error elements and red links? I know destructive is common and well know in our system but doesn't work for all red cases we have (e.g. currently we need two different color tokens for destructive and error)

@bmartinezcalvo @egardner Adding on to a question by Bárbara on Slack about possible icons on Red Links:
Red links are a MediaWiki/Wiki project speciality and, because of their solely use as links to not yet filled articles, will never carry icons start or end.

I would suggest to continue using “Red link” as label as it's the chosen label from the community and it isn't sufficiently described with destructive or danger. It's a special feature, that needs special handling and would otherwise be more confusing by either vague thematic grouping (red link becoming part of danger group) and separation from a long established label.
For Codex outside of wiki projects Red Links are also a component type that is highly probable fully ignored.

In T313507#8118837, @Volker_E wrote:

I would suggest to continue using “Red link” as label as it's the chosen label from the community and it isn't sufficiently described with destructive or danger.

@Volker_E if we use the name Red link then the logical solution to be consistent with the nomenclature would be to name the other as Blue link. Apart from the blue link, we need to think in possible future names in case we want to introduce a new dark/subtle link in our system in some moment. So we have 3 options with the names:

1. Name the links with the same flavors of our tokens: Progressive/ Destructive/ Neutral (in case we would introduce a new dark link)
2. Name the links with the name of the color used: Blue link/ Red links/ Black link (I don't agree with these names since we only use the global names of colors in the primitive colors but never in the decisions)
3. Find new names that match with the use of each link: Base link (blue)/ New link (red)/ Subtle link

In T313507#8118837, @Volker_E wrote:

@bmartinezcalvo @egardner Adding on to a question by Bárbara on Slack about possible icons on Red Links:
Red links are a MediaWiki/Wiki project speciality and, because of their solely use as links to not yet filled articles, will never carry icons start or end.

@Volker_E regarding icons I think we should create the Link component with the configurable properties Red/Blue and Icon/noIcon (as we have in button component with its flavors) and explain to use red links for new pages without icon (as I explained in the recommendations in the Figma spec sheet). One thing are the props of the component and other how we want to use this component according to each case.

In terms of usage, I'd consider the "blue" links to be the default; dark/subtle links and redlinks would be alternate styles.

What about non-text links (link tags that wrap other elements)? Is that a part of this work? Or does Link Component/Link Style only apply to text links?

After a design sync with @Volker_E and @Sarai-WMDE I've created this new version of the Link specs with the following:

• Separated blue link and red link in different specs since they have different props:
  • Link (blue) will have start and external link icon props while
  • Red link will not have any icon props and it will not use color tokens since our text color tokens are reserved for destructive elements, so Red link will use component tokens instead
• We commented to use the following names:
  • Link: this will be our base link, in this case the link is blue but in the future it could be expanded to a new dark variant so this link could be blue or black in case we add it)
  • Red link: we used this name for links used for [new] pages without content since it's so common in our community
• Icon-only link will not be implemented since we don't have any use case with this props
• Disabled state won't be added as state since we don't have any use case with disabled links
• Underlined will be implement as component prop but we will use the not underlined link by default
• Any text size and format from our text tokens could be used as link text

The task is ready to be implemented since the Figma spec was added in the task and almost all open questions were solved.

@DAbad we should update the Design Style Guide since the type of links and names don't match with the ones defined in the Figma spec. Should the DSG update be part of this MVP task or the Epic T309248

I believe the work on this scope MVP is done (it is heavily informed by the outcome of another spike, T314332). We can move on to implementation now (which I guess will be handled in a separate ticket yet to be created?).

As an aside, our proposed solution to T314332: Distribute design system styles as part of Codex should clear up any confusion around how "red links" (which are MW-specific) should get handled in Codex (which exists outside of MW): we will provide a "red link" LESS mixin alongside the standard link mixin so that consumers can apply it where appropriate. Users of Codex who are not working in a MediaWiki environment can simply ignore this.

In T313507#8204018, @egardner wrote:

I believe the work on this scope MVP is done (it is heavily informed by the outcome of another spike, T314332). We can move on to implementation now (which I guess will be handled in a separate ticket yet to be created?).

@egardner to finish this task we need to update T309248 with the MVP scope (as it's specified in the acceptance criteria). To complete this we need to:

• 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

So we need to assign a developer for this task (will you be the developer for this?) and then implement it. Then I think this will be done in this task and we don't need to create another ticket for the implementation, right?

Implementation will be done in https://phabricator.wikimedia.org/T309248.

As per team discussion, implementation will be determined after our review of: https://phabricator.wikimedia.org/T314332 which is scheduled for Sept 1, 2022.