Help talk:Line-break handling

several ways to force line breaks
Hello. I have a question the documentation currently does not appear to answer. Even if the answer is "it can't be done" that would be preferable to not addressing the question at all.

How do you programmatically request a newline, of the kind that works in a bulleted list? That is, is there a template or code that reproduces "the simplest method"?

If you want to send a bulleted list as a parameter, but the bulleted list itself contains template calls, then the alternative methods (to "the simplest method") just doesn't work. Example: I want to specify the following See Also bulleted list as the seealso parameter of the singlenotice template:
 * this template
 * that template

As far as I can understand, the only way to supply the kind of newline that makes Wiki understand the second asterisk should become a bullet is by using "the simplest method", that is physically using a newline even in the middle of the template call:

Note the abrupt line break, even in the middle of a "single line" of a template call.

You can see this in practical action by examining.

This looks ugly to me and so I'm asking if and how to replicate this kind of newline using code. To illustrate what I'm looking for, let's imagine the answer is "use the __NEWLINE__ magic word" (my made up example) in which case I can replace the above ugliness with:

Note how there now is no abrupt line break in the middle of a template call.

I hope I have managed to explain my query. Again, if there is no way to do this, please update the documentation to make this clear so no further editor is sent on a goose chase with no end (since finding something that doesn't exist is the hardest quest). Cheers CapnZapp (talk) 11:40, 6 December 2020 (UTC)

I would like to ask an advanced wiki editor well versed in wiki markup the following question:

How do you request a newline, of the kind that works in a bulleted list? (Please see the entire talk section for context and details). Thank you.

(If this question is too technical for Help me, please suggest a better place to ask for help. Again thank you.)

CapnZapp (talk) 14:40, 10 December 2020 (UTC)
 * , this is probably what you're looking for. Let me know if you have any further questions; I've marked your request as helped but I'm happy to elaborate. Perryprog (talk) 15:51, 10 December 2020 (UTC)
 * No that doesn't work. Cheers CapnZapp (talk) 15:41, 11 December 2020 (UTC)

The second asterisk isn't converted to a bullet the way it is after "an actual wikitext linebreak (i.e. pressing )" (to quote the help you link to). The result I get when I replace the with is like this:
 * first bulleted line is fine (this line starts with a bullet, not the asterisk I wrote)
 * but second bulleted line is not, here the asterisk remains unconverted

I'm asking how (and if) I code a that actually is interpreted as such by Wiki list markup. In the line just above this, what should I replace with? Best regards, CapnZapp (talk) 15:40, 11 December 2020 (UTC)
 * , alright I'm still not totally sure what you mean so here's a few examples and hopefully one of them is what you want. For the sake of simplicity I'm not going to make it the correct indentation level (i.e., within this "reply"), as that would add some extra markup. You can also ignore the div tags as those are only for visual clarity; they don't affect the markup used.

you do this. Perryprog (talk) 16:21, 11 December 2020 (UTC)
 * This is an unordered list
 * Indented list item
 * One method of multiple paragraphs. Is like this.
 * While another.Is like this.
 * For non-paragraph line breaks


 * I am asking if there is another way to insert a immediately before a list item (bullet) that isn't physically pressing the Enter key, so the entry text remains one line, yet is interpreted as two by the software. Is there a code or something that replicates a  in a way that work with list items? CapnZapp (talk) 18:30, 11 December 2020 (UTC)

So let's illustrate me trying to create an unordered list consisting of two items without using a physical. In all of the following paragraphs, I'm hoping to see two list items "Palm trees" followed by "Date nuts". Okay? Here goes:


 * Palm trees * Date nuts


 * Palm trees* Date nuts


 * Palm trees * Date nuts

...but in all three examples the second asterisk remains unconverted because it isn't on a new line, like in this case:

But here I had to do it by physically pressing Enter. This means it's not only two lines in the output but in the editor as well.
 * Palm trees
 * Date nuts

So  doesn't work. Neither does, nor. I'm asking what - if any - code that can replace the actual physical keypress of my Enter key that (unlike that keypress) keeps the input (as viewed in the editor) as one line, yet is still interpreted by the software as two lines like the keypress (so the second asterisk gets properly converted into a bullet). CapnZapp (talk) 18:32, 11 December 2020 (UTC)

If you now realize you do not know the answer to my question (or if you still do not understand what I'm asking) please mark my request back to "unhelped", so more advanced wiki editors can give it a try. And again, if this question is too technical for Help me altogether, please suggest a better place to ask for help. Thank you CapnZapp (talk) 18:36, 11 December 2020 (UTC)
 * , I'm so sorry, I completely misunderstood what you were trying to achieve. I don't think I know anyway to achieve what you're asking, although it may be possible. Going back to your original question, now that I think I properly understand it, you should be able to embed a multiline list within a template parameter like so (tested using Single notice and see also): I hope this helps. If this is all resolved, and it's OK with you, I'd like to refactor this section as it's a bit messy right now markup-wise. Perryprog (talk) 19:02, 11 December 2020 (UTC)
 * This is exactly the use case I have shown that I am using but wish to avoid! For the final time: I am asking if there is any other way to send along the newlines than to actually press newline (and so avoid the physical line breaks in the editor) - but a way that still triggers the list bullet. Yours, CapnZapp (talk) 19:10, 11 December 2020 (UTC)
 * , I see. I'm not sure why that would be desirable (it's fairly normal for wikitext to appear that way), but I don't believe there's any way to have MediaWiki interpret that as a bulleted list without line breaks. The only other option would be using the bulleted list template or by manually entering the unordered list tags as HTML.LikeThisPerryprog (talk) 19:17, 11 December 2020 (UTC)
 * Thank you. Now, would you say you are confident it cannot be done or only that you do not know of a way. I hope you understand I wish no insult here - I just have no indication of your knowledge level, so I am asking you to evaluate if there is any point in reopening the help query or if you feel reasonably confident you have provided the authoritative, final answer. Regardless, thank you for your time! CapnZapp (talk) 12:38, 12 December 2020 (UTC)
 * , fair question—I would say I'm reasonably confident, but there's a possibility there's a method I'm unaware of. No offense taken, as I do have a habit of hedging my speech unnecessarily. In other words: I don't consider my answer an authoritative, final answer. Perryprog (talk) 16:57, 12 December 2020 (UTC)
 * I'm having difficulty understanding why you want to avoid pressing - is it broken on your keyboard? I also can't find where you have given a use case - which article are you working on? Which section of that article? -- Red rose64 &#x1f339; (talk) 23:32, 11 December 2020 (UTC)
 * Hello Redrose64 and I answered your questions right at the top of the section :) CapnZapp (talk) 12:31, 12 December 2020 (UTC)
 * Specifically, . I find physically broken lines in the editor looks primitive and I'm asking if there's a way to avoid it (but still trigger MediaWiki's detection of list items). As a programmer, I'm not used to the physical appearance of the code having an effect on the execution of the program. It feels wonky to have to break a line in the editor and there there "should" be a code to replace the physical keypress. I mean, it's not as if we're still in the 1950s and coded in FORTRAN (where each statement had to start on a new line)... :) CapnZapp (talk) 12:41, 12 December 2020 (UTC)
 * , to be fair though, in WYSIPWYG markup languages the result of the markup is often wholly based on the appearance of the code. Regardless, MediaWiki's handling of newlines+lists has always had a difficult learning curve, and is generally unintuitive from an average user's perspective. I would say don't worry too much about extraneous newlines in wikitext. While there is a bit of contention on single line breaks within prose, it seems to me to be generally acceptable to use a line break for when a line break is intended to be displayed in the resulting text. (With the exception being dealing with line breaks in "weird" areas, like within list items or footnotes.) Perryprog (talk) 17:04, 12 December 2020 (UTC)
 * Thanks. No, I'm not worried, insomuch that I did post . At this stage, I'm just curious if there's a magic trick to somehow avoid it. If I was told "no there is no code or marker that represents the physical newline" the way there is is in, well, just about every other programming language, then at least I knew to stop wondering. CapnZapp (talk) 19:56, 12 December 2020 (UTC)
 * Let's approach this from a different direction. How about if you had asked "is there a template which will take several arguments written on a single line and convert them to a list, one item per argument?" To which I would have replied "Yes, it is Template:Bulleted list, which may be shortcut to ". So,  emits  - is that what you are looking for? -- Red rose64 &#x1f339; (talk) 23:17, 12 December 2020 (UTC)
 * Again, please read the top of the section User:Redrose64. There I explain I need to send the bulleted list into a template. Specifically supplying it as the seealso parameter of the singlenotice template. I could not get a template to work in this scenario - I couldn't get nested templates (e.g. ) to work. Therefore I am/was not asking if there is such a template. Instead I'm asking if there is a code or magic word or key escape that encodes  in a way that doesn't break the line in the editor, but works fully when interpreted by MediaWiki. I am asking this because I find it aesthetically displeasing to have to physically press ENTER in the middle of a template call. CapnZapp (talk) 22:39, 14 December 2020 (UTC)
 * , you need a space between "see" and "also". Perryprog (talk) 23:27, 14 December 2020 (UTC)
 * If you mean my reply just now to Redrose, that was just an example. Again please read the start of this talk section where I am clearly explaining my actual use case (which I would like to improve so I don't have to in the middle of a code line.) But I've fixed the mistake even in the example now. CapnZapp (talk) 10:11, 15 December 2020 (UTC)
 * , I was responding to "I couldn't get nested templates [...] to work". Currently the example you have there  as expected, so I'm not sure what your problem with it is. Perryprog (talk) 14:00, 15 December 2020 (UTC)
 * I made it work . I have no idea why my previous efforts failed, let's just suffice to say I tried A LOT of different approaches. Thank you. CapnZapp (talk) 14:28, 15 December 2020 (UTC)
 * , no worries :). We all have those moments. Perryprog (talk) 14:31, 15 December 2020 (UTC)

"Wikipedia:NOBR" listed at Redirects for discussion
An editor has identified a potential problem with the redirect Wikipedia:NOBR and has thus listed it for discussion. This discussion will occur at Redirects for discussion/Log/2022 November 21 until a consensus is reached, and readers of this page are welcome to contribute to the discussion. XtraJovial (talk • contribs) 01:35, 21 November 2022 (UTC)

 Let us ignore syntax highlighters that do not accept &lt;br&gt;
This page is not a policy or guideline. I don't think we should be making life more complicated for average editors by discouraging them from using the simpler.

Therefore I suggest syntax highlighters be changed to accept , or to ignore it, or to ignore all the   break forms.

This is in response to this note from on my talk page:

Please do not remove slashes from br tags. Please do not do this. It interferes with the proper functioning of syntax highlighters. Please see H:BR for an explanation. – Jonesey95 (talk) 18:41, 7 December 2022 (UTC)

I have seen this discussion elsewhere, and in most cases help pages end up going back to using  because helping average editors is more important in many people's eyes than pleasing the few people using the problematic syntax highlighters. --Timeshifter (talk) 08:57, 8 December 2022 (UTC) . By the way I have hundreds of thousands of edits on wikis (Wikipedia, Commons, Fandom, Shoutwiki). So I have some experience in believing this having dealt with many editors. I know gadget programmers are mostly volunteers like me and you. I am just pointing out to them, and the writers of this help page, of the need for the change. And the futility of expecting most Wikipedia editors to use . I respect programmers greatly, and that is why I bother to have this discussion with them here and elsewhere. I think some programmers don't understand how the average editor thinks about these things. --Timeshifter (talk) 11:54, 9 December 2022 (UTC) . Rather than have the discussion with just one programmer (as in the past) I decided to have the discussion on this talk page this time. Since this help page discusses the issue somewhat.
 * this is the talk page for discussing improvements to the page Help:Line-break handling, it is nothing to do with improving gadgets. There are at least two ways of displaying syntax highlighting: one of them is part of the MediaWki editor, for which you need to file a feature request at, per WP:BUGS; another is found at , and for that gadget, is a known issue, see mw:User:Remember the dot/Syntax highlighter - feature requests for that may be left at User talk:Remember the dot, see mw:User:Remember the dot/Syntax highlighter. -- Red rose64 &#x1f339; (talk) 18:19, 8 December 2022 (UTC)
 * Thanks for all the gadget links. My problem with this help page was with this section of the help page:
 * H:BR ( https://en.wikipedia.org/wiki/Help:Line-break_handling#%3Cbr_/%3E_or_%3Cbr%3E )
 * insisting on avoiding the use of  : "and so should be avoided". --Timeshifter (talk) 20:35, 8 December 2022 (UTC)
 * We should not alter that advice until all syntax highlighting tools (that are in common use) are amended to permit the form. Altering the guidance and then asking the various software providers to comply with the changed guidance will not yield a swift response. Yes,  is valid HTML but so is, and is really not that much more difficult to type. Over the last twelve years or so I have got so used to it that I type in the space and slash instinctively, just as I do for , , ,  and [//www.w3.org/TR/2018/SPSD-html5-20180327/syntax.html#void-elements several others]. -- Red rose64 &#x1f339; (talk) 00:02, 9 December 2022 (UTC)
 * . I have usually had this discussion with programmers. Most editors aren't programmers. And most editors do not have over 250,000 Wikipedia edits like you. Even if millions of Wikipedia editors were convinced to use (and more importantly, remember to use correctly with space and the correct slash) I don't see how that would be an incentive to the programmers of the gadgets to change them to accept  . I think it would be a disincentive. They would no longer need to change their gadgets.
 * I think most editors aren't going to bother using
 * Not yet "over 250,000", as of this morning I'm still 315 short of that figure. I suppose that if you throw in Commons (5,807), Meta (1,825) and Wicipedia Cymraeg (104), it would be a few thousand more. If you want to contact gadget writers, this really is the wrong page - it has 64 watchers, and only 6 of them have viewed the page recently. You could try WP:VPT, that will get several of them at once. -- Red rose64 &#x1f339; (talk) 23:07, 9 December 2022 (UTC)
 * I was mainly concerned about letting editors who also happen to be programmers see the futility of trying to get most Wikipedians to use
 * From looking at mw:User:Remember the dot/Syntax highlighter it seems that User:Remember the dot is already well aware of the issue. And I have less time, health, and energy than before. So I don't have time to do much more about it. I definitely don't have the energy for Wikimedia's Phabricator, or WP:VPT. Maybe others reading this might do so. --Timeshifter (talk) 05:15, 12 December 2022 (UTC)
 * You are still requesting this on the wrong page. Accordingly I have left a note at Village pump (technical). -- Red rose64 &#x1f339; (talk) 19:59, 12 December 2022 (UTC)

What the proposal actually says is placed on the wrong page, yes. But the proposal that is left unsaid, I agree with: let us ignore syntax highlighters. If they want to remain unable to understand , that's their problem. Meanwhile, the world will keep on using , pretty much regardless of what our page says. So why not simply change it to accept  ? Honestly, any piece of software that still can't handle  probably should be ignored. CapnZapp (talk) 20:09, 12 December 2022 (UTC)
 * I changed the title of this talk section to make things clearer. --Timeshifter (talk) 20:31, 12 December 2022 (UTC)
 * I agree that the text and so should be avoided. should no longer be in ... they can break several of the available syntax highlighters for wiki code in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided.. The default syntax highlighter supports &lt;br> just fine, and from memory I don't believe the wikEd highlighter had issues with it either (but I used that one a long time ago). The only one I can recall being an issue is Remember the dot's (which is the one offered as a separate gadget). That editor has previously refused to make the relevant change, so I do not think we should be basing any of our help or guidance text based on that highlighter accordingly. HTML is not XML and has not been XHTML in over a decade. Izno (talk) 20:36, 12 December 2022 (UTC)
 * In fact, I'd rather see Remember the dot's gadget removed entirely given the deliberate choice not to support HTML, but that is certainly a comment for another place. Izno (talk) 20:43, 12 December 2022 (UTC)
 * Tim Starling (WMF dev/sysadmin) wrote "&lt;br> is valid wikitext" in February 2017. Any syntax highlighter which cannot handle &lt;br> should be removed from public view. Johnuniq (talk) 23:45, 12 December 2022 (UTC)
 * Here is the full discussion:
 * https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_153#%3Cbr/%3E_or_%3Cbr%3E%3F
 * Or go to Village pump (technical)/Archive 153 and then to this section:
 *  or ?  which is section 54.
 * I think we have consensus to remove: and so should be avoided.
 * I clarified the section title after the new info that some syntax highlighters accept
 * --Timeshifter (talk) 04:32, 13 December 2022 (UTC)

or  work better for some editors. I'm one of those editors. I use 's syntax highlighter and find that it improves my editing and does so better than any of the other available highlighters. I don't know how many other people use it, but I think more would if they were aware of it and if it worked better. One way to make it work better is to use . Another way would be to change the highlighter, but this has not happened despite being requested for many years (just because it looks like an easy fix doesn't mean that it is).
 * No one is punishing people for using , but we are acknowledging that

is reasonable. I think that's what we have here now, and I don't see a need for change. SchreiberBike &#124; ⌨ 20:15, 13 December 2022 (UTC) is used in few pages. So it is not helping you much now with your preferred syntax highlighter. it will have little effect on your use of the syntax highlighter. Because few people are going to use . or work better for you, feel free to keep using that. The underlying question here is: should we be able to correct other Wiki editors when they use , using this how-to guide as our argument? (To be clear, that argument is: "don't use  because there is software that can't handle it.") I can agree it doesn't matter nearly as much as if this page was a policy or guideline, but still. Cheers CapnZapp (talk) 14:12, 14 December 2022 (UTC)
 * I agree that it is futile to try to get people to change their behavior if that change makes no difference to them. And requiring everyone to use one kind of line break would be a bad idea. However, asking them nicely, providing an explanation here for why the change is helpful, and discouraging people who want to eliminate
 * Izno wrote: "The only one I can recall being an issue is Remember the dot's (which is the one offered as a separate gadget). That editor has previously refused to make the relevant change,"
 * No matter how much prodding is done to get people to use
 * So I prefer not to confuse the average Wikipedia editor. I prefer to make things simpler for them. --Timeshifter (talk) 21:14, 13 December 2022 (UTC)
 * We aren't discussing the taste of individual Wiki editors, SchreiberBike, we are discussing its usage relative to editing software. If
 * Framing it as correction is its own issue. :) It is not something to correct. Izno (talk) 17:42, 14 December 2022 (UTC)

