This probably works on trunk, but is broken on 1.17
Version: 1.17.x
Severity: normal
Description
Description
Details
Details
- Reference
- bz27468
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T28676 Milestone: MediaWiki 1.17 release tarball (tracking) | |||
| Resolved | None | T29468 Force underlined links don't work in 1.17 monobook |
Event Timeline
Comment Actions
mediawiki wrote:
The problem appears to be the a{} block in skins/monobook/main.css?301-1 on line 65 (at least, that's where it is on the file currently on en.wikipedia). The text-decoration:none; line there is overriding the a{text-decoration:underline;} in the HTML (as they're the same specificity and the stylesheet is imported after that decoration in the HTML).
Browsing SVN, the generation of that a{text-decoration:underline;} bit in the HTML seems to have changed in trunk (moved from Skin.php to ResourceLoaderUserOptionsModule.php) but it appears to still work in the same way. And that block in skins/monobook/main.css isn't changed. So I suspect it would still be broken in trunk, though I don't have a working trunk site to test it on.
Comment Actions
Right ... @Roan, remember how I at one point stated that we did not need ALL skins converted to ResourceLoader in 1.17 ? I was mistaken, we need it for this issue.
Comment Actions
Created attachment 8182
Path to order userprefs correctly
OK, patch attached that will fix this. However, first some comments.
1: The order of loading these items is actually affixed in buildCssLinks() of OutputPage.php
It was
other (static stuff, and all private modules, including user preferences css)
dynamiclinks (here is where the old style skins and other unported material will be)
site
user
2: The type of the ResourceLoaderUserOptionsModule is private, not user and buildcsslinks puts private modules with the 'other' modules.
I considered changing this simply to user, in the hope that that would fix it, but I don't know what kind of consequences that has for caching etc. Also since this order is actually rather specific, I went with the approach in my path.
I created an improved order in buildCssLinks that manually makes sure that the css from the preferences is between the site css and the user css (as it has always been). I'm also using a for loop, though we could of course continue to use array_merge, in my experience though, it ordered 1 2 3 as 132 for some strange reason, so i went with the foreach approach instead.
Attached: