Wikipedia:Interface administrators' noticeboard

Welcome to the interface administrators' noticeboard

Shortcuts

• WP:IAN
• WP:IANB

This is the interface administrator noticeboard, for discussion of interface administrators and coordination of edits to the interface.

Currently only interface administrators can undelete JS/CSS pages, if you have an uncontroversial undelete or deleted version retrieval request, please list it below.

Any administrator can delete JS/CSS/JSON pages, for speedy deletions just use a CSD template on the page or its talk page.

Individual requests for edits to interface or user JavaScript/CSS pages should continue to be made on their respective talk pages.

Click here to start a new discussion

0 interface-protected edit requests v·h
Page Tagged since Protection level Last protection log entry
Updated as needed. Last updated: 11:38, 29 April 2025 (UTC)

IAdmin access - 2FA requirement now being enforced

Just a note, that the already required 2FA access for group members, is now being enforced by the software. If an int-admin doesn't have 2FA enabled, your int-admin permission will be listed as "disabled" (only when you view your own groups) - and the access will not be available until you enable 2FA. Thank you, — xaosflux ^Talk 22:55, 29 March 2025 (UTC)[reply]

What's stopping the attacker setting up their own 2FA, if you have it disabled? Re-enabling intadmin after 2FA is disabled should require some kind of third party (e.g. crat or steward), otherwise this seems like security theater. The only scenario where this might help is when the attacker wants to "quietly" use your privileges without you noticing. That might make a bit of sense for oversight access, but for intadmin, what can the attacker do beside leave a very public trail of edited pages? Suffusion of Yellow (talk) 23:10, 29 March 2025 (UTC)[reply]

I'm just the messenger here. Feel free to open more feature requests to help improve the process. — xaosflux ^Talk 23:30, 29 March 2025 (UTC)[reply]

Yep, more a question for the crowd, than you specifically. Suffusion of Yellow (talk) 23:43, 29 March 2025 (UTC)[reply]

I think the point here is to force folks to adopt what is a genuine improvement in account security (in case they weren't already). We should not be dismissing this as needless security theater even if a specific attack scenario ("what if the account was already compromised") was not considered. Sohom (talk) 23:34, 29 March 2025 (UTC)[reply]

I ... guess. But I hope it's made clear at the time you are disabling 2FA that re-enabling it will let your account regain access to intadmin privileges. Otherwise it might provide a false sense of security: "I'm not going to use the bit anyway in the next few months, so I'll just disable 2FA now." Suffusion of Yellow (talk) 23:49, 29 March 2025 (UTC)[reply]

Notably, currently the only supported way to change authentication devices is to remove/reactivate - we certainly wouldn't want everyone doing that having to go see granters again (who also would have no way to know that the request wasn't from a theoretical compromised account). — xaosflux ^Talk 00:23, 30 March 2025 (UTC)[reply]

Gadget to hide decorative sticky elements

Moved from Wikipedia:Village pump (technical)/Archive 219 § Gadget to hide decorative sticky elements

 – Aaron Liu (talk) 16:18, 28 April 2025 (UTC)[reply]

Per Special:GoToComment/c-AntiCompositeNumber-20250420003300-RfC:_allowing_editors_to_opt-out_of_seeing_floating_decorative_elements, we should have a gadget labeled "Hide decorative sticky elements" that consists of the following CSS file:

.sticky-decoration {display:none !important;}

Aaron Liu (talk) 01:49, 20 April 2025 (UTC)[reply]

I had made a thingy at User:HouseBlaster/sandbox.css. I propose and support simply making that into a gadget. Best, HouseBlaster (talk • he/they) 02:01, 20 April 2025 (UTC)[reply]

For reference, the line of CSS I gave is the same exact thing but with 200% the spaces. Though, I also just changed my line of CSS to say "sticky-decoration" instead of "floating-decoration". Aaron Liu (talk) 04:19, 20 April 2025 (UTC)[reply]

There was no opposition to the suggestions of creating a gadget to opt-out and for other editors to edit user pages to implement the class, but these issues did not have significant discussion. does not support the creation of a gadget, so I suppose you're taking up the suggestion? A one liner isn't really what we should support gadgets for, and it really is a one liner. Izno (talk) 04:36, 20 April 2025 (UTC)[reply]

Normally I would agree with you. I think that telling people, in an official guideline, to go and check a box in their preferences is far superior to telling them to fiddle with their CSS. Best, HouseBlaster (talk • he/they) 04:40, 20 April 2025 (UTC)[reply]

I agree, especially since this is a matter of accessibility. jlwoodwa (talk) 07:21, 20 April 2025 (UTC)[reply]

