MediaWiki talk:Mobile.css

Remove .fileinfo-paramfield

It is requested that an edit or modification be made to this protected page.
Administrators: Please apply <nowiki> or {{Tl}} to the tag after the request is fulfilled.

---

Fulfill this request after checking that the code is safe

TheDJ

Remove

.fileinfo-paramfield { width: 15%; }

On A_view_of_SEABA_School_02.jpg on a mobile device (iPhone 375x667) the headings are being floated to the left.

Raised by @Kuldeepburjbhalaike on Telegram.

If these are needed for tablet/desktop please wrap them in a suitable media query so they do not apply at mobile resolutions. Let me know if you need any further help. Jdlrobson (talk) 16:12, 9 February 2024 (UTC)

@Jdlrobson: This is likely the outcome of Module talk:Information#Proposal: Move template styles to site-wide CSS – TemplateStyles was more specific and thus used to override this rule. Now, with MediaWiki:Filepage.css, we’ve lost this specificity. Filepage.css is loaded on all pages in the file namespace (both on mobile and desktop), but it’s not loaded outside of the file namespace, where Mobile.css is still needed as MediaWiki:Common.css is still not loaded on mobile. As a short-term solution, prefixing the rule with body:not(.ns-6) would fix file pages while not leaving other pages more broken than they are now. In the longer term, we should finally get rid of Mobile.css and just load Common.css everywhere (which would still require this namespace scoping, but at least only once instead of twice, reducing the number of scenarios to be tested). And in the longest term, TemplateStyles should be scalable, allowing us to get rid of the same styles being defined at three places (TemplateStyles, Common.css, Filepage.css). —Tacsipacsi (talk) 12:27, 10 February 2024 (UTC)

Thanks for the pointer!

@Lucas Werkmeister FYI the changes you have made have consequences on mobile. I am not 100% sure how you want to fix them.

We (including Amie) should also talk about this strategy of moving into Common.css as it is in direct conflict with mobile strategy which encourages use of TemplateStyles and moving CSS out of Common.css! Jdlrobson (talk) 16:02, 10 February 2024 (UTC)

I guess an alternative solution would be to make the specificity in /styles.css / Filepage.css higher, with some trick like .fileinfo-paramfield.fileinfo-paramfield (just doubling the class). I’m not sure if I like that more or less than the body:not(.ns-6)… what do you think @Tacsipacsi @Jdlrobson? Lucas Werkmeister (talk) 18:24, 10 February 2024 (UTC)

(I suppose changing it in Mobile.css at least has the advantage that it won’t cause a recursive purge of some 78 million pages…) Lucas Werkmeister (talk) 18:27, 10 February 2024 (UTC)

any reason not to move it to a default gadget that is only loaded on file pages - wouldnt that be the best of all worlds? Jdlrobson (talk) 20:03, 10 February 2024 (UTC)

@Lucas Werkmeister: Increasing the specificity wouldn’t mitigate the issue that the same styles are now defined on four pages (TemplateStyles, Filepage.css, Common.css, Mobile.css) and there’s no guarantee that they won’t start to diverge in ways that cause breakage again. If the Mobile.css files don’t apply in the file namespace, then it may become inconsistent across namespaces, but at least not broken in any single namespace.

@Jdlrobson: There’s an important feature that only Filepage.css and TemplateStyles provide (gadgets, Common.css etc. don’t): they’re loaded on wikis using InstantCommons. If these styles were neither in TemplateStyles nor in Filepage.css, copies of file description pages on other wikis (including WMF and third-party ones) would be broken. So a gadget only loaded on file pages wouldn’t be a solution.

On the other hand, it may be a good idea to merge Mobile.css and Common.css styles (that cannot be migrated to TemplateStyles – I’m all for moving things to TemplateStyles!) for use in other namespaces in a default gadget, maybe even one that’s configured to load everywhere except in the file namespace to make sure that things broken on other wikis are broken on Commons as well. (I wish there was an option to load a gadget in all namespaces except for some: this option would be useful to skip file namespace here, but also elsewhere to e.g. skip the special namespace. Without this option, we’d need to list all namespaces in MediaWiki:Gadgets-definition, which is long and harder to maintain, but possible.) —Tacsipacsi (talk) 01:36, 11 February 2024 (UTC)

@Lucas Werkmeister: I suggest we do the following for this block, so that at least it is not in the way (and the title are fullwidth again):

/* Styling the parameter fields */
.fileinfo-paramfield {
 background: #ccf;
 text-align: right;
 padding-right: 0.4em;
 font-weight: bold;
}
/* Layout on larger devices */
@media only screen and (min-width:720px)  {
 .fileinfo-paramfield {
  width: 15%;
 }
}

Is it ideal ? No, but unfortunately there are a few templates other than the main info-template that are used outside of the file namespace, that might break if we remove this entire block. For now, I think it is the best we can do and the tables that are in this situation should get cleaned up eventually (esp with dark mode coming), so let's not fuzz about it too much, perfection is the enemy of good. —TheDJ (talk • contribs) 13:13, 26 June 2024 (UTC)