I would appreciate it very much if the CSS-sanitizer would no longer block modern CSS functions - especially:

@Aklapper I just ran into this problem again.

The following tasks are still open to complete the onboarding guide from my side:

Just checked it on de.Wiki and it seems to be working.
@Tgr Thanks for the express delivery!

@Tgr Thanks for the implementation. It would be good ta have it deployed on Commons asap, because we also need some time to build and test the landing pages - that need to be ready on Thursday evening latest.

@Jdlrobson The problem is, that with MediaQueries react to the viewport width - not to the width of the content column. The very same viewport-width can result in totally different content widths, depending on the skin, the content lives in.

• In Minerva e.g. the content column is limited but fills up the full viewport on smaller devices.
• In Vector the content column floats to infinit but has to share its space with the side column
• In Timeless there are to side-columns and a max-width
• etc.

So for a really good working layout, one needs to know, which skin one is in.

I can't stress enough that it's really important to be able to use this feature right from the beginning of the campaign on. We had a significant slump in contributors last year, which, according to our analysis, can also be attributed to the inadequate optimization for the increasing proportion of mobile users.

@Tgr: Any plans, when this is going to be deployed.
As I told you on Wikimania. We need this feature for the LandingPages of this years WLM-Campaigns - starting in little more than a week now.

@Tgr @Deskana Just as a quick reminder: We talked about this task on Wikimania. And both of you agreed, that it should be possible to implement and deploy it by mid August, so that is ready to use for this years WLM campaign (starting end of this month).

@Aklapper Please revert the vandalism of @Vvjjkkii (also in other tickets).

Btw. an additional skin class on .mw-parser-output wouldn't solve the problem, since it is not possible to specify a selector for this element in TemplateStyles. On .mw-parser-output is different from within .mw-parser-output.

In T197617#4300908, @stjn wrote:

However, wouldn’t it eliminate the goal of mw-parser-output if such selector was allowed?

I would recommend, to suffix (instead of prefix) any selector including body with .mw-parser-output

IMHO there is nothing to be said against enabling subpages in de.Wiki, since they are already widely used in the Template-Namespaces anyhow – including but not limited to the documentation pages under "xy/Doku".

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.

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?

I too, don't see a reason, why it should be necessary to prevent people from using <templatestyles> within normal Wiki-Pages. There are quite some use cases where styles are only necessary for a single page – e.g. the MainPage or the central Meta-Pages. And it would be just a waste of energy to force people to create single-use-templates for that.

Jepp. I tested that via resizing and I think, that we should implement it in a way that it works when resizing, since it is quite common to resizes the browser while reading and comparing another document.
I've already seen a banner with some of the changes applied.

@kai.nissen thanks for the fast reaction!
I just rechecked it. Here are my comments:

Hi! Thanks for implementing the banner. Although the overall look'n'feel is quite good already, I do have some requests and suggestions concerning the layout:

+1 (We talked about this in Esino Lario.)

We still got the some layout-issues:

@Jdlrobson Sorry, but I don't see a difference between a "PageImage" and a "LeadImage" here:

Beside that this suggestion would rise editorial problems – especially if the WikiData-images would overrule (3.) the images used in the local articles:

Please differentiate between Commons' project goal and the international legal reality. Copyright laws are complex – especially in an international context. And regardless of its ambitions, there are a lot of Commons images that can not be used in certain language versions. E.G. German Wikipedia can not use all the images wth licence templates implementing {{Urheberrechtlich_geschützt}}
https://commons.wikimedia.org/wiki/Special:WhatLinksHere/Template:Urheberrechtlich_gesch%C3%BCtzt

@Nemo_bis sorry, but you don't get the point: This is not just a problem of this very image (and it definitely can not be solved by a deletion request). This is a general problem:

As I already pointed out in T87336 this is not really a good idea from the copyright point of view, because..

• pageimages belong to the language versions of wikipedia and therefore need to obey the local copyright laws..
• while WikiData seems to be based on US-copyright alone.

@Nemo_bs: Does that really solve the problem? No it doesn't!
It just demonstrates that we do have another problem and that task T95026 isn't a solution but an implementation that would cause a lot of copyright problems itself:

This task is really important, because the current system of using the first image regardless of its context produces strange results sometimes. Take the german Dean Martin article for example:
https://de.wikipedia.org/w/index.php?title=Dean_Martin&action=info

Imho for volunteers like us the key benefit of OTRS Version 5 is the mobile ready user interface. Being able to Prozess some Tickets while commuting would realy increase our productivity.

@matmarex We are in the middle of Wiki Loves Monuments right now. For multi uploads this probably is the most busy time of the year. Therefore it is really important to fix this issue as fast as possible!

Just as a note:
I am running a small wiki for the students attending my lecture on the same shared hosting servers we are talking about here. This Wiki was also affected by the block, since it included instant commons (which may be one of the main use cases for API-access from servers).

I just tested it and the button appears and works.

Since the distortion is the major argument against using pano images in Wikipedia, it would be great if this viewer not only integrates with commons, but with MediaWiki as well. An integration into the MediaViewer or some kind of extension that can be enabled via common.js

Even if Fair Use is the excuse to ignore the the CC attribution requirements, this feature has to be disabled in all language versions, where Fair Use does not exist (e.g. most of continental Europe).