>>! In T483#2239190, @coren wrote:
> Regardless, it is probably worthwhile to ask what the communities around templates think before we figure it out - at least on the bigger projects.  Ima do this this week.

Is there any follow-up to this? I agree with Brion that restricting TemplateStyles to the Template namespace seems unnecessary. I'm pretty wary of global configuration variables, so if we can kill `$wgTemplateStylesNamespaces`, I think that's a win.

>>! In T483#2293604, @GWicke wrote:
>> It's not immediately clear to me what the fundamental difference is between that and the current scheme (a <style> tag in the header)?
> 
> The <style> tag in the header requires a page-global aggregation pass to collect styles, which would need to be implemented in the PHP parser, Parsoid, VisualEditor, and any other application composing wiki content (such as apps).
> 
> The inline stylesheet on the other hand keeps each template expansion self-contained, and avoids the complexity of global passes. It is both easier to implement, and easier to consume.

I looked at T124966 a bit recently. The TemplateStyles extension is scheduled for a security review the week of May 30, according to T133408#2281285. Do you think your implementation concerns are hard blockers to deploying the TemplateStyles extension to Wikimedia wikis in the next few months?

>>! In T483#2289858, @TheDJ wrote:
> This made me realize: We need to make this a less sheet and MediaWiki/Wikimedia should have a centralized less sheet with predefined variables, functions/mixins etc. We could properly document those variables and functions and use them in our examples. We could put complicated CSS magic in descriptively named functions/variables, so that people don't have to understand all the CSS details, they can just be "in this situation i need to use this function".

It's funny, when I was skimming T133408 and starting to consider the various security concerns, one thought I had was "thank God we're not trying to start with a CSS preprocessor, variables and functions and a whole embedded programming language would make this crazy difficult to review." If we get really comfortable with being able to fully sanitize CSS output, I suppose adding a preprocessor wouldn't be totally insane. You'd still need to either do the processing client-side in JavaScript or do sandboxing server-side, the latter being similar to how we deal with embedded Lua, I believe.

I don't think we need to block the deployment of TemplateStyles over preprocessor support, though. Support for a preprocessor would probably happen in this extension at around the same time or after it happens for MediaWiki core (cf. T56864).

I'm hoping to find some time to play around with TemplateStyles this week. I'm curious whether features such as `url()` will be totally banned or only banned for non-Wikimedia domains. If we're going to disallow certain kinds of CSS (i.e., if we're only going to allow a subset of CSS), we'll want to make sure that the documentation and user interface both make this clear early and often to prevent headaches and frustration.