Page MenuHomePhabricator

Add new token in Codex for "media" borders
Closed, ResolvedPublic2 Estimated Story Points

Description

Background

Description:

Currently inside MediaWiki core we have borders for thumbnails and code snippets (which I'll from now on refer to media) . The current value is #eaecf0 and it is not covered by existing design tokens. Volker suggested on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/969954 this might warrant a new token.

Thumbnail border

.mw-image-border .mw-file-element {
	border: 1px solid #eaecf0;
}

.thumbborder {
	border: 1px solid #eaecf0;
}

pre,
code,
.mw-code {
	border: @border-width-base @border-style-base #eaecf0;
}

.wikitable {
	background-color: #f8f9fa;
}

.wikitable> tr > th,
.wikitable > * > tr > th {
      background-color: #eaecf0;
}
History (if needed):

[Likely a historic artifact. Not sure how this has evolved over the years.]

Known use case(s):
image.png (1×1 px, 982 KB)
* Borders on thumbnails (example from article Porsche 914 on enwiki)
image.png (302×1 px, 156 KB)
-
image.png (536×1 px, 183 KB)
or at mediawiki.org on Codex article * Borders on code snippets (example from article CSS on enwiki)
Captura de pantalla 2023-12-20 a las 21.23.05.png (1×1 px, 368 KB)
Light divider in the ToC
Captura de pantalla 2023-12-20 a las 21.23.26.png (1×1 px, 492 KB)
Light dividers in the Tools panel

Considerations

  • Community tend to be sensitive to changes in color relating to article content.
  • Readability is key in these (border) color choices, we shouldn't over-emphasize the borders here, as they are not required to be contrast-compliant for understanding the elements difference with its surrounding text.

User stories

add at least one user story

Previous implementations

  • Codex demo: add the corresponding link to the current token's category in the Codex demo
  • Design style guide: add the corresponding Design Style Guide link, if applicable

Design spec

Open questions

Add here the questions to be answered in order to design and implement the token

Acceptance criteria (or Done)

Design

  • Design the Figma spec sheet and add it in this task
  • Add the token as Figma variable in the library. This step will be done by a DST member.

Code

  • Implement the token in Codex
  • Update components that use this token (if needed)

Event Timeline

CCiufo-WMF subscribed.

Clearing out the inbox and just getting around to this now, I wonder if this relates to / is needed for T338015: Module: Add Module component to Codex.

CCiufo-WMF renamed this task from Add new <name to be confirmed> token in Codex for "media" borders to Add new token in Codex for "media" borders.Dec 8 2023, 11:00 PM

@CCiufo-WMF Only slightest IMO. If we want to make 'module' a catch-all box, then maybe. I think it also doesn't make sense to have a media border. As code snippets are a separate thing for me. Saying this as it quickly gets confusing when to apply a Module and when not if there is no clear guidance what it actually is and should contain.

@Volker_E I've found these 2 new cases with the light border (included them in the task description):

Captura de pantalla 2023-12-20 a las 21.23.05.png (1×1 px, 368 KB)
Light divider in the ToC
Captura de pantalla 2023-12-20 a las 21.23.26.png (1×1 px, 492 KB)
Light dividers in the Tools panel
AnneT triaged this task as Medium priority.Jan 8 2024, 6:49 PM
AnneT set the point value for this task to 2.
Volker_E changed the task status from Open to In Progress.Jan 19 2024, 12:42 PM

After some conversations, there is an agreement for @border-color-muted to name this new token, so I've included the Figma exploration file with this proposal in the task description.

Here's some insight into the conversation around naming the token:

  • (Option 1) Create a new token for color #EAECF0 and decide on the naming of that token - ie. subtle-light, decorative, muted, faint
  • (Option 2) Rename @border-color-subtle to @border-color-decorative (#C8CCD1) and create a new token called @border-color-decorative-subtle (#EAECF0)

Option 2 meant we would deprecate the existing token @border-color-subtle. The deprecation process is costly in time and effort. The process would include communicating the deprecation to stakeholders, documenting the deprecation to inform developers, and refactoring affected projects.

Change 991873 had a related patch set uploaded (by LWatson; author: LWatson):

[design/codex@main] styles: Add new border color token for "media" borders

https://gerrit.wikimedia.org/r/991873

I've added the design token @border-color-muted to Codex as a decision token in codex-base.json and will assign this task to @bmartinezcalvo for design sign-off.

  • Refer to this patch to verify that the token is documented in the correct JSON file.
  • Preview the new token in Codex.

Change 991977 had a related patch set uploaded (by LWatson; author: LWatson):

[design/codex@main] styles: Apply border-color-muted in Codex

https://gerrit.wikimedia.org/r/991977

[Likely a historic artifact. Not sure how this has evolved over the years.]

For historic context; This derived from the original (2004 monobook) toc/toccolours and these were also used by the thumbs of those skins. The wikipedia sitestyles prettytable (as it was called originally) and infoboxes adapted to the toc colour schema. Eventually prettytable was added to core as wikitable. If I remember correctly the colours changed slightly in Vector 2010 for readability and these changes were back ported to monobook.

Monobook itself was heavily based on the skin of another open source project, Plone, and adapted by one of the early technical volunteers. I believe... Gabriel Wicke? to become Monobook. So likely that is where the colours stem from.

I've added the design token @border-color-muted to Codex as a decision token in codex-base.json and will assign this task to @bmartinezcalvo for design sign-off.

  • Refer to this patch to verify that the token is documented in the correct JSON file.
  • Preview the new token in Codex.

@lwatson thank you, it looks good to me.

Just a small improvement to make the list of border color tokens easy to understand, could we move the @border-color-subtle next to this new @border-color-muted? Since they are both for non-interactive borders, I would place them together. So the order would be:

  1. border-color-base
  2. border-color-interactive
  3. border-color-disabled
  4. border-color-subtle
  5. border-color-muted

I've made the same comment on patch @bmartinezcalvo, @lwatson actually pro-actively asked for that – let's follow the Figma order 👍🏼

Change 991873 merged by jenkins-bot:

[design/codex@main] styles, token: Add new border color token for "media" borders

https://gerrit.wikimedia.org/r/991873

Change 991977 merged by jenkins-bot:

[design/codex@main] styles: Apply border-color-muted in Codex

https://gerrit.wikimedia.org/r/991977

Change 992533 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v1.2.1 to v1.3.0

https://gerrit.wikimedia.org/r/992533

Change 992533 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.2.1 to v1.3.0

https://gerrit.wikimedia.org/r/992533

During our work on building guidelines and a system for constructing forms, we found a need for a sort of module, somewhat related to this task, where a group of related fields (not a fieldset) appear within a container to visually group them. When attempting to find a border token for this container, @border-color-subtle felt too dark and @border-color-muted felt too light. For now we have set it to use @border-color-muted. During our addition to colors for dark mode, we have added a new value between these two—Gray250. This value is meant to meet this need of a border color that does not feel too dark or too light.

Instead of adding yet another border token, the goal here would be to replace the value that @border-color-muted has assigned to it, from Gray200 to Gray250. This would slightly darken all existing instances of this token where it is being used. Some examples are below.

I don't think this hurts these interfaces at all, but if anything helps them by darkening the borders slightly to provide just slightly better contrast and therefore accessibility, without taking away from the visual hierarchy of an overall lighter border.

Screenshot 2024-03-18 at 10.52.30.png (1×428 px, 67 KB)

Screenshot 2024-03-18 at 10.53.06.png (1×392 px, 124 KB)

Screenshot 2024-03-18 at 10.53.48.png (1×1 px, 156 KB)

Screenshot 2024-03-18 at 10.51.07.png (762×1 px, 300 KB)

Screenshot 2024-03-18 at 10.50.16.png (1×2 px, 1 MB)