[10:50:46] All my TemplateStyle pages are broken, there seems to be an update in the skin. : https://tools-static.wmflabs.org/bridgebot/1aff5be2/file_61608.jpg [11:26:29] We are slowly moving viewport limiting of images from minerva into core under the skin—responsive class [11:27:00] So if you are messing with image styling, and run a skin in responsive mode, then this might influence you [11:27:09] Had dark mode updated lately? (re @djhartman: We are slowly moving viewport limiting of images from minerva into core under the skin—responsive class) [11:27:32] It didn’t perform well on Wikidata [11:27:37] But i dont know what ‘your templatestyle pages’ are… (re @Susannaanas: All my TemplateStyle pages are broken, there seems to be an update in the skin.) [11:28:17] There are almost daily changes to enable dark mode long term. (re @cvictorovich: Had dark mode updated lately?) [11:29:02] Yeah it matters for me: I’m a fan of dark mode [11:29:25] Wikidata will take a while, it's still the same item layout for 10 years so the code is quite ancient [11:29:38] For elsewhere? [11:29:58] I’m lately editing frequently here (re @sjoerddebruin: Wikidata will take a while, it's still the same item layout for 10 years so the code is quite ancient) [11:30:32] On wikisource, dark mode obscures index pages severely [11:30:54] Some projects need to adjust their templates [11:31:09] It's just highlighting poor design choices [11:33:19] I haven’t checked, but in general, thats all just templates if i remember correctly, so those templates just arent dark mode compatible yet. (re @cvictorovich: On wikisource, dark mode obscures index pages severely) [11:33:45] Many templates are working poorly (re @sjoerddebruin: Some projects need to adjust their templates) [11:34:35] How can we adjust? [11:34:54] I might take actions if I get some instructions [11:37:35] https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis [11:38:41] there's a page with lots of specific things that need to be fixed at https://night-mode-checker.wmcloud.org/ (re @cvictorovich: I might take actions if I get some instructions) [11:39:40] I might engage in it [11:42:59] How are these data useful? [11:45:46] Color: white… [11:47:57] Codex is still lacking common background colors imo, various shades of green and yellow [11:48:44] The most important and most basic fix that helps almost all these templates, is wherever you define backgound color, ALSO define text color and vice versa. [11:49:48] There is more you can do (use css variables, have templatestyles that define a dark mode variant etc. [12:46:02] These rules are breaking layouts not color. Don't we have a policy to not use "!important" in CSS? (re @Susannaanas: All my TemplateStyle pages are broken, there seems to be an update in the skin.) [12:46:56] "pages that use templates that include styles" (re @djhartman: But i dont know what ‘your templatestyle pages’ are…) [12:47:31] https://www.mediawiki.org/wiki/Extension:TemplateStyles [12:58:39] Avoid. Big difference. (re @tuukkahastrup: These rules are breaking layouts not color. Don't we have a policy to not use "!important" in CSS?) [12:59:29] I'm pretty sure he knows what templatestyles are, but we don't know which templates the displayed styles are used on (re @tuukkahastrup: "pages that use templates that include styles") [13:44:28] I wish we did. using `!important` just leads to more and more things being marked as `!important`, because it's the only way to modify those styles (re @tuukkahastrup: These rules are breaking layouts not color. Don't we have a policy to not use "!important" in CSS?) [14:33:24] unfortunately we have lots of places that use inline styles (just a casual 15 year project to get rid of). so unfortunately that's not possible right now. Which is why its 'avoid' not 'forbidden'. (re @Nikki: I wish we did. using !important just leads to more and more things being marked as !important, because it's the only way to modi...) [14:33:37] in the mean time, no one has pointed at a page that has an actual problems. [14:34:17] @Susannaanas ^ [14:57:42] here's an example I could find https://meta.wikimedia.org/wiki/Wiki_Loves_Living_Heritage/Elements_of_dance [14:58:57] it's overriding the header, making it a lot bigger than it's supposed to be, and the images in the list, where it's making them inconsistent sizes [14:59:51] This can probably be fixed with aspect-ratio and object-fit properties? [15:01:11] they already have `object-fit` [15:02:11] The problem with the theoretical best is that you end up with a huge CSS download. [15:05:22] Oh, I was not following all day! Yes, the lavish use of importants is overriding styles in my templates. I will point to many of them next. It was previously a nuisance mainly in the mobile layouts, which I have not been able to fix, but the !importants gradually creep into image display everywhere. I wonder if it would be good practice in a convoluted project [15:05:22] such as Wikimedias [15:05:22] to seriously avoid using importants? [15:08:07] and `aspect-ratio` doesn't seem like it has the desired behaviour, the images can still end up taller than they were supposed to be [15:08:19] The main page https://meta.wikimedia.org/wiki/Wiki_Loves_Living_Heritage [15:08:20] - Headers (across the project) [15:08:22] - All images and their positioning [15:08:51] If I remember right, aspect-ratio was not whitelisted for css (re @Nikki: and aspect-ratio doesn't seem like it has the desired behaviour, the images can still end up taller than they were supposed to b...) [19:42:00] @Susannaanas I made some changes [19:42:01] https://meta.wikimedia.org/w/index.php?title=Template%3AWiki_Loves_Living_Heritage%2Fstyle.css&diff=26937527&oldid=26145917 [19:43:25] overall, the idea is to keep images within a certain height range, instead of setting a fixed height. [20:10:10] Do you know how the "a img" selector came about? [20:10:11] It seems both too specific and too generic. Why not all img? I can imagine some icons etc in templates needing to be excluded, but then why not exclude thumbnails? Lots of images can be inside a link but not be a thumbnail. [20:10:13] Hardcoding the magic incantation "a img" in template style overrides does not seem sustainable to me long-term. (re @djhartman: @Susannaanas I made some changes [20:10:14] https://meta.wikimedia.org/w/index.php?title=Template%3AWiki_Loves_Living_Heritage%2Fstyle.css...) [20:15:33] Has some change affecting infoboxes also been deployed? I don't remember seeing communication about this and now the infoboxes on nlwiki are looking different and are wider without any community consulation [20:16:52] Almost every attribute is getting overridden : https://tools-static.wmflabs.org/bridgebot/478a113f/file_61626.jpg [20:20:51] Those appear to be MobileFrontend hacks for Minerva from many years ago. I'm not sure why those would apply on desktop on nl.wikipedia.org by default. Does it say where the override is coming from? (try ?debug=2 [20:21:44] And then? [20:22:50] Look for the same crossed-out styles again in the devtools, but this time look for a line by the same name that isn't crossed out. This would be for a differnet selector that includes ".infobox" in it but is likely stronger and thus "wins" the css cascade. [20:25:49] @media all and (min-width: 640px) { [20:25:49] body.skin--responsive .mw-parser-output .infobox { [20:25:50] margin: 0.5em 0 1em 35px !important; [20:25:52] max-width: 320px !important; [20:25:53] width: auto !important; [20:25:55] float: right !important; [20:25:56] clear: right !important; [20:25:58] } [20:25:59] } [20:27:05] Guess https://phabricator.wikimedia.org/rEWMEc0398fbedb91815f5537bc13e9819b5787cc4f90 is the culprit? [20:28:46] Guess I should follow instructions here? https://www.mediawiki.org/wiki/Extension:WikimediaMessages#Site_admin_helper [20:29:11] https://phabricator.wikimedia.org/T360386 [20:29:49] Some background: [20:29:49] https://phabricator.wikimedia.org/T360386 "Create a WikimediaMessages module for sharing styles between Vector 2022 and Minerva" [20:29:50] https://phabricator.wikimedia.org/T358078 "Community discussion about hacks.less" [20:31:44] https://nl.wikipedia.org/w/index.php?title=MediaWiki:Wikimedia-styles-exclude&oldid=67669624 worked [20:32:17] I understand the change, but there was no communication at all [20:32:42] Also, our images currently follow the width of infoboxes, something needs to be done about that as well if things change [20:33:54] Yeah, I get the "full width on mobile" idea, but forcing the exact colors and width of Minerva's infobox is a bit much and indeed not compatible with the diversity of different Infobox variants within a wiki, let alone across different wikis. [20:34:37] the downside is that now the styles are disabled on minerva as well [20:34:38] The style you linked to is not what caused the issue btw, it's a few lines higher up. The style that was added there actually re-re-reoverride it to re-apply the float:right; mode (which the template already does). [20:38:20] good point, this should be a > img (re @Krinkle24: Do you know how the "a img" selector came about? [20:38:20] It seems both too specific and too generic. Why not all img? I can imagine som...) [20:42:40] It looks like it still renders fine on nlwiki mobile m-dot. [20:42:41] nlwiki stores the infobox styles on MediaWiki:Common.css which MF disables. If you wanted to apply these styles on mobile, I'm not sure how right now beyond duplicating styles. Can't copy to Mobile.css (the Common.css mobile alternative) since that's deprecated. Copying to Minerva.css works but then it would load twice for desktop users of Minerva, and still [20:42:42] leaves you with two v [20:42:43] ersions to maintain. [20:42:44] This was decided in https://phabricator.wikimedia.org/T190083. (re @sjoerddebruin: the downside is that now the styles are disabled on minerva as well) [20:44:17] It's mostly the tablet view that is impacted [20:44:37] also infoboxes don't use their full width on mobile atm, could be you hit the cache [20:45:03] https://tools-static.wmflabs.org/bridgebot/07a71183/file_61628.jpg [20:45:56] Hm.. yeah. looks like a mistake in refactoring. Parsoid replaced .image. The FAQ def does not say to remove the ".image" selector. It still needs something. [20:45:58] https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Media_structure/FAQ (re @djhartman: good point, this should be a > img. or just img [20:45:59] There used to be the structure a.image > img. Then parsoid rewrite happened and ...) [20:47:17] Fastest solution imo would be a way to disable on vector only [20:50:41] But both .image and .mw-file-element might be off here. That would still target small icons that aren't thumb/frame figures but e.g. inline images right? The replacement for `.thumb` is `figure[typeof~="mw:File/Thumb"], figure[typeof~="mw:File/Frame"]`, I think? (re @djhartman: good point, this should be a > img. or just img [20:50:41] There used to be the structure a.image > img. Then parsoid rewrite happened and ...) [20:52:41] This css specifically is for inline images though. and has other classes prefixing it. So for this particular case that would be ok. (re @Krinkle24: But both .image and .mw-file-element might be off here. That would still target small icons that aren't thumb/frame figures but ...) [21:47:27] does anyone why the infoboxes style has changed? I can't find the reason but now they seem very different [21:50:56] no, I can see them very different also at en.wikipedia (re @sjoerddebruin: It's mostly the tablet view that is impacted) [21:51:32] https://tools-static.wmflabs.org/bridgebot/f64f7576/file_61633.jpg [21:51:35] See https://phabricator.wikimedia.org/T367462 [22:10:12] is there a way to solve it locally, or we must wait for a global solution?