I think some communities would want that protection on some level, so I can’t really fathom why anything like a user right to edit TemplateStyles wasn’t introduced.

"I think some communities would want that protection on some level" isn't very good justification for adding features. Once some communities actually do want it, then we'd have a better idea of the actual requirements such a feature would need.

since other such tools, e. g. Gadgets 2.0, have the respective user rights that allow end-users and communities to restrict or loosen up the right to editing in some ways

On the other hand, neither Scribunto nor templates themselves have special user rights. TemplateStyles is much more similar to those than to Gadgets.

Specifically, an edit to a gadget can run arbitrary JavaScript code in the browser of everyone who visits, so those edits need to be locked down to trusted user groups. TemplateStyles has no such ability, the worst that someone can do is vandalize in ways that are (for the most part if not entirely) already possible with inline CSS and wikitext (about which, let's not go into details here).

In T187729#3985777, @Anomie wrote:

"I think some communities would want that protection on some level" isn't very good justification for adding features. Once some communities actually do want it, then we'd have a better idea of the actual requirements such a feature would need.

There is expected consensus in Russian Wikipedia to enable it for editing by admins and technical admins, so I have written in advance about this. However, the fact that there is no clear demand enough (until the discussion in ruwiki ends) for now doesn’t mean that there will be no demand from MediaWiki/Wikimedia communities that would like to use this extension down the road.

In T187729#3985777, @Anomie wrote:

On the other hand, neither Scribunto nor templates themselves have special user rights. TemplateStyles is much more similar to those than to Gadgets.

Modules and templates can be restricted via namespace protection, so there is no real need to have a user right around it (same with Gadgets 2.0, TBF, but they still have it either way). TemplateStyles, on the other hand, is a special class of pages that can be only restricted via hacks such as Titleblacklist.

In T187729#3985938, @stjn wrote:

There is expected consensus in Russian Wikipedia to enable it for editing by admins and technical admins

Just out of curiosity, has the discussion been influenced by FUD-slinging, or are there real concerns with the feature that lead to that expected consensus?

However, the fact that there is no clear demand enough (until the discussion in ruwiki ends) for now doesn’t mean that there will be no demand from MediaWiki/Wikimedia communities that would like to use this extension down the road.

It doesn't mean there will be either. As I said, "might" isn't a very good reason to go adding features.

And if it turns out it's only Russian Wikipedia that wants this, it might be better to add the restriction something like this instead.

Modules and templates can be restricted via namespace protection,

That's not a perfect solution, though. {{SomeOtherNamespace:Title}} works as well for pages not in the Template namespace, though. Scribunto doesn't currently allow its modules to live outside the Module namespace, but it has been proposed. And in either case, using namespace-level protection would also prevent non-privileged users from updating documentation when /doc subpages are used.

In T187729#3986048, @Anomie wrote:

Just out of curiosity, has the discussion been influenced by FUD-slinging, or are there real concerns with the feature that lead to that expected consensus?

Don’t know what exactly do you call ‘FUD-slinging’ so can’t comment on that. I would call those concerns legitimate, but I am a little biased since I also share them.

In T187729#3986048, @Anomie wrote:

And if it turns out it's only Russian Wikipedia that wants this, it might be better to add the restriction something like this instead.

It is rather counter-productive and insulting to use a link to something that is called ‘a shitty hack’ in this discussion.

In T187729#3986048, @Anomie wrote:

That's not a perfect solution, though. {{SomeOtherNamespace:Title}} works as well for pages not in the Template namespace, though. Scribunto doesn't currently allow its modules to live outside the Module namespace, but it has been proposed. And in either case, using namespace-level protection would also prevent non-privileged users from updating documentation when /doc subpages are used.

Well, there is some programmatic solution with its caveats, there is no such solution for TemplateStyles.

I get that the developers have their own vision of what problems do TemplateStyles solve and how they can be used, but I don’t see why my proposal gets in the way of that or deserves such opposition, and this is no RfC to restrict TemplateStyles usage.

In T187729#3986048, @Anomie wrote:

And if it turns out it's only Russian Wikipedia that wants this, it might be better to add the restriction something like this instead.

No, it doesn't. Hebrew Wikipedia already decided to ask sanitized-css permission be given to autopatrol users only. I'll file a new task in about five hours, after the official finalizing of this decision.

Just out of curiosity, has the discussion been influenced by FUD-slinging

Yeah, formely I had on opinion in this manner. But then I realized that it is possible to repaint and rearrange the whole interface on the website.

It is said in introduction to TemplateStyles that you are doing parsing of styles and the majority of css3 syntax is supported.

By the way, if you are doing parsing, why not to add .mw-parser-output to the beginning of each selector? Simple regex expression will do the job.

And long discussions on restricting user access could be eliminated.

In T187729#4003511, @The-city-not-present wrote:

By the way, if you are doing parsing, why not to add .mw-parser-output to the beginning of each selector? Simple regex expression will do the job.

The extension already does this but it doesn’t protect against styling parts of the content outside the template scope.

In T187729#4003511, @The-city-not-present wrote:

But then I realized that it is possible to repaint and rearrange the whole interface on the website.

This is incorrect.

By the way, if you are doing parsing, why not to add .mw-parser-output to the beginning of each selector?

This is, in fact, exactly what TemplateStyles does. And it's why that mw-parser-output wrapper was added in the first place.

Simple regex expression will do the job.

I'm not confident that that is true. css-sanitizer takes the safer route of actually parsing the selector lists and prefixing each selector.

In T187729#4003522, @stjn wrote:

The extension already does this but it doesn’t protect against styling parts of the content outside the template scope.

True, although you can write wikitext without TemplateStyles that screws with content outside the template scope too.

In T187729#4003511, @The-city-not-present wrote:

But then I realized that it is possible to repaint and rearrange the whole interface on the website.

Not quite, but you can paint over it which is practically the same. That's a solvable problem (T40848 has some suggestions, it's not public though), it just wasn't seen as a high priority given that TemplateStyles doesn't introduce anything new.

