Wikipedia talk:Banning policy
![]() | The project page associated with this talk page is an official policy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic. |
|
|||||||||||
This page has archives. Sections older than 90 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
Semantic markup
[edit]@Tryptofish: the HTML is Semantic HTML. '''...'''
is the wikitext version of <b>...</b>
, which is not meant for empahsis (even though countless editors use it for emphasis...). Likewise for italics: from MOS:EMPH, The most accessible way to indicate emphasis is with the HTML
There is recent discussion on this matter at Wikipedia talk:Manual of Style/Accessibility § Strong tags. Best, HouseBlaster (talk · he/him) 21:06, 12 February 2024 (UTC)
<em>...</em>
element or by enclosing the emphasized text within an {{em|...}}
template. Italics markup (''...''
, or <i>...</i>
) is often used in practice for emphasis, but this use is not semantically correct markup, so emphasis markup is preferred.
- We're talking about this: [1]. I don't know whether that discussion at a MOS talk page really represents community consensus, but it certainly does not match my day-to-day experience. --Tryptofish (talk) 21:11, 12 February 2024 (UTC)
- MOS:EMPH indicates that we should use
<em>...</em>
for emphasis over'''...'''
, and MOS:BOLD says that in the rare cases bolding is used as emphasis we should use<strong>...</strong>
. With all due respect, I don't believe day-to-day experience trumps accessibility concerns. HouseBlaster (talk · he/him) 21:16, 12 February 2024 (UTC)- I can't tell from the MOS discussion whether there are really accessibility concerns or not. --Tryptofish (talk) 21:18, 12 February 2024 (UTC)
- I realize it is a fairly dense thread :) From SMcCandlish,
Screen readers and other assistive tech need to distinguish between semantic emphasis and presentation. Best, HouseBlaster (talk · he/him) 21:26, 12 February 2024 (UTC)Whether screen readers right this second support this semantic markup very well is immaterial; it exists and is well-defined as serving this semantic purpose, and support will get better over time. What's never going to be helpful is using
''...''
(equals<i>...</i>
), or'''...'''
(equals<b>...</b>
) where semantic emphasis is intended, because that is purely visual formatting with no semantic implications (e.g. italics around foreign terms or book titles, or boldface to mimic the bold keyword in a directly quoted definition that was boldfaced that way in the original source). Screen readers will ignore that non-semantic markup on purpose and are never going to change in that regard.- I just commented there, that there should be community buy-in or there will be a lot of pushback resembling the revert that I made. The first step in getting buy-in is for the community to understand the need for a change, if indeed such a need even exists. And I have to admit that I, for one, still do not understand. --Tryptofish (talk) 21:32, 12 February 2024 (UTC)
- I realize it is a fairly dense thread :) From SMcCandlish,
- I can't tell from the MOS discussion whether there are really accessibility concerns or not. --Tryptofish (talk) 21:18, 12 February 2024 (UTC)
- MOS:EMPH indicates that we should use
- What is the scope of this campaign? Is every use of wikitext going to be replaced with "correct" html? On all pages? Johnuniq (talk) 22:13, 12 February 2024 (UTC)
If the wikitext is correct, then I have no plans to touch it. If I come across incorrect wikitext, I try to correct it (the same way one might correct a typo).
I think "campaign" is the wrong word to use: I am not going around and looking for changes to make. In this case, while reading the page for an unrelated reason, the underline of
this exception <u>does not</u> allow for reporting vandalism to administrative noticeboards
caught my eye:<u>...</u>
is for things like seplling errors, not for emphasis. While I was making that edit, I also fixed other markup to semantically meaningful. HouseBlaster (talk · he/him) 22:24, 12 February 2024 (UTC)- I don't doubt the good intentions of this, but I have real concerns. One of the things you changed in that edit was an anchor for a section, doing away with using Template:Anchor for that purpose. I've always thought that anchors were for where something was linked to, from somewhere else. Unless I'm missing something, that has nothing to do with accessibility, nothing to do with screen readers. It's just some editors' personal opinion of what the "correct" markup should be. Has that template been brought up at WP:TfD? If there are real issues having to do with accessibility, if there are real reasons to do emphasis one way and not another, then there is a process of addressing that community-wide, but a small discussion at a MOS subpage talk page isn't that. --Tryptofish (talk) 22:44, 12 February 2024 (UTC)
- The anchor template was substituted per its documentation: see Template:Anchor#Rationale for substitution in the header. That is not an accessibility issue; I sincerely apologize for implying otherwise. HouseBlaster (talk · he/him) 22:49, 12 February 2024 (UTC)
- OK. [2]. But my other concerns remain. --Tryptofish (talk) 22:55, 12 February 2024 (UTC)
- Rereading this, I think I should clarify that the recent discussion is not the impetus of the change. MOS:EMPH has said we should use
<em>...</em>
(and not use''...''
) for emphasis since 2011. I opened that thread at the MOS talk page to make sure I understood the current guidelines, not to change them. HouseBlaster (talk · he/him) 04:16, 13 February 2024 (UTC)- Thanks for that information, but frankly, I'm shocked that MOS has said this since 2011, since the number of editors who follow that guidance can probably be counted on the fingers of one hand. (I don't think it's an expectation at Featured Articles, for example.) I'm pretty sure that if this were put to a community-wide discussion, a lot of other editors would feel the same way that I do. (And I'm sorely tempted to do just that.) For that matter, it's also shocking that, for all these years, the WMF markup for the editing window has never been made congruent with what MOS says there. Perhaps MOS has become a sort-of walled garden where most editors only look when something (like this) draws their attention, but that's a discussion for another talk page, not here. It also makes me wonder how big an issue it really is for accessibility, since it seems to have attracted little notice. Please understand, I'm coming at this from a perspective of wanting to be friendly to accessibility issues, but there is so much about this that is so bizarre. --Tryptofish (talk) 21:36, 13 February 2024 (UTC)
- You are obviously coming in good faith (and I am sincerely glad we can both recognize that). Though I would say "WMF has not added it to the toolbar" is hardly anything surprising (as just two examples, WP:THEYCANTHEARYOU and graphs still disabled). I would welcome an RfC at WT:MOSTEXT. Best, HouseBlaster (talk · he/him) 22:11, 13 February 2024 (UTC)
- Yes, I want to confirm that I also see all of this as good faith. I don't know if I will do anything like an RfC (or maybe a more general discussion), but if I do, it will more likely be someplace like the Village Pump, definitely not at a MOS talkpage. --Tryptofish (talk) 23:40, 13 February 2024 (UTC)
- You are obviously coming in good faith (and I am sincerely glad we can both recognize that). Though I would say "WMF has not added it to the toolbar" is hardly anything surprising (as just two examples, WP:THEYCANTHEARYOU and graphs still disabled). I would welcome an RfC at WT:MOSTEXT. Best, HouseBlaster (talk · he/him) 22:11, 13 February 2024 (UTC)
- Thanks for that information, but frankly, I'm shocked that MOS has said this since 2011, since the number of editors who follow that guidance can probably be counted on the fingers of one hand. (I don't think it's an expectation at Featured Articles, for example.) I'm pretty sure that if this were put to a community-wide discussion, a lot of other editors would feel the same way that I do. (And I'm sorely tempted to do just that.) For that matter, it's also shocking that, for all these years, the WMF markup for the editing window has never been made congruent with what MOS says there. Perhaps MOS has become a sort-of walled garden where most editors only look when something (like this) draws their attention, but that's a discussion for another talk page, not here. It also makes me wonder how big an issue it really is for accessibility, since it seems to have attracted little notice. Please understand, I'm coming at this from a perspective of wanting to be friendly to accessibility issues, but there is so much about this that is so bizarre. --Tryptofish (talk) 21:36, 13 February 2024 (UTC)
- Rereading this, I think I should clarify that the recent discussion is not the impetus of the change. MOS:EMPH has said we should use
- OK. [2]. But my other concerns remain. --Tryptofish (talk) 22:55, 12 February 2024 (UTC)
- The anchor template was substituted per its documentation: see Template:Anchor#Rationale for substitution in the header. That is not an accessibility issue; I sincerely apologize for implying otherwise. HouseBlaster (talk · he/him) 22:49, 12 February 2024 (UTC)
- I don't doubt the good intentions of this, but I have real concerns. One of the things you changed in that edit was an anchor for a section, doing away with using Template:Anchor for that purpose. I've always thought that anchors were for where something was linked to, from somewhere else. Unless I'm missing something, that has nothing to do with accessibility, nothing to do with screen readers. It's just some editors' personal opinion of what the "correct" markup should be. Has that template been brought up at WP:TfD? If there are real issues having to do with accessibility, if there are real reasons to do emphasis one way and not another, then there is a process of addressing that community-wide, but a small discussion at a MOS subpage talk page isn't that. --Tryptofish (talk) 22:44, 12 February 2024 (UTC)
Is there any chance of a direct answer to the spirit of my question. Let's say there are six million articles and uncountable other pages. How many of them are likely to use apostrophes for wikitext and fit the above "incorrect wikitext, I try to correct"? What is the status of Help:Wikitext#Format? Johnuniq (talk) 01:30, 14 February 2024 (UTC)
- In articles, apostrophes are correct the vast majority of the time.
<em>...</em>
and<strong>...</strong>
are for emphasis, not formatting. At MOS:TEXT, there are numerous reasons to use bold/italics; all of them except emphasis should use apostrophes. How many pages will be impacted? Not many in mainspace (when was the last time you saw emphasis used in mainspace? I can't recall the last time I encountered it...), none in the various talk spaces (except for possibly in banners), none in userspace. So, the direct answer: I don't know, but mostly in the project/help/template namespaces. HouseBlaster (talk · he/him) 02:02, 14 February 2024 (UTC)- I feel like this doesn't add up. I thought this was about accessibility, for people who use screen readers. But now, I'm hearing that we have to distinguish between formatting, and formatting for emphasis. Are people who use screen readers confused when, in the context of a policy page (not a mainspace page), the screen reader tells them that some text has been formatted in italics or bold, but does not tell them whether or not the intention of the formatting was to provide emphasis? --Tryptofish (talk) 18:48, 14 February 2024 (UTC)
Using semantic markup has been part of the HTML standards from the beginning, so this isn't new guidance. Generally, though, most people don't think about the labelling their words semantically when writing. Instead they consider how they want their words to look. Some semantics are clear: text editors will have a list button, as users know what that will look like. They have italic and bold buttons instead of emphasis and strong emphasis, though, as it's not apparent what visual effect that might have. For that matter, the semantic difference between the two is fuzzy as well. This fuzziness contributes to the difficulty in implementing a standard handling mechanism by screen readers. Some people have suggested that the screen reader voice could provide additional emphasis on elements marked up as having emphasis or strong emphasis. A lot of use of bold text on the web, though, is more about creating guideposts in text passages to help readers navigate to what they are looking for, and it might not be suitable for these passages to be read with emphasis. Having editors provide easy options for italic and bold is probably a better choice in the overall scheme, to avoid imparting misleading semantics by default.
A side note on what screen readers do in practice: as I understand it, some provide an option to announce when an emphasis or strong emphasis tag is present (I believe it could be a verbal announcement, some kind of sound, or an alternate voice), more intended for proofreading when editing than regular reading. They don't provide support for a emphasis voice intonation (which to work well would probably need some type of AI-based program to take into account the surrounding context).
My personal advice would be two-fold: first, we should look for other ways beyond marking phrases in bold to help readers navigate through text. Perhaps more nutshell summaries should be provided at the start of sections. (This wouldn't be appropriate in articles, but as mentioned by HouseBlaster, this type of guidepost technique isn't used in articles.) Second, given that even on Wikipedia guidance pages, emphasis semantics is not really critical to communicating the ideas being presented, I would focus on very specific situations. Perhaps on a given page, just one phrase in the overall nutshell summary ought to be marked as having emphasis. isaacl (talk) 18:59, 14 February 2024 (UTC)
- To repeat: Are people who use screen readers confused when, in the context of a policy page (not a mainspace page), the screen reader tells them that some text has been formatted in italics or bold, but does not tell them whether or not the intention of the formatting was to provide emphasis? --Tryptofish (talk) 19:05, 14 February 2024 (UTC)
- I'm not sure why you're repeating your question to me; I did read it after you posted it moments ago and don't have any insight into reader confusion. I will note, though, that as I understand it, screen reader users don't generally browse web pages using the proofreader mode enabled where elements get announced, as it results in too many extraneous announcements. isaacl (talk) 19:12, 14 February 2024 (UTC)
- I'm not trying to be testy, sorry, but I think my question gets to the heart of what this talk section is trying to resolve: whether this policy page should be formatted one way, or the other. But I think you actually just provided some information that helps to answer the question. If the typical Wikipedia user who reads this policy page using a screen reader for accessibility is likely (at least most of the time) to do so with the screen reader set to a mode that does not distinguish between fonts that we format using multiple apostrophes, and fonts that we format with HTML markup, then this isn't a real accessibility issue. I'm inclined to think that the edit to this policy page should be reverted back to what it was before (except for that anchor).
- I'm also starting to realize that this as-yet unchallenged 2011 edit to an obscure corner of MOS should also be reverted: [3]. It uses, as an illustrative example, some text that is clearly supposed to look like part of a mainspace article ("Gellner accepts that knowledge must be..."). Yet we are being told here that
there are no plans to make changes of that sort throughout mainspaceproblems in mainspace are rare. --Tryptofish (talk) 19:34, 14 February 2024 (UTC) Revised. --Tryptofish (talk) 23:04, 14 February 2024 (UTC)- I didn't say I have no plans to touch mainspace. I said
Not many in mainspace
(ironically, emphasis added). Emphasis in general is not used throughout mainspace, but on those rare occasions it is used it should be with<em>...</em>
or (in extraordinary circumstances)<strong>...</strong>
. (In the example at the MOS page, semantic markup is correct.)Additionally, respectfully but strongly object to the idea that if most screen readers ignore these tags that means it is not an accessibility issue. Most people don't need a screen reader, but that doesn't mean we can ignore the needs of those who do. Again, I would welcome an RfC on the subject. HouseBlaster (talk · he/him) 22:56, 14 February 2024 (UTC)- I'm not saying to ignore this particular issue, but that there are practical difficulties in dealing with it, and that there is a better benefit-cost ratio for resolving other accessibility problems. Not having certain phrases marked up as being emphasized is mostly not a significant loss in communication; it's a progressive enhancement for those who can make use of it. In articles, given the broad spectrum of reader cultural backgrounds, I think recasting the sentence to avoid emphasis would be clearer. isaacl (talk) 23:16, 14 February 2024 (UTC)
- (edit conflict) If I understand correctly, this isn't a matter of some screen readers paying attention to the tags and others ignoring them. It's that readers who use them are unlikely to be using them on policy pages in proofreader mode, and so the only reason to change policy pages as you have done is to accommodate those few readers who do read the policy page in proofreader mode. And (I think) those few readers who do use proofreader mode will still know when there is italic or bold font, but they will just not be told by the software whether that font selection was made for the purpose of emphasis, or for some other purpose. When sighted readers (like me) read policy pages, we see italic and bold fonts, but nothing tells us (unless we go into the edit window and are aware of the distinctions being made in this discussion), whether the font selection was made for the purpose of emphasis, or for some other purpose. Of course, most of us easily infer what the purpose of the font was, assuming we even care. And I suspect that readers who use screen readers are just as able to infer purpose from the context. So what's the accessibility issue? What will confuse people who use screen readers? --Tryptofish (talk) 23:18, 14 February 2024 (UTC)
- Based on my understanding, announcing the emphasis elements has been tried by at least one screen reader and disliked by its users, and thus it isn't a default behaviour for that implementation. I mentioned what I've seen about proofreader mode in JAWS because it is a workaround to still get these elements announced, but it's intended to let people check that they wrote their markup correctly, so they're willing to put up with additional verbosity. (I believe the specific element is announced, since that's key to knowing if the markup is correct.) isaacl (talk) 00:09, 15 February 2024 (UTC)
- Thanks. I think this additional information provides even more reason to conclude that
there is not a legitimate accessibility issue herethe accessibility issue here is not substantive enough to justify changing the markup on this policy page, and maybe not substantive enough to justify changes elsewhere. --Tryptofish (talk) 17:58, 15 February 2024 (UTC) --Tryptofish (talk) 18:38, 15 February 2024 (UTC)
- Thanks. I think this additional information provides even more reason to conclude that
- Based on my understanding, announcing the emphasis elements has been tried by at least one screen reader and disliked by its users, and thus it isn't a default behaviour for that implementation. I mentioned what I've seen about proofreader mode in JAWS because it is a workaround to still get these elements announced, but it's intended to let people check that they wrote their markup correctly, so they're willing to put up with additional verbosity. (I believe the specific element is announced, since that's key to knowing if the markup is correct.) isaacl (talk) 00:09, 15 February 2024 (UTC)
- I felt it helped illuminate the relevance of the question too, so I was surprised you repeated it. I do think semantic markup of this type is ideal, but given the practical difficulties in achieving it or making use of it, I feel the benefit-cost ratio is low. I'm mostly ambivalent about the original edit that initiated this discussion; either way doesn't bother me too much (other than the underlining, which traditionally is taught as a typewriter-equivalent to italics before italic fonts became readily available to everyone, but I get that not everyone has that reaction).
- Regarding the manual of style diff, as it's in alignment with the techniques described in the Web Content Accessibility Guidelines, I can't object too much to it. But as I mentioned, personally I suggest focusing on specific, targeted instances, and off-hand I can't really think of something that really benefits from this in an article. (Taking that sample fragment as an example, I think I'd rewrite it to try to convey the same connotation in a different way.) isaacl (talk) 23:11, 14 February 2024 (UTC)
- I agree with you about the cost-benefit. And my comment about the MOS diff was more of a rhetorical point, than a proposal to actually revert it, especially since this isn't the page to decide that. --Tryptofish (talk) 23:22, 14 February 2024 (UTC)
- I didn't say I have no plans to touch mainspace. I said
- I'm not sure why you're repeating your question to me; I did read it after you posted it moments ago and don't have any insight into reader confusion. I will note, though, that as I understand it, screen reader users don't generally browse web pages using the proofreader mode enabled where elements get announced, as it results in too many extraneous announcements. isaacl (talk) 19:12, 14 February 2024 (UTC)
- I don't want to do anything too hastily, so I'll just post here that I think that any changes to policy pages are expected to have consensus if they are disputed, and I'm still waiting to see if anyone wishes to rebut the most recent arguments made in this discussion. Absent such a rebuttal, I think it will be appropriate at some point to undo the formatting changes. --Tryptofish (talk) 21:45, 16 February 2024 (UTC)
- Let me try again: The HTML spec says
<b>...</b>
(which is the HTML produced by'''...'''
) is not for emphasis. That is what<em>...</em>
and<strong>...</strong>
are meant to do. There are plenty of sources which explain why using semantically appropriate HTML is an accessibility concern (see, e.g. [4][5][6]). I am not sure why a change for accessibility needs to be consideredsubstantive enough
to be worthwhile. If you argument is that MOS:TEXT is incorrect, that is an argument you can make at a RfC. I am reminded of File:Diagram of IGNORE.svg: if the rules are wrong, the solution is to change the rules, not ignore them. HouseBlaster (talk · he/him) 22:03, 16 February 2024 (UTC)- Maybe you could summarize how those "plenty of sources" rebut what I said above? I said:
If I understand correctly, this isn't a matter of some screen readers paying attention to the tags and others ignoring them. It's that readers who use them are unlikely to be using them on policy pages in proofreader mode, and so the only reason to change policy pages as you have done is to accommodate those few readers who do read the policy page in proofreader mode. And (I think) those few readers who do use proofreader mode will still know when there is italic or bold font, but they will just not be told by the software whether that font selection was made for the purpose of emphasis, or for some other purpose. When sighted readers (like me) read policy pages, we see italic and bold fonts, but nothing tells us (unless we go into the edit window and are aware of the distinctions being made in this discussion), whether the font selection was made for the purpose of emphasis, or for some other purpose. Of course, most of us easily infer what the purpose of the font was, assuming we even care. And I suspect that readers who use screen readers are just as able to infer purpose from the context. So what's the accessibility issue? What will confuse people who use screen readers?
--Tryptofish (talk) 22:19, 16 February 2024 (UTC) - PS: I've done a quick read of the three sources you linked to, but I'm not an expert on the subject. I think I'm reading that "semantic markup" is a good thing, because, for example, it's better to label a button for people to click on as a <
button
>. I'm not understanding how that refutes what I said. --Tryptofish (talk) 22:31, 16 February 2024 (UTC)- It is the same logic as the button example: just as it is better to label a button a button, it is better to label emphasis as emphasis. Using apostrophes will not confuse anyone, put differently, it is not "broken". An analogy would be a GA: a GA is not a "bad" article, but that doesn't mean a FA isn't a "better" article. HouseBlaster (talk · he/him) 00:38, 18 February 2024 (UTC)
- Thank you for answering, and it seems to me that this is, indeed, what it boils down to. I referred below to ipse dixit assertions, and I think that's what "it's better" amounts to in this instance. I can agree that, in a sort of general, almost philosophical, way, it is kind-of "better". But I think we have gotten some progress towards consensus by you agreeing that the older formatting won't confuse anybody, and wasn't literally "broken". And it seems to me, per what I said above, that we aren't so much dealing with a matter of accessibility for persons with disabilities, as we are with something that is kind-of "better" in the way that it can announce the purpose of some formatting as being about emphasis when users of screen reader software enable a particular software mode. But it isn't really something that we need to do, to prevent readers from becoming confused, any more than we need a way to tell sighted readers why some text is formatted the way that it was. So it seems to me that it's misleading to call this an accessibility issue. It's more an issue of the most "elegant" way to markup online text.
- And when we're in that context, it's fair to consider what is convenient for most Wikipedia editors, and what is most familiar to most Wikipedia editors, and the fact that WMF still gives us software where the multiple-apostrophe markup is the default. If we're not really doing this to accommodate readers with disabilities, then we can reasonably consider how best to accommodate most editors here, who routinely markup text the way we routinely do. And that's where I'm coming from. --Tryptofish (talk) 00:56, 18 February 2024 (UTC)
- Where we disagree is that about whether it is an accessibility issue here. Emphasis should use emphasis markup, because semantic markup is more accessible. MOS:TEXT currently says we should use
<em>...</em>
(and<strong>...</strong>
) when we want to emphasize things. If you wish to revert the change to this page, I think the most appropriate thing would be to propose a change to MOS:TEXT. (C.f. WP:LOCALCONSENSUS.) HouseBlaster (talk · he/him) 01:12, 18 February 2024 (UTC)- You seem to be saying that it
will not confuse anyone, put differently, it is not "broken"
, while at the same time you are saying that it is an accessibility issuebecause semantic markup is more accessible.
Please explain to me why non-semantic markup is less accessible, even though it will not confuse anyone. Thanks. --Tryptofish (talk) 21:30, 18 February 2024 (UTC)- Respectfully, this line of discussion is something that is better suited to a RfC than this talk page. That being said, it will not confuse anyone because
<b>...</b>
and<i>...</i>
are presentational markup—it is no more confusing than just not emphasizing anything at all. That being said, to communicate emphasis, semantic markup should be used. To quote SMcCandlish (part of which I included in my third post in this thread):Whether screen readers right this second support this semantic markup very well is immaterial; it [semantic markup] exists and is well-defined as serving this semantic purpose, and support will get better over time.
HouseBlaster (talk · he/him) 21:55, 18 February 2024 (UTC)- Either it's an accessibility issue or it isn't. Clearly, you are advocating treating it as such an issue, not because anyone will be confused, but purely on an ipse dixit basis, because
semantic markup should be used
or because another editor said that it's immaterial whether or not it affects readers. You keep acting like the burden is on me to open an RfC at MOS, but I could just as well demand that you get consensus to change Help:Wikitext#Format, as another editor pointed to earlier in this discussion. --Tryptofish (talk) 22:15, 18 February 2024 (UTC)- MOS:TEXT is a guideline, Help:Wikitext is not. Most of the time presentational markup is what should be used, which is why Help:Wikitext recommends what it does. With all due respect, I have explained how semantic markup is beneficial: it makes it easier for machines to process information, which is the cornerstone of accessibility software. HouseBlaster (talk · he/him) 22:26, 18 February 2024 (UTC)
- You keep saying stuff like "with all due respect". I'm not trying to upset you, really, but I'm just insisting on logical thinking, not ipse dixit commandments, and I'm taking your replies to me as they come. I really don't want to have an edit war on a policy page. --Tryptofish (talk) 22:33, 18 February 2024 (UTC)
- MOS:TEXT is a guideline, Help:Wikitext is not. Most of the time presentational markup is what should be used, which is why Help:Wikitext recommends what it does. With all due respect, I have explained how semantic markup is beneficial: it makes it easier for machines to process information, which is the cornerstone of accessibility software. HouseBlaster (talk · he/him) 22:26, 18 February 2024 (UTC)
- Either it's an accessibility issue or it isn't. Clearly, you are advocating treating it as such an issue, not because anyone will be confused, but purely on an ipse dixit basis, because
- Respectfully, this line of discussion is something that is better suited to a RfC than this talk page. That being said, it will not confuse anyone because
- You seem to be saying that it
- Where we disagree is that about whether it is an accessibility issue here. Emphasis should use emphasis markup, because semantic markup is more accessible. MOS:TEXT currently says we should use
- It is the same logic as the button example: just as it is better to label a button a button, it is better to label emphasis as emphasis. Using apostrophes will not confuse anyone, put differently, it is not "broken". An analogy would be a GA: a GA is not a "bad" article, but that doesn't mean a FA isn't a "better" article. HouseBlaster (talk · he/him) 00:38, 18 February 2024 (UTC)
- Maybe you could summarize how those "plenty of sources" rebut what I said above? I said:
- Let me try again: The HTML spec says
Whether to use formatting or not
[edit]- Here is my feedback on each change:
When the word "page" is used in a ban, it means any page on Wikipedia, including for example user, talk, discussion, file, category or template pages.
Bold weight feels unnecessarily loud. I suggest re-writing it to "When a ban refers to a page, this includes any Wikipedia page, across all namespaces."Reverting obvious vandalism (such as page content being replaced by obscenities) or obvious violations of the policy about biographies of living persons.
Strong emphasis feels like an unnecessary intensifier. I suggest removing bold weight.If someone is banned from the Wikipedia namespace, administrative boards, or is under a similar restriction, this exception does not allow for reporting vandalism to administrative noticeboards.
Underlining is not recommended by Wikipedia:Manual of Style/Text formatting § How not to apply emphasis, and again emphasis feels like an unnecessary intensifier. I suggest removing the underline.Editors who are blocked from editing by the Arbitration Committee can appeal ...
The styling is presentational, with the bold text indicating a type of inline heading. The italic setting for "by the Arbitration Committee" isn't really necessary, but could be considered to be additional presentational markup to help separate the text from the rest of the heading. I suggest leaving this as italic markup.The measure of a ban is that even if the editor were to make good or good-faith edits, permitting them to edit in those areas is perceived to pose enough risk of disruption, issues, or harm, to the page or to the project, that they may not edit at all, even if the edits seem good.
This one is not presentational. Personally I would remove the italic markup as I wouldn't give it additional emphasis, but I can see the argument for using emphasis markup.This does not mean that edits must be reverted just because they were made by a banned editor...
Emphasis feels like an unnecessary intensifier. I suggest removing the italic markup.Editors in turn are not permitted to post or edit material at the direction of a banned or blocked editor...
Italic markup seems unnecessary. I suggest removing it.Editors who are banned from specific pages or topics must immediately cease editing these pages or topics. If they do not, then a block will be used to enforce the ban.
"Then" is extraneous and could be removed. However it might be better to recast with something like "Failing to do so can result in being blocked to enforce the ban."Such a block will necessarily prevent their editing of the entire site, but they are not banned from the site and remain members of the community.
Italic markup seems unnecessary. With the advent of partial blocks, I suggest recasting to "A full block will prevent banned editors from editing the entire site beyond their user talk page, but they are not banned from the site and remain members of the community."It is unacceptable to take advantage of banned editors,...
Though personally I wouldn't give this additional emphasis, I can see an argument for it and thus using strong markup.
- isaacl (talk) 03:51, 17 February 2024 (UTC)
- Thanks for pointing out that one of the changes was actually of something that was presentational, rather than for emphasis. It seems to me that, while switching many of these to plain text might be a good way to resolve the dispute, there are really two separate questions. The question that has been at hand throughout the discussion is whether or not to use the multiple-apostrophe markup when non-plain text is intended. The second question, whether we need non-plain text at all, is really a separate question, and I suppose that in each instance an editor had a reason for the formatting when it was originally added. (I know you realize that already, and that's why you presented the list in talk.) I'm hoping to get a clear resolution to the original question, beyond just ipse dixit assertions, and I'm still waiting. --Tryptofish (talk) 22:40, 17 February 2024 (UTC)
- The general question is broader than this page, and stirs up a lot of passionate debate amongst some, so to try to reach a compromise on what should be done with this page in the meantime, I examined each case to see when emphasis might be warranted, and only found two. Editors often think "this seems important; it should be set with some kind of emphasis", but as you alluded to, just because that's how it currently is doesn't mean that's actually the most effective way. Within plain prose, bold weight has a shouting connotation to many, which can be unpleasant to read. I think italics are often used by editors to mimic a speaking stress, but that can be overused, and can be difficult for non-native English speakers to interpret. isaacl (talk) 23:03, 17 February 2024 (UTC)
- For clarity, I did not change the bolding of Editors who are blocked from editing by the Arbitration Committee (in other words, I did not change anything that was presentational to use emphasis markup). I purposefully left it as
'''...'''
because it is presentational. HouseBlaster (talk · he/him) 01:15, 18 February 2024 (UTC)- In this edit, you changed the markup for the italic setting to emphasis, and my comments were about that portion of the text. isaacl (talk) 01:19, 18 February 2024 (UTC)
- Ah. I see that as emphasis (i.e. this avenue of appeal is only open to editors blocked by ArbCom). HouseBlaster (talk · he/him) 01:24, 18 February 2024 (UTC)
- The bold phrases are essentially inline headings describing categories of users. There's no parallelism between the two headings that would warrant emphasizing part of one. Emphasis can come across as speaking louder and it's somewhat strained to be louder at the end of the heading. Thus I do not feel that emphasis is appropriate. isaacl (talk) 01:40, 18 February 2024 (UTC)
- Ah. I see that as emphasis (i.e. this avenue of appeal is only open to editors blocked by ArbCom). HouseBlaster (talk · he/him) 01:24, 18 February 2024 (UTC)
- In this edit, you changed the markup for the italic setting to emphasis, and my comments were about that portion of the text. isaacl (talk) 01:19, 18 February 2024 (UTC)
- Thanks for pointing out that one of the changes was actually of something that was presentational, rather than for emphasis. It seems to me that, while switching many of these to plain text might be a good way to resolve the dispute, there are really two separate questions. The question that has been at hand throughout the discussion is whether or not to use the multiple-apostrophe markup when non-plain text is intended. The second question, whether we need non-plain text at all, is really a separate question, and I suppose that in each instance an editor had a reason for the formatting when it was originally added. (I know you realize that already, and that's why you presented the list in talk.) I'm hoping to get a clear resolution to the original question, beyond just ipse dixit assertions, and I'm still waiting. --Tryptofish (talk) 22:40, 17 February 2024 (UTC)
- Here is my feedback on each change:
There's another change, not listed above.It's in a footnote in the WP:BANEX section. The relevant part of the text isthis exception does not allow for reporting vandalism to
, where "does not" is underlined. The markup for underlining there seems to me to be particularly wonky, and I don't think there's a compelling reason for underlining instead of italics or bold. Maybe we could change that to either italics or bold? --Tryptofish (talk) 23:18, 18 February 2024 (UTC)- Yes, I discussed this change. I suggested just removing the underline. isaacl (talk) 23:22, 18 February 2024 (UTC)
- Woops. I see it now. In this case, I think some sort of emphasis serves a good purpose. But the "new" formatting for underline is awful looking, when viewed in the edit window. If we could just change it to some sort of emphasis, that won't change the meaning of the policy page, and with that, the remaining changes that are contested are not overly confusing to editors looking in the edit window. --Tryptofish (talk) 23:34, 18 February 2024 (UTC)
- Personally, when I hear the different forms of emphasis in my mind and compare them to a normal reading of the sentence, I feel the regular reading is the most natural and fully conveys the intent of the sentence. Typographic changes are best used in a sparing manner. I appreciate, of course, that you and others may have a different view. We both agree that underlining is not a best practice for this sentence. isaacl (talk) 23:43, 18 February 2024 (UTC)
- I changed it: [7]. With that, the overall cumulative changes to the policy page are this: [8]. As that stands, while I personally am not particularly happy about it, I also don't think it's that big a deal. There's nothing that will seriously (and, yeah, I wrote
''seriously''
) confuse editors who edit the page and are accustomed to the multiple-apostrophe markup. --Tryptofish (talk) 23:46, 18 February 2024 (UTC)- I don't really like changing it to bold. To me, bold is being loud, and thus I wince when reading that sentence. Emphasis markup would be less jarring. isaacl (talk) 23:50, 18 February 2024 (UTC)
- At this point, I wince when I read this discussion. If everyone is a little bit unhappy, maybe that's good enough.
--Tryptofish (talk) 23:53, 18 February 2024 (UTC)
- I passed that point long ago, which is why I tried to find some compromise for this page. :) If someone wants to address the broader issue somewhere else, more power to them. isaacl (talk) 23:56, 18 February 2024 (UTC)
- If we aren't all unhappy, it ain't a compromise :) HouseBlaster (talk · he/him) 00:03, 19 February 2024 (UTC)
- I have no interest in starting a broader discussion elsewhere. Again, [9] is the cumulative total of what has changed. If anyone wants to come along and revert most of it back, I won't object, but I'm personally not going to do it. The one broader comment I want to make here is that editors who want to make these kinds of changes on policy pages would be well advised to bring it up in talk before jumping in and doing it, no matter how certain you are that it is The Right Thing To DoTM. --Tryptofish (talk) 00:08, 19 February 2024 (UTC)
- At this point, I wince when I read this discussion. If everyone is a little bit unhappy, maybe that's good enough.
- I don't really like changing it to bold. To me, bold is being loud, and thus I wince when reading that sentence. Emphasis markup would be less jarring. isaacl (talk) 23:50, 18 February 2024 (UTC)
- I changed it: [7]. With that, the overall cumulative changes to the policy page are this: [8]. As that stands, while I personally am not particularly happy about it, I also don't think it's that big a deal. There's nothing that will seriously (and, yeah, I wrote
- Personally, when I hear the different forms of emphasis in my mind and compare them to a normal reading of the sentence, I feel the regular reading is the most natural and fully conveys the intent of the sentence. Typographic changes are best used in a sparing manner. I appreciate, of course, that you and others may have a different view. We both agree that underlining is not a best practice for this sentence. isaacl (talk) 23:43, 18 February 2024 (UTC)
- Woops. I see it now. In this case, I think some sort of emphasis serves a good purpose. But the "new" formatting for underline is awful looking, when viewed in the edit window. If we could just change it to some sort of emphasis, that won't change the meaning of the policy page, and with that, the remaining changes that are contested are not overly confusing to editors looking in the edit window. --Tryptofish (talk) 23:34, 18 February 2024 (UTC)
- Yes, I discussed this change. I suggested just removing the underline. isaacl (talk) 23:22, 18 February 2024 (UTC)
Sorry for necroing this, but I saw it at RFA today, and I don't really want to comment negatively in the RFA. But converting a bunch of concise code to verbose code seems questionable to me. A search for <strong> in MOS:ACCESS reveals no results prescribing that we must do it this way, suggesting that these types of changes do not have consensus yet. Seems also to run afoul of WP:COSMETICBOT. I think it would be wise for wikignomes to not start mass converting these yet until a stronger consensus is formed. These types of changes have a history of controversy even when they have consensus, for example MalnadachBot's HTML linting task. –Novem Linguae (talk) 10:25, 19 June 2024 (UTC)
- You're right that it isn't in MOS:ACCESS; I hadn't realized that before. The part of MOS where it does appear is MOS:EMPHASIS. The case for it being an accessibility issue is fairly weak. Screen readers used in their normal mode of operation cannot tell the difference. The only way it comes into play for screen readers is when they are used in "proofreader mode", and I'm not even sure if that's really an accessibility issue. This seems to arise from some editors believing that, in HTML, it's more elegant or correct to code that way. In the discussion above, I was pointed to some sources that, primarily, are making the argument that display items, such as a clickable button, should be coded with HTML tags such as <button>, rather than in other ways, which makes sense, but the argument made for text emphasis at MOS:EMPHASIS (about the standard markup provided by the WMF software edit window being "semantically incorrect") strikes me as something that is likely not to have widespread community consensus. As for whether that part of MOS should be changed, that's a discussion for there, not here. Personally, I would be in favor of changing it, but it's a discussion I have little appetite to start. As for the issue here, I've already said that I would have no objection if someone wants to revert this policy page back to where it was before the changes, but I also have little appetite for reverting it myself. --Tryptofish (talk) 23:09, 23 June 2024 (UTC)
Are "site bans", "CBANs", and "indefinitely blocked by the community" all the same thing?
[edit]Drbogdan was recently blocked, and the closer stated the community's consensus is that Drbogdan is blocked indefinitely
. Is this the same thing as a CBAN? Is this the same thing as a site ban? This policy intermixes the terms a bit so I would like to get clarification, and possibly edit the policy to be clearer about this. Thoughts? –Novem Linguae (talk) 00:56, 7 July 2024 (UTC)
- As per Wikipedia:Banning policy § Community bans and restrictions, a community ban is a sanction agreed upon by the consensus of the community (thus covers any type of editing restriction). Editors indefinitely blocked by community consensus
are considered "banned by the Wikipedia community"
. Some editors have argued for a distinction between being indefinitely blocked and a site ban; others (including me) feel that an indefinite block is just the technical means used to enforce a site ban. There is no operational difference between a consensus finding of "site ban" or "indefinite block" with respect to appeal, but it may affect how editors choose to deal with the sanctioned editor's previous edits, or user talk page edits. isaacl (talk) 01:21, 7 July 2024 (UTC) - I think community-imposed sanctions should be appealed to the community, regardless of what we call them. I think that's mostly what WP:CBAN and WP:UNBAN are about, as well as making sure enough time is taken on serious matters. Firefangledfeathers (talk / contribs) 01:44, 7 July 2024 (UTC)
- I was part of the uncertainty at the thread at Drbogdan's talk page that prompted Novem Linguae to raise the question here. Actually on checking this policy it's quite clear it is a CBAN as it says
Editors who are indefinitely blocked by community consensus, or remain indefinitely blocked after due consideration by the community, are considered "banned by the Wikipedia community"
. It's even clearer when you look at the RfC that's the citation to those words which seems to address this specific point. DeCausa (talk) 08:15, 7 July 2024 (UTC) - Basically CBAN is the who, site ban is the what, and the indef is the how. Someone who thoroughly fucks up is "banned from editing Wikipedia, by the community, enforced with an indefinite block". The first part is often left implicit but, even though the RfC DeCausa mentioned stopped people wikilawyering on that point, I still think it's good practice to always include the word "ban" when closing such threads. – Joe (talk) 14:35, 7 July 2024 (UTC)
- On that last point, see the comment here from Ivanvector (the blocking admin for Drbogdan which prompted this). DeCausa (talk) 16:27, 7 July 2024 (UTC)
- My overall sense was that an indef block is basically like handing down a life sentence/whole-life tariff while a ban is like giving someone 500 years in prison— there’s no practical difference, it’s just that one is a straightforward description and the other is more a symbolic “insult to injury”; either way they’re in jail forever (literally or metaphorically). Personally I’d like to do away with “banning” people because it’s confusing to newcomers and feels like punishment, not prevention (see the aforementioned comparison) Dronebogus (talk) 05:27, 9 July 2024 (UTC)
- Neither is necessarily a "life sentence". "Indefinite" is not necessarily "permanent", and some editors who were previously community banned have successfully returned to editing after they figured out what they did wrong and convinced the community it would not happen again (and some were, or at least said they were, rather young when they did the stuff that got them banned, and with some age and experience realized how foolish they'd acted). Of course, some others screwed up the second chance (third ones are an awful lot harder to talk your way into), and some did things so horrendous that no one would ever be willing to risk their return. But while those are editors who probably are in fact out for good, that's not true of every indefinitely blocked, or even community banned, editor. (And indef blocks even less so—I'm always willing to talk to editors who I indef, and if they really do get it and seem willing to do better, I'll generally give them a chance to prove it.) Seraphimblade Talk to me 05:55, 9 July 2024 (UTC)
- It sounds like community indefinite blocks are a step above regular indefinite blocks. With regular indefinite blocks, making a sincere and convincing unblock request can show that the editor is going to stop doing the behavior, and make the block go away quickly. With a community indefinite block, the community just finished a big ani, and if the editor immediately appeals and it is copied over to ani again, I suspect the community will be unlikely to consider it until a significant amount of time has passed. The 6 months in the standard offer comes to mind. –Novem Linguae (talk) 08:29, 9 July 2024 (UTC)
- Administrators can only impose blocks for specific disruptions that are contrary to policy, or when authorized via a contentious topic designation or a community authorization to impose discretionary sanctions. The community can reach a consensus to enact an editing restriction based on patterns of behaviour, up to restricting editors from editing any page on the site (by default, leaving the user talk page as an exception). Editing restrictions outside of arbitration rulings have to be appealed to the one responsible for the restriction or to the community. (For contentious topics/discretionary sanctions, the admin is acting on the authorization of either the arbitration committee or the community, and so the restriction is appealed to the authorizing body.) I don't know exactly what you are thinking of when you say "a step above", but community-imposed sanctions (whatever they are) do need to be appealed to the community, not just a single administrator. isaacl (talk) 14:37, 9 July 2024 (UTC)
- It sounds like community indefinite blocks are a step above regular indefinite blocks. With regular indefinite blocks, making a sincere and convincing unblock request can show that the editor is going to stop doing the behavior, and make the block go away quickly. With a community indefinite block, the community just finished a big ani, and if the editor immediately appeals and it is copied over to ani again, I suspect the community will be unlikely to consider it until a significant amount of time has passed. The 6 months in the standard offer comes to mind. –Novem Linguae (talk) 08:29, 9 July 2024 (UTC)
- Neither is necessarily a "life sentence". "Indefinite" is not necessarily "permanent", and some editors who were previously community banned have successfully returned to editing after they figured out what they did wrong and convinced the community it would not happen again (and some were, or at least said they were, rather young when they did the stuff that got them banned, and with some age and experience realized how foolish they'd acted). Of course, some others screwed up the second chance (third ones are an awful lot harder to talk your way into), and some did things so horrendous that no one would ever be willing to risk their return. But while those are editors who probably are in fact out for good, that's not true of every indefinitely blocked, or even community banned, editor. (And indef blocks even less so—I'm always willing to talk to editors who I indef, and if they really do get it and seem willing to do better, I'll generally give them a chance to prove it.) Seraphimblade Talk to me 05:55, 9 July 2024 (UTC)
Should our guidelines for user talk pages include something on how topic bans apply to them
[edit]My mistake, this is covered |
---|
The following discussion has been closed. Please do not modify it. |
|
Explicit policy on third party "appeals"
[edit]I propose two changes/additions to the page to reflect how policy is actually being enforced:
- Explicitly state somewhere that third-party appeals are not entertained, similarly to the page on blocks.
- From the table in WP:BLOCKBANDIFF, change: "Bans imposed by community consensus or for repeated block evasion may be lifted by community discussion (unless needing ArbCom review)" to begin with "After appeal, bans imposed by community consensus ...".
Background for this can be found here. Having these two statements would have saved me time, and the time of some very annoyed administrators. Epachamo (talk) 16:57, 27 July 2024 (UTC)
- I've made this proposal about a month ago, with no feedback, I'm extremely hesitant to just make the changes to such a high profile policy page. Is this a be bold situation? Do I need to get an administrator to make a change to a policy page? Epachamo (talk) 02:17, 28 August 2024 (UTC)
- The AN section you linked is now archived here. Sorry, I don't have an opinion at the moment but people are generally reluctant to change long-standing wording that has generally worked. Also, there is always an WP:IAR possibility that a third-party might have a good reason to ask for an unblock of someone and that should not be shut down by more wording here. Johnuniq (talk) 04:55, 28 August 2024 (UTC)
Do TBans include edit requests?
[edit]Are you allowed to still make edit requests? Why is the rule not clear? Emdosis (talk) 18:26, 28 July 2024 (UTC)
- Topic banned editors are not allowed to make edit requests related to the designated topic. I think there's a lot we could do to clarify what a topic ban covers, but I think this case is already pretty clear in the policy, especially: Firefangledfeathers (talk / contribs) 01:08, 29 July 2024 (UTC)
- the intro:
"The purpose of a topic ban is to forbid editors from making edits related to a certain topic area"
, - and the fifth example:
"discussions or suggestions about [the topic] anywhere on Wikipedia"
- the intro:
- Agree with Firefangledfeathers. This is both the written policy and usual practice. In any case, the admin who imposed the ban can vary the conditions to make them stricter or weaker than usual, so that is who you should ask regarding the details of your ban. Zerotalk 03:18, 29 July 2024 (UTC)
- Topic bans are something that should not be confused with the extended confirmed restriction for the Israel-Palestine topic area, where edit requests are the only permitted action. --Tryptofish (talk) 17:12, 30 July 2024 (UTC)
"...or obvious violations of the policy about biographies of living persons.
", should simply say 'obvious violations of Wikipedia's policies' imo. Emdosis (talk) 18:37, 28 July 2024 (UTC)
- No. It's too common to see that t-banned editors have unorthodox, inconsistent, or erroneous interpretations of policy. I can see the case for the BLP exception, since we're so sensitive around BLP issues, but expanding the exception is more likely to lead to problems than to fix them. Firefangledfeathers (talk / contribs) 01:08, 29 July 2024 (UTC)
- @Firefangledfeathers. Absolutely agree. We don’t want arguments about policy, BLP is the only exception we should have for the reasons you give plus many of these editors are in any case too inexperienced to understand them Doug Weller talk 17:37, 30 July 2024 (UTC)
Addition to PROXYING
[edit]WP:PROXYING, part of this policy, limits what actions editors can take at the direction of banned or blocked users. We don't currently have any constraints placed on the banned/blocked users themselves. I'm suggesting that we add such constraints, though I don't have a draft in mind. Is there any interest in proscribing, possibly with some exceptions, directing others to edit on your behalf when subject to a site ban or site block? Firefangledfeathers (talk / contribs) 02:09, 4 August 2024 (UTC)
- Directing others to edit on your behalf while banned is ban evasion, which is discussed in Wikipedia:Banning policy § Evasion and enforcement. One potential consequence is discussed in Wikipedia:Banning policy § Reset of ban following evasion. isaacl (talk) 04:29, 4 August 2024 (UTC)
Can a topic ban from a ct area specifically exclude “broadly construed”?
[edit]If it does that seems to create problems for both the editor and any Admin trying to enforce it. Note this is not a hypothetical question as it’s based on a ban from gensex with this exception. Doug Weller talk 17:12, 23 August 2024 (UTC)
- The standard set of restrictions described at Wikipedia:Contentious topics § Standard set includes
page bans (from the entire contentious topic, a subtopic, or specified pages within the topic)
. So admins are authorized to impose an editing restriction for a tailored subset of the designated contentious topic area. As a matter of practicality, they should be very clear on the boundaries of that subset. isaacl (talk) 17:52, 23 August 2024 (UTC)- I agree with isaacl. Firefangledfeathers (talk / contribs) 17:54, 23 August 2024 (UTC)
- I also agree with Isaac but want to note that Contentious topics rules are set by ArbCom so we can't really come to a binding consensus here. Best, Barkeep49 (talk) 18:04, 23 August 2024 (UTC)
- I agree it's not a matter for community consensus, but I also don't think we should read something into the contentious topic procedure that isn't there. As currently written, it doesn't specify that editing restrictions under the scope of the standard set must be on a broadly construed set of pages, and as far as I can recall, there is no context in the procedure that implies this. isaacl (talk) 19:22, 23 August 2024 (UTC)
- It seems to me that if "broadly construed" were automatically required, it would go without saying. In the vast majority of instances, it's beneficial to say "broadly construed", so it gets said the vast majority of the time. But the fact that it gets said implies that, if it had not been said, then it wouldn't necessarily be the case. We now even have page blocks, so in theory it should be acceptable to ban, explicitly, from a clearly defined narrow set of pages, if that is the chosen sanction. --Tryptofish (talk) 21:31, 23 August 2024 (UTC)
- I agree it's not a matter for community consensus, but I also don't think we should read something into the contentious topic procedure that isn't there. As currently written, it doesn't specify that editing restrictions under the scope of the standard set must be on a broadly construed set of pages, and as far as I can recall, there is no context in the procedure that implies this. isaacl (talk) 19:22, 23 August 2024 (UTC)
- I also agree with Isaac but want to note that Contentious topics rules are set by ArbCom so we can't really come to a binding consensus here. Best, Barkeep49 (talk) 18:04, 23 August 2024 (UTC)
- I agree with isaacl. Firefangledfeathers (talk / contribs) 17:54, 23 August 2024 (UTC)