| Amorymeltzer | |
| Aug 10 2018, 1:42 AM |
| F24771843: Modern.png | |
| Aug 10 2018, 3:18 PM |
The fix in T200148 (specifically https://gerrit.wikimedia.org/r/450153) added position:relative to #mw_content in the modern skin. This should be undone, it borks the coordinates system in the Modern skin. See for example https://en.wikipedia.org/wiki/New_York_City?useskin=modern — normally, the coordinates should appear higher up, in the menu bar.
As I said at T200148#4493010, the ideal solution for that would be to deal with the toolbar CSS, but this needs fixing separately.
@Amorymeltzer Unless the site is down, about to go down, or unusable for a very large group of users a ticket is not Unbreak Now!
See also https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels
More anti-modern chauvinism!!1! (Thanks DJ, that's helpful — I put a stopgap into sitewide Modern.css, so it's certainly less now, more unbreak.)
Instead of such a "nuclear option" which re-introduces T200148, you should set a more appropriate top value for #coordinates. Based on some quick testing 0.1em seemed to work well enough to restore/keep the current behavior while still allowing to remove that position: static; from #mw_content. Additionally it should play nicer with the site notice when one is present.
Here's a screenshot of the aforementioned New York City article with my proposed #coordinates fix applied, a site notice hacked in and position: static; removed from #mw_content:
Part of the point of doing the position and layer changes on both these skins is also just to make a clearer, more consistent-between-skins separation between content and navigation stuff. Needless to say this won't always work, but there are other potential extension incompatibilities that this should also help avoid, so if we have another option than to simply revert it, I'd argue that's probably ideal.
(Not that the cited codemirror or whatever it is bug also doesn't need to be fixed...)
I don't know about nuclear, but if that also fixed other things Isarra, then fabulous. What I was trying to suggest in T200148 was that altering the entire content box to tweak what was seemingly an issue of misaligned z-indexes between the notifications flyout and the toolbars appeared incongruent. Changing the coordinates setup is indeed easy enough, but then again it's not clear to me what else folks have customized that would change.
@Omar_Ghrida: Not sure why you added Front-end-Standards-Group; this sounds pretty specific to a single codebase (plus it's usually up to groups themselves what they'd like to have on their workboard).
the element #mw_content no longer exists. and since the coordinates are provided by site CSS, using MediaWiki:Modern.css was the correct fix here.
Making coordinates an indicator would be a good step in the right direction to future proof this.