Last modified: 2011-02-20 17:25:33 UTC
This probably works on trunk, but is broken on 1.17
Why do you say "probably"? Have you tested it anywhere?
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.
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.
Created attachment 8182 [details] 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.
Fixed in r82518.
