Topic on Manual talk:Coding conventions/CSS

In 2015, S added the already-long-recommend practice of avoiding clashes between extensions' styles by prefixing the class names. However, @Krinkle has reverted this, claiming:

The ext- prefix has afaik never been established. It was written here in 2015 and since then adopted in 3 extensions presumably only from reading it here. We generally don't distinguish between something being a core component or an extension component. That's what namespaces are for, e.g. mw-foo the "foo" feature, whether bundled, core or extension is not important.)

Let's discuss?

Basically I do appreciate the strategy of prefixing selectors, especially class names.

We have a huge pile of selector orgins, which are assigned to cause special effects and special decorations:

• MW core
• MW extensions
• Skin and navigation elements, page structure
• Site gadgets
• User scripts
• TemplateStyles within projects
• So-called “global gadgets” and “global templates” and “global modules”
• Dynamically generated classes and ID, like headline IDs etc.
• This local MainPage is telling me: class="ext-discussiontools-replytool-enabled ext-discussiontools-newtopictool-enabled ext-discussiontools-sourcemodetoolbar-enabled ext-discussiontools-topicsubscription-enabled skin-vector mediawiki ltr sitedir-ltr mw-hide-empty-elt ns-0 ns-subject page-MediaWiki rootpage-MediaWiki skin-vector-2022 action-view"

There is no registry for class names visible, neither for MW nor anywhere else.

• By reserving mw- and ext- at least no conflict is expected with those.
• ext-extName- is rather robust since extension names are unique and quite stable, with exception of cite and echo (later CiteThisPage and Notification).
• Since ext-extName- is unique and easily tracked back to the extension, each extension just needs to administrate their own sub-identifiers within their business, not interfering with anybody else, even not checking entire core whether this word has been used. And core does not need to take care whether there is or ever might be an extension with such a name.
• We do need more prefix policies, not less.
• Since there is no central MW core selector registration, and everybody can setup any extension under any name not yet used for extensions, even within MW name conflicts may occur. Looking at Category:All extensions I am not sure that they never ever collide with any core functionality. E.g. arrays authors checkpoint collection comments contributors counter look like regular English words which might easily clash with any purpose of core mw- selectors.
• If ext- policy shall be terminated, the replacement is at least mw- (as modified), not simply omitting any prefix.
• There is also PHP programming on 3rd party out of WMF area.

The existing word is problematic and likely to create work for my team.

The problem with the `mw-` prefix is that when skins use it, it gives the illusion of code something from core that can be relied on. In Vector and Minerva at least we have been trying to move away from this, and exclusively using `mw-` only inside core code. For example `mw-body` is not a class that applies to all skins, but `mw-body-content` is. This creates a lot of confusion when classes only apply to Vector but not Monobook for example.

At very least, could we suggest mw-<extname>- or mw-<skinname> if we insist on the mw- prefix. In skins we have been using the skin name for skin-specific code e.g. vector-body, minerva-body as it makes it easier for gadget developers to understand the context in which the classes apply.

Agreed, mw- is a bad one to use. mw-<extname>- and mw-<skinname>- could work, though ext- and by analogy skin- seems just as good?

Whether something is an extension or core can change, as can its name e.g. Flow/Structured Discussions, Echo/Notifications/core?, Vector (and the short-lived Vector extension), Monobook, phab:T28751, and phab:T31145 off the cuff.

I don't particularly think it's a big deal to use 'ext-/skin-' but those become (small) lies if something moves from to the other.

Particularly regarding skins, whether you put something in mw- or in skin-, you still add a name that might just end up cargo-copied to some other skin for e.g. compatibility with gadgets (not yet a solved issue), or which has the potential for reuse at a later date and now you're stuck with another name that doesn't tell quite the right story.

I agree that system software should carry a prefix regardless, and even given the above I'd probably say I agree with That's what namespaces are for, e.g. mw-foo the "foo" feature, whether bundled, core or extension is not important.) Just know that we'd end up with a bunch of mw-echo and mw-flow prefixed names floating around possibly in core.

It's astonishingly rare that HTML-generating code (i.e., a feature) is moved into or out of core, however.

Neither skins nor extensions are limited to MediaWiki staff, and many many old extensions and skins were not adopted ever, or removed from canonical MW maintenance.

• Therefore a selector specific to a particular skin or extension is not necessarily a mw-ext- or mw-skin-.
• A new skin may be developed as volunteer experiment, perhaps the dark mode (which is impossible for wiki content but may be used for interface area) or a different mobile experience. They might be included into MW support later. Remember Timeless cologneblue nostalgia MySkin Athena. They should not change their selector naming strategy when changing classification.
• The same goes for JavaScript gadgets developed within a Wikipedia, but offered globally by MediaWiki one day since convincing. Remember navigation popups.

It is quite obvious what skin and gadget and extension matters are, and what a slim core even for non-WMF projects is supporting as minimal solution.

• Therefore no mass migration is expected, if there is a long term and clear concept what core business shall be and how to extend this by additional features from any source.

MediaWiki staff

Can you explain what you think this means? There are no "MediaWiki staff". Do you mean "Wikimedia Foundation, Wikimedia Deutschland, Wikimedia Sevrige, and other paid and volunteer engineers working on MediaWiki core and Wikimedia-deployed extensions, libraries, services, tools, and skins"?

I can't understand your comment.

I do mean all people involved into MedaWiki development, but especially narrowing to WMF employees who are making the final decisions rather than volunteers. Deciding which extensions are merged with core or which skins will be maintained for WMF wikis is mostly confirmed by product managers etc.

On the other hand, everybody might develop an experimental extension or skin. Those need selectors, even if not part of default distribution of MediaWiki.

Deciding which extensions are merged with core […] is mostly confirmed by product managers etc.

That is not true. Why do you think that?

I got this impression over many years.

If it is really “not true” please tell me several examples from the last decade where such a decison has been made by volunteers only without any WMF employee involved and finally approving.

> If it is really “not true” please tell me several examples from the last decade where such a decison has been made by volunteers only without any WMF employee involved and finally approving.

That's not what you said? You claimed decisions were made by product managers, which is not true and has never been true. There is no product manager for MediaWiki. The very few scope decisions that have been made have been made by the MediaWiki development community following the normal consensus process.

But clearly you're here for an argument rather than to spread information, so I'll just disengage. Thanks!

I also like the ext- convention, and would like to see this recommendation returned to the manual. It seems that the main objection is that it's not a widespread practice — but I'm not sure it has to be, to still be useful (and it'll only grow in usage, if we let it).

OK, I've re-added it for now; improvements welcome!

Great, thanks! Looks good.