Page MenuHomePhabricator

Clearer naming conventions for Non-JS CSS files like `mediawiki.action.history.styles.css`
Closed, DuplicatePublic


Currently we implement modules with two CSS/Less files named

  • mediawiki.action.history.css
  • mediawiki.action.history.styles.css

One for styling elements in the main rendering, and the other for elements specific to the JS enhanced experience.

Let's find a less confusing and redundant naming pattern.
Are all the occasions of *.styles.css only including “basic” styles for non-JS support like the above as this task is a follow-up to
Others in core are:

  • mediawiki.action.edit.styles.css
  • mediawiki.special.preferences.styles.css
  • mediawiki.special.upload.styles.css

Event Timeline

Echo uses in its [[ | modules folder two sub-folders ]] – nojs and styles – side-by-side.
I like the idea of a nojs folder, but would rather like to see it as child of the corresponding folder like

  • mv resources/src/mediawiki.action/mediawiki.action.history.css resources/src/mediawiki.action/nojs/mediawiki.action.history.css

Can ResourceLoader handle two files with the same name in two folders?

Volker_E moved this task from Inbox to Accepted on the Front-end-Standards-Group board.

After a short conversation at the Front-end-Standards-Group meeting @Krinkle ensured, that RL would be able to handle two files like laid out above easily, but there has been a tendency lately (?), to change file names towards file paths reflecting module hierarchy.
The proposals that have been brought up:

  • resources/src/mediawiki.action/history.css
  • resources/src/mediawiki.action/nojs/history.css
  • resources/src/mediawiki.action/history/styles.css
  • resources/src/mediawiki.action/history/noscript.css
  • resources/src/mediawiki.action/history/basic.css or main.css
  • resources/src/mediawiki.action/history/dynamic.css or interactive.css

There has been a related patch on bringing more sanity to print-only CSS files by @Fomafix

This task has been assigned to the same task owner for more than two years. Resetting task assignee due to inactivity, to decrease task cookie-licking and to get a slightly more realistic overview of plans. Please feel free to assign this task to yourself again if you still realistically work or plan to work on this task - it would be welcome!

For tips how to manage individual work in Phabricator (noisy notifications, lists of task, etc.), see for available options.
(For the records, two emails were sent to assignee addresses before resetting assignees. See T228575 for more info and for potential feedback. Thanks!)