That's the crucial point, IMO - almost anything bad you could do with TemplateStyles you can already do right now, and it hasn't proven much of a problem. There's the occasional technically skilled vandal who manages to obscure the page somehow so the edit has to be reverted from the recentchanges link, but it's a small nuisance only and there is no reason to expect that it would become worse after enabling TemplateStyles. The only difference I can think of is that it will be possible to do very targeted vandalism (e.g. a certain screen resolution only) which might fly under the radar for longer (but is also less disruptive).

By the way, if you are doing parsing, why not to add .mw-parser-output to the beginning of each selector? Simple regex expression will do the job.

T483 has some discussion on all the exciting ways in which a naive regex-based parser breaks. That is only of historical interest now, though, since @Anomie wrote a full, spec-compliant CSS parser for TemplateStyles which does prefix selectors.

One scenario in which this user right would be more meaningful were to add a configuration flag to restrict styling in wikitext (ban the position attribute, everything else is relatively harmless I think) and switch that on once the wiki has migrated to TemplateStyles. Together with the user right, that would be a real impediment in CSS vandalism, without much negative impact on contributors.

On the other hand, CSS vandalism is already not much of an issue, so maybe this would be a solution in search of a problem.

I'd like to join the people who are asking: Is this an actual problem?

Is this a problem in svwiki, where this feature is already deployed?

Why are there supposed to be differences between projects? "The Syldavian Wikipedia community asks for it" is not, by itself, a good explanation. If there is an actual problem with vandalism, then yes, there should be permissions. If not, let's not make imagine blockers out of thin air.

In T187729#4005559, @Amire80 wrote:

Is this a problem in svwiki, where this feature is already deployed?

Since the test on Swedish Wikipedia was run for less than a week, it is not entirely correct to ask this.

In T187729#4005565, @stjn wrote:

In T187729#4005559, @Amire80 wrote:

Is this a problem in svwiki, where this feature is already deployed?

