Talk:Community Wishlist/W350

Previous CWS

Community Wishlist Survey 2023/Miscellaneous/Update TemplateStyles CSS rules to current CSS spec versions. Nardog (talk) 16:45, 9 January 2025 (UTC)

Update on Your Wishlist Request: TemplateStyles CSS Enhancements

Hello @This, that and the other,

Thank you for submitting this wishlist request. We've been reviewing it internally, and the wish overall seems valuable, but it has been broken down across multiple teams within the Foundation. We’ve been following up internally to assess feasibility and next steps. Some parts could be straightforward to implement, while others may require deeper investigation.

We might need further clarification from you as discussions progress, and we truly appreciate your patience and contributions.

We’ll keep you updated as things move forward. Let us know if you have any additional insights or use cases that could help shape this conversation.

--ARamadan-WMF (talk) 09:15, 5 March 2025 (UTC)

Pinging also: @Likibp, Tgr, Izno, Anomie, Ciencia Al Poder, Iniquity, Robertsky, Geofferic, DaxServer, HouseBlaster, Tol, SHB2000, NMaia, عُثمان, Tinker Bell, Pppery, Lt2818, Spencer, Ron Waffle, Afernand74, Arado Ar 196, Golmote, Tucvbif, Terasail, Goliv04053, JrandWP, Betseg, Libcub, HLFan, Nux, Tacsipacsi, Pigsonthewing, Quiddity, Jaideraf, Aishik Rehman, Cyfraw, ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Amorymeltzer, CX Zoom, VulcanSphere, Dominic Z., Hans5958, TheDJ, Jeeputer, Nikki, Nw520, PKM, Amire80, Althair, and আফতাবুজ্জামান: Nardog (talk) 13:53, 7 March 2025 (UTC)

Thanks @ARamadan-WMF. To piggyback, additional specification would help us scope the request, as allowing anyone to set the value of a TemplateStyle variable would require a security review, for example. JWheeler-WMF (talk) 19:39, 7 March 2025 (UTC)

To start with, it would be great to fix the existing bugs with use of CSS variables. For instance, TemplateStyles rejects the following:

div { border-color: var(--background-color-notice-subtle); }

Allowing the setting of variables is another story. I didn't actually add that Phab task to the wishlist request - someone else did. In order to streamline the work, I would favour leaving it out of the scope of this wishlist request.

For me, if I was taking on this request, I would start by asking the following questions:

• When TemplateStyles was originally written, what sources did the authors consult in order to decide on the set of CSS syntax, properties, selectors etc. that are allowed by the sanitiser?
• Can we consult those sources anew today, and update the sanitiser's ruleset to match what they currently say?

This, that and the other (talk) 23:46, 7 March 2025 (UTC)

There is also currently rumblings that everything in w:Category:Templates using TemplateStyles to style external elements might break, which would disallow various usecases like w:Template:Sticky header. Getting some clarity (ideally official support for such things) would be appreciated. Best, HouseBlaster (talk • he/they) 01:46, 8 March 2025 (UTC)

Roughly, TemplateStyles included the CSS rules which have been widely supported by the browsers at the time of its creation (2016, IIRC) and had a relatively stable specification (W3C Candidate Recommendation or above). What that meant in practice is documented in the README of css-sanitizer, the library that TemplateStyles uses for CSS conformance checks.

Since then, the extension hasn't been actively maintained, only a handful of CSS features were added on an ad-hoc basis. There has been some discussion in T354228 on making the support expectations more formal.

Not supporting css variables in border-color is a security restriction, not a bug. In general, CSS variables make it very hard to validate and restrict what the user is doing, and so somewhat defeat the purpose of sanitizing CSS. While most other CSS features are just a matter of spending the developer time on adding them to the ruleset, CSS variables are a significant security tradeoff. Tgr (talk) 20:58, 14 March 2025 (UTC)

it has been broken down across multiple teams within the Foundation This is a weird comment to me. Why do you think there are multiple teams needed here? Besides the DOING team or even singular person, the only group that someone might need to reach out to is Security for any given patch where there are significant additions or potential for misuse (e.g. the recent discussion of the character < in media queries, the use and creation of variables generally).

additional specification feels a bit puzzling as well. I've kept the pair of projects on Phabricator pretty organized. Honestly what I think would help a lot would be to make some decisions related to the handful of non-technical tasks in the projects (e.g. phab:T354228, which would at least would put an upper scope on the work that needs to be done at an arbitrary date).

You could probably even just prioritize the specific features, even if in sum they don't align with everything a specific revision of a relevant dated standard says (e.g. we have a request for a ruby specific CSS feature, we don't necessarily need to add every ruby specific CSS feature from the ruby CSS spec that we don't yet support, even though this is the easiest way to track things - just leave yourself a note or two in the readme as with today - and/or also consider splitting the readme if tracking the specific features gets too bothersome. More documentation is better...). Izno (talk) 05:56, 12 March 2025 (UTC)

Given what is specifically proposed in this wish, I don't think the WMF Security Team would take issue in adding support for lh units, width: fit-content and even @supports (mask-image: none) . If anyone would like to get change sets up for those in gerrit, they can just add myself, @Reedy, @Cscott and @Bawolff as reviewers. Expanding var support is a bit more contentious in that there are definitely certain attack surfaces we need to restrict. SBassett (WMF) (talk) 14:22, 6 May 2025 (UTC)

One thing to keep in mind is that most css properties (so excluding @ rules) can already be set in inline style attributes, so the additional risk of allowing them in templatestyles is typically pretty low. CSS spec usually does a pretty good job in the modern era of having new features not be crazy. Its pretty hard to think of anything we wouldn't want to allow other than certain css functions and certain @ rules. Bawolff (talk) 16:25, 6 May 2025 (UTC)

New update about the wish

During our recent Wishathon, some progress has been made in granting this wish, thanks to Tim Starling and MusikAnimal: seven different patches have been filed that are awaiting code review at the moment (phab:T324526, phab:T394619, phab:T277755, phab:T360725, phab:T368089, phab:T293633, and phab:T371809), plus a couple more ideas are being evaluated (phab:T394963 and phab:T394964). Sannita (WMF) (talk) 13:36, 18 June 2025 (UTC)

And with the exception of the ideas, these are now all solved and deployed —TheDJ (talk • contribs) 09:31, 27 August 2025 (UTC)

OpenType support

Hi there, I recently came across a lack of OpenType support for a ligature preference I wanted to implement. In general, ensuring wide support for OpenType features ought to be a useful thing to do given the multilingual nature of the project. I would imagine these are low risk from a security perspective. It would be good to know if these are in the works. JimKillock (talk) 16:23, 26 June 2025 (UTC)