Page MenuHomePhabricator

ResourceLoader: Implement support for LESS in wiki modules (user and site), supporting e.g. MediaWiki:Common.less
Closed, DeclinedPublic

Description

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

Details

Reference
bz54864

Related Objects

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 2:32 AM
bzimport set Reference to bz54864.
bzimport added a subscriber: Unknown Object (MLST).

Yes, we'll need to devise some way to override the @import handling...

Extending summary because I spent way too long looking for this bug.

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.

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

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.

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)

Izno added subscribers: Volker_E, FO-nTTaX, JJMC89.
Izno subscribed.
In T56864#2867288, @Tgr wrote:

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)

So-merged! :D

Krinkle closed this task as Declined.EditedMay 20 2020, 5:24 PM

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.