and it helped. Until it hit this:
 * Gadget author here. If there were some wiki tag that required the slash to be omitted, I would feel compelled to support it regardless of the impacts to complexity and performance. In reality, the opposite is true: There are several tags (,  and its many translations, etc.) that must be closed with a slash. I suspect that MediaWiki does not support implicitly closing these tags for pretty much the same reasons that I don't want to support implicitly closed tags in the syntax highlighter gadget. (And no one else has stepped up to support this in the gadget's code either.) That said, I really don't care about it as much as I used to, and I want to respect community consensus, so I've added a   config parameter to the syntax highlighter which can contain a list of implicitly self-closed tags. You can set this parameter on a per-site basis in MediaWiki:Gadget-DotsSyntaxHighlighter.js by following the instructions at mw:User:Remember the dot/Syntax highlighter. The list is empty by default, which will hopefully keep its impact on performance negligible by default, and also hopefully make it clear that the user or site administrator will have to keep the list up to date if new self-closing tags are added or removed. Happy holidays, and let there be peace on Earth, or at least on Wikipedia. —Remember the dot (talk) 22:15, 25 December 2022 (UTC)
 * . I enabled the gadget just now in preferences. I opened up source editing in Help:Table for the whole page. The highlighting does not seem to match up with anything. Is that because of the many  tags on that page?
 * On your info page (mw:User:Remember the dot/Syntax highlighter) it says "The highlighter is not compatible with some gadgets, browser add-ons, and other customizations." Maybe you could list them on that info page. So I can see if I have any of those enabled.
 * On the other hand the highlighting seems to be lining up correctly in the source editing for this talk section. There are no  tags in it outside of nowiki tags.
 * I will add a  tag in preview to see if it messes things up in preview mode. It does, and it does it instantly. Everything after the   tag is messed up.
 * I removed all the many  tags in source editing in Help:Table and replaced with
 * Apparently that space at the end messed things up. Everything after that was highlighted with the same color.
 * There were 3 instances of that from there on. I fixed them all in preview and the highlighting was working correctly.
 * I would think that is a pretty common event to have a space before >
 * And so I wonder if that can be accommodated in the syntax highlighter. --Timeshifter (talk) 02:38, 26 December 2022 (UTC)
 * And so I wonder if that can be accommodated in the syntax highlighter. --Timeshifter (talk) 02:38, 26 December 2022 (UTC)


 * As far as I can see, you're discussing from the point of view where mediawiki exists in isolation. Please take the overall HTML rules and - most importantly - actual practices into account. In short, since HTML readers - i.e. web browsers - understand a slashless  without complaining, the only practical response is to accommodate this usage here as well. CapnZapp (talk) 11:10, 26 December 2022 (UTC)

