Page MenuHomePhabricator

[EPIC] :visited link styling should not be applied to button-type-links
Open, Needs TriagePublic

Description

Description

Some links in our interfaces function more as button than links. The distinction between buttons and links can be a bit fuzzy at times, but for example:

reply (Talk page)view filters (History page)hide (TOC)edit (section headings)
Screen Shot 2022-10-14 at 8.14.41 AM.png (364×742 px, 93 KB)
Screen Shot 2022-10-14 at 8.16.15 AM.png (378×1 px, 85 KB)
Screen Shot 2022-10-14 at 8.15.39 AM.png (516×650 px, 63 KB)
Screen Shot 2022-10-14 at 8.14.55 AM.png (338×934 px, 84 KB)

These button-type-links should not get :visited styling.

Solution (short term)

I'm not sure if there's a systematic way to approach this, or if we just have to file tasks one-by-one to fix them.

Discussion (long term)

  • One question already raised by the design systems team: should these interface elements be links in the first place? If they were buttons we would avoid the issue of :visited styling
  • What about global navigational links (for example the links in the main menu, e.g. Help, Donate, About Wikipedia, etc.)?
  • What about table of contents links?

Event Timeline

alexhollender_WMF renamed this task from [Bug] :visited link styling should not be applied to button-type-links to :visited link styling should not be applied to button-type-links.Oct 14 2022, 12:22 PM
alexhollender_WMF created this task.
  • One question already raised by the design systems team: should these interface elements be links in the first place? If they were buttons we would avoid the issue of :visited styling

Maybe not, but they keep coming up in designs year after year. I suspect enforcing this would be very difficult.

  • What about global navigational links (for example the links in the main menu, e.g. Help, Donate, About Wikipedia, etc.)?

They link to pages which can be visited, so presumably should be styled as visited?

  • What about table of contents links?

In general real hash fragments can be visited, meaning the URL with the fragment is in the user's history. If you think of "visited" as meaning "viewed that section" then the colouring is less useful, so there's an argument to disable in there, but note that fragment links can appear elsewhere in the interface and in user-generated content, so it would be difficult to change this consistently.

I'm not sure if there's a systematic way to approach this, or if we just have to file tasks one-by-one to fix them.

Likely will have to be fixed on a case-by-case basis.

reply (Talk page)

Screen Shot 2022-10-14 at 8.14.41 AM.png (364×742 px, 93 KB)

Fixed in T319013

view filters (History page)

Screen Shot 2022-10-14 at 8.16.15 AM.png (378×1 px, 85 KB)

These link to separate pages (search results) and as such it is argualby correctly to style them as "visited"

hide (TOC)

Screen Shot 2022-10-14 at 8.15.39 AM.png (516×650 px, 63 KB)

This are not rendered with <a> tags so are never given the visited link styling

edit (section headings)

Screen Shot 2022-10-14 at 8.14.55 AM.png (338×934 px, 84 KB)

These also link to a "separate" page, the edit page (although it isn't separate when using VE, but it does have a new URL), so again styling these is arguably correct.

Jdlrobson renamed this task from :visited link styling should not be applied to button-type-links to [EPIC] :visited link styling should not be applied to button-type-links.Oct 18 2022, 5:58 PM
Jdlrobson moved this task from Incoming to Epics/Goals on the Web-Team-Backlog board.

This should be considered an epic as all the screenshots are of different features here and this is not specific to Vector 2022

thanks for your comments @Esanders

edit (section headings)

Screen Shot 2022-10-14 at 8.14.55 AM.png (338×934 px, 84 KB)

These also link to a "separate" page, the edit page (although it isn't separate when using VE, but it does have a new URL), so again styling these is arguably correct.

two things that come to mind:

  • I think it might be weird to style Edit source as visited and not Edit (which can appear next to each other in the section header)
  • we don't style the Edit source link in the article toolbar as visited

This ticket is in tracking for web team and following for DST. @ovasileva is this something we plan to work on? If not, is there another more appropriate team who could work on this?