Page MenuHomePhabricator

Phase out JS-based legacy page indicators
Open, LowestPublic

Description

Many years ago, the Page status indicators was added to MediaWiki. This recognised the common need of wikis to display icons and small interfaces on the top right of article headers.

Prior to this feature, the way communties accomplished this is with absolute-relative positionining overrides using inline CSS, where each kind of icon reserved a specific offset (e.g. pixels 0-50 from the top right might be for featured articles, pixels 55-100 for coordinates link, pixels 105-200 for "spoken audio" etc.).

This method was hard to maintain for editors, sometimes caused different icons to overlap each other due to offsets being out of sync, and created a user experience that was confusing due to icons appearing in seemingly random places. In the example above, on articles with just a coordinate link, it would appear oddly floating in the middle of the title bar as the space around it was reserved for other icons that might be there.

This was somewhat mitigated by the use of a site-wide javascript customisation snippet that, after the page loads, would take any of these icons, strip away their reserved position offsets, and line them up in order from offset 0.

This however adds a JS payload, and causes jarring reshuffling of the layout after initial page render, which means the page settles much later than it normally would.

This task is to help communities finish migration away from this approach to the standard <indicator> which handles all this with our core framework for this purpose, without need to "adjust" it after the fact on the browser's end while the user is looking at it.

Commons.js pages that contain Top_icon_raw (there are also other places to search):

Todo:

Ready for script and style removal:

Notes:

On each of these wikis, search in all namespaces for insource:/Top_icon_raw/ to find the usages that may need to be converted from e.g. <div class="Top_icon_raw">…</div> to <indicator name="…">…</indicator>.

Event Timeline

FGoodwin changed the task status from Open to In Progress.Apr 10 2024, 3:05 PM

Made relevant changes on-wiki for those wikis I had access to; I didn't make changes on individual users' pages. @Krinkle

@FGoodwin can you list out which wikis you made changes to?

Made edits across wikis; given the range of wikis and variety of pages across languages needing changes, encouraging communities to make associated edits.

Aklapper changed the task status from In Progress to Open.Apr 11 2025, 10:21 PM

Resetting task status from "In Progress" to "Open" as this task has been "in progress" for more than one year (see T380300). Feel free to set that status again, or rather break down into smaller subtasks.

BPirkle added subscribers: FGoodwin, BPirkle.

Removing inactive assignee

Probably the search should be something more like this one, which catches non-Common.js pages that do appear quite relevant.

Probably the search should be something more like this one, which catches non-Common.js pages that do appear quite relevant.

They are not relevant.

  • The Common.js query yields 16 results from 16 wikis, of which 15 are wikis that use the feature and need migration, and 1 is a talk page.
  • The suggested query yields 38 results. This including the same 15 wiki results that we care about, plus 21 redundant CSS pages ("Common.css", "Print.css", "Common.css/Tweaks.css"), plus 2 false positives (code comment in "Monobook.js" on nlwiki, and an unused "vis.js" gadget file on elwikisource).

We often begin with the complete wildcard CSS/JS preset and narrow it down when filing a task, so that we have an easy list to work from. (I don't know if that's what @Samwilson did, but it's what I would have done.)