ResourceLoader: Refactor style loading
authorTimo Tijhof <ttijhof@wikimedia.org>
Wed, 25 Jul 2012 21:20:21 +0000 (14:20 -0700)
committerTimo Tijhof <ttijhof@wikimedia.org>
Tue, 2 Oct 2012 22:23:16 +0000 (00:23 +0200)
commitff594d3b0ae88009120fcde48c91c24c1e3d0445
tree437df9ae7e793492b5e8fba7c1334c971b0f31c9
parent3e88364a672833048d3b26501ef9495261b19f03
ResourceLoader: Refactor style loading

Fixes:
* bug 31676: Work around IE stylesheet limit.
* bug 35562: @import styles broken in modules that combine
  multiple stylesheets.
* bug 40498: Don't output empty "@media print { }" blocks.
* bug 40500: Don't ignore media-type for urls in debug mode.

Approach:
* Re-use the same <style> tag so that we stay under the 31
  stylesheet limit in IE. Unless the to-be-added css text from
  the being-loaded module contains @import, in which case we do
  create a new <style> tag and then re-use that one from that
  point on (bug 31676).

* Return stylesheets as arrays, instead of a concatenated string.
  This fixes bug 35562, because @import only works when at the
  top of a stylesheet. By not unconditionally concatenating files
  within a module on the server side already, @import will work
  in e.g. module 'site' that contains 2 wiki pages.

  This is normalized in ResourceLoader::makeCombinedStyles(),
  so far only ResourceLoaderWikiModule makes use of this.

Misc. clean up and bug fixes:
* Reducing usage of jQuery() and mw.html.element() where
  native DOM would be very simple and faster. Aside from
  simplicity and speed, this is also working towards a more
  stand-alone ResourceLoader.
* Trim server output a little bit more
  - Redundant new line after minify-css (it is now an array, so
    no need to keep space afterwards)
  - Redundant semi-colon after minify-js if it ends in a colon
* Allow space in styleTest.css.php
* Clean up and extend unit tests to cover for these features
  and bug fixes.
* Don't set styleEl.rel = 'stylesheet'; that has no business
  on a <style> tag.
* Fix bug in mw.loader's addStyleTag(). It turns out IE6
  has an odd security measure that does not allow manipulation
  of elements (at least style tags) that are created by a
  different script (even if that script was served from the same
  domain/origin etc.). We didn't ran into this before because
  we only created new style tags, never appended to them. Now
  that we do, this came up. Took a while to figure out because
  it was created by mediawiki.js but it calls jQuery which did
  the actual dom insertion. Odd thing is, we load jquery.js and
  mediawiki.js in the same request even...
  Without this all css-url related mw.loader tests would fail
  in IE6.
* mediawiki.js and mediawiki.test.js now pass jshint again.

Tested (and passing qunit/?module=mediawiki; 123 of 123):
* Chrome 14, 21
* Firefox 3.0, 3.6, 4, 7, 14, 15, 16beta
* IE 6, 7, 8, 9
* Safari 4.0, 5.0, 5.1
* Opera 10.0, 11.1, 11.5, 11.6, 12.0, 12.5beta
* iPhone 3GS / iOS 3.0 / Mobile Safari 4.0
  iPhone 4 / iOS 4.0.1 / Mobile Safari 4.0.5
  iPhone 4S / iOS 6.0 Beta / Mobile Safari 6.0

Change-Id: I3e8227ddb87fd9441071ca935439fc6467751dab
RELEASE-NOTES-1.20
includes/resourceloader/ResourceLoader.php
includes/resourceloader/ResourceLoaderFileModule.php
includes/resourceloader/ResourceLoaderModule.php
includes/resourceloader/ResourceLoaderWikiModule.php
resources/mediawiki/mediawiki.js
tests/qunit/data/styleTest.css.php
tests/qunit/suites/resources/mediawiki/mediawiki.test.js