Last modified: 2013-04-14 09:45:14 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T49195, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 47195 - Remove skins that can't be properly supported and instead add some easy-to-support options for all skins
Remove skins that can't be properly supported and instead add some easy-to-su...
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.21.x
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-04-13 12:38 UTC by Rainer Rillke @commons.wikimedia
Modified: 2013-04-14 09:45 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rainer Rillke @commons.wikimedia 2013-04-13 12:38:04 UTC
In Bug 41246, it turned out that skins are maintained by volunteers. This is not an option for a popular CMS, especially if they can't be maintained properly. 
Removing the Cologne Blue skin completely after its main benefit was removed should be considered.

Skins often also complicate the situation so compatibility wrappers must be written (cf. mw.util.$content) that in turn suffer from other issues (e.g. being undefined or null when accessed too early) which can only be fixed with huge efforts. Another example is that some links in the quickbar in the classic (&useskin=standard) like the move link do not carry IDs.

What people often want are just some features of the skin like a different background color or smaller elements/padding/margin, a fixed sidebar. I know this because I am involved in the community and take the time listening to people's proposals.

https://meta.wikimedia.org/wiki/Turning_off_outdated_skins goes will just remove skins but does not offer options that work without editing personal js or css.

Encouraging people to edit they personal CSS, can for example lead to difficult and strange-to-detect side effects: Consider a user adding invalid CSS to their file; then ResourceLoader merges this CSS with the usergroup CSS and both will fail.
Comment 1 Daniel Friesen 2013-04-13 14:39:34 UTC
Sorry, but MediaWiki is an open-source project and large swaths of the software ARE maintained by volunteers.

And skins are an important feature. And differences between skins are a fact which is part of the fundamentals of this feature.

And there is nothing wrong with mw.util.$content being undefined. DOM nodes are not available right away. That is a fact of scripting. There is nothing new about having to wait for dependencies and dom to be ready.

Standard has been removed. Bugs in it aren't relevant. Quickbar is dead too. All that stuff was part of rotting code that was completely unmaintained by even volunteers and was actively getting in the way of development.

This doesn't look like an actual bug report with a request.
Comment 2 Andre Klapper 2013-04-13 15:52:31 UTC
This report is too vague, as it misses clear criteria when to call this request "fixed" at some point (e.g. meaning of "properly supported" is subjective).

http://meta.wikimedia.org/wiki/Talk:Turning_off_outdated_skins might be a better place to discuss first, to end up with specific and actionable items.
Comment 3 Rainer Rillke @commons.wikimedia 2013-04-14 00:08:31 UTC
(In reply to comment #1)
> differences between skins are a fact
> which is part of the fundamentals of this feature
You can't combine the feature of each skin; this is too fixed and that's why we got more skins than we could maintain.

Please don't forget: Most editors just like to work with MediaWiki. Skins are a bit like books behind glass windows. Nice to view at but very inflexible.

(off topic)
> nothing wrong with mw.util.$content being undefined [...]
> is nothing new
> about having to wait for dependencies
It should be function -taking one argument: a callback function- not a property that is null this time and the next time, maybe it is a jQuery object. Who knows?

(In reply to comment #2)
> misses clear criteria
It's when options that are really required are present so skins can be dropped.
Comment 4 Andre Klapper 2013-04-14 09:45:14 UTC
(In reply to comment #3)
> It's when options that are really required are present so skins can be
> dropped.

Again: Define "options" and define "really required". 
Former is vague, latter is subjective.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links