The horizontal rule that is specified as the background for div.portal elements is flickering briefly on page load:
Description
Details
Related Objects
- Mentioned In
- rSVEV16e16eb0751a: Don't use JavaScript to style first sidebar portlet
rSKIN5bcd9c81ef7b: Updated mediawiki/skins Project: mediawiki/skins/Vector…
rSVEC6c7412b5963f: Don't use JavaScript to style first sidebar portlet
rSVEC176b7e2a0e26: Don't use JavaScript to style first sidebar portlet
rSVEC16e16eb0751a: Don't use JavaScript to style first sidebar portlet
Event Timeline
Change 190645 had a related patch set uploaded (by Bartosz Dziewoński):
Don't use JavaScript to style first sidebar portlet
In the off-chance some user script or style actually depends on .first, I'd feel safer if the skin (vector.php) just adds the class statically.
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.
I think what Bartosz's main concern is, why does that class have to be added with JavaScript, which may incur a rendering delay?
I searched both the MediaWiki: and User: namespaces and found only one case: ru:User:Зелёный Кошак/edittools.js. So I think we can get rid of it and let this particular user know via a friendly note on his or her talk page. Thoughts?
@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
styles/scripts.
Edokter added a comment.
I think what Bartosz's main concern is, why does that class have to be
added with JavaScript, which may incur a rendering delay?
TASK DETAIL
https://phabricator.wikimedia.org/T89542
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or
!assign <username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: matmarex, Edokter
Cc: polybuildr, Edokter, gerritbot, matmarex, Krinkle, ori, Aklapper,
GWicke, Jdforrester-WMF, Jay8g
Change 190645 merged by jenkins-bot:
Don't use JavaScript to style first sidebar portlet
Change 190699 had a related patch set uploaded (by Ori.livneh):
Don't use JavaScript to style first sidebar portlet
Change 190699 merged by jenkins-bot:
Don't use JavaScript to style first sidebar portlet
Change 190700 had a related patch set uploaded (by Ori.livneh):
Don't use JavaScript to style first sidebar portlet
Change 190700 merged by jenkins-bot:
Don't use JavaScript to style first sidebar portlet
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...
@polybuildr, there should be no issues with doing that, but it won't help
IE 6, because MediaWiki doesn't send any JavaScript to it (it's
blacklisted in /resources/src/startup.js along with a few other outdated
or intentionally limited browsers).