Just curious, but the RfC was about user pages, but are there any legitimate uses of these "position: <absolute|sticky|fixed>;" elements elsewhere? I know I have been meaning to get the up/down skip buttons used on WP:HD and WP:TEA adjusted so they don't obscure the mobile/desktop toggle. Commander Keane (talk) 07:31, 20 April 2025 (UTC)[reply]

The skip buttons you mention were brought up in the RfC statement as one example of legitimate use. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)[reply]

Support making that into a gadget as well. * Pppery * _{it has begun...} 13:46, 20 April 2025 (UTC)[reply]

Support, I guess. Though, this seems like a fool's errand, as editors can and will create new elements regularly, and these won't be with the class sticky-decoration (or whatever class name), so the gadget will do nothing. Gonnym (talk) 13:55, 20 April 2025 (UTC)[reply]

The new section (WP:DecoFloat) created by that RfC which thus is now a guideline says that such new elements should have that class, and another thing unopposed (though not really discussed) in the RfC is that editors should be able to drive by and add the class. I'm sure opt-outers would gnome every example of such stickies. Aaron Liu (talk) 14:46, 20 April 2025 (UTC)[reply]

That's all fine. As an editor who fixes lint and other errors, I doubt most people that add those annoying features are going to add the class, which then falls upon gnomes and other editors to fix those horrible features. So we require at least two steps for editors to not view these, and yet still non-registered users can't hide them. Gonnym (talk) 14:49, 20 April 2025 (UTC)[reply]

I feel like most of this was already discussed in the RfC. There's no independent merits you've brought up that only apply to the gadget proposal and not the RfC. Aaron Liu (talk) 15:01, 20 April 2025 (UTC)[reply]

Well then, you know what. I completely oppose on the ground that I think this will do nothing and is completely pointless. Hope that helps. Gonnym (talk) 18:29, 20 April 2025 (UTC)[reply]

If the usage on user pages is deemed a significant accessibility issue, then personally I think the elements in question should be hidden by default, and users can opt into seeing them. If there isn't enough usage to make it a significant accessibility issue, then I think the drawback of adding an additional gadget isn't warranted. isaacl (talk) 16:58, 20 April 2025 (UTC)[reply]

Don't let the perfect be the enemy of the good. jlwoodwa (talk) 17:12, 20 April 2025 (UTC)[reply]

Managing accessibility concerns is about managing tradeoffs. Neither approach is perfect. In my opinion, if the accessibility issue is significant, then the better tradeoff is to let people opt into the problem, rather than opt out of it. isaacl (talk) 18:00, 20 April 2025 (UTC)[reply]

We just had this discussion at the RfC... Elli (talk | contribs) 20:28, 20 April 2025 (UTC)[reply]

Just raising a specific point regarding the relative tradeoffs for managing accessibility, which was not discussed during the previous RfC. (As noted in the summary, detailed discussion of a gadget did not take place.) isaacl (talk) 18:03, 21 April 2025 (UTC)[reply]

It's only a significant issue for a significant but small percentage of users; I think it's worth the drawback (I presume you just mean the preferences table and the in-this-case-tiny burden on intadmins). The significant drawbacks of having such elements be hidden by default have been discussed in the RfC. Aaron Liu (talk) 17:57, 20 April 2025 (UTC)[reply]

