Wikipedia talk:User pages/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

Allow harmless MediaWiki imitations

Please allow imitations of the MediaWiki interface which don't harm the actual one. However, fake notification banners or harmful interface imitations mustn't be allowed. SonicIn2022 (talk)

I've no idea what you mean. Could you provide an example or a more detailed explanation? Schazjmd (talk) 16:42, 8 March 2023 (UTC)

I suspect it is about Wikipedia:User pages#Simulation and disruption of the MediaWiki interface. —CX Zoom[he/him] ^{(let's talk • {C•X})} 08:26, 9 March 2023 (UTC)

Removing comments from user talk pages

An editor asked a question of me on my talk page and I gave a reply. Recently, the same editor removed the section [1]. Is this generally allowed? Not bothered either way in this instance, just wondering what the etiquette is. Rupples (talk) 19:45, 18 June 2023 (UTC)

@Rupples, once you reply, it would be inappropriate for the other editor to remove the whole conversation from your talk page. It's up to you if you want to revert that removal (so the conversation remains and can eventually be archived) or not. Schazjmd (talk) 20:02, 18 June 2023 (UTC)

Good of you to answer. Just realised this page isn't really appropriate for my previous question and was in the process of striking through! I wonder if something along the lines of the following could be added to the opening paragraph of WP:NOBAN? "It is not considered good etiquette to remove conversations from other users' talk pages, without first seeking agreement." Rupples (talk) 20:17, 18 June 2023 (UTC)

@Rupples, the guidance for talk pages, WP:OWNTALK, says Although archiving is preferred, users may freely remove comments from their own talk pages. I think in this instance, it's just a fairly new editor who may have thought that was an appropriate way to convey that they'd read your reply and considered the conversation done. They just need WP customs explained to them. Schazjmd (talk) 21:01, 18 June 2023 (UTC)

Block notices

Is (repeated) removal of block notices e.g., User talk:37.147.79.38 allowed? I assume so, but I thought I'd check. Edward-Woodrow :) _[talk] 22:27, 15 July 2023 (UTC)

In general, yes. They know they're blocked, we know they're blocked, no harm is being done. Of course doing it in the way that 37.147.79.38 did it is going to get reverted and is not going to end up going well for them. -- zzuuzz ^(talk) 22:57, 15 July 2023 (UTC)

Question

I recently came across CooperGoodman's ^{(no ping)} userpage from a Village Pump discussion. That second section definitely isn't on-topic for WP, but I'm on the fence on for whether it qualifies as causing "widespread offense" or constituting "extremely offensive material". My inclination is to leave it alone, but I could definitely use with a second opinion. Cheers, Edward-Woodrow :) _[talk] 12:59, 9 September 2023 (UTC)

Clarification: I mean, I understand (or at least assume) that the intent is humourous, but... Edward-Woodrow :) _[talk] 13:00, 9 September 2023 (UTC)

• Doesn’t offend me. It appears to be a quote. Flat humor, but humor. Blueboar (talk) 13:08, 9 September 2023 (UTC)

It's meaningless copypasta. --Onorem (talk) 13:11, 9 September 2023 (UTC)

likely to bring the project into disrepute

you may not include in your user space material that is likely to bring the project into disrepute

This should be removed. It's a hopelessly subjective standard, "disrepute" being entirely in the eye of the beholder, and entirely dependent on audience. What is "likely to bring the project in disrepute" amongst some people is likely to bolster the project among others. (And how likely is "likely"?) This language creates more problems than it solves, as it can be wielded by literally any side in any userpage conflict, but offers no meaningful, actionable, or usable guidance. Levivich (talk) 17:28, 2 December 2023 (UTC)

In context, that statement is a summary of what has been found removable in the past by MfD, much like WP:OUTCOMES for AfD. I agree that it itself would be problematic to enforce as policy, but as a summary of consensus, it should probably be refined rather than removed entirely. Jclemens (talk) 19:20, 2 December 2023 (UTC)

Levivich, can you suggest alternate wording? Cullen328 (talk) 03:21, 16 January 2024 (UTC)

I don't think there is anything wrong with the existing wording. It falls under the heading of commonsense. It strikes me as similar to the old saying about pornography. "I can't define it, but I know when I see it." Has this ever been abused? Is there anything that would prevent a user from appealing to AN/I if they felt someone was being unreasonable in their interpretation of this? To be honest, I can't even remember it being invoked. But I think it's good thing to have on the books. -Ad Orientem (talk) 03:38, 16 January 2024 (UTC)

The language at WP:UPNOT is fine. It gives examples of unsuitable material ("disrepute") such as racist ideology and disruptive content, whether serious or trolling. As normal, rules focus on concepts rather than attempting to list every bad thing. As Ad Orientem noted, participants in a deletion discussion might recognize disrepute when seeing an example but would not be able to define it. Johnuniq (talk) 04:56, 16 January 2024 (UTC)

@Cullen328: I think WP:UPNOT already has better alternate wording, likely to give widespread offense. (To save a click, the full sentence is: In addition, there is broad agreement that you may not include in your user space material that is likely to bring the project into disrepute, or which is likely to give widespread offense (e.g. racist ideology).)

Similarly, WP:UP#Images that would bring the project into disrepute has a pretty good description of what kind of images should not be on a userpage, and I'd keep it all, except changing "likely to bring the project into disrepute" to "likely to give widespread offense" (and same everywhere else in WP:UP). Levivich (talk) 05:11, 16 January 2024 (UTC)

Levivich, I think that there is an important distinction between the concepts of "offense" and "disrepute". The first is a personal reaction, and as we all know, some people are more prone to being offended than others, and even among people who are easily offended, they can be offended by very different things. Disrepute refers not to individual emotional reactions but rather to the reputational damage to Wikipedia as a whole. Twitter/X is a good example, I think. I am not easily offended by something like an individual tweet. I may be surprised, bemused, and unhappy that trolling and doxxing and racism and sexism and veiled (or not so veiled) threats are welcomed there, but I am not offended. I do think that Twitter/X has fallen deeper into disrepute in the Musk era, and I do not want lax monitoring to allow the same thing to happen to Wikipedia. Perhaps "disrepute" is almost an archaic term in 2024, but the new wording should not lose the reputational connotations. Cullen328 (talk) 08:06, 16 January 2024 (UTC)

I think doxing, racism, sexism, and threats are things that are likely to give widespread offense (even if not to you), and I can't really think of an example of something that is likely to give widespread offense but not likely to bring the project into disrepute, which why I say "disrepute" is doing no work in the sentence, and why I don't think there needs to be a second category of prohibition in addition to "widespread offense". Levivich (talk) 17:01, 16 January 2024 (UTC)

False claims on user page

I am wondering what, if anything, can be done about an editor's user page which makes false claims of having made 100K edits and being a member of the Twenty Year society, despite the fact that the user in question has only been on Wikipedia since 2017 and has only made 3,500 edits. They have indirectly denied having previous accounts... Skyerise (talk) 11:18, 26 January 2024 (UTC)

@Skyerise Is that still an issue? Doug Weller talk 15:15, 14 April 2024 (UTC)

@Doug Weller: well, depends. The content of their user page is obviously and intentionally funny. Yet it also includes various templates and categories from the 20 YS etc. which still make the kind of claims above. And yet I've recently been told there is nothing we can do if an obviously not retired user posts a big retired from Wikipedia banner at the top of his user page. So do we even care about this? If current protocol is to just ignore such things, then I don't want to make waves. Skyerise (talk) 15:25, 14 April 2024 (UTC)

I don’t know protocol but often see retired templates on active users user or talk pages. Annoying but not worth saying anything I usually decide. Doug Weller talk 18:12, 14 April 2024 (UTC)

Proposed addition to information on removing notices from own talk page

Currently it reads:

Policy does not prohibit users, whether registered or unregistered, from removing comments from their own talk pages, although archiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the user has read and is aware of its contents; this is true whether the removal was manual or automatic. There is no need to keep them on display, and usually users should not be forced to do so. It is often best to simply let the matter rest if the issues stop. If they do not, or they recur, then any record of past warnings and discussions can be found in the page history if ever needed, and these diffs are just as good evidence of previous matters.

I think it should say something like:

Policy does not prohibit users, whether registered or unregistered, from removing comments from their own talk pages, although archiving is preferred. If a user removes material from their talk page, it is normally taken to mean that the user has read and is aware of its contents; this is true whether the removal was manual or automatic. There is no need to keep them on display, and usually users should not be forced to do so. It is often best to simply let the matter rest if the issues stop. If they do not, or they recur, then any record of past warnings and discussions can be found in the page history if ever needed, and these diffs are just as good evidence of previous matters. While it is a user's prerogative to remove material from their talk page, removal and ignorance of warnings may be taken into account by administrators when evaluating any sanctions to take.

(adding "While it is a user's prerogative to remove material from their talk page, removal and ignorance of warnings may be taken into account by administrators when evaluating any sanctions to take", for anyone who can't see the bolded portion above on their browser)

Thoughts? —DIYeditor (talk) 01:57, 23 May 2024 (UTC)

Why? Primefac (talk) 11:17, 23 May 2024 (UTC)

Because I see a difference between someone simply archiving or removing stale notices, and a certain kind of belligerent removal-and-ignorance (often with questionable edit summaries) that certain users do who apparently don't like to be told what to do. I think it should say here you are free to remove it, but if you are doing it belligerently or simply ignore the notice, it can be considered as evidence of disruption. —DIYeditor (talk) 18:43, 26 May 2024 (UTC)

If the base assumption is that removal follows reading and awareness, then it doesn't really matter why (or how) the notices are removed; repeated disruption related to the original notices can still result in sanctions. Primefac (talk) 20:04, 26 May 2024 (UTC)

It's unclear. What does "taken into account" mean? Is that a euphemism for "might give stronger punishments because you didn't leave the badge of shame on your talk page" (in which case, it ought to be more direct), or does it just mean "might notice that you've already been warned repeatedly about this" (in which case, it's redundant)?

DIYeditor, it feels like you want to punish people for being defiant. That may not be the most productive approach to humans, regardless of whether they're teenagers sassing their parents or editors saying something snarky about a warning. If you'd like to read about a site that took a different approach, then I suggest https://www.newyorker.com/news/letter-from-silicon-valley/the-lonely-work-of-moderating-hacker-news The relevant stuff starts about halfway through that article. WhatamIdoing (talk) 00:14, 27 May 2024 (UTC)

