Page MenuHomePhabricator

Selected table cells in Wikidata Query UI are almost unreadable
Closed, ResolvedPublic


Selected cells in the table result view now have a way too saturated background color that makes the contents almost unreadable.

Reported by @Moebeus on Telegram.


  • Run a Wikidata query with tabular results, example
  • Click a table cell to select it

Non-hyperlink content has poor color contrast:

Screen Shot 2023-10-31 at 15.34.51.png (150×600 px, 8 KB)

Hyperlink content is entirely unreadable, it’s the exact same color:
Screen Shot 2023-10-31 at 15.34.53.png (150×600 px, 8 KB)

(Hovering over it changes it to barely readable:)
Screen Shot 2023-10-31 at 15.35.55.png (150×600 px, 8 KB)


Acceptance criteria:

  • The color is restored to a lighter version.

Open questions:

Event Timeline

(The color was changed yesterday in styles: Replace WikimediaUI Base with Codex Design Tokens, and the table cell highlight was evidently a part that I didn’t test. I’ll defer to the designers to decide what the color should be instead.)

Less urgent (doesn’t affect readability, just aesthetics), but might as well discuss it here too: I’m pretty sure the “splitter” between the Query Helper and the SPARQL code editor didn’t use to be this saturated either.

Screen Shot 2023-10-31 at 15.48.23.png (720×1 px, 50 KB)

Edit – it used to look like this (disregard the “localhost”):

Screen Shot 2023-10-31 at 15.55.23.png (720×1 px, 48 KB)

Shouldn't the acceptance criteria be that text and links in selected table cells have enough contrast?

As Lucas mentioned, this is an unwanted consequence of the process of replacing legacy styling variables. My assumption was that a variable must have been replaced by another with an equivalent name but a different value.

I just found that to be correct and that we need to do two changes:

  1. In line 469, the right token to use would be @background-color-progressive-subtle (instead of @background-color-progressive). This will fix the contrast issue that now affects selected cells.
  1. The same goes for line 584. This will return the splitter to its original color.

Human error is very likely and understandable in these comprehensive replacement processes. Sorry for the oversight! Wishing we could rely on visual regression testing.

Change 970420 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[wikidata/query/gui@master] Fix two colors

I just found that to be correct and that we need to do two changes:

Thanks! Yeah, the old variable name was kind of confusing in retrospect, if I understand correctly. Uploaded a change with -subtle, which looks good to me in local testing.

(Pulling into the sprint board since most of the work was done already [I’m counting Sarai’s comment as most of the work, me putting the patch together based on that didn’t take long])

Change 970420 merged by jenkins-bot:

[wikidata/query/gui@master] Fix two colors

Change 970729 had a related patch set uploaded (by WDQSGuiBuilder; author: WDQSGuiBuilder):

[wikidata/query/gui-deploy@production] Merging from 38178de4420b7a0fef5887167eb1e0c448e073d5

Change 970729 merged by Lucas Werkmeister (WMDE):

[wikidata/query/gui-deploy@production] Merging from 38178de4420b7a0fef5887167eb1e0c448e073d5

Arian_Bozorg claimed this task.
Arian_Bozorg subscribed.

Looks good to me, thanks so much :)