The horizontal rule that is specified as the background for div.portal elements is flickering briefly on page load:
- Mentioned In
rSKIN5bcd9c81ef7b: Updated mediawiki/skins Project: mediawiki/skins/Vector…
Or the JS adding .first could be kept as is. This would remove the FOUC while ensuring that any user script/style still works, if that is a concern.
Also, if we want to still give some support to non grade A browsers, then the CSS for .first could be kept as is too.
@Edokter, I meant that maybe we should ensure support for the first class
(by adding it in JS) while still adding in the new sibling selector change.
This would probably take care of the FOUC as well as support user
Edokter added a comment.
I think what Bartosz's main concern is, why does that class have to be
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or
To: matmarex, Edokter
Cc: polybuildr, Edokter, gerritbot, matmarex, Krinkle, ori, Aklapper,
GWicke, Jdforrester-WMF, Jay8g
I know we don't support IE6 anymore, but does that mean we should actively break IE6?
What was wrong with my suggestion of simply adding the class statically, thus maintaining compatibility (and skinability I might add), instead of using a 'modern' CSS selector, which otherwise adds no benifit at all?
We're not breaking IE 6, it was already not working.
I did the patch the way I did it because it was simpler and neater; I made the effort to support IE 7+. I didn't think that rewriting the PHP code to do this, only to support IE 6 better, would be a good use of my time. (It's not like this a critical feature, like reading or editing pages; it's a little grey line in the sidebar…) If you think it's a good use of yours, please submit a patch and I'll be happy to merge it.
Note, though, that Vector already looks quite messed up on IE 6 (although it is perfectly functional).
Is there an issue with not removing the CSS off .first and also leaving in the JS that adds in .first? The FOUC will be handled by using the sibling selector and IE6 will not break because the JS will still be working.
@polybuildr, That would result in more redundant code.
@matmarex, Just leave it... I'm just annoyed it got to this messed up state because people insist on using new methods, even when trusted methods work just as well, without any extra work, and which would keep the site presentable for older browsers.
I think that's just terribly lazy...