LESS support was recently added for RL, but only for core/extension generated modules. It would be nice if users could also create their own .less subpages (or MediaWiki: pages for sitewide) that RL would automatically compile into CSS.
Ori mentioned on IRC that there may be some security issues that need to be addressed like @import "/etc/passwd";
Version: 1.22.0
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T28751 Extensions that should really be core functionality (tracking) | |||
| Open | None | T122924 Merge Extension:Theme into core | |||
| Declined | None | T56864 ResourceLoader: Implement support for LESS in wiki modules (user and site), supporting e.g. MediaWiki:Common.less |
Note that besides other security vectors, there's also a DOS vector. Small .less files that generate several gigabytes of output and consume large amounts of CPU for long periods of time can be made.
Using LESS inside the user space is in my opinion of very little value because, contrary to the file system, there wouldn't be much re-use or composition. It'd basically just be syntactical sugar for something that is relatively trivial to do without LESS.
It might even be something we'll never do, or do much later on once we get a grip on more important things and have found ways around the problems it introduces.
At this point I'd recommend against writing a patch, as it wouldn't be ready for approval.
Why not add https://github.com/leafo/lessphp/blob/011afcca8e6f1000a6e789921ba805fa578271a3/lessify.inc.php to mediawiki which converts css to less.
Actually I think replacing Common.css with Common.less outright (see T78345) would be a great idea from an organisation perspective. The use of nesting is an invaluable way to identify dead code blocks and keep these messy wiki pages organised.
See https://www.mediawiki.org/wiki/Requests_for_comment/LESS#Case_study:_LESS_in_MobileFrontend
Nesting would (and should) not be used in most cases relevant in that scenario. It's quite often misused.
See also T152832: Allow template editors (or interface editors) use Less instead of CSS (probably could be merged, although at the moment TemplateStyles does not use ResourceLoader)
Declining for now. This would take considerable investment within performance/security constraints to get "right". I'm not sure that's something we should invest in anytime soon (over other things). This is naturally is why we haven't yet in the last seven years.
I think the long-term trajectory should be that gadgets should be given the oppertunity to have all the same capabilities as extensions. That means localisation, unit testing, linting, code review, multi-file edits, and things like LESS variables imports (ref T112747).
I think it would be a much better use of developer time (both MW devs and Gadget devs) if we focus on these capabilties from the other end instead. That is, to make it really easy to create a Git-based gadget through an expedited and extension-like mechanism (ref T22153, T71445).
This would of course never be mandatory for a gadget. It should imho always be possible to do what people do today: To write code in web standard technologies (JS and CSS), and just save that without any additional tooling.
But when additional capabilities and features are desired, they can opt to become Git based. We know already that the most popular gadgets actually wouldn't mind this (afaik) considering that's exactly what they're doing already. They use LESS and other processing steps e.g. from GitHub or Travis and them publish to the wiki as plain CSS/JS.