Since we're apparently doing the bold-face thing, I support making this into a gadget. If anyone thinks it should be default-on, we can have an RFC about that later. In the meantime the gadget will help those who wouldn't know display: none; from background: url(https://fsb.ru/1x1.png) enable an accessibility feature without worrying. Suffusion of Yellow (talk) 21:04, 22 April 2025 (UTC)[reply]

Moved to IAN

Moved this here so that we can get an implementable result on whether to add this gadget, hopefully that's not improper. Aaron Liu (talk) 16:20, 28 April 2025 (UTC)[reply]

I will note that as of the moment, we have 3 usages of the class across user CSS pages (two of which are the same user). Do we want to wait for more widespread usage before declaring it a gadget ? Sohom (talk) 22:04, 28 April 2025 (UTC)[reply]

For context, .rootpage-Wikipedia_Articles_for_deletion .afd-help sees 58 uses, .ambox-Orphan has 185 uses, non of them have standalone gadgets Sohom (talk) 22:14, 28 April 2025 (UTC)[reply]

Neither of those is an accessibility issue though. jlwoodwa (talk) 22:14, 28 April 2025 (UTC)[reply]

Yes, agreed, I was think out aloud. I don't disagree that we should have this gadget at some point, but I feel like doing it now feels premature given that we have a total of 26 user-pages wrapping elements and 2 CSS pages that use this. Personally, the outcome I would want would be for us stay this proposal for a few more months and then come back to it when we have significant adoption (both across userpages and user CSSes). In the current state, the guideline/gadget will be making a false promise (hiding sticky elements for a majority of the cases). Sohom (talk) 22:29, 28 April 2025 (UTC)[reply]

@Sohom Datta 3 usages, you say? (I seem to have accidentally dismissed the notifications for this thread, sorry for the late reply.) Aaron Liu (talk) 12:19, 1 May 2025 (UTC)[reply]

@Aaron Liu 3 usages in CSS user sub-pages (aka people actually hiding the sticky content, which is what this gadget is aimed at doing). Also, see my follow up, I do agree that this should eventually be implemented, however, I'm on the fence about doing it right now, given that (according to your query) 42 userpages wrap their floating elements. Sohom (talk) 14:18, 1 May 2025 (UTC)[reply]

I don't see why CSS subpage adoption matters. That has no impact on the efficacy of the opt-in. I also don't think 42 is a small number, especially as the infamous fly only has 34 file links total, not all of which are sticky. Aaron Liu (talk) 16:38, 1 May 2025 (UTC)[reply]

@Aaron Liu Can you throw me the link to that query ? I the RFC gave me the impression that this was a much more widespread problem that would require wider adoption than I see at the moment. Sohom (talk) 18:14, 1 May 2025 (UTC)[reply]

Special:WhatLinksHere/File:Fly transparent.gif. Like I said, that's just for the infamous fly. The infamous bouncing ball is used in so many userboxes and stuff that the first four links I clicked on all didn't sticky it, plus at has 15,000+ total file link usages (again, not excluding non-stickies), so I didn't bother trying to count it. Aaron Liu (talk) 22:37, 1 May 2025 (UTC)[reply]

What about userpages using templates with the CSS class, rather than using the class directly? jlwoodwa (talk) 16:43, 1 May 2025 (UTC)[reply]

For {{stickwrap}}, the number is surprisingly zero. Maybe due to the innate repulsion of wrapping a wrapper div with another div. I don't know about other templates. Aaron Liu (talk) 16:46, 1 May 2025 (UTC)[reply]

This sounds like a chicken-and-egg problem, as it's quite likely there would be more instances of user pages wrapping floating elements if this were a gadget. I think we should just implement it today. No point in pushing the can down the road for a few more months when a lot of energy has already been spent on the proposal. – SD0001 (talk) 19:18, 1 May 2025 (UTC)[reply]

I agree. Aaron Liu (talk) 23:20, 1 May 2025 (UTC)[reply]

Per the above, I've gone ahead and implemented the gadget at MediaWiki:Gadget-remove-sticky-decoration.css, MediaWiki:Gadget-remove-sticky-decoration and MediaWiki:Gadgets-definition. The gadget is under the "Test" section for now, we can discuss and figure out which section to put this under (and make sure I've not messed up elsewhere). Sohom (talk) 00:36, 2 May 2025 (UTC)[reply]

Thanks! If it's under a section "Appearance" would fit the most. I agree that it's a bit of a loose fit. Aaron Liu (talk) 01:35, 2 May 2025 (UTC)[reply]

Agree that "Appearance" would be the most appropriate section. Thanks for your work, all :) HouseBlaster (talk • he/they) 22:07, 2 May 2025 (UTC)[reply]

Moved to the "Appearance" section. Sohom (talk) 02:07, 3 May 2025 (UTC)[reply]

Inactive interface administrators 2025-04-28

The following interface administrator(s) are inactive:

• DErenrich-WMF (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
• Galobtter (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— JJMC89 bot 23:20, 28 April 2025 (UTC)[reply]

• First is exempt, later is  Done — xaosflux ^Talk 00:19, 29 April 2025 (UTC)[reply]

  That said, this "exempt" situation propping up every month is problematic, so I might as well ask: @DErenrich-WMF: do you still need interface admin rights here? You don't seem to have used them since September. @JSutherland (WMF): Did you really intend to grant Daniel permanent interface admin rights? Most WMF grants of rights on community wikis are temporary. * Pppery * _{it has begun...} 00:55, 29 April 2025 (UTC)[reply]

  I'm following up. Joe Sutherland (WMF) (talk) 18:26, 30 April 2025 (UTC)[reply]

  Daniel let me know he doesn't need the rights at the moment so I went ahead and removed them. Joe Sutherland (WMF) (talk) 19:07, 30 April 2025 (UTC)[reply]

  Thanks. * Pppery * _{it has begun...} 19:10, 30 April 2025 (UTC)[reply]