Page watchers may be interested in Wikipedia talk:Manual of Style § Mobile skin and block quotations. Please feel free to participate there. Izno (talk) 04:07, 7 September 2024 (UTC)[reply]

I'm not quite sure what Izno's edit summary "and here" means in Special:Diff/1257001458. It doesn't seem to be related to his previous edit on the same page over a month ago, but it might be related to the edit summary "no reason for that" in Special:Diff/1257000611 over at Module:Infobox/styles.css. I don't know how readers of the edit summary "and here" are supposed to understand it, because it takes investigating Izno's edits today before and after to get just a guess at what's meant.

However, what I am sure about is that removing .content from this CSS rule made its comment outdated: Use three classes to match specificity of MobileFrontend/Minerva selectors. It's no longer three classes, but two in each selector. —⁠andrybak (talk) 21:42, 12 November 2024 (UTC)[reply]

I'm sure the note was necessary to note before. Some upstream changes (that we shouldn't be subject to anyway, but that's an aside) have adjusted the expectations for what we need to do locally I think. So now I'm pretty sure the note isn't necessary. Izno (talk) 22:03, 12 November 2024 (UTC)[reply]

Resolved

Update 1: Appears that I duplicated functionality in an existing template, so I did a quick and dirty merge. Awesome Aasim 21:47, 18 November 2024 (UTC)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I recently created a template that changes what content is displayed depending on whether dark or light mode is used. However, it requires a bit of CSS to make working. Please add the following tested CSS into the common.css to make the behavior work as intended.

.lightdark-islightmode {
	display: inline;
}

.lightdark-isdarkmode {
	display: none;
}

@media screen {
	html.skin-theme-clientpref-night .lightdark-islightmode {
		display: none;
	}

	html.skin-theme-clientpref-night .lightdark-isdarkmode {
		display: inline;
	}
}


@media screen and (prefers-color-scheme: dark) {
	html.skin-theme-clientpref-os .lightdark-islightmode {
		display: none;
	}

	html.skin-theme-clientpref-os .lightdark-isdarkmode {
		display: inline;
	}
}

The added lines will make the template work. Since as far as I am aware there isn't CSS that will change this theme, the only way to do this is to have some CSS to make this template work like a switch, similar to all the CSS hiding and showing elements for different user groups.

If it is technically feasible, you can condense the .lightdark-islightmode and .lightdark-isdarkmode down to .lightmode/.islightmode and .darkmode/.isdarkmode to make this CSS work outside of the template I created. Awesome Aasim 01:51, 17 November 2024 (UTC)[reply]

 Not done not going to add this to the site wide script for all readers just for this one template that doesn't have any current usability, and is unlikely to be used in places all readers would need it, such as in articles. — xaosflux ^Talk 02:24, 17 November 2024 (UTC)[reply]

I see the primary use case being templates where icons may need to shift colors depending on background. For example changing a black icon to white where readability is concerned. But I am not going to further debate the merits of such a change yet as I do agree it may need more time to determine its prospective use on pages across Wikipedia. Awesome Aasim 04:21, 17 November 2024 (UTC)[reply]

This doesn't need Common.css anyway. It can be done solely in TemplateStyles. Izno (talk) 07:06, 17 November 2024 (UTC)[reply]

You're right. I thought it would, apparently not! Awesome Aasim 16:42, 17 November 2024 (UTC)[reply]

Sorry to pile on here after the close, but please see the template's talk page, where I asked if this template was redundant to {{if dark}}. – Jonesey95 (talk) 04:35, 18 November 2024 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

mdot is displaying both the anonymous and logged in parameters for {{if IP}} for logged out users. autoconfirmed-show was added to common CSS around the same time as mobile CSS. looks like user-show also needs to be added to the same section. cc: MusikAnimal Jeremyb (talk) 21:25, 15 December 2024 (UTC)[reply]

oops forgot to include the test case: Wikipedia:Meetup/Seattle/Wikipedia Day 2025 Jeremyb (talk) 22:26, 15 December 2024 (UTC)[reply]

 Done * Pppery * _{it has begun...} 18:11, 25 December 2024 (UTC)[reply]

Could we re-think the decision here not to include the nonsysop-show class? Since admins don't have the separate extended-confirmed right, anything that's hidden from non-EC users gets hidden from admins too, and that causes all sorts of problems: there was an issue here a while back, and now all admins are getting a blaring bold-faced STOP: YOU MAY ONLY USE THIS PAGE TO CREATE AN EDIT REQUEST warning on any talk page about the Arab-Israeli conflict. I think that pretty obviously overcomes the concerns about there being no use case for this, and the security concerns aren't valid either (you can already hide things from admins with Template:If extended confirmed). Not adding an edit request for now to get consensus first. Extraordinary Writ (talk) 09:28, 20 February 2025 (UTC)[reply]