Paywalled. I often encounter users who have some kind of problem with rules and express it by deleting warnings with snarky edit summaries, very often completely valid warnings. I do imagine it is they rather than I who don't get along well in life. Still, never said I would make a good cop, or wikipedia admin, or moderator. At any rate, yes, I think editors who do this "oppositional-defiant" behavior should be punished more harshly than those who try to accommodate the processes here. —DIYeditor (talk) 02:26, 27 May 2024 (UTC)

Got a problem with my user talk page

I can not get the text on my user talk page to show up except by clicking on 'About this page'. Is there anyone who can help me with this John Kryten (talk) 21:15, 15 June 2024 (UTC)

I think the problem was that you didn’t give the text a header. I added one, and now it seems to work. Blueboar (talk) 22:40, 15 June 2024 (UTC)

Thank you My username is John Kryten though not John Krysten John Kryten (talk) 12:35, 16 June 2024 (UTC)

Oops… sorry about that. I have corrected the header I added (feel free to further edit that header if you want it to say something else). The important thing is that your userpage should now work, and that it shows the text you wanted. Happy editing! Blueboar (talk) 12:30, 19 June 2024 (UTC)

Thank you Happy editing John Kryten (talk) 17:25, 14 July 2024 (UTC)

Proxying while blocked

This user[2] is challenging someone telling them they should not use their talk page while blocked to ask other editors to edit for them, saying that they cannot find anything preventing them from doing so. I think this needs to be made explicit. Thanks. Doug Weller talk 08:20, 27 February 2024 (UTC)

Well, they're wrong, because WP:PROXYING (linked to by Novem in the first place) states it fairly clearly. Primefac (talk) 14:14, 27 February 2024 (UTC)

@Primefac Thanks. I knew that was somewhere, but I think it needs to be added here as well. Probably under "Ownership and editing of user pages". Doug Weller talk 14:41, 27 February 2024 (UTC)

Might be useful; further interaction with them has shown even that fairly clear language can be reworded to suit very specific circumstances. Primefac (talk) 15:09, 27 February 2024 (UTC)

WP:PROXYING does not [state] it fairly clearly. It doesn't state it at all. It does not say that blocked editors should not use their talk page while blocked to ask other editors to edit for them. It says that editors [...] are not permitted to post or edit material at the direction of a banned or blocked editor. It says nothing about what the blocked editor can or cannot do.  Tewdar  18:08, 27 February 2024 (UTC)

Users are not allowed to be directed by blocked users to make edits. Therefore, a blocked user should not be directing editors to make edits. Primefac (talk) 18:10, 27 February 2024 (UTC)

I agree with this interpretation, and there's plenty of precedent to cite on revoking TPA for posting proxying requests. I still would support explicit mentions here and in the block and ban policies that it is inappropriate to post edit requests in violation of a block/ban. Firefangledfeathers (talk / contribs) 18:13, 27 February 2024 (UTC)

This does not follow at all. Why not just add 'site-wide blocked users may only use their talk pages to request unblocks', to WP:BLOCK, if that's what you want?  Tewdar  18:13, 27 February 2024 (UTC)

That's what this discussion is, well, discussing. Primefac (talk) 18:52, 27 February 2024 (UTC)

I went and corrected the typo that "the user" indicated [3]. Clearly, it was a net positive for the encyclopedia. Do you want to ban me for it? Go ahead. XMcan (talk) 20:51, 27 February 2024 (UTC)

I can’t believe so much time gets wasted on arguing when something is so simple, and you can just go ahead and make it better. XMcan (talk) 20:54, 27 February 2024 (UTC)

XMcan, the discussion on that user's talk page is about their edits. This is about the next time this happens, and making sure our policies match up with what actually happens. Primefac (talk) 21:05, 27 February 2024 (UTC)

I agree, but I believe this was a one-time occurrence. I don't have any reason to think this user will spend the rest of her life finding typos and directing us from her talk page solely to correct them. Do we need to fix problems that don't exist just because they may potentially exist? XMcan (talk) 21:32, 27 February 2024 (UTC)

@XMcan I see on your talk page you were very unhappy about the user’s block. I presume that’s part at least of why you are here. But it’s a real issue that does exist, I’ve seen it quite a few times. There’s no reason to believe it won’t happen again. Doug Weller talk 21:44, 27 February 2024 (UTC)

For the record I was not referring to the "next time" for this particular user, I was referring to the next time that an admin says "you can't use your talk page except for unblocks" and is questioned on it. Primefac (talk) 09:40, 28 February 2024 (UTC)

Primefac, I understood you and agree. We need wording that will deter disruptive editors from gaming the system. -- Valjean (talk) (PING me) 15:42, 28 February 2024 (UTC)

WP:PROXYING doesn't state that at all. WP:PROXYING says, my emphasis,

Editors in turn are not permitted to post or edit material at the direction of a banned or blocked editor (sometimes called proxy editing or proxying) UNLESS they are able to show that the changes are productive and they have independent reasons for making such edits.

That "unless" means that proxying is only prohibited if editors are not able to show the changes are productive and they have independent reasons for making such edits. If they are able to do so (e.g., "fix obvious typo"), then editors are permitted to edit material at the direction of a banned or blocked editor. I'm not sure that's what the community wants it to mean, but that's what it says.

It has an inherent logical contradiction in its phrasing, which is that it is by definition impossible to have an independent reason to do something at the direction of somebody else. Either it's "at the direction" or it's "independent" but it can't be both at the same time. Teh community should probably vote on whether they do or do not want blocked/banned editors to point out obvious typos, BLPvios, etc., and then update the docs to say so clearly. Levivich (talk) 21:40, 27 February 2024 (UTC)

I don't have an opinion about the proxying, but I must protest against turning Doug's query into a binary question between a) blocked users asking others to make edits, versus b) blocked users only being allowed to use their pages to request unblock, as for example Primefac does here. As far as I'm aware, it doesn't say anywhere that a blocked user may only use their page to request unblock, and I wish admins wouldn't keep bollocking or sanctioning people per the notion that we have that rule. I'm also completely against codifying it to be a rule. A block is a shock, and it's only too human to react to to that block with protests and venting. That should be tolerated, being as we are humans, up to a point. If it goes on and on, and/or becomes ugly w r t to the blocking admin or other individuals, I will eventually revoke tpa. That's my system, and I'm sticking to it. Bishonen | tålk 13:09, 28 February 2024 (UTC).

I wish admins wouldn't keep bollocking or sanctioning people per the notion that we have that rule - that's why I want to pursue this line of inquiry and potentially clarify things; I was wrong and have have changed my opinion, but there are still a large number of admins who likely have misread the policy (or conflated it with the BAN regulations). Primefac (talk) 14:08, 28 February 2024 (UTC)

• I think this needs to be handled on a case by case basis… because a LOT depends on what the blocked editor is asking others to do on his/her behalf. For example, I see nothing wrong with a blocked editor writing: “Prior to being blocked, I was about to shift my attention to cleaning up the awful grammar in article Y. Could someone follow up on that?” Such a request is not really a PROXY request. The blocked editor is not “directing” the editing of others, just requesting normal editing.

On the other hand, if the blocked editor writes: “Since I have been blocked, and can not continue my righteous crusade, would someone please nominate NewsIdontlike.com for deprecation at RSP. Carry on the good fight!” That would be “directing” others, and a PROXY request. Blueboar (talk) 13:54, 28 February 2024 (UTC)

@Firefangledfeathers, Tewdar, Blueboar, and Primefac: I think the need to continue this is demonstrated by the XRV discussion involving me mentioned below. Doug Weller talk 15:20, 14 April 2024 (UTC)

I agree, though I'd prefer to wait until the XRV is concluded. Maybe someone can ping us all again when it's over? Firefangledfeathers (talk / contribs) 12:05, 15 April 2024 (UTC)

@Firefangledfeathers Oh we definitely should wait. I'll ping you all when it's closed. Doug Weller talk 12:17, 15 April 2024 (UTC)

@Firefangledfeathers, Tewdar, Blueboar, Primefac, Bishonen, and Levivich: shall we try to come to a conclusion now? Doug Weller talk 13:33, 20 July 2024 (UTC)

@Doug Weller, I had this conversation on my watchlist but hadn't yet commented because I didn't think I needed to say what had already been said by numerous others. However is there some specific wording for any changes because I can't see it above? TarnishedPath^talk 13:54, 20 July 2024 (UTC)

I would just repeat what I said above. Blueboar (talk) 14:07, 20 July 2024 (UTC)

I'd like for this guideline to say something like

Users who are site-blocked or site-banned are encouraged to primarily use their talk pages for unblock requests or conversation leading toward such a request. Though blocked or banned users retain much of the wide latitude afforded to all users in their own user space, they may lose access to their user talk page if they violate policies (e.g., WP:PROXYING) or otherwise continue acting disruptively. This is especially true if they continue the behavior that led to the block or ban or if they try and direct others to edit on their behalf (see WP:PROXYING.)

I think we should change WP:PROXYING to be more concrete about what's impermissible for the banned/blocked user, but that's a conversation for WT:BAN. If we can't agree to a change their, my proposal here would end at "led to the block or ban". Firefangledfeathers (talk / contribs) 15:38, 20 July 2024 (UTC) striking and inserting 04:07, 21 July 2024 (UTC)

What do you think about striking the last sentence and ending with "...if they violate policies (e.g. WP:PROXYING) or otherwise continue acting disruptively."? Levivich (talk) 15:52, 20 July 2024 (UTC)

I'm fine with that, although I would like to get something that hints at disruption of the type that led to the block being particularly risky. Maybe that's common sense enough that it can be left out or parked in an essay. Firefangledfeathers (talk / contribs) 21:59, 20 July 2024 (UTC)

The wording with Levivich's suggested change sounds good to me. TarnishedPath^talk 03:52, 21 July 2024 (UTC)

So amended. Firefangledfeathers (talk / contribs) 04:07, 21 July 2024 (UTC)

XRV Notice

