https://bugzilla.wikimedia.org/show_bug.cgi?id=45229
Web browser: ---
Bug ID: 45229
Summary: RL sorts stylesheet modules added by addModuleStyles
alphabetically
Product: MediaWiki
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: ResourceLoader
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected],
[email protected], [email protected]
Classification: Unclassified
Mobile Platform: ---
ResourceLoader sorts the modules for stylesheets added with addModuleStyles
alphabetically ignoring dependencies.
In other words if you create the module 'a' and make it depend on the module
'b'. And then do `$out->addModuleStyles( 'b' ); $out->addModuleStyles( 'a' );`.
ResourceLoader will load 'a' first and then load 'b', even though both the
dependencies and addModuleStyles say that's wrong.
Skins use addModuleStyles to add skin styles to the page. The setupSkinUserCss
was crafted previously so that addStyle could be used in the correct order by
overriding the function and using parent::setupSkinUserCss at the right spots.
And this works for subskins too since they can let the parent skin add it's
styles before adding their own styles. However the alphabetical sorting done by
RL goes and undoes any precise ordering required by that.
This is problematic for the creation of subskins. If you create a 'skin.foo'
that depends on 'skin.vector' and setup setupSkinUserCss properly RL will go
and put skin.vector after your
The only reason every skin isn't already broken by the shared styles is that
'mediawiki.legacy.' alphabetically sorts before 'skin.'. If we fixed that and
started using 'skins.common.' some skins could start to break.
Also note that most skins use mediawiki.legacy.shared and
mediawiki.legacy.commonPrint which are not added by any core or third party
skin to the dependency setup of the skin's module. So even if we fix this to
not sort things before the things they depend on it would be best to make sure
we also fix it to take addModuleStyles into account.
The ideal situation of course is to fix addModules to know that some modules
should not be loaded by JS (another key on the module registration) and just
use addModules inside of initPage, deprecating setupSkinUserCss for anything
besides addStyle usage (eg: IE stylesheets) and old skin compatibility.
But we have skins that use addModuleStyles right now so we'll need to fix this
bug at minimum for compatibility.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are watching all bug changes.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