I'm still opposed to it in the same manner as the before. As far as your example, if someone made a big blaring message that is causing confusion, it should obviously be reverted. — xaosflux ^Talk 10:28, 20 February 2025 (UTC)[reply]

The message is an important warning for non-extended-confirmed editors—it's just that admins have to see it too for as long as this simple change is blocked. I just don't understand the logic: do you really think Template:If extended confirmed should show things to non-admins but hide them from admins? (That's the status quo.) Extraordinary Writ (talk) 11:21, 20 February 2025 (UTC)[reply]

It sounds like that message is important to tell editors about, but it doesn't have to use the verbiage it is currently using. — xaosflux ^Talk 13:59, 20 February 2025 (UTC)[reply]

That template and associated class probably also shouldn't exist. Izno (talk) 16:06, 20 February 2025 (UTC)[reply]

I can at least understand that argument, but you've been making it for years and it's never gone anywhere, so we've just ended up stuck with this illogical middle ground. Maybe we need an RfC giving multiple choices on what to do with these classes (your position, mine, and the status quo). Extraordinary Writ (talk) 21:36, 20 February 2025 (UTC)[reply]

It hasn't gone anywhere because it takes a consensus generating activity to move from where we are, indeed. Izno (talk) 21:47, 20 February 2025 (UTC)[reply]

If I write this up as an RfC, how many classes would you propose getting rid of? Is it just about extendedconfirmed-show and nonextendedconfirmed-show, or does it also extend to unconfirmed-show, patroller-show, templateeditor-show, extendedmover-show, and/or abusefilter-helper-show (which can all hide things from admins too)? Extraordinary Writ (talk) 23:13, 20 February 2025 (UTC)[reply]

I'd get rid of anything that causes admins not to see some content. Izno (talk) 00:43, 21 February 2025 (UTC)[reply]

I don't want to misrepresent you, so would you mind just putting a wording you're comfortable with here? (All of these classes can be used to hide things from admins, but most of them rarely are, and getting rid of them all would be quite a change.) Extraordinary Writ (talk) 01:47, 21 February 2025 (UTC)[reply]

To facilitate admins being able to see what most editors will see, I think in most cases it would be better not to hide the general message from admins, and to add an admin-specific message explaining which categories of users are not shown the message in question. isaacl (talk) 18:12, 20 February 2025 (UTC)[reply]

That sounds like a good method. — xaosflux ^Talk 22:31, 20 February 2025 (UTC)[reply]

Support enabling this. The community clearly wants and expects this to exist (as the example edit shows), and there's no good reason to stifle that. * Pppery * _{it has begun...} 18:51, 22 February 2025 (UTC)[reply]

there's no good reason to stifle that Please don't speak as fact what is actually your opinion. We have already said why we should't support content hidden from admins but not arbitrary other users, but I can trivially produce some vandalism that makes it obvious why. Izno (talk) 20:20, 23 February 2025 (UTC)[reply]

An acceptable alternative for me is to add the classes to the group-sysop.css page. Defeats some of the point for a lot of the people who expect these classes to work a certain way, but that's basically my compromise position.

Extend this to arbitrary other user groups, by the way. Content displayed only to autoconfirmed users is as bad as content displayed only to extended-confirmed users with the observing groups as extended-confirmed and sysop, respectively. Izno (talk) 20:23, 23 February 2025 (UTC)[reply]

If the issue is vandalism why not filter the display:none behind body:not(.ns-0)? That probably ameliorates most of the vandalism potential. I don't know about a class that hides things for sysops but I would support adding `nonextendedconfirmed-show` to MediaWiki:Group-sysop.css with the ns filter I mention. Galobtter (talk) 20:46, 23 February 2025 (UTC)[reply]

Still have to fix the vandalism. The particular variety I'm thinking of is the image related vandalism via templates, which adds at least ns-8 to the filter. Izno (talk) 20:56, 23 February 2025 (UTC)[reply]

I'm fine with the compromise position. I also don't have any issues with filtering out mainspace (these shouldn't be used there anyway), but any filters should be applied consistently to all classes; these ones are far less of a vandalism threat than (say) anonymous-show, which has been used without incident for nearly a decade. Extraordinary Writ (talk) 23:18, 23 February 2025 (UTC)[reply]

I think we need to take a step back and think about the overall goals. Non-admins aren't directly affected by what is shown to admins. To better support non-privileged users, admins should be able to see the messages displayed to most users, and ideally to users in different categories. If it doesn't already exist, that could be done with a user script or gadget. In the interim, I think letting the general messaging appear to admins and adding additional explanatory notes shown only to them would help admins support all users as well as understand what situations apply to different categories of editors. isaacl (talk) 23:28, 23 February 2025 (UTC)[reply]