The “proxying while blocked” editor mentioned here subsequently had their talk page access revoked by the OP. In case anybody is interested, there is currently a discussion at Wikipedia:Administrative action review regarding that TPA revocation.— Preceding unsigned comment added by XMcan (talk • contribs) 17:57, April 13, 2024 (UTC)

Convenience link: Wikipedia:Administrative action review/Archive 1#Indefinite TPA revocation for “proxying while blocked” –Novem Linguae (talk) 17:03, 20 July 2024 (UTC)

Standpoint of the editor proxying

• Question: It takes two to tango… and two to proxy. Is there any policy or guideline where we approach this issue from the stand point of the editor acting as the proxy (ie something outlining when it is appropriate to edit on someone else’s behalf vs when it is inappropriate to do so)? Blueboar (talk) 16:42, 20 July 2024 (UTC)

  Hey Blueboar. I think we actually have more policy/guideline for the proxy, since they at least get a line at WP:PROXYING. It's still unclear what is permissible, and I do think we should draw a clearer line. We have a total absence of policy/guideline for the ... I don't actually know what to call them ... proxymaster? That's part of what we're hoping to fix above. Firefangledfeathers (talk / contribs) 22:01, 20 July 2024 (UTC)

Thanks all, nice to see this brought to a conclusion. Doug Weller talk 07:12, 21 July 2024 (UTC)

Should we be saying something about use of the talk page if topic banned from an area?

I think editors might not realise that "all pages" includes their talk page. I've just seen an editor telling someone else that they can say anything they want on their talk page, and as they are topic banned it would be nice to be able to quote this guideline. Doug Weller talk 15:44, 20 July 2024 (UTC)

I agree as it is a recurring matter, this includes extended confirmed topics for those who are not extended confirmed. Sir Kenneth Kho (talk) 11:39, 28 July 2024 (UTC)

But ARBPIA says user space is exempt. Doug Weller talk 13:23, 28 July 2024 (UTC)

Could you cite the sentence saying it? I took a cursory look but did not find it, perhaps I failed to see the nuances. Sir Kenneth Kho (talk) 14:38, 28 July 2024 (UTC)