Since the test on Swedish Wikipedia was run for less than a week, it is not entirely correct to ask this.

It's somewhat more correct than to talk about problems in languages where it was not yet deployed at all.

In T187729#4055827, @Deskana wrote:

Gergő notes in T133410#4055687 that this task is based on a misunderstanding of the threat model. A security restriction such as this one would achieve next to nothing in terms of security since styles can be embedded directly in the template. Additionally, TemplateStyles has already undergone and passed a security review in T133408.

For the above reasons, this task is declined.

A pity. Could you change your mind, or at least listen to the reasons why it seems, at least to our community, as wrong decision, please? Because it's much better than a new discussion in our community to turn off such a wonderful tool as TemplateStyles at all, just because of security leak. Thank you.

In T187729#4055839, @IKhitron wrote:

A pity. Could you change your mind, or at least listen to the reasons why it seems, at least to our community, as wrong decision, please? Because it's much better than a new discussion in our community to turn off such a wonderful tool as TemplateStyles at all, just because of security leak.

I already explained it. I'll put it more bluntly then: the "security threat" behind this task is imaginary because the styles can be embedded directly in the template. Experienced developers and security experts have told you this already, and now I've told you twice as well. I'm not going to have engineers spend their time fixing imaginary security holes.

If you won't use a piece of software because of imaginary security holes, so be it.

In T187729#4055843, @Deskana wrote:

I already explained it. I'll put it more bluntly then: the "security threat" behind this task is imaginary because the styles can be embedded directly in the template. Experienced developers and security experts have told you this already, and now I've told you twice as well. I'm not going to have engineers spend their time fixing imaginary security holes.

More pity. You explained your side, but we can't explain why what the things you just said seem wrong to us. You can disagree, but at least you could listen.

In T187729#4055843, @Deskana wrote:

I already explained it. I'll put it more bluntly then: the "security threat" behind this task is imaginary because the styles can be embedded directly in the template. Experienced developers and security experts have told you this already, and now I've told you twice as well. I'm not going to have engineers spend their time fixing imaginary security holes.

Didn’t want to spill the beans on this, but your arguments do not convince anyone. When you would have ability to do this through the inline styles − maybe they would, yes. When you would have ability to add any animations (@keyframes) to inline styles, maybe they would, yes. When you would have ability to add transitions, to change the appearance of default elements of the site inside the template or inside the content area, maybe they would, yes.

For now it seems like developers have a stance that TemplateStyles can be used in one true way and the communities that want to use it for different purposes can sod off, because developers of TemplateStyles obviously share only their own vision.

In T187729#4056200, @stjn wrote:

Didn’t want to spill the beans on this, but your arguments do not convince anyone. When you would have ability to do this through the inline styles − maybe they would, yes. When you would have ability to add any animations (@keyframes) to inline styles, maybe they would, yes. When you would have ability to add transitions, to change the appearance of default elements of the site inside the template or inside the content area, maybe they would, yes.

What makes any of those things worse than changing random words to "poop" or other vandalism, inserting shock images, or things like T10679, that all have been done with inline styles in templates, that necessitates extraordinary protections for TemplateStyles?

Great. Now, eventually, I can answer. If you create a template, you use it in many pages. It could be 30, or 30,000, but it's a large number. And if it's 30,000, you protect it. With TemplateStyles, a lot of cases will be for one particular page. Maybe even most. And an edit in css file does not appear in recent changes and especially in watchlist for this particular page. So, most of the people will not know that the page was changed, when css was. And TemplateStyles is much more powerful than inline css. Incredibly more. Imagine that you add a new class with TemplateStyles, "fifth column in table is italic", and add this class name to some table in a particular page. And a year after some vandal adds .references {color: white;}, so the change will not be at the table at all, but in absolutely different place of the page. Inline css is always local, inside div or span scope. So they are not the same, period. And also, it has no sence to protect each css page, much simpler to create a permission. This is why we decided allowing this to autoparolled only (the community minority was against this, and asked editinterface only, but they lost), and a year or three years after, when we'll be more used to this, we'll reconsider, and possibly remove this restriction. Thank you.