See MOS:SIMPLIFY (Manual of Style): Excerpt: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly." See also: KISS principle.

The ' or ' section of Help:Line-break handling needs to be completely rewritten. I may get around to it if someone else does not do it first. --Timeshifter (talk) 00:52, 13 February 2023 (UTC)
 * The Manual of Style isn't discussing varieties of HTML other than a highly specific set of obsolete tags (a ten year old topic). It is telling us to use HTML sparingly. I would argue that KISS tells us to not impose extra rules over and on top of those that HTML already institute. CapnZapp (talk) 10:42, 25 February 2023 (UTC)
 * You previously wrote: "Meanwhile, the world will keep on using , pretty much regardless of what our page says. So why not simply change it to accept   ? Honestly, any piece of software that still can't handle   probably should be ignored."
 * I am just trying to get rid of the extra rule imposed by this help page about avoiding the use of  : "and so should be avoided".
 * See: Help talk:Table. David Göthberg noted in 2008: "Also up until recently all documentation listed  as the code for forced line breaks. But some months ago some XHTML enthusiasts went around and edited a lot of the help pages to show the   or even the  ."
 * So I am just trying to go back to when things were simpler, and we weren't even mentioning anything other than the simplest form:
 * And we certainly weren't discouraging the simplest form. --Timeshifter (talk) 19:30, 25 February 2023 (UTC)

See Special:Diff/1144939614. edit summary: "I am still seeing unnecessary alterations, so describe exactly what happens (checking page source, it seems that MediaWiki now favours the   form without space) - have tested this at Special:Diff/1144937008"

That was tested in a sandbox that is overwritten soon. Here is the test in a permanent sandbox: When I look at the page source from my Firefox browser I see that the emitted HTML is '''  and not   '''
 * User:Timeshifter/Sandbox190

But none of that matters in what we recommend average editors use. Most people in this thread agree that we should recommend the simplest form:   

KISS principle. We are not stopping people from using other forms. Those forms may actually be simpler for them since that is what they are used to using in their other programming. But they are a small subset of Wikipedia editors. --Timeshifter (talk) 13:08, 16 March 2023 (UTC) '''
 * Re That was tested in a sandbox that is overwritten soon, yes, that is why I supplied it as a diff - it will be available indefinitely.
 * Re When I look at the page source from my Firefox browser - are you using the browser's "inspect" feature, or the true "View page source" feature? In Firefox, the source displayed by "inspect" is sanitised.
 * The trigger for my testing and subsequent three edits (one was a typo corr) was having edits appear in my watchlist, from various users, who are making pointless watchlist-clutter for no good reason. For example, (by ) links to H:BR which I presume was being misread, because one perfectly-valid form was replaced by another perfectly-valid form. -- Red rose64 &#x1f339; (talk) 15:11, 16 March 2023 (UTC)
 * Firefox browser > tools menu > browser tools > Page source.
 * or
 * Firefox browser > 3-line menu > More tools > Page source.
 * It looks like to me that Mediawiki converts all the valid Mediawiki wikitext forms to this HTML form:
 * It looks like to me that Mediawiki converts all the valid Mediawiki wikitext forms to this HTML form:
 * So this statement in H:BR is incorrect if I am reading the page source correctly:
 * "The MediaWiki software converts valid forms like, , and to . It also converts the invalid form  to ."
 * And H:BR shouldn't be telling people to convert anything to the slashed forms, according to most people in this thread. Invalid forms that don't work at all should be changed to
 * And you are right about sandboxes. I just prefer a sandbox per topic where I can more easily do further editing, correct mistakes, incorporate suggestions, have a focused history, etc.. --Timeshifter (talk) 17:07, 16 March 2023 (UTC)
 * Hello; I can respond to the inquiry. Previously, H:BR read as favoring &#60;br /&#62;. If this has changed (which the page history seems to suggest), then I was unaware of it. Which line-break form is least likely to cause display issues under certain circumstances (the most backwards compatible)? That is the one I will use going forward. Thank you for alerting me to this discussion, and the changes to the help page. &#8212;&#160;CJDOS,&#160;Sheridan,&#160;OR&#160;(talk) 03:06, 17 March 2023 (UTC)
 * . Please read this whole thread. Most people want the simplest form, , to be recommended. Mediawiki recognizes several forms. So people can use whatever is simplest for them to remember. Some coders are used to other forms. But they are a small percentage of Wikipedia editors. And the KISS Principle implies we should try to keep things simple for the average editor. --Timeshifter (talk) 04:10, 17 March 2023 (UTC)
 * Whether you use, , or  makes absolutely no difference at all to the display of the rendered page. There are two reasons for this: (i) the MediaWiki software converts three of them to the fourth when the page is served to the client; (ii) even if the MediaWiki software did not do that, all major browsers (and most others) treat all four versions identically. So there is no reason to alter one of these to any other. That said, when editing a page and certain syntax-highlighting tools are in use, the  and  forms can give a less-satisfactory experience compared to the  and  forms. So some people will alter an unslashed form to a slashed form when making an edit for another reason; but the space is always optional. -- Red rose64 &#x1f339; (talk) 11:52, 17 March 2023 (UTC)

By the way, I like my outdents messy. :), . The syntax highlighter in question was discussed higher up. Its author refuses to make it work by default. People have to take extra steps. I am guessing it is done this way because the extra code that is required would slow it down too much for his liking. The extra work required to deal with the many variations of various bits of HTML that MediaWiki accepts but his syntax highlighter does not.

Many in this thread have said that Mediawiki should not change, but that his syntax highlighter should change, since only a relatively few people use it. Versus the millions of Wikipedia editors who come and go, and prefer things simple.

I have done a lot of editing at Fandom/Wikia. The standard default source mode editing window I am using comes with a syntax highlighter. It has no problem with.

is used most of the time on Wikipedia. So there is little improvement to the syntax highlighter here when a relatively few coders and programmers use the slashed forms. A single use of  in the edit window here breaks the syntax highlighting.

So this whole effort is pointless, and only makes the average editor unnecessarily confused. We should recommend the simplest form, , as we did in the past. --Timeshifter (talk) 17:14, 17 March 2023 (UTC)


 * I rewrote the help page section. See page version


 * I also updated my sandbox:
 * User:Timeshifter/Sandbox190
 * Go to the page source for the sandbox and look for "Rendered result". There you will see that the MediaWiki software converted all 5 acceptable break forms to  in the HTML.
 * So that is what the browser sees. --Timeshifter (talk) 17:07, 30 March 2023 (UTC)
 * Add me to the list of people who oppose the recent change to remove the note. First, if you are arguing that is more simple than, really? It is two characters longer. Are we going to start changing "colour" to "color" because the latter is more "simple"? Or even take this very section header: do you think it is easier to figure out what  means given that you know what  means, or to figure out what &lt;br&gt; means?  I would actually argue that  is more intuitive: it follows the general principle that a slash ends the effect of a given HTML tag. Add me to the list of people that think we should encourage , but only as a WP:COSMETIC change. HouseBlastertalk 01:38, 16 April 2023 (UTC)
 * Help:Line-break handling in the    section does not say one form is simpler than another. It just says "Use whichever form is simplest for you to remember." That depends on the person. --Timeshifter (talk) 03:33, 16 April 2023 (UTC)

wbr tag
MOS:SIMPLIFY: See:   in this section: Help:HTML in wikitext. is not mentioned there.

I changed the and soft hyphens section of Help:Line-break handling. is now used there instead of

See diff and this version of the help page. --Timeshifter (talk) 19:19, 23 February 2023 (UTC)


 * Please just accept that HTML is idiosyncratic and quirky. As long as Wikipedia accepts HTML, editors will use any legit HTML, and never admonish editors for using variants simply because they're not mentioned here. In other words, please stop trying to invent a special Wikipedia HTML dialect. No editing of this or other help pages change this fact - whether is mentioned or not doesn't matter; we need to be able to respond correctly to all legal versions of void tags.  CapnZapp (talk) 10:32, 25 February 2023 (UTC)
 * Please see my reply to your similar remark in the previous talk section. I beg to differ though about MOS:SIMPLIFY. It says "Other things being equal, keep markup simple."
 * So I think help pages should recommend the simplest form. At the same time though, as you say, we can mention that Wikipedia will accept the other variants too. I changed the help page to say:
 * "See in this section: Help:HTML in wikitext.  is not mentioned there, though Wikipedia will accept that variant."
 * It is in this version of the help page.--Timeshifter (talk) 19:52, 25 February 2023 (UTC)
 * Regarding though Wikipedia will accept that variant, it's not Wikipedia; it's web browsers - and I don't know of any that won't treat and  as exact equivalents. It's part of the HTML spec that void elements (such as br and wbr) do not have end tags, and may be written either with or without the slash (see section 8.1.2.1 item 6). So I see absolutely no reason to discourage the  and  forms. -- Red rose64 &#x1f339; (talk) 20:10, 25 February 2023 (UTC)
 * Wikipedia does not accept all HTML that browsers accept. --Timeshifter (talk) 22:05, 25 February 2023 (UTC)
 * Indeed; but that is controlled by the whitelist which gives permitted element names, not syntactical constructs. For example, is forbidden, not because of the slash but because the img element as a whole is not in the whitelist - for that reason,  is also forbidden. There are more than fifty elements defined in the HTML 5.2 spec which are not whitelisted. -- Red rose64 &#x1f339; (talk) 22:48, 25 February 2023 (UTC)

I think that help pages should point out the simplest HTML first. MOS:SIMPLIFY. We can then mention other less-simple HTML such as tags with a blank space and a slash. And everything else. But we should also point out that using the simplest HTML helps new editors. Complex HTML should actively be discouraged.

See Wikipedia talk:Line breaks usage (from 2006-2008) and the section titled:  vs . I especially like this example from David Göthberg in 2008: The last 2 bolding methods should be actively discouraged. --Timeshifter (talk) 00:09, 26 February 2023 (UTC) . You keep pointing to "keep it simple".... but both variants are arguably equally simple to use and understand! That one is more formal or that the other is viewed by some as less "clean" is definitely not what the SIMPLIFY author had in mind. All it does say is that if you can say it using wiki markup, that's preferable. Once you need to use HTML, use HTML. In this regard, it is better if Wikipedia actively avoids creating new rules and limitations over and beyond all those that years of HTML evolution has already created. Wikipedia may not "be" a browser, but you sure use one to access it!MOS:SIMPLIFY contains exactly one decree: "Obsolete elements and attributes should be updated or removed". Anything else is rightly left up to editor (and consensus) discretion. Take There are many templates that allow HTML markup to be used without putting it in articles directly for instance. For editors with zero HTML experience, this is useful information for sure. For editors with HTML experience, on the other hand, it is fortunate that this sentence is offering a solution, not telling us we must use it, since if you already know to do it in HTML, having to learn about Wiki templates whose function is only to "hide" HTML (while introducing a new programming hurdle that is arguably just as high to everyone except maybe Wiki grognards...!) would be a pain. So while saying "MOS:SIMPLIFY is prescriptive" is true, it actually has to prescribe something for it to be prescriptive in practice. (Still not sure whether we actually disagree; posting this mostly for clarity) CapnZapp (talk) 15:31, 26 February 2023 (UTC)
 * You are free to edit these pages to use whatever variant you feel represent best practices, but please don't think these pages are or should be prescriptive. I'm just trying to make the point Wikipedia should deviate from actual HTML as little as possible, and only when we have a damn good reason. What we specifically should not do is to attempt to "fix" the "broken" rules of HTML. The more HTML Wikipedia works with, the better. That is: the fewer special rules and exceptions (from how HTML works, not per a specification, but as actually implemented by major browsers, including all manners of lenience, legacy, and/or idiosyncrasy) an editor must remember, the better. To be clear; each and every time Wikipedia doesn't support something Chrome* can handle, we really ought to have a much better rationale than "Chrome really shouldn't accept this; it isn't how HTML is supposed to work." *) Or Internet Explorer, or Netscape Navigator, or Safari... take your pick. Regards, CapnZapp (talk) 10:16, 26 February 2023 (UTC)
 * Wikipedia isn"t a browser. And MOS:SIMPLIFY is prescriptive. On the other hand it is good that Wikipedia can handle much of the HTML thrown at it. Because people are going to use what they are familiar with. Most people are not familiar with HTML, and why make them be familiar with it when the MediaWiki software does not need much HTML in wikitext. We certainly shouldn't be encouraging people to use stuff like this:
 * --Timeshifter (talk) 11:45, 26 February 2023 (UTC)
 * It's not saying that. It's saying is that people shouldn't be admonished for using  instead of . Similarly, people shouldn't be admonished for using  instead of  - Wikipedia handles both just as well as each other, and so do all browsers. Neither form is more "correct" than the other. -- Red rose64 &#x1f339; (talk) 11:55, 26 February 2023 (UTC)
 * "Admonishing" is a harsh word. We are not saying that all the HTML versions don't work. We are only recommending the simplest version of HTML in help pages. Simplest for the average Wikipedia editor. MOS:SIMPLIFY. We acknowledge the other versions, and can even list some of them. But we recommend using the simplest version. I don't go around and change the other versions of HTML unless it is some paragraph I am actively editing for other reasons. But on help pages we need to recommend and use the simplest versions. It is a recommendation, not an admonishment. --Timeshifter (talk) 12:15, 26 February 2023 (UTC)
 * You appear to take two stances, one reasonable and one less so. (But I could be misinterpreting you) Using MOS:SIMPLIFY to argue help pages should offer the most user-friendly instructions is perfectly fine, and I actively encourage such work.Using MOS:SIMPLIFY to argue certain approaches to HTML coding should be discouraged/admonished/take your pick is actively misreading that part of the Manual of Style. It does not tell editors which HTML code to write. It certainly does not pick sides in nitpicking debates such as vs
 * You appear to take two stances, one reasonable and one less so. (But I could be misinterpreting you) Using MOS:SIMPLIFY to argue help pages should offer the most user-friendly instructions is perfectly fine, and I actively encourage such work.Using MOS:SIMPLIFY to argue certain approaches to HTML coding should be discouraged/admonished/take your pick is actively misreading that part of the Manual of Style. It does not tell editors which HTML code to write. It certainly does not pick sides in nitpicking debates such as vs

You wrote: "You keep pointing to 'keep it simple'.... but both variants are arguably equally simple to use and understand!"

For the vast majority of editors means adding a space and a slash to. So is not simpler. So help pages should recommend the simpler version for most people. Some, not all, HTML coders may think both are equally simple since they may no longer even think about it. They are not prohibited from using though I wish they would think about the average editor.

Same for and.

As I said before, and we apparently disagree, I believe the first sentence in MOS:SIMPLIFY "Other things being equal, keep markup simple" is also prescriptive. By itself. --Timeshifter (talk) 16:04, 26 February 2023 (UTC)
 * The thing is, some people take H:LINEBREAK and H:HTML as describing the only permitted forms, and actively alter all other forms (even if 100% working as intended) to match those pages. -- Red rose64 &#x1f339; (talk) 20:42, 26 February 2023 (UTC)
 * I personally don't have a problem with some wikignomes changing wikitext to the simpler (non-slash) forms. How is making things simpler for the average editor hurting anybody? Many HTML coders will continue using what their muscle memory tells them to use:
 * H:LINEBREAK and H:HTML doesn't say they are prescribing the only permitted forms. Maybe some blurb can be put at the top saying that variant forms with the slash are also accepted, though not recommended due to MOS:SIMPLIFY and the KISS Principle. I think a statement at the top of the page is much better than cluttering up that page with all the less-simple variants, and confusing average editors. --Timeshifter (talk) 22:44, 26 February 2023 (UTC)
 * SIMPLIFY is certainly not telling us to waste time squabbling over which exact syntax to use for our HTML. And more importantly, squabble over what exactly "simple HTML" would be. Therefore, Timeshifter, we have come full circle, and my farewell reply to you now is the same as when this section started: Please just accept that HTML is idiosyncratic and quirky. As long as Wikipedia accepts HTML, editors will use any legit HTML, and never admonish editors for using variants simply because they're not mentioned here. In other words, please stop trying to invent a special Wikipedia HTML dialect. No editing of this or other help pages change this fact. CapnZapp (talk) 21:24, 26 February 2023 (UTC)
 * Wikitext is its own special and simple coding. That is what it is famous for. I don't ever remember HTML being considered to be simple coding. I have edited basic webpages in HTML. Much, not all, of HTML is accepted in wikitext. As you said "editors will use any legit HTML". I am not stopping them. Nothing in the section here is stopping them. All it is doing is asking them to try to use the simplest version for the average editor. Not what is simplest for the much smaller subset of editors who are also HTML coders. --Timeshifter (talk) 22:32, 26 February 2023 (UTC)

Be mindful between asking and telling, is all I am saying. As Redrose stated, The thing is, some people take H:LINEBREAK and H:HTML as describing the only permitted forms, and actively alter all other forms. Please don't be those people, and please don't write help pages as if addressed to those people.

This discussion started because you didn't just say I changed the and soft hyphens section of Help:Line-break handling. You also justified those changes with MOS:SIMPLIFY: See:  in this section: Help:HTML in wikitext#Formatting. is not mentioned there. This made my alarm bell go off - could it be that Timeshifter is misreading our Manual of Style's instruction to keep markup simple to mean detailed instructions on what HTML to use and not to use? To that end, I explained to you that the MOS is not saying that is somehow wrong.

Again, if you made the edit because you want to recommend "simple" forms to beginners, that's fine. But if you made the edit because you think that is somehow wrong, or that our MOS discourages it, then you need to think again. Don't waste your time changing fully functional HTML, and most of all, don't tell editors they're writing the wrong HTML code - specifically: don't tell editors they're not writing HTML that isn't simple enough. Wiki markup is indeed its special code language, but when editors reach its limits and resort to HTML, the manual of style does not prescribe details. All it does, is make sure everybody agrees that when and if wiki markup is sufficient, use that in preference to using HTML. Do not interpret some forms of HTML as "simpler" than others - some sticklers for standards will inevitably misunderstand this to mean Wikipedia should only contained "well-formed" HTML. This obscures the greater goal - that Wikipedia does not ask coders to learn a special dialect of HTML for Wikipedia. If you need to use HTML, any HTML that's good enough for browsers is good enough for us. (With a well-defined set of exceptions)

Again, not saying you do any of this. Just making sure we're on the same page. Had you just made your edits, I probably wouldn't have responded. But with your justification I felt the need to set the record straight. Cheers. CapnZapp (talk) 14:09, 27 February 2023 (UTC)