@Sir Kenneth Kho see [{Wikipedia:Arbitration/Requests/Clarification and Amendment#Statement by Selfstudier]] linking to Wikipedia talk:Arbitration Committee/Noticeboard#Why does ARPBIA allow userspace as an exception? and specifically [https://en.wikipedia.org/wiki/Wikipedia:Arbitration/Index/Palestine-Israel_articles#:~:text=ago)%20(UTC%2B0)-,Definition%20of%20the%20%22area%20of%20conflict%22,discussions%20in%20all%20namespaces%20with%20the%20exception%20of%20userspace%20(%22related%20content%22),-Passed%206%20to[ Doug Weller talk 15:15, 28 July 2024 (UTC)

Interesting, WP:PIA clause 4(B) seemed to be in tension with WP:ECR clause A(1). I hope we will receive clarity on WP:BROADLY, the former is not excessively broad, while the latter could have precedent, depending on the original intent of WP:ECR in 2021 and 2023. Sir Kenneth Kho (talk) 16:05, 28 July 2024 (UTC)

WP:NOINDEX

Are there any reasons why we should not require NOINDEX on all pages in userspace (not draftspace)? (I would also include article talk pages and archives.) If not, then it should happen automatically. If there are any reasons, let's discuss them. I have long done this for my user and user talk pages and of course all my subpages. If I've missed a subpage, it's an accident.

Our userspace page content is not part of the encyclopedia and is not intended to be "outward" facing. Userspace is our personal "desk" in the editorial back offices of the encyclopedia's publishing house. It should only contain stuff related to communication with other editors and helping editors improve the project. That includes personal notes, sandboxes, personal essays, and article development, IOW the stuff editors do.

By contrast, our articles are in the front office where the public comes to see what this place is all about. We are not a web host for stuff unrelated to these purposes. -- Valjean (talk) (PING me) 15:07, 4 August 2024 (UTC)

I thought everything in the user namespace was already automatically NOINDEXed (by a bot)… that’s what it says at WP:NOINDEX. Is that not happening? Blueboar (talk) 17:09, 4 August 2024 (UTC)

You're right! Thanks. -- Valjean (talk) (PING me) 17:17, 4 August 2024 (UTC)

Editing of others' user pages by new or unregistered users

I am way behind in the Help Desk archives but I discovered something new here. I decided to try it myself while logged out and although I got to the edit screen, I saw a big pink box saying I can't do the edit. I didn't know it was possible to not edit while not seeing "View source". I don't see anything on the user page guidelines that says this. — Vchimpanzee • talk • contributions • 23:04, 6 August 2024 (UTC)

It's mentioned under WP:UP#PROTECT. It's the result of Wikipedia:Requests for comment/Protect user pages by default, and uses an edit filter (803 (hist · log)) instead of protection. That way new users can still edit their own user page. -- zzuuzz ^(talk) 00:03, 7 August 2024 (UTC)

That didn't specify the situation I encountered. I find it hard to believe two random people would have protected their user page in this way. In fact, one of them was mine, and I know I haven't done it. Unless someone did it after vandalism.— Vchimpanzee • talk • contributions • 15:57, 7 August 2024 (UTC)

The filter applies to all user pages not owned by the person editing it, when the person trying to edit is not confirmed. In other words, if you log out and try to edit any user page, the filter will prevent you publishing the edit. Technically it's not the same as protection, though the end result is broadly similar. -- zzuuzz ^(talk) 15:49, 8 August 2024 (UTC)

Can we include this information somehow in the description?— Vchimpanzee • talk • contributions • 15:53, 8 August 2024 (UTC)

Oh, now I see it.— Vchimpanzee • talk • contributions • 21:23, 8 August 2024 (UTC)

Newcomer homepage

I saw a reference to this in the Teahouse archives but I don't know where it is covered. Apparently not on WP:UP. Based on the response to the question, I got the impression this would be a "user page" in the sense of user talk pages and user pages.— Vchimpanzee • talk • contributions • 23:16, 2 September 2024 (UTC)

Help:Logging in § Your user page and user talk page is the only thing I could find that indicates that a user/talk page is located in the top of every window. Primefac (talk) 15:45, 3 September 2024 (UTC)

Should the newcomer homepage be added to that information on that page?— Vchimpanzee • talk • contributions • 20:54, 3 September 2024 (UTC)

See Wikipedia:Growth Team features#Newcomer homepage (and the section above it for why certain articles keep having extra links added by new editors). You can turn it on at the bottom of the User Profile tab in Preferences. NebY (talk) 17:53, 3 September 2024 (UTC)

I was looking for something that explains the newcomer homepage to new editors.— Vchimpanzee • talk • contributions • 20:59, 3 September 2024 (UTC)

Is this acceptable from a fairly new editor?

187 edits, claims 15 years [4] Doug Weller talk 14:26, 29 November 2024 (UTC)

Their biography does state they've been editing as an IP for that time period, so I don't see why not. Primefac (talk) 16:24, 29 November 2024 (UTC)

Yes, that makes sense. Whatever is there, I think good faith means we ignore it and I shouldn't have brought it here. Doug Weller talk 16:26, 29 November 2024 (UTC)

UTP acronym

Re: [5]

I thought my edit was fairly uncontroversial. I should know by now that very little is uncontroversial in Wikipedia editing.

My position is well articulated at User talk:Primefac#UTP, so I won't repeat it here. ―Mandruss ☎ IMO. 17:27, 9 February 2025 (UTC)

WP:KEEPDECLINEDUNBLOCK

It's been pointed out to me that WP:KEEPDECLINEDUNBLOCK was modified a couple of years ago to apparently allow for declined unblock requests of non-sitewide bans to be removed. I'm trying to find the discussion of this -- it doesn't make much sense to me, so I'd like to see how the consensus was developed. --jpgordon^{𝄢𝄆𝄐𝄇} 20:36, 23 February 2025 (UTC)

I see no good reason for the change; I think declined unblock requests should only be removable when the block is, regardless of its scope. Jclemens (talk) 23:22, 23 February 2025 (UTC)

I agree with Jclemens. I should think that reviewing admins would want to see previous requests/responses, whether it's a partial or sidewide block. Schazjmd (talk) 00:35, 24 February 2025 (UTC)

I don't recall but I guess the idea is that someone might be indefinitely partially blocked from an article, but there is no need for them to wear the badge of shame forever. By contrast, a notice for a currently active sitewide block should be retained. That seems reasonable. The contribs for The ed17 at that time show that single edit with no corresponding comment in a discussion. Johnuniq (talk) 01:15, 24 February 2025 (UTC)

Perhaps prior requests (for parblocks) should be kept or at least pointed out if a new request is made? 331dot (talk) 01:47, 24 February 2025 (UTC)

Is there a less obvious way to keep notes of declined non-site-blocks readily accessible to any administrator? Gaming the system as stated now is so simple I don't think BEANS even applies. Jclemens (talk) 01:50, 24 February 2025 (UTC)

Thanks for the ping Johnuniq. I have no recollection of what prompted me to make that edit. As you say, it's a real outlier of an edit that day. I have no objections if anyone here wants to modify it. Ed ^{[talk] [OMT]} 17:19, 24 February 2025 (UTC)

I've removed the "sitewide" modifier. Thanks! --jpgordon^{𝄢𝄆𝄐𝄇} 19:28, 8 March 2025 (UTC)

Discussion at Wikipedia:Village pump (idea lab) § Wrapping floating decorative elements in a standardized CSS class

 You are invited to join the discussion at Wikipedia:Village pump (idea lab) § Wrapping floating decorative elements in a standardized CSS class. HouseBlaster (talk • he/they) 20:47, 10 March 2025 (UTC)

RfC: allowing editors to opt-out of seeing floating decorative elements

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.

---

Should the following be added as a section at Wikipedia:User pages § What may I have in my user pages?, which allows editors to opt-out of seeing floating decorative elements? HouseBlaster (talk • he/they) 23:02, 16 March 2025 (UTC)

Proposed wording

Floating decorative elements

Editors are permitted to have a reasonable number of decorative elements which follow the reader down the screen on their user page, their talk page, or both. Some editors find these elements distracting or otherwise annoying. If they are included, they should be wrapped in class=floating-decoration. This allows anyone to opt-out of seeing floating elements by adding the following line to their common.css:

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

Functional elements (such as {{skip to top and bottom}}) should not be wrapped in class=floating-decoration.

Survey (decorative elements)

• Support as proposer. I'll start by saying I am talking about the stuff you can view at User talk:HouseBlaster/sandbox; if you follow the opt-out instructions in the proposal you can see what that page looks like once you are opted out.

  I completely understand that many people find floating decorations to be a great way to have some fun while editing Wikipedia. I edit Wikipedia first and foremost because it is fun. I do not want to be the WP:FUNPOLICE; I do not want to stop anyone from expressing themselves. At the same time, I personally find them to be extremely distracting. A great deal of Wikipedians have sensory issues, myself included. These elements are not a problem for everyone, but they are a problem for some people. Helping those people contribute to Wikipedia is a worthwhile endeavor, and far from a solution in search of a problem – even if you are not personally experiencing the problem.

  The point of this addition is to provide editors with a way to opt-out of the elements, not to ban them. If you do not modify your common.css, this will have zero impact on how the items are displayed.

  CREEP is a valid concern for any PAG proposal. However, this needs to come from a centralized area to be effective; the name and use of the CSS class need to be standardized, lest you need to enter many different rows into your common.css to opt-out (if the elements have the opt-out class included at all). HouseBlaster (talk • he/they) 23:02, 16 March 2025 (UTC)

  It appears I forgot to say that I also support allowing editors to make edits to add the class. I think this goes without saying—this is a collaborative encyclopedia, after all, and gnomes should be able to lend a helping hand. This is especially useful if the editor whose userspace it is isn't familiar with CSS. Best, HouseBlaster (talk • he/they) 06:08, 13 April 2025 (UTC)

  I think that is very optimistic. Wikipedia is very difficult to use. The good news is most people won't find these userpages. But then the process from finding such a userpage (and thus the damage is done) to finding out who to change your css, which sounds like some hacker thing, and then trying to find help on how to change it, and then trusting someone to change the code on your computer. You have to think about this from the POV of a complete noob. The whole process could take days, and most would give up. Wikipedia may be a collaborative encyclopedia, but most people don't treat it like that. Maybe people expressing themselves a little less out of concern for others would be a move in the right direction. DrGlef (talk) 08:58, 15 April 2025 (UTC)

  Just toggle it as a gadget as suggested below. Aaron Liu (talk) 01:44, 16 April 2025 (UTC)

• Support per HB. This is an accessibility issue. voorts (talk/contributions) 23:15, 16 March 2025 (UTC)
• Support per above. I can see no downsides in allowing people to opt out of seeing these elements if they choose to. Thryduulf (talk) 23:29, 16 March 2025 (UTC)
  • I also support SMcCandlish's additional suggestion re permissible maintenance. Thryduulf (talk) 01:50, 17 March 2025 (UTC)
• Support There really isn't any reason to not allow the option to disable this. Its just never been thought about before so it has never been proposed. — Preceding unsigned comment added by DotesConks (talk • contribs) 23:36, 16 March 2025 (UTC)
• Support per above. Aaron Liu (talk) 00:18, 17 March 2025 (UTC)
• Support per above Tarlby ^{(t) (c)} 00:20, 17 March 2025 (UTC)
• Oppose First: if these sort of elements are making a page unusable, they can already be removed by others as they are disruption. (Keep in mind that logged out users can't use this "opt out" proposal). This proposal seems to give blessing that editors should be able to make pages disruptive (because you could just 'opt out' if you don't like the disruption). Almost no editors are going to maintain personal user scripts, nor should we expect them to. As far as enforcement goes, I suppose this would just give license for others to add a class if the original author didn't, and won't give the author good excuse to revert that - but is that really a problem? (i.e. Have authors been resistant to this?) — xaosflux ^Talk 00:47, 17 March 2025 (UTC)

  Note: I don't oppose stating that this is a recommended class (add it to Wikipedia:Catalogue of CSS classes) to use on such elements, mostly want to ensure that this isn't a carve out to the more important SMI section. — xaosflux ^Talk 01:02, 17 March 2025 (UTC)

  If a decoration is really disruptive then it can still be removed. There's people who find all floats annoying regardless of disruption (like SMcCandlish below). Aaron Liu (talk) 01:52, 17 March 2025 (UTC)

  @Xaosflux: Would changing the first sentence to read something like Editors are permitted to have a reasonable number of policy-compliant decorative elements... address your concerns? The intention was absolutely not to provide an exception to WP:SMI (or any other part of our PAGs), any more than e.g. Wikipedia:User pages#Userboxes gives people license to host WP:POLEMIC userboxes. HouseBlaster (talk • he/they) 04:50, 17 March 2025 (UTC)

  Helps some. I think this may be too niche - are there other such "annoying" elements that could all be addressed at once while we are here (in the same manner? (i.e. just a list of CSS classes that should be used). — xaosflux ^Talk 09:37, 17 March 2025 (UTC)

  If there are other elements people find annoying or inaccessible, I would support a list of CSS classes. Not sure what they would be; do you have any in mind? HouseBlaster (talk • he/they) 20:08, 17 March 2025 (UTC)

• Support. This stuff is annoying, and a CSS class is the sensible, low-impact way to address it. But include a line-item that it is permissible as WP:REFACTOR maintenance for anyone to add this class as needed, since we can't depend on particular editors always complying (or still being active).  — SMcCandlish ☏ ¢ 😼  00:53, 17 March 2025 (UTC)
• Support with the conditions proposed by SMcCandlish. JuxtaposedJacob (talk) | :) | he/him | 00:55, 17 March 2025 (UTC)
• Oppose as written per Xaosflux. Also, this is way the heck too complicated for most editors. If you want to let editors have decorative floating elements but you want other registered editors to be able to opt-out of seeing them (why don't people have to opt in to annoying decorative features?), then it needs to be a much simpler system, like "Wrap your decorative floating element in this pre-made Template:Reduce risk of annoying people" and "If you don't want to see decorative floating elements, then go to Special:Preferences#mw-prefsection-gadgets and tick the box for 'Stop seeing annoying decorative floating elements'". Solutions that sound like "Edit Special:MyPage/common.css" are not solutions. WhatamIdoing (talk) 02:47, 17 March 2025 (UTC)

  If you know how to make something floaty, you should know how to add a CSS class. Editing a page to add certain lines is not nerve-racking since you do not need to understand the styles. And there's no reason a template and a gadget can't be created; but we need consensus first to adopt the class.

  why don't people have to opt in to annoying decorative features?

  Since then the vast majority of users would never notice and this would strongly disincentivize users from adopting the class. Aaron Liu (talk) 02:50, 17 March 2025 (UTC)

  • If you know how to make something floaty, you know how to copy and paste what you found on someone else's page. You do not necessarily know what CSS is, much less how to add a CSS class.
  • Editing .css and .js pages actually is nerve-racking to a lot of editors. Anything with a big pink warning box that says "Code that you insert on this page could contain malicious content capable of compromising your account" is nerve-racking. Some editors, even after being reassured that what they want to do is fine, will refuse to do it because they're scared of getting it wrong.

  WhatamIdoing (talk) 02:55, 17 March 2025 (UTC)

  If you are copy/pasting from someone else's page, the thing you are copy/pasting should already be wrapped in the CSS class. If you are creating your own, you know what a CSS class is.

  I'd be happy to support a gadget to make this easier for users to opt-out. HouseBlaster (talk • he/they) 03:03, 17 March 2025 (UTC)

  Requiring people to opt in to annoying decorative features would disincentivize editors from creating annoying decorative features, which is not IMO a bad thing.

  We don't need to "incentivize" users to adopt the CSS class; that's something we can "require" them to do. All you need is someone to notice and report a violation, and then any CSS-capable admin can add the necessary class and explain to the user that their available choices are "keep the CSS class" that hides their annoying decorative element, "remove the annoying stuff", or "get blocked". WhatamIdoing (talk) 05:58, 17 March 2025 (UTC)

  Hi WhatamIdoing,

  I've created the User:MolecularPilot/Floating Decoration template, which marks content using the floating decoration class. It works similarly to your "Reduce risk of annoying people" template. For example, using:

  {{User:MolecularPilot/Floating Decoration|this is a floating decoration}}
  applies the effect. If this proposal is approved, I'll move the template into the main template namespace.

  I’ve also developed a user script for a gadget at User:MolecularPilot/HideFloatingDecorations.js. If the proposal passes, I plan to propose it as an official gadget (note that only interface admins can designate a user script as an official gadget, and there’s a process for it).

  In summary, if approved, you’ll be able to mark something simply by using a template, or opt out by ticking a box in the gadgets section. You can test this functionality on the User:MolecularPilot/sandbox page, where you'll see some marked decorative elements using the template. If you install the HideFloatingDecorations.js script, that floating decorative elements will be hidden, confirming that it works. :) MolecularPilot^Talk 02:50, 24 March 2025 (UTC)

• Support as a compromise to "banning these entirely", which I'd also support. Some progress on this is better than nothing. Elli (talk | contribs) 04:30, 17 March 2025 (UTC)

  I'd support banning entirely, at least on ordinary User:/User_talk: pages. Also anything flashing/blinking/spinning, because that's also annoying. WhatamIdoing (talk) 05:50, 17 March 2025 (UTC)

• Oppose. I'd support the opposite, an opt-in version. Any editor that wants to view these annoying items, should edit their preference to allow viewing. The burden should not be on every single editor. --Gonnym (talk) 08:59, 17 March 2025 (UTC)

  That sounds like an even stronger version of this, not "the opposite". And it would still require a CSS class. None of the stuff you wrote after "Oppose" squares with the word "Oppose". Toadspike [Talk] 11:31, 18 March 2025 (UTC)

• Support – regarding WhatamIdoing's comment, it is easy to create a template that wraps the content in such a class. I made a demonstration at {{User:Chaotic Enby/Floating decoration}} if anyone wants to try it out.
  
  This line should be invisible if you have the relevant CSS line masking .floating-decoration
  Chaotic Enby (talk · contribs) 11:23, 17 March 2025 (UTC)
• Support. I'd be just as happy to make them opt-in or even entirely forbidden, but opposing this suggestion on the grounds that you would prefer one of those is just letting the perfect be the enemy of the good. Caeciliusinhorto-public (talk) 16:15, 17 March 2025 (UTC)
• Support. As others have said: This is an accessibility issue. Lova Falk (talk) 16:32, 17 March 2025 (UTC)
• Oppose per WP:CREEP. The amount of effort required to maintain and enforce this new guideline is not worth the undoubtedly tiny proportion of editors that are annoyed enough by floating content to find and add the right CSS rule to their common.css. Better to just forbid these and other such visual junk entirely. – Joe (talk) 17:52, 17 March 2025 (UTC)

  Oppose per Joe above. I don't see why this is urgent enough that a css extension can't address this. -1ctinus📝🗨 18:31, 17 March 2025 (UTC)

  CSS-selecting elements by inline style is super fragile to the point of near-impossibleness. Aaron Liu (talk) 19:16, 17 March 2025 (UTC)

  It's trivial; editors would just drive by and add the class. Aaron Liu (talk) 19:16, 17 March 2025 (UTC)

• Support, probably as it was originally written. I appreciate that the proposal seeks not to be overly Malvolio-ish. Based on other comments, I think the two hinge-points are that editors who, um, leave their flies in the open are expected to do that formatting thing, while editors who don't want to see it then have to do the opting not to see it. I'm predisposed to wanting to support accessibility needs, but I'm also not predisposed to equating "this annoys me" to an accessibility issue. So I think a small amount of effort on both "sides" is the fair way to go. --Tryptofish (talk) 21:27, 17 March 2025 (UTC)
• Support, honestly this is a low budget way to appeal to everyone. If you don't like it, you can opt-out without affecting everyone else. I am not persuaded by xaosflux, as far as I'm aware its consensus not to delete things from someone's userpage. Someone may choose to have lots of extra images all around their page (that I've found cover content on mobile), and if I want to not see that I should be able to not see it. I also shouldn't be the one to be the fun police and remove it. A way for me to locally block those is a great compromise. --JackFromWisconsin (talk | contribs) 22:59, 17 March 2025 (UTC)
• Support A step forward. We can't even talk about opt-in or opt-out without the tags in place. -- GreenC 23:37, 17 March 2025 (UTC)
• Support for accessibility reasons, and following this, I would encourage building a gadget to make opting-out easier, for the sake of inclusion. For those of us who know CSS, it's trivial both to add decorative elements to our user page, and to edit our common.css to avoid seeing these. But those who don't know the first thing about CSS and just want to hide the annoying floaty things should also have a simple path to opting out. ClaudineChionh (she/her · talk · contribs · email · global) 23:54, 17 March 2025 (UTC)
• Support as second choice, with opt-in as first choice. Seraphimblade ^{Talk to me} 00:07, 18 March 2025 (UTC)
• Support It should not be mandatory to have to look at digital flies crawling on your computer screen. ‍Relativity ⚡️ 03:57, 18 March 2025 (UTC)

  I agree. IMO the only open question is whether it ought to be this difficult to get rid of them. In all of Wikipedia's history, about 14.6 million registered editors have made at least one edit. Only about 45,000 of them created a .css file. Why should people who want to get rid of this have to do something that 99.7% of Wikipedia editors have never done? WhatamIdoing (talk) 04:04, 18 March 2025 (UTC)

  I think that this is a fair point. And as I noted below: "The ability to edit CSS should not be requirement for editing (or reading!) Wikipedia". - jc37 15:32, 18 March 2025 (UTC)

• This is an accessibility issue, but so is the proposal. It's like what MediaWiki originally did with dates: a mechanism that only works for a few logged-in users that have accounts, rather than for everyone who is attempting to read the behind-the-scenes parts of Wikipedia. We, the people with accounts who are participating in this semi-protected discussion, aren't the majority of the people dealing with this; so whilst it is greatly convenient to us few, I try to remember what all the people without accounts will experience, and that they have no ability to participate here. Uncle G (talk) 10:47, 18 March 2025 (UTC)

  This is a comment that I think we all should try to do more to keep in mind when discussing. We all-too-often get caught up in personal preference and ILIKEIT/IDONTLIKEIT. It would be nice if we can look beyond our own world view and consider others, whether they be readers, newbies or whomever else. - jc37 15:32, 18 March 2025 (UTC)

• Support, though I would also be open to banning these elements outright because 1. this technical solution doesn't fix the problem for readers without an account or folks who don't know/want to edit their CSS and 2. they're bloody annoying, which this discussion has made me realize is not just a "me thing". Toadspike [Talk] 11:36, 18 March 2025 (UTC)

  I also agree with [[Aaron below that an opt-in system is worse than an opt-out or a ban, since it'll raise the ire of people who like floaty bits while still having a large technical burden for no reason. Toadspike [Talk] 11:38, 18 March 2025 (UTC)

• Support (drawn here by ping) per WhatamIdoing; I didn't realise these were that annoying, so of course, if people find them distracting or annoying or anything else that inhibits a collegial atmosphere of cooperation then of course this simple piece of code should be added. It seems like not a lotta work to make some editors happy. And no-one seems to be being placated at anyone's expense, so—unless I'm misreading the proposal—I don't see the harm. Fortuna, Imperatrix Mundi 20:47, 18 March 2025 (UTC)
• Something completely different or I guess oppose in short. I think there are two different use cases for floating elements in user space. The first is on user talk pages. Those can be annoying and get in the way of communication, and should be generally limited. Talk pages are practical spaces for communication with other editors, and should be generally free of detritus, although some decoration is fine. I'd make an exception however for the jump to top/jump to bottom buttons that are useful on longer pages. So TLDR: a policy based solution on floating elements on user talk pages is a more effective solution to the actual problem at hand than a technical solution with limited impact.
  The second use case is on user pages. A user page has a limited practical function, and we have long given significant leeway to people as to how to run them. They're somewhere between introduction, awards case, soapbox, and bulletin board. If somebody wants to make their user page kind of annoying...they should be allowed to. I hope User:EEng will forgive me mentioning him right after that sentence, but his "may be seen from space" user page is almost purposefully too long to practically navigate. And that's okay! If you find that annoying, don't look at it. You don't have to. You could build the best FA of all time with EEng and never have to visit his user page. There are joke user pages filled with an almost absurd number of floating elements...and that's the joke. It's meant to be impractical, in a GeoCities bad website of the 90s way. Let people have that fun. CaptainEek ^{Edits Ho Cap'n!}⚓ 23:44, 18 March 2025 (UTC)

  @CaptainEek, could you perhaps provide me a list of every userpage that has these elements? That would be very helpful. Then I could do as you say, and not look at them. -- asilvering (talk) 04:10, 20 March 2025 (UTC)

  @Asilvering I can't say I make a habit of cataloguing userpages by their use of certain design elements :P But if you really did want to know, I'm sure you could work backwards from what pages transclude those templates. CaptainEek ^{Edits Ho Cap'n!}⚓ 04:14, 20 March 2025 (UTC)

  I wonder how I might get that, without looking at any of the userpages or templates in question? -- asilvering (talk) 04:35, 20 March 2025 (UTC)

• Support for accessibility reasons. I would also support banning these as they are annoying and I don't see a purpose for them.— yutsi (talk) 02:48, 19 March 2025 (UTC)
• I feel this is overregulation. Accordingly, oppose. Stifle (talk) 16:54, 19 March 2025 (UTC)

  Please can you explain further - I don't understand how a small change to allow something to be opt-out can be "overregulation"? Thryduulf (talk) 17:39, 19 March 2025 (UTC)

  Requiring users to put an additional style/class on their userpage for a very niche use case is overregulation to me. Or WP:CREEP if you prefer. It's also way too complex. Stifle (talk) 08:52, 20 March 2025 (UTC)

  CREEPY... maybe, too complex, I don't think so. If someone knows how to add a floaty thing in their page(s) they'll also know how to add a extra class, no? If they simply copy paste some code, then most likely they also don't mind someone else improving it. Would they? (I mean most people, some might mind) - Nabla (talk) 18:51, 28 March 2025 (UTC)

• Support. I would greatly benefit from this change. I would also support banning them, but I don't want to squash other people's fun simply because I have a brain injury. -- asilvering (talk) 04:08, 20 March 2025 (UTC)

  "I don't want to squash other people's fun"... are you sure you're on the right website? Herostratus (talk) 19:39, 24 March 2025 (UTC)

• Oppose. I would support a mechanism allowing readers to filter out flashing lights liable to trigger seizures. But just how much is there an issue here with some non-moving elements on a web page? The proposer is "extremely distracted" by them; I sense that with others it is mostly just an aesthetic dislike. I don't think we need to protect the latter category of reader: really it is not so difficult to click to another page, or just accept that others have poor taste. But are there readers that are really upset, something like the reaction some people have to spiders? How common is this? Some people like these little icons, and like other people seeing them, don't want to have to learn how to make them optional, and would resent the heavy-handed insistence on this: it is not a totally cost-free option. Were it really only one person who is seriously upset by them, maybe we ought to say, too bad. JMCHutchinson (talk) 18:01, 20 March 2025 (UTC)

  Check out all the oppose !votes saying "it should be opt-in" or even "... banned". Aaron Liu (talk) 18:39, 20 March 2025 (UTC)

  @Jmchutchinson, I am sure that it is an aesthetic dislike for many people. I can also tell you from experience that at least some of these elements do function very much like the "flashing lights" issue. I personally have been punked by the bouncing globe icon, the "snowflakes" effect, and the fly. (The fly one is "my fault", I guess, in that I observed it, decided it wouldn't be a problem, and went about reading the talk page anyway. Big mistake.) There are others I find irritating or briefly nauseating, but which do not cause my physical pain, and indeed then I do simply click to another page and accept that others have taste I find disagreeable. The others, though... well, I've learned that if I want to talk to rsjaffe, I should do it off-wiki. -- asilvering (talk) 00:53, 21 March 2025 (UTC)

• Support: I think one of the great treasures of Wikipedia is its user pages allowing fairly freeform HTML and CSS, in opposition to the modern Web's locked-down platforms, so I think users should be free to have goofy and poor-taste CSS on them if they so desire. I thus strongly oppose all the !votes to ban these. I also concur with Stifle that editors shouldn't feel overregulated on their user pages. However, I don't think the proposal is so strict as to be overbearing; it uses the word should, which doesn't seem too harsh, and I think any editors who manually create these elements would be technical enough to know how to add a CSS class. Even still, for those who somehow aren't able to or don't know the rule, SMcCandlish's addition would solve that by explicitly allowing others to fix it. In all, it seems a fairly modest proposal that rectifies a small problem without too much risk of causing future headaches. Dan Leonard (talk • contribs) 20:30, 20 March 2025 (UTC)
• Second choice to banning such elements. ~ ToBeFree (talk) 22:10, 20 March 2025 (UTC)
• Support, but would strongly prefer an opt-in system. Fun is great. Bad 90's and early 00's websites were great. You know what's also great? Accessibility. And I can't quite get behind an argument that because these are meant to be impractical and inaccessible to other users, than that makes it more fun? Well, twelve year old me who insisted on writing all her emails in pastel pink would have agreed. But preteen GLL is not somebody anybody should aspire to be.... GreenLipstickLesbian💌🦋 22:27, 20 March 2025 (UTC)
• Support per Elli and ToBeFree and others ~ Lindsay^Hello 13:06, 23 March 2025 (UTC)
• Support, I think it should be something you can opt-out of, especially as it messes with accessibly tools or can make the page annoying and distracting to someone. I've hopefully made the process of both marking a section as a floating decorative element and opting out of them easier for those who aren't as technically passionate with a user script (could be a gadget) and template I've just made, see my reply to WAID. MolecularPilot^Talk 02:54, 24 March 2025 (UTC)
• Oppose. Leave people alone. If the page bothers you, close it. Users are allowed to have no userpage and many do. An annoying userpage the you feel compelled to close at once can't provide less information than one that doesn't even exist, and might provide more. Just because we can compel other editors to construct their public face way we find more personally pleasing doesn't mean we should. Herostratus (talk) 19:39, 24 March 2025 (UTC)
• Change vote to No Vote, I misunderstood the situation sorry. Herostratus (talk) 01:24, 25 March 2025 (UTC)

  This is a reasonable argument for userpages (though I still disagree) but not reasonable for talkpages, which are an important part of communication on the project. Users should not be allowed to make their own talkpages inaccessible or obnoxious to others. Elli (talk | contribs) 20:35, 24 March 2025 (UTC)

  Oh jeez I didn't see that sorry. Also I misunderstood that it was just an opt-out thing rather than a proscription or use. I changed to No Vote. Herostratus (talk) 01:24, 25 March 2025 (UTC)

• Oppose WP:CREEP --qedk (t 愛 c) 00:47, 25 March 2025 (UTC)

  I don't see how this would make the user pages policy harder to grasp and understand. Aaron Liu (talk) 11:00, 25 March 2025 (UTC)

• Support as an accessibility issue. Tenpop421 (talk) 15:04, 25 March 2025 (UTC)
• Support, though I'd prefer an opt-in system. I have sensory issues and some of them, especially the fly and bouncing globe, annoy the crap out of me. I'm concerned that other editors that would prefer to disable these would not know how to edit a .css or even what it is, so I think an opt-in system is best. We lose nothing by making it opt-in (self-expression can also be done in other ways), and gain a lot in terms of accessibility making it opt-in. Grumpylawnchair (talk) 00:23, 26 March 2025 (UTC)
• Support Personally I think everybody should be required to gaze upon the glorious visage of Jimbo Wales as they read my user talk, but if some would rather not see him staring deeply into their soul then adding a bit of CSS is a reasonable compromise. The WP:CREEP and WP:MALVOLIO arguments are definitely a factor though, and I'd oppose any measures to make them opt-in or banned. The Wordsmith^{Talk to me} 01:14, 27 March 2025 (UTC)
• Support as per ACCESSIBILITY, We should make it easier for those with issues/disabilities not harder. –Davey2010^Talk 01:24, 1 April 2025 (UTC)
• Support If this is causing serious accessibility issues, we need to fix that, and this seems like a good way to do so without causing any issues for people who do enjoy it. QuicoleJR (talk) 19:34, 4 April 2025 (UTC)
• oppose (strongly) and some better suggestions:
  • 1: I don't want to be "forced" to do something in order to get rid of this "decoration".
  • 2: A *fancy signature*, in most cases, is **harder** to read or speak than an ordinary one. If such a signature isn't enough for some techies,
  • 3: suggestion: they {(additional clarification: those editors who want to show CONSTANTLY moving things like flies, "raining" '@'s or animated emojis)} may use a link like funny fly or tricky tech stuff on their *main* page linking to one of their SUB pages where they can show all their technical knowledge and artistic talents {addition: about moving objects}.
  • 4: Show some respect !! - You (techies) don't have the right to F O R C E such things on all others who visit your page!
  • 5: suggestion: And such a sub page then should not contain any *other* or *more* useful information except {addtion: animated} tech tricks.
  • 6: If a reader shows interest in a registered editor('s page), this editor should consider this interest already an honour. Why **annoy** their visitors!!? Would you annoy your guest(s) at home -- if you had one/some?
  • 7: Such CONSTANTLY moving/distracting stuff on the two *main* pages of an editor comes close to - no - IS vandalism. And while we are at this issue:
  • 8: suggestions: an **animated** something (like a GIF):
    • 8.1: may move for ONE SECOND (or ONE cycle), but then it should stop by itself.
    • 8.2: It may OFFER the visitor a button to let it move *again*,
      • 8.2.1: for a couple of seconds (or cycles) or
      • 8.2.2: (better) as long as a certain key is held down. THIS would show respect, this would truly be user-friendly.
  • 9: Especially "those who find such stuff extremely annoying" also hate to be forced to waste their time and nerves in order to find out where and how to switch such stuff off. I'm not exaggerating: to some readers/editors such stuff is and the additional work would be like a rape. It's the mind that suffers, much more than the body.
  • 10: Ask the millions of only-readers whether they like such stuff!!

Steue (talk) 02:38, 5 April 2025 (UTC) {} (in no. 3 and 5) = my additions. Steue (talk) 03:14, 7 April 2025 (UTC)

• @Steue: I am – at the very least – asking you to strike your comparison to rape. HouseBlaster (talk • he/they) 05:43, 5 April 2025 (UTC)

  I agree. That was definitely unacceptable. QuicoleJR (talk) 22:35, 5 April 2025 (UTC)

  I am struggling to parse this. You are saying that we should instead force people to delete information and move their signatures to user subpages full of tricky syntax and information on how to achieve such signatures so that we won't force people to waste their time? Aaron Liu (talk) 01:40, 6 April 2025 (UTC)

  @House and QuicoleJR I didn't mean to insult those who have been raped sexually, or belittle their suffering, I have never been, but this is HOW I FEEL when I have to tolerate a fly or "raining" '@'s or other PERMANENTLY moving things on my screen. @Aaron Liu I don't fully understand your comment, but I only mean MOVING things, and of those only CONSTANTLY moving things.

  I don't mean to ban fancy signatures; I don't really like them, but I can tolerate them, as long as they are not moving. And I do admire some, for their trickyness; but are they as easy and fast to read as non-manipulated signatures? And some even conceil what is the link to their talk page -- not the best idea, I think, if you want people to write to you, is it? Steue (talk) 18:33, 6 April 2025 (UTC)

  @Steue: Who has a moving signature? --Redrose64 🌹 (talk) 18:58, 6 April 2025 (UTC)

  @ Redrose64 I dunno, I havn't seen one. I just guessed it could be. I wouldn't want to have it on my screen while trying to concentrate on real text, but I would like to know whether it's possible, little challenge! But maybe better somewhere else. I do offer my user talk page for this. Steue (talk) 19:18, 6 April 2025 (UTC)

  If you've never seen one, it's likely that they don't exist. Please do not divert this RfC with irrelevant hypotheticals. --Redrose64 🌹 (talk) 20:40, 6 April 2025 (UTC)

  I still don't understand what you mean. I'm guessing this comment means non-moving fancy signatures are fine, but I'm doubting whether that's the correct interpretation since you go on to say they are very bad, and I still don't get what your argument/position on moving things are. Aaron Liu (talk) 21:08, 6 April 2025 (UTC)

  I am be projecting my own ideas, but anything but standard signatures decrease function, but moving objects on the screen cross a line for Steue. I think Steue is phrasing it poorly, but when objects start moving on my screen I feel a lost of control, which feels like a violation of autonomy. It is more comparable to having something stolen or being hacked than being raped. Users also choose sigs that are unreadable and hard on the eyes. It isn't considerate of others. I think there has to be a limit to what users are allowed to do. I also think that since the people making these things have technical know-how and are the ones having fun, the burden should fall on them of doing the work.

  I think the language of forcing people to do things is wrong. I am not sure if looking at user pages is ever useful and no one is being forced to make annoying animations etc. There are already policies limiting what one can have on a user page. People just don't want their right to annoy people to be infringed. DrGlef (talk) 16:42, 17 April 2025 (UTC)

  Meanwhile I have numbered my points and added some clarifications to my points 3 and 5. @Aaron Liu: I thought my points 7 and 9 do say it clearly. Steue (talk) 03:14, 7 April 2025 (UTC)

  @Steue: Please write your replies in a readable manner because that was borderline unreadable (preferably your entire content in a single paragraph and no need for line break tags). I've fixed it for now. --qedk (t 愛 c) 01:35, 9 April 2025 (UTC) Apologies for the accidental ping, Aaron. --qedk (t 愛 c) 01:37, 9 April 2025 (UTC)

  im sorry? additional work would be like a what? im gonna ask you to maybe not say that? sorry, but its just incredibly unnecessary. ogusokumushi^{( ୧ ‧₊˚ 🎐 ⋅ )} 16:34, 16 April 2025 (UTC)

• Support - simple accessibility thing. Should be easy to implement. Bluethricecreamman (talk) 15:54, 13 April 2025 (UTC)
• Make Opt Out default Those things are more than annoying and people who don't know what CSS is shouldn't be subjected to them. DrGlef (talk) 08:48, 15 April 2025 (UTC)
• Support Allowing people to opt-out of these sounds like a good idea and will improve accessibility. Opm581 ^{(talk | he/him)} 22:16, 15 April 2025 (UTC)

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.

Discussion (decorative elements)

• Notified: Template:Centralized discussion, Wikipedia:Village pump (policy), Wikipedia:Village pump (proposals), and Wikipedia:Village pump (idea lab) § Wrapping floating decorative elements in a standardized CSS class (where the WP:RFCBEFORE took place). HouseBlaster (talk • he/they) 23:02, 16 March 2025 (UTC)
• Comment - This is an interesting proposal, and I think I "support" the idea of the creation of the specialised class. Though, reading the above, it sounds like more than one class may be necessary based upon usage/type. That said, I think the proposal has it backwards. I think this should be a situation where such things are turned off by default, and users can opt-in to turn these on. (Perhaps through CSS as noted or maybe in preferences.) The ability to edit CSS should not be requirement for editing (or reading!) Wikipedia, and this really feels like something of an WP:ACCESSABILITY issue. - jc37 08:57, 17 March 2025 (UTC)

  Opt-in would turn off the display for everyone who doesn't care. You'd see someone testing to implement a floaty, go "voila!" when the floaty works when the class is removed, and then sink into the depths of despair as they realize the class is required. I like some of these floaties, and opt-in would make nearly nobody new want to do it. Opt-in would pretty much be banning it altogether, and even if you think it should be opt-in, an opt-out is way better than nothing. Aaron Liu (talk) 11:40, 17 March 2025 (UTC)

  To whom we all say: "I'm sorry that you you have 'sunk into the depths of despair' because you haven't found more people to play with the toy you created, but while we allow for such toys, that's not our primary purpose here." I understand you want such things and want access to such things - I do too! - but usability goes beyond the toys you and I think are important for community-building and fun. As a volunteer site, we should tend to lean towards being more inclusive and accessible of editors and readers. And if this type of toy is (among other things) driving people to communicate less on talk pages, that makes it a hindrance to collaboration. I think there's a middle ground to be found here, and hopefully we will get there. - jc37 15:38, 18 March 2025 (UTC)

  Implementing opt-in comes with the opting technical burden that's unjustified here as it would have pretty much the same effect as banning; it's not a middle ground at all. I believe that the majority of users do not mind the floaties much, else they'd have been banned as long time ago. See also Wikipedia:MALVOLIO. Aaron Liu (talk) 19:44, 19 March 2025 (UTC)

  If someone chose to not collaborate on a talk page due to the presence of these - how would we know?

  As for Wikipedia:MALVOLIO - this isn't about being the "fun police". It's about fostering an environment for collaboration. Community-building and fun has a place in that. (As I already noted above.) But not at the sacrifice of direct collaboration. As I said, there's a middle ground here. I've read all your comments on this page, and I get that you seem to think this is just people trying to spoil your fun. But in all seriousness, there are some legitimate concerns here. Addressing those concerns goes a lot further than merely opposing because you think your fun is being spoiled by people that you think don't understand.

  (Incidentally, accusing me of being the "fun police" - that's one for the ages : ) - jc37 07:06, 20 March 2025 (UTC)

• What about people (like me) who might not know how to “opt out”? Will there be an great big obvious button on any page that includes floaty stuff (whatever that is) for us to push, or will we be expected to know that you can turn it off if you go to “settings”, then to “viewer preferences”, then to… you get my point.
  Thinking an “opt in” would be better. Blueboar (talk) 21:09, 17 March 2025 (UTC)

  If there is something that you are annoyed by but don't know what it is or what you can do about it, you can always ask at the Wikipedia:Help desk (or Wikipedia:Village pump (technical) if you know it's a technical thing), where knowledgeable editors will tell you what it is and what you can do about it. Thryduulf (talk) 21:29, 17 March 2025 (UTC)

  Are you telling me I would have to go to the help desk to figure out how to turn annoying “floaty things” off? Blueboar (talk) 21:53, 17 March 2025 (UTC)

  1. What can you do right now?
  2. A gadget can be written for an easy opt-out. Aaron Liu (talk) 22:00, 17 March 2025 (UTC)

  @Blueboar if there is something on Wikipedia that you don't know how to do, then the help desk exists for the purpose of answering your question. You would probably need to be more specific than "floaty things" but we cannot provide in-your-face instructions for everything everybody might dislike or want to customise. Thryduulf (talk) 23:33, 17 March 2025 (UTC)

  Yes, but there's a certain amount of "Beware the leopard" going on here. If a page is going to behave in a distinctly abnormal manner, then turning it off needs to be easy and obvious. We shouldn't be sending people on a trip to a disused basement lavatory to get technical directions just because someone else likes floaties and worries that if your Jimbo-face jump-scare wasn't defaultly visible to all IPs and most editors, then you might give up and go get your own website for your CSS toys. WhatamIdoing (talk) 04:00, 18 March 2025 (UTC)

  @WhatamIdoing I agree with you, but... these floating elements are currently allowed. Making them possible to disable is an improvement over impossible to disable, so I don't see how opposing this brings you any closer to the goal of "opt-in". Once this class exists, an RfC to change "opt-out" to "opt-in" could be held and would be quite easy to technically implement since the work for it would already be done. Elli (talk | contribs) 04:02, 18 March 2025 (UTC)

  Right now, what I want is something that makes it much easier to comply (e.g., ChaoticEnby's wrapper template) and much, much, much easier to opt-out (e.g., a gadget, which should be trivial). I do not think that the proposal as written is appropriate. I think it should be re-written as "use this template; see example [yes, you techy people can use the equivalent code]" and "tick this box in your prefs". WhatamIdoing (talk) 04:06, 18 March 2025 (UTC)

  Sure, but isn't that letting perfect be the enemy of good? If this doesn't pass, the status quo of "no floating CSS class" remains. Requiring a class doesn't hurt any other efforts to further restrict this. Elli (talk | contribs) 04:09, 18 March 2025 (UTC)

  Since RFCs aren't votes, it is technically possible for editors to stop voting and form a consensus that isn't either approval of the original question or rejection of the original question.

  We could actually decide, for example, that this is a good idea in principle but with an implementation that assumes far too much technical skill, and that instead it ought to say something similar but different. For example, editors might prefer this:

  Floating decorative elements

  Decorative elements which follow the reader down the screen are banned completely from all namespaces except User: and User_talk:, where they may only be used in limited ways, must not be overly risky or annoying (e.g., blinking), and must be easy for others to opt out of. If included, they must use Template:Floating decoration wrapper or equivalent CSS code. Editors who do not wish to see these may hide them by ticking the box in Special:Preferences#mw-prefsection-gadgets, "Hide decorative floating elements". Functional elements (such as {{skip to top and bottom}}) should not be hidden.

  Or they might not. Some editors might actually believe that Wikipedia is best off when it's too difficult or daunting for annoyed editors to hide these elements. Or we might decide that this doesn't go far enough, and that we want to have this class hide the floaty stuff from IPs, too. The point is, the community isn't bound to just answer the exact question asked. The suggested text can be improved. WhatamIdoing (talk) 20:09, 18 March 2025 (UTC)

  I really like your suggestion – regarding the template, I've already made {{User:Chaotic Enby/Floating decoration}} so we can try it out before moving it to templatespace. Chaotic Enby (talk · contribs) 20:14, 18 March 2025 (UTC)

  Jinx! Sorry, I made the same thing before seeing your reply here after seeing WAID's !vote above in the survey section about difficulty. I'll U1 mine - basically ours have the exact same code! I've also made a user script to "opt out" of these elements, it can be made into a gadget that can be enabled by a box tick in settings if this passes, User:MolecularPilot/HideFloatingDecorations.js! :) MolecularPilot^Talk 02:58, 24 March 2025 (UTC)

  Thanks, but this really should be CSS instead of a script. Just a gadget CSS file that consists of .sticky-decoration {display:none !important;} would work. Aaron Liu (talk) 11:01, 24 March 2025 (UTC)

  Oh, I didn't know gadgets could be CSS as well, I thought they were only scripts (that's why I made a script, CSS would be better for this use case).. Thank you for informing me! :) MolecularPilot^Talk 11:27, 24 March 2025 (UTC)

  Yeah. You can even make CSS userscripts as shown at User:BrandonXLF/GreenRedirects! Gadgets can just say it's just CSS in their definition. Aaron Liu (talk) 11:29, 24 March 2025 (UTC)

  That BrandonXLF thing is an awful lot of bother for a single rule having just one selector and just one declaration. I would even question the complexity - is the !important annotation even necessary? Anyway, examples of gadgets that are purely CSS include: "Display diffs with the old yellow-and-green colors and design", "Disable smaller font sizes of elements such as infoboxes, navboxes and reference lists", "Justify paragraphs", "Move section [edit] links to the right side of the screen". There are several more. --Redrose64 🌹 (talk) 20:17, 24 March 2025 (UTC)

  Late but yes, the !important is necessary. Some of the elements (e.g. the teacup at User talk:HouseBlaster/sandbox, which was taken from a real talk page) manually set display:block (or something else), so we need to override it. If your choice is "please opt-out", you don't want to further style things, so the normal reason why !important is the devil does not really apply. Best, HouseBlaster (talk • he/they) 04:27, 14 April 2025 (UTC)

  I agree, but I think Redrose was questioning the importance of BrandonXLF's GreenRedirects rule. Aaron Liu (talk) 16:31, 14 April 2025 (UTC)

  Ah. In that case carry on :) HouseBlaster (talk • he/they) 16:34, 14 April 2025 (UTC)

  @HouseBlaster and Aaron Liu: What I meant was that the directions at User:BrandonXLF/GreenRedirects look like an awful lot of jumping-through-hoops that could daunt the average user. It should never be necessary to invoke JavaScript in order to add a CSS rule to your personal Wikipedia setup, especially when that CSS rule does not need JavaScript in order to work correctly, nor does any JavaScript depend on that CSS. The CSS rule concerned is at User:BrandonXLF/GreenRedirects.css, which is nine lines; and only three of those actually do something; and they can be condensed into one line:

  a.mw-redirect { color: #060 !important; } /* Make redirects green */
  

  and this can be put straight into Special:MyPage/common.css. In this you will see !important - this is what I referred to as "the !important annotation", and it's documented here. I consider the !important annotation to be a cop-out, it's like a rule saying "I don't care about the precedence of selectors, you must do what I say". In most cases, using a more specific selector can achieve the desired outcome in a more predectable manner. All modern browsers support all of the features of Selectors Level 3, which is comprehensive for most needs; and many current browsers also support Selectors Level 4. If your browser supports Selectors Level 4 (as mine does - Firefox 137.0.1), it's possible to write some pretty nifty rules without going anywhere near !important. The only times that !important is actually useful are: (i) to override the styles set in a style="..." attribute; (ii) to override another rule that you have no control over (like one that's imported from somebody else's page), that itself has had !important stuffed in. In this case, I don't think that it does anything useful, so we can use

  a.mw-redirect { color: #060; } /* Make redirects green */
  

  and we don't even need to increase the specificity with a more complex selector. --Redrose64 🌹 (talk) 21:01, 14 April 2025 (UTC)

  That's what I call the importance of a rule :) Aaron Liu (talk) 21:52, 14 April 2025 (UTC)

  Floating decorative elements

  A reasonable amount of decorative elements which follow the reader down the screen are only allowed on user and user talk pages, where they must not be overly risky or annoying (e.g. blinking).

  Some editors find these elements distracting or otherwise annoying. If included, they must use Template:Sticky decoration wrapper or equivalent CSS code. Editors who do not wish to see these may hide them by ticking Preferences → Gadgets → Appearance → Hide decorative floating elements.

  This section does not apply to functional elements such as {{skip to top and bottom}}.

  Technically, "floating" is used to describe left-, center-, or right-aligning an element (e.g. a picture as seen on Wikipedia and that "shortcut" box) so that flowing elements (e.g. text) wraps around it, not things that have a fixed position on screen. I think I realized before that this was a problem with the proposed class name as well but forgot about it... Aaron Liu (talk) 21:46, 18 March 2025 (UTC)

  I like what you've written here. WhatamIdoing (talk) 03:47, 24 March 2025 (UTC)

  (And I don't think this had to be worded as an oppose directly citing an oppose in mind and in spirit, especially when continued while supporters were coming to a consensus that such easier methods should be incorporated.) Aaron Liu (talk) 21:45, 18 March 2025 (UTC)

  The name was chosen as a reference to eye floaters. Maybe "sticky-decoration" would work better? HouseBlaster (talk • he/they) 23:34, 18 March 2025 (UTC)

  I think the difficulty describing these things shows how it will be difficult to ask for help to turn it off. I also think most users will assume they can't be turned off and therefore won't try to. Maybe user pages could have a link to turn them off/on. Additionally, new accounts could be directed to turn it off. DrGlef (talk) 16:17, 17 April 2025 (UTC)

  It's not difficult to describe at all. In fact the abundance of terms that have been thrown around to describe them shows that instead of showing the opposite. Aaron Liu (talk) 01:07, 18 April 2025 (UTC)

  Basically what you are saying, is that users who aren't tech savvy have to go through the hassle and humiliation of using the help desk to turn off a feature that has nothing to do with building an encyclopedia? DrGlef (talk) 16:11, 17 April 2025 (UTC)

  Who finds the help desk humiliating? If one doesn't have the communication skills to speak up, one cannot do that during disputes and perhaps should do the impossible of avoiding every dispute. Aaron Liu (talk) 01:06, 18 April 2025 (UTC)

  Some people are embarrassed to ask how to do things, especially when it seems simple to others. Remember, this is about a topic not relevant to building an encyclopedia. This is about technical skills, not communication skills. The goal is to make Wikipedia more user friendly. When balancing the user friendliness against self-expression, I don't know why there should even be a question on which one has priority. DrGlef (talk) 09:58, 18 April 2025 (UTC)

• Question: why is this suddenly an issue? Is there a user who has filled their user/user talk page with such objects that are causing annoyance? If so, discuss it with that user, get them to cut down the amount. Or, has it become a widespread problem? What sort of increase over what time period are we talking about? --Redrose64 🌹 (talk) 08:38, 18 March 2025 (UTC)

  I don't know why it is an issue, but looking at the number of responses above, obviously it is an issue that engages quite a lot of users. With the opt-out possibility, both those who have floating objects and those who are disturbed by them, can have it their way - instead of having to engage in dreary discussions. Lova Falk (talk) 11:08, 18 March 2025 (UTC)

  In my experience, accessibility is often suddenly an issue because people routinely ignore it until someone says something. voorts (talk/contributions) 01:34, 25 March 2025 (UTC)

• Similar question to the one above, but why are floats bad? We use them all the time to position images in articles, to do userbox tables, nobody has complained about their accessibility like ever. (Even WCAG doesn't seem to discourage them) Sohom (talk) 11:19, 18 March 2025 (UTC)

  Reading deeper into this RFC, I'm going to assume that when we are talking about "floaties" we aren't talking about the float: <left|right|center>; markup but rather the position: <absolute|sticky|fixed>; top: <number>px; fixed positioning markup? Sohom (talk) 11:26, 18 March 2025 (UTC)

  Yes, the latter. Aaron Liu (talk) 12:16, 18 March 2025 (UTC)

  See User:BD2412 and User:Fortuna imperatrix mundi for two User: pages that would be affected. See User:Minorax for an example of elements that would probably be considered "functional". WhatamIdoing (talk) 20:16, 18 March 2025 (UTC)

  I'm game to add any wrap that eases reader access. I am aware that my bouncing ball generally blocks the main menu. BD2412 T 20:29, 18 March 2025 (UTC)

  The curious thing is that for me (using MonoBook in Firefox), whilst the two bouncy balls are in front of most of the sidebar boxes, they pass behind two of them - the "search" and "languages" boxes. These two boxes are both given the declaration z-index: 3;, but I don't know why that should be. --Redrose64 🌹 (talk) 23:04, 18 March 2025 (UTC)

  I see the same as Redrose in Monobook (what I use by default). In Vector they appear between the link text and the background, making the links difficult to read but clickable, in Vector 2022 they appear in front of everything making the links behind unreadable and unlcickable. In timeless they are behind both for all boxes, meaning the balls are only visible in the narrow gaps and after the lowest box. Minerva has no sidebar, but on desktop a wide enough margin that they only obscure 1-2 characters of each line and only when they squish. In all cases the results are the same in the latest versions of Firefox and Chromium (running on Xubuntu linux) I've not tested any other browsers or OSes. Thryduulf (talk) 23:21, 18 March 2025 (UTC)

  Thanks, WhatamIdoing for the ping; I've commented above. When you say my user page would be affected, do you mean I would be affected in what I saw, or the viewers of the page? It was in response to a suggestion that they were moved to the user page rather than talk. I kind of assumed that no-one looks at user pages whereas talk is pretty busy (although I see that I was actually wrong: the former has ~770 in the last month, the latter only a 100 less. Blimey!) Fortuna, Imperatrix Mundi 20:47, 18 March 2025 (UTC)

  You'd need to wrap your moving objects in the code, and the tiny fraction of people who opted out would then not see it (or would only see a static version? I'm not sure). Unless you opted out, nothing would change for your view, or for any logged-out readers' view. WhatamIdoing (talk) 22:01, 18 March 2025 (UTC)

  The people who opt-out would see nothing. The people who do not opt-out would see exactly what you see right now. Best, HouseBlaster (talk • he/they) 23:09, 18 March 2025 (UTC)

  Does this mean it also covers "snow" and other fullscreen effects? The flies are one thing but any fullscreen animation should be opt-in at minimum. REAL_MOUSE_IRL talk 10:57, 19 March 2025 (UTC)

  Yes. Aaron Liu (talk) 11:25, 19 March 2025 (UTC)

 You are invited to join the discussion at Wikipedia:Village pump (technical) § Gadget to hide decorative sticky elements. HouseBlaster (talk • he/they) 19:19, 20 April 2025 (UTC)

What is a fake article?

"Fake articles" in userspace are commonly known as draft articles, which are allowed. The section does a poor job of articulating a distinction, and as a result I see people nominate random userspace drafts on the basis of WP:FAKEARTICLE. — Rhododendrites ^talk \\ 02:45, 24 April 2025 (UTC)

Made an edit to try to make it clearer. — Rhododendrites ^talk \\ 03:36, 24 April 2025 (UTC)

I don’t think FAKEARTICLE is really referring to user drafts (which might, with work, be legitimately moved to Mainspace - or at least to Draftspace for review and consideration).

I think it is really talking about deliberate hoaxes, fancruft, user autobiographies, and similar stuff made to look like an article - but which will never be accepted into Mainspace. Blueboar (talk) 17:10, 24 April 2025 (UTC)

Hoaxes, etc. that are meant for mainspace but not appropriate for it have their own guidelines/policies. "Fake article", more or less by process of elimination, are the things that look like articles but aren't meant for mainspace. i.e. they aren't meant to be articles (like good faith drafts, bad faith drafts, hoaxes, etc. all are); they just look like articles. — Rhododendrites ^talk \\ 18:36, 24 April 2025 (UTC)

Meh… I would not call a draft that someone is working on in their user space a “Fake”. It is a “potential” article. Blueboar (talk) 21:49, 26 April 2025 (UTC)

I don't think they were calling user space drafts "fake" - rather that it is one of a range of items which are intended to be moved to mainspace at some stage & therefore arn't fakes.Nigel Ish (talk) 12:06, 27 April 2025 (UTC)

My user page

Hi, on my user page I don't know how to make the userbox scrollable (on mobile devices, only the left half is visible), could you please help me? Thank you in advance. JacktheBrown (talk) 15:24, 30 April 2025 (UTC)

The problem on mobile devices is caused because of the "width:30%" restriction in the div element, 30% of the mobile width can only fit so much of the userbox. If you remove that part, userbox will show in full, but the remaining text will be sandwiched badly to the left of the userboxes. I have used {{stack}} on your userpage to fix it. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:44, 30 April 2025 (UTC)

@CX Zoom: thank you very much, is it possible to put the userbox in the center? JacktheBrown (talk) 18:59, 30 April 2025 (UTC)

Done. —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:08, 30 April 2025 (UTC)

@CX Zoom: perfect, thank you very much. JacktheBrown (talk) 19:11, 30 April 2025 (UTC)

You're welcome! —CX Zoom[he/him] ^{(let's talk • {C•X})} 19:18, 30 April 2025 (UTC)