In T187729#4056782, @IKhitron wrote:

And an edit in css file does not appear in recent changes and especially in watchlist for this particular page. So, most of the people will not know that the page was changed, when css was.

The same happens with templates. You can change a template without that affecting the watch list entries or recent changes entries of the articles using that template. Additionally, the CSS pages used in the article are in the Transcluded templates list (page information) and in the Templates used in this page list (edit), so it is exactly the same as the templates for that too.

How is TemplateStyles worse than changing the tags of a template to have non-closed tags that would break the whole layout of the article or adding <div style="display:none"> at the beginning of random articles to make them look empty?

Please, do not quote a part of my words only. If it was just this, it was exactly as in templates. I'm talking about all the context, all what I said.

How is TemplateStyles worse than changing the tags of a template to have non-closed tags that would break the whole layout of the article or adding <div style="display:none"> at the beginning of random articles to make them look empty?

The difference is that if somebody that do not understand in templates or css will see you code, they will open the page at this first line (or fifth, or wherenever the code was changed), to see how does it looks at this particular place. Again, you can't add inline code in line number one, so the change will affect only from the line number one hundred, but look the same until that. It can be done theoretically, but you should have permissions to edit mediawiki:common.css, and the vandal has not.

In T187729#4056782, @IKhitron wrote:

With TemplateStyles, a lot of cases will be for one particular page. Maybe even most.

That seems unlikely to me, although I suppose it's possible. It strikes me as more likely that TemplateStyles will be used for meta-templates like enwiki's mbox family.

That can be true for templates too. For example, enwiki has many templates along the lines of https://en.wikipedia.org/wiki/Template:Dallas_weatherbox, and there have been proposals to do that with some kinds of infoboxes.

And an edit in css file does not appear in recent changes and especially in watchlist for this particular page. So, most of the people will not know that the page was changed, when css was.

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

I also note that TemplateStyles stylesheets will show up in the "templates used in this page" at the bottom of the (non-VE) edit form, and will work with scripts such as this one or anything else that people might use to catch template vandalism now.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

In T187729#4056924, @Anomie wrote:

In T187729#4056782, @IKhitron wrote:

With TemplateStyles, a lot of cases will be for one particular page. Maybe even most.

That seems unlikely to me, although I suppose it's possible. It strikes me as more likely that TemplateStyles will be used for meta-templates like enwiki's mbox family.

You'll see.

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

No. I said with the page name.

And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

Yes, so again, if it would just this, and not all the context, it would be OK.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

I can give you a problematic code with any css operator.

And at the and, guys: I'm not trying to convince you that I'm right and you are wrong. We do not ask to make these restrictions for all wikis. It's just for us, we believe it can be problematically vandal-wise in our wiki, so it is local. I'm sure you can prove me for example that editinterface permission should exist, and you do not force it to al wikis, or should not exist, pick one, and remove it for all wikis. It's an issue of local policy, so please do not make policy decisions for us, exactly as we do not do it to somebody else. Thank you.

In T187729#4056984, @IKhitron wrote:

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

No. I said with the page name.

If that's what you meant, then the same applies to edits to "normal" templates.

And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

Yes, so again, if it would just this, and not all the context, it would be OK.

I don't understand what you're trying to say here.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

I can give you a problematic code with any css operator.

This seems to be a non sequitur.

And at the and, guys: I'm not trying to convince you that I'm right and you are wrong. We do not ask to make these restrictions for all wikis. It's just for us, we believe it can be problematically vandal-wise in our wiki, so it is local. I'm sure you can prove me for example that editinterface permission should exist, and you do not force it to al wikis, or should not exist, pick one, and remove it for all wikis. It's an issue of local policy, so please do not make policy decisions for us, exactly as we do not do it to somebody else. Thank you.

The problem is that you're trying to make development decisions for us. In which case you do need to convince us that you're right.

Or else, I suppose, you're wanting to block deployment of TemplateStyles to ruwiki hewiki entirely because we won't spend development effort to make your demands possible. In that case you don't need to convince us that you're right here, you just have to convince whoever is in charge on T188198: Enable TemplateStyles on ruwiki on 2018-04-10 the task to enable it there that the ruwiki hewiki community doesn't want it (and that there's no good reason to insist, if they want to insist).

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

EDIT: hewiki, not ruwiki. Sorry.

Minor comment: IKhitron is commenting here on his own on behalf of Hebrew Wikipedia, not Russian.

In T187729#4056984, @IKhitron wrote:

And at the and, guys: I'm not trying to convince you that I'm right and you are wrong. We do not ask to make these restrictions for all wikis. It's just for us, we believe it can be problematically vandal-wise in our wiki, so it is local. I'm sure you can prove me for example that editinterface permission should exist, and you do not force it to al wikis, or should not exist, pick one, and remove it for all wikis. It's an issue of local policy, so please do not make policy decisions for us, exactly as we do not do it to somebody else. Thank you.

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

In T187729#4057043, @Anomie wrote:

In T187729#4056984, @IKhitron wrote:

It does appear in recent changes, just as "normal" templates do. And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

No. I said with the page name.

If that's what you meant, then the same applies to edits to "normal" templates.

See my next words below.

And edits to "normal" templates don't show up in the watchlist for a particular page, in exactly the same way.

Yes, so again, if it would just this, and not all the context, it would be OK.

I don't understand what you're trying to say here.

I'm saying, that if it was just this sentence, than the state would be exactly as is templates. But this is just one of many characteristics, that creats the bad situation together.

Inline css is always local, inside div or span scope.

I don't want to go into too many details for WP:BEANS reasons, but T10679 belies that at the level most people will care about even though you're right that it's always affecting just the element the inline style is on.

I can give you a problematic code with any css operator.

This seems to be a non sequitur.

Sorry, I do not understand you.

And at the and, guys: I'm not trying to convince you that I'm right and you are wrong. We do not ask to make these restrictions for all wikis. It's just for us, we believe it can be problematically vandal-wise in our wiki, so it is local. I'm sure you can prove me for example that editinterface permission should exist, and you do not force it to al wikis, or should not exist, pick one, and remove it for all wikis. It's an issue of local policy, so please do not make policy decisions for us, exactly as we do not do it to somebody else. Thank you.

The problem is that you're trying to make development decisions for us.

No, I do not. You should not apply this change to all wikis, just a couple.

In which case you do need to convince us that you're right.

Or else, I suppose, you're wanting to block deployment of TemplateStyles to ruwiki entirely because we won't spend development effort to make your demands possible. In that case you don't need to convince us that you're right here, you just have to convince whoever is in charge on T188198: Enable TemplateStyles on ruwiki on 2018-04-10 that the ruwiki community doesn't want it (and that there's no good reason to insist, if they want to insist).

If it was not clear: I'm speaking for hewiki, not ruwiki. We asked the same.
And just afetr the permission I wanted to ask this feture before the the rest wikis, because it's wonderful, not turn it off.

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

I thought about this, of course. But it has some some problems: (1) Not all the edit is vandal, so it's not so right to use abuse filter for this. (2) It's complexity problem. (3) Why to allow open the page to edit and do not allow to edit, in place of make it read only for some users, it will heart in the good ones morally. (4) It's a problem of more than one wiki, and more than one large wiki.

In T187729#4057059, @Amire80 wrote:

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

Let's talk next year.

In T187729#4057089, @IKhitron wrote:

In T187729#4057043, @Anomie wrote:

I don't understand what you're trying to say here.

I'm saying, that if it was just this sentence, than the state would be exactly as is templates. But this is just one of many characteristics, that creats the bad situation together.

In other words, the points you were trying to make regarding edits to TemplateStyles CSS pages not showing up in recentchanges and watchlists don't actually make TemplateStyles edits worse than normal template edits?

The problem is that you're trying to make development decisions for us.

No, I do not. You should not apply this change to all wikis, just a couple.

You're wanting additional features added to the code. Whether to do so or not is a development decision.

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

I thought about this, of course. But it has some some problems: (1) Not all the edit is vandal, so it's not so right to use abuse filter for this. (2) It's complexity problem. (3) Why to allow open the page to edit and do not allow to edit, in place of make it read only for some users, it will heart in the good ones morally. (4) It's a problem of more than one wiki, and more than one large wiki.

Your (1) seems to be reading too much into the name "AbuseFilter". Which is why enwiki changed all the things they could to call it "EditFilter" there instead.

Your (2) would need more explanation. As it stands, it's an empty claim.

Your (3) is a valid point, but given the current state of this task you might have to live with that if you want TemplateStyles on hewiki but don't want to allow "untrusted" classes of users to edit. Or, as I mentioned, you could just insist on not having TemplateStyles at all if that's the tradeoff your community wants to make.

Your (4) is not particularly valid, as other wikis could use the same filter if they want the same restriction.

In T187729#4057121, @Anomie wrote:

In T187729#4057089, @IKhitron wrote:

In other words, the points you were trying to make regarding edits to TemplateStyles CSS pages not showing up in recentchanges and watchlists don't actually make TemplateStyles edits worse than normal template edits?

Not at all. I'm saying it's an element of context.

The problem is that you're trying to make development decisions for us.

No, I do not. You should not apply this change to all wikis, just a couple.

You're wanting additional features added to the code. Whether to do so or not is a development decision.

OK, if you say so. Still it would be very nice.

Or, another option you might try would be to add a local abusefilter that checks something like new_content_model == "sanitized-css" & ! "whatever" in user_groups.

I thought about this, of course. But it has some some problems: (1) Not all the edit is vandal, so it's not so right to use abuse filter for this. (2) It's complexity problem. (3) Why to allow open the page to edit and do not allow to edit, in place of make it read only for some users, it will heart in the good ones morally. (4) It's a problem of more than one wiki, and more than one large wiki.

Your (1) seems to be reading too much into the name "AbuseFilter". Which is why enwiki changed all the things they could to call it "EditFilter" there instead.

Sure, but I'm not the boss in this question in our wiki. I agree with your words.

Your (2) would need more explanation. As it stands, it's an empty claim.

As far as I know, abusefilter needs more complexity, because it checks every edit in the world, and avoids some, instead of not allowing some kind of edits, exactly as editinterface permission on mediawiki namespace editing.

Your (3) is a valid point, but given the current state of this task you might have to live with that if you want TemplateStyles on hewiki but don't want to allow "untrusted" classes of users to edit. Or, as I mentioned, you could just insist on not having TemplateStyles at all if that's the tradeoff your community wants to make.

Exactly. I do want have it.

Your (4) is not particularly valid, as other wikis could use the same filter if they want the same restriction.

I meant if it's something local, as bad word on some language, it can be fixed with abusefilter. Something more common can get its own technical solution, as for example url blacklists - it could be added as abusefilter as well.

Not seeing any point in leaving the feedback after the developers already made their mind and probably won’t change it under any circumstances, but still.

In T187729#4057059, @Amire80 wrote:

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

Not fair to ask this with 13 pages using TemplateStyles overall.

In T187729#4056734, @Anomie wrote:

What makes any of those things worse than changing random words to "poop" or other vandalism, inserting shock images, or things like T10679, that all have been done with inline styles in templates, that necessitates extraordinary protections for TemplateStyles?

The fact that there are no rules for what members of communities can and can not do with TemplateStyles. So unless you are developing them right now, it is not similar to vandalism in any way, shape or form. For now adopting TemplateStyles, even if we all want it very well, is akin going to a terra nullius, so it is only natural that some communities (like Hebrew) want a permanent edit protection to exclude potentially destructive actions or (like Russian) want gradual roll-out of the feature with developing those same rules that would ensure knowledgeable TemplateStyles adoption by bigger groups of people.

Wikimedia developers, like Amir that is also present in this discussion, like to push out new things without measuring their supposed impact and necessary steps to ensure the most productive and quality usage, and then communities have to pick up scraps after them. So multiple communities are genuinely interested in trying out this feature, but I guess this is not possible without throwing out the baby and keeping the bathwater. Good luck to Hebrew Wikipedia community on working out the decision that works for them.

In T187729#4057166, @stjn wrote:

The fact that there are no rules for what members of communities can and can not do with TemplateStyles.

This argument reminds me of http://tvtropes.org/pmwiki/pmwiki.php/Main/LoopholeAbuse, and https://xkcd.com/1552/. I'm sure that communities have plenty of general rules that cover any actual vandalism or disruption that would apply just fine to people who try to cause problems using TemplateStyles.

In T187729#4057166, @stjn wrote:

In T187729#4057059, @Amire80 wrote:

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

Not fair to ask this with 13 pages using TemplateStyles overall.

Did anybody in the Swedish Wikipedia think that it's problematic not to have this kind of protection, before or after the deployment?

Hebrew has less traffic and active editors than Swedish. Russian has more. Why is it a problem for Hebrew and Russian, but not a problem for Swedish?

In T187729#4057166, @stjn wrote:

Not fair to ask this with 13 pages using TemplateStyles overall.

FYI, CirrusSearch can search directly by content model, like this.

In T187729#4057059, @Amire80 wrote:

This, again, makes me ask: Were there any actual problems in the Swedish Wikipedia since the deployment? It has now been almost a month since then.

There were some bugs found and fixed, such as T188143 and T189528. There were some non-critical improvements that don't block further deployments identified, such as T188760 and T187142. This is all typical for a first deployment, of course. There were no other issues, to my knowledge.

To summarize:

• TemplateStyles CSS pages are handled the exact same way as templates for change tracking purposes;
• CSS stylesheet vandalism is no different in impact from inline CSS vandalism (you can do different things, but you can already use inline CSS to take over the entire viewport);
• CSS vandalism is more annoying than dangerous, so there is no need to preempt imaginary things, they can be addressed once they have been shown to happen;
• if someone really insists on access control to TemplateStyles pages, it's already possible with AbuseFilter (although the user experience will be somewhat sub-par). More usefully, it can be used to tag CSS changes from less trusted users for quicker review.

So there is not much point in trying to prevent CSS stylesheet vandalism as long as templates can be vandalized with positioned content etc. for much the same effect. It might be interesting to revisit this after restricting inline CSS capabilities, but rolling out TemplateStyles and porting existing inline styles is a prerequisite to that.

I've updated the documentation on how CSS vandalism can be handled.

In T187729#4057510, @Tgr wrote:

• TemplateStyles CSS pages are handled the exact same way as templates for change tracking purposes;

Wrong, as I explained.

• CSS stylesheet vandalism is no different in impact from inline CSS vandalism (you can do different things, but you can already use inline CSS to take over the entire viewport);

Wrong, as I explained.

• CSS vandalism is more annoying than dangerous, so there is no need to preempt imaginary things, they can be addressed once they have been shown to happen;

We did not talk about this, but if you are, it's absolutely the opposite. It's much more dangerous, because it's invisible in wikicode for a lot of people.

• if someone really insists on access control to TemplateStyles pages, it's already possible with AbuseFilter (although the user experience will be somewhat sub-par). More usefully, it can be used to tag CSS changes from less trusted users for quicker review.

I already explained why it's wrong.

And by the way, did you think about one more reason to restrict this, in addition to all reasons you already have? A regular vandal should learn the wikicode to make more problems here, in wiki. But he can come when he already know css, because it's a language that exists outside in the world.
I do not know why do you insist against all the arguments, and I still did not hear even one argument why this permission can be wrong (not why it's irrelevant), so it's us vs still nothing. Please reconsider. Thank you.

In T187729#4057257, @Amire80 wrote:

Did anybody in the Swedish Wikipedia think that it's problematic not to have this kind of protection, before or after the deployment?

Hebrew has less traffic and active editors than Swedish. Russian has more. Why is it a problem for Hebrew and Russian, but not a problem for Swedish?

Seeing that as of now you and I can edit the CSS code for amboxes, navboxes and infoboxes in Swedish Wikipedia, I don’t think their community really minds anything at this point.

I would also guess that they care less about the things like colour contrast, which at this point can be tracked only through inline code and modules and not CSS. And so on, and so on, and so on, yet again − this is very useful on paper, but when we try to push everyone into one paradigm, alas, it yet again falls down in its purpose.

In T187729#4057528, @stjn wrote:

In T187729#4057257, @Amire80 wrote:

Did anybody in the Swedish Wikipedia think that it's problematic not to have this kind of protection, before or after the deployment?

Hebrew has less traffic and active editors than Swedish. Russian has more. Why is it a problem for Hebrew and Russian, but not a problem for Swedish?

Seeing that as of now you and I can edit the CSS code for amboxes, navboxes and infoboxes in Swedish Wikipedia, I don’t think their community really minds anything at this point.

OK, and is it a problem?

And by the way, did you think about one more reason to restrict this, in addition to all reasons you already have? A regular vandal should learn the wikicode to make more problems here, in wiki. But he can come when he already know css, because it's a language that exists outside in the world.

This sounds like a reason to make it easier for people to edit CSS pages, not a reason to make it harder.

I do not know why do you insist against all the arguments, and I still did not hear even one argument why this permission can be wrong

A wiki is a site that anyone can edit. It is supposed to have less restrictions, not more.

In T187729#4057582, @Amire80 wrote:

And by the way, did you think about one more reason to restrict this, in addition to all reasons you already have? A regular vandal should learn the wikicode to make more problems here, in wiki. But he can come when he already know css, because it's a language that exists outside in the world.

This sounds like a reason to make it easier for people to edit CSS pages, not a reason to make it harder.

Not funny. If vandals are more powerful here, you do not give them more opportunities.

I do not know why do you insist against all the arguments, and I still did not hear even one argument why this permission can be wrong

A wiki is a site that anyone can edit. It is supposed to have less restrictions, not more.

Enwiki does not allow anonyms to create new articles, as far as I know. I do not trying to change this, because it's not of my business.

A little addition. You said above that inline and TemplateStyle css can do the same. I just remembered it's wrong even from programming point of view. You can't redefine inline the behavior of existing mediawiki classes, or their interaction with user classes (as I mentioned before abour references with white text).

In T187729#4057595, @IKhitron wrote:

In T187729#4057582, @Amire80 wrote:

And by the way, did you think about one more reason to restrict this, in addition to all reasons you already have? A regular vandal should learn the wikicode to make more problems here, in wiki. But he can come when he already know css, because it's a language that exists outside in the world.

This sounds like a reason to make it easier for people to edit CSS pages, not a reason to make it harder.

Not funny. If vandals are more powerful here, you do not give them more opportunities.

We'll, are vandals more powerful?

If more people know CSS than wiki syntax, it doesn't mean that people will vandalize CSS more.

More people know Hebrew than wiki syntax, but we aren't protecting the whole article space because of that.

I do not know why do you insist against all the arguments, and I still did not hear even one argument why this permission can be wrong

A wiki is a site that anyone can edit. It is supposed to have less restrictions, not more.

Enwiki does not allow anonyms to create new articles, as far as I know. I do not trying to change this, because it's not of my business.

There's ongoing research, which is trying to check whether it's good that this is restricted or not. I don't know what will be the result of this research.

These questions are supposed to be answered by research, not by overprotection against assumed problems

In T187729#4057648, @Amire80 wrote:

In T187729#4057595, @IKhitron wrote:

Enwiki does not allow anonyms to create new articles, as far as I know. I do not trying to change this, because it's not of my business.

There's ongoing research, which is trying to check whether it's good that this is restricted or not. I don't know what will be the result of this research.

T170851 will tell us at some point.