We've reached a community consensus for enabling TemplateStyles in de.Wiki
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/TemplateStyles#Frage
And we are really looking forward to use "real CSS" to fix problems like these:
https://wiki.martinkraft.net/mobileProbleme.html
https://wiki.martinkraft.net/mobileProblemePortale.html
https://wiki.martinkraft.net/whyWeNeedCss.html
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Enable TemplateStyles on dewiki | operations/mediawiki-config | master | +1 -0 |
According to T181188, dewiki is already using RemexHtml, so there shouldn't be any technical blockers.
TemplateStyles is being deployed to all Wikivoyages today. I'll schedule dewiki for next week.
Change 422414 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/mediawiki-config@master] Enable TemplateStyles on dewiki
Unchecked CSS changes will not be hidden for readers; filed T190945: FlaggedRevs is not compatible with TemplateStyles. Please advise whether that should be a blocker.
Unchecked CSS changes will not be hidden for readers; filed T190945: TemplateStyles is not comaptible with FlaggedRevs. Please advise whether that should be a blocker.
One could bypass that problem by making css-pages editable only by users with right "Sichter" (editor). For example by using a "Dreiviertelsperre" (editeditorprotected).
T190945 shouldn't be a blocker.
In de.Wiki only admins are allowed to change the content type (to sanitized CSS). So they are in control of the number and purpose of CSS documents and their protection status.
By the way: Although most of the templates aren't protected either, we didn't experience a lot of vandalism there. So why should CSS be worse?
You don't need the editcontentmodel to create a page with the Sanitized CSS content model.
For example, Template:Example/style.css does not exist on testwiki, but if created it will have the Sanitized CSS content model.(1)
TemplateStyles sets the default content model to sanitized-css for .css pages in the Template: namespace. I think that would surpass such permission checks.
Although most of the templates aren't protected either, we didn't experience a lot of vandalism there. So why should CSS be worse?
Template vandalism would be prevented by FlaggedRevs and CSS vandalism wouldn't. Judging from the experiences of wikis where there is no FlaggedRevs, template vandalism is not really a problem even without that extra layer of defense, so personally I wouldn't worry about it.
See also T187729 for lots of related discussion.
On the other hand, setting $wgTemplateStylesNamespaces to the empty array would prevent that and so require the explicit content model change.
Template vandalism would be prevented by FlaggedRevs and CSS vandalism wouldn't.
Technically FlaggedRevs doesn't prevent template vandalism, it just hides it from (most?) readers. Assuming someone who can stabilize the template doesn't do so without noticing the vandalism, anyway. I suppose it could "prevent" it by being a disincentive.
IMHO CSS (especially sanitised CSS) does not offer a lot of fun options to vandals. From a vandals point of view it is probably way more satisfying to lease some swear words in articles than changing the font-size.
And if something like this happens, it can be handled easily by 3/4-protecting the CSS files.
I don't think we need special protection or flagged revisions for CSS pages. As far as I'm aware, there is no such protection e.g. for Lua modules and I have yet to come across a case of Lua vandalism. Similarly to heavily used templates, also the CSS pages will be 1/2-protected if the need arises.
Let's assume good faith editors, there is nothing a vandal can break which cannot be solved by every other community member by means of a simple rollback.
Change 422414 merged by jenkins-bot:
[operations/mediawiki-config@master] Enable TemplateStyles on dewiki
Mentioned in SAL (#wikimedia-operations) [2018-04-04T17:26:07Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:422414]] Enable TemplateStyles on dewiki T190910 (duration: 01m 17s)
That is in fact the case, although for a different reason (dewiki has $wgNamespacesWithSubpages[NS_TEMPLATE] set to false).
So to use TemplateStyles one has to use Special:ChangeContentModel and set the style page content model to sanitized CSS, which is pretty bad user experience (including that the code editor is not activated when creating a new css page).
That's unexpected.
(including that the code editor is not activated when creating a new css page).
Do Special:ChangeContentModel first, then edit it.
Default content model handling should be fixed one way or other. Either by removing the override for $wgNamespacesWithSubpages[NS_TEMPLATE] (dewiki does use subpages, not sure why the software should pretend they are not subpages), or by removing the subpage check from TemplateStyles (I don't think using Template:Foo + Template:Foo.css is necessarily a worse pattern than using Template:Foo + Template:Foo/styles.css, so this would make sense on it's own), or if nothing else works we should add a hook specific to dewiki to the configuration.