Page MenuHomePhabricator

Add support for embedded files in site CSS
Closed, DeclinedPublic

Description

Right now, only relative URLs can be embedded in CSS thus limiting the feature to extensions/core stylesheets. However, some user scripts also embed images and it would be handy to have support for this in ResourceLoader via @embed.

An extension to this idea was to utilise something similar to [[Special:FilePath/$file]] to automatically update the file when it gets replaced/improved. For example:

.foo {
   ...
    /* @embed */
    background-image: url( 'filepath:Bar.png' );
    ...

Event Timeline

onei created this task.Oct 4 2015, 7:12 AM
onei raised the priority of this task from to Needs Triage.
onei updated the task description. (Show Details)
onei added a project: MediaWiki-ResourceLoader.
onei added a subscriber: onei.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 4 2015, 7:12 AM
Krinkle added a subscriber: Krinkle.EditedNov 12 2015, 10:15 PM

I don't think we should implement that feature. It has various problems:

  • Introduces syntax that doesn't work by default (e.g. it is not an optimisation, but a requirement for functional rendering as by default in a browser filepath: would point no-where). This hinders development mode as well.
  • It violates the boundary between the isolated ResourceLoader system and MediaWiki user-generated content. Thus requiring that we track updates to that file within MediaWiki and somehow dispatch updates to purge and regenerate the gadget module that uses this. Such logic doesn't presently exist and can't be prioritised at the moment. Ideas are welcome however.
  • It may also detriment page load performance. Recent research indicates that the habit of encouraging embedded images is actually negative to page load performance. In 2010 this was useful to reduce the total number of HTTP requests. But in 2015 we should probably focus our optimisation on SPDY/HTTP2 which the majority of users support. In that protocol, browsers have a persistent session to the web server. As such, requesting additional files doesn't have any notable overhead. It has the benefit of allowing the page to have its first render without all images (e.g. waiting 1 second to start reading the page, instead of 5 or 6 seconds).

Using images will still work, but you'll have to use the https://upload.wikimedia.org/... url instead.

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 12 2015, 10:15 PM
Krinkle triaged this task as Low priority.Nov 12 2015, 10:16 PM
Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.
Krinkle set Security to None.
Krinkle closed this task as Declined.Jul 27 2016, 2:30 AM

Closing for now.

With regards to performance, using upload.wikimedia.org urls should be fine.

These urls are not ideally cacheable, but that's a known issue and not specific to ResourceLoader.

When the tasks are complete, it will most likely mean MediaWiki generates version-specific urls for thumbnails. And it will likely require purging of articles when images change. At that point we can create a task for ResourceLoader in MediaWiki to support something to automatically expand the canonical url for the thumbnail into a cacheable one (similar to what MediaWiki does when parsing), and hook it up with cache propagation in some way. (We can track it through the database and detect it within 5 minutes like we detect other changes in the startup module already).