MarkAHershberger has uploaded a new change for review.
Change subject: ResourceLoader: Refactor style loading
......................................................................
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: I3c76e9a8cebfa993d51bfd4b9b4a0963c03cf370
---
M RELEASE-NOTES-1.20
M includes/resourceloader/ResourceLoader.php
M includes/resourceloader/ResourceLoaderFileModule.php
M includes/resourceloader/ResourceLoaderModule.php
M includes/resourceloader/ResourceLoaderWikiModule.php
M resources/mediawiki/mediawiki.js
M tests/qunit/data/styleTest.css.php
M tests/qunit/suites/resources/mediawiki/mediawiki.test.js
8 files changed, 424 insertions(+), 160 deletions(-)
git pull ssh://gerrit.wikimedia.org:29418/mediawiki/core
refs/changes/89/26289/1
--
To view, visit https://gerrit.wikimedia.org/r/26289
To unsubscribe, visit https://gerrit.wikimedia.org/r/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I3c76e9a8cebfa993d51bfd4b9b4a0963c03cf370
Gerrit-PatchSet: 1
Gerrit-Project: mediawiki/core
Gerrit-Branch: REL1_20
Gerrit-Owner: MarkAHershberger <mhershber...@wikimedia.org>
Gerrit-Reviewer: Krinkle <ttij...@wikimedia.org>
_______________________________________________
MediaWiki-commits mailing list
MediaWiki-commits@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-commits
