Help talk:Line-break handling

This is the talk page for discussing improvements to the Line-break handling page.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Archives: 1: 12 months

	This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
Mid	This page has been rated as Mid-importance on the project's importance scale.

Shortcut

WT:NOWRAP

"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 Wikipedia:Redirects for discussion/Log/2022 November 21#Wikipedia:NOBR 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)[reply]

Let us ignore syntax highlighters that do not accept

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 Jonesey95 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)[reply]

@Timeshifter: 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 phab:, per WP:BUGS; another is found at Preferences → Gadgets → ^(S) Syntax highlighter: Alternative to the default coloring of wiki syntax in the edit box (works best in Firefox and works almost all of the time in Chrome and Opera), and for that gadget,   is a known issue, see mw:User:Remember the dot/Syntax highlighter#Parsing - feature requests for that may be left at User talk:Remember the dot, see mw:User:Remember the dot/Syntax highlighter#Reporting bugs. --Redrose64 🌹 (talk) 18:19, 8 December 2022 (UTC)[reply]

Thanks Redrose64 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)[reply]

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 <hr />, <img ... />, <link ... />,  and several others. --Redrose64 🌹 (talk) 00:02, 9 December 2022 (UTC)[reply]

Redrose64. 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 . 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)[reply]

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. --Redrose64 🌹 (talk) 23:07, 9 December 2022 (UTC)[reply]

I was mainly concerned about letting editors who also happen to be programmers see the futility of trying to get most Wikipedians to use . 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.

From looking at mw:User:Remember the dot/Syntax highlighter#Parsing 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)[reply]

You are still requesting this on the wrong page. Accordingly I have left a note at Wikipedia:Village pump (technical)#Syntax highlighter feature requests. --Redrose64 🌹 (talk) 19:59, 12 December 2022 (UTC)[reply]

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)[reply]

I changed the title of this talk section to make things clearer. --Timeshifter (talk) 20:31, 12 December 2022 (UTC)[reply]

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 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)[reply]

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)[reply]

Tim Starling (WMF dev/sysadmin) wrote " is valid wikitext" in February 2017. Any syntax highlighter which cannot handle should be removed from public view. Johnuniq (talk) 23:45, 12 December 2022 (UTC)[reply]

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 Wikipedia: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)[reply]

No one is punishing people for using , but we are acknowledging that or work better for some editors. I'm one of those editors. I use @Remember the dot'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).

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 is reasonable. I think that's what we have here now, and I don't see a need for change. SchreiberBike | ⌨ 20:15, 13 December 2022 (UTC)[reply]

is used in few pages. So it is not helping you much now with your preferred syntax highlighter.

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 it will have little effect on your use of the syntax highlighter. Because few people are going 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)[reply]

We aren't discussing the taste of individual Wiki editors, SchreiberBike, we are discussing its usage relative to editing software. If 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)[reply]

Framing it as correction is its own issue. :) It is not something to correct. Izno (talk) 17:42, 14 December 2022 (UTC)[reply]

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 (<references/>, <section/> 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 voidTags 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#Site defaults. 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)[reply]

Remember the dot. 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 and it helped. Until it hit this:

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)[reply]

Remember the dot: 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)[reply]

See MOS:SIMPLIFY (Wikipedia:Manual of Style#Keep markup simple): 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)[reply]

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)[reply]

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#Line breaks. 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)[reply]

See Special:Diff/1144939614. Redrose64 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:

User:Timeshifter/Sandbox190

When I look at the page source from my Firefox browser I see that the emitted HTML is   and not  

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)[reply]

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, this edit (by CJDOS) links to H:BR which I presume was being misread, because one perfectly-valid form was replaced by another perfectly-valid form. --Redrose64 🌹 (talk) 15:11, 16 March 2023 (UTC)[reply]

Redrose64

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:

 

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)[reply]

Hello; I can respond to the inquiry. Previously, H:BR read as favoring . 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. — CJDOS, Sheridan, OR (talk) 03:06, 17 March 2023 (UTC)[reply]

CJDOS. 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)[reply]

@CJDOS: 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. --Redrose64 🌹 (talk) 11:52, 17 March 2023 (UTC)[reply]

By the way, I like my outdents messy. :)

CJDOS, Redrose64. 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)[reply]

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)[reply]

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 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. House Blaster^talk 01:38, 16 April 2023 (UTC)[reply]

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)[reply]

wbr tag

MOS:SIMPLIFY: See:  in this section: Help:HTML in wikitext#Formatting. 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)[reply]

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)[reply]

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#Formatting.  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)[reply]

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. --Redrose64 🌹 (talk) 20:10, 25 February 2023 (UTC)[reply]

Wikipedia does not accept all HTML that browsers accept. --Timeshifter (talk) 22:05, 25 February 2023 (UTC)[reply]

Indeed; but that is controlled by the whitelist which gives permitted element names, not syntactical constructs. For example, <img /> is forbidden, not because of the slash but because the img element as a whole is not in the whitelist - for that reason, <img> is also forbidden. There are more than fifty elements defined in the HTML 5.2 spec which are not whitelisted. --Redrose64 🌹 (talk) 22:48, 25 February 2023 (UTC)[reply]

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:

Well, let's first ask another question: Which markup should we use for bold text? `'''Bold'''` `<b>Bold</b>` `<span style="font-weight:bold;">Bold</span>` I think we all know that the wikimarkup `'''Bold'''` is the recommended one. Mainly because it is simpler to use, especially for the majority of editors that don't know HTML and CSS.

The last 2 bolding methods should be actively discouraged. --Timeshifter (talk) 00:09, 26 February 2023 (UTC)[reply]

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)[reply]

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:

Bold

--Timeshifter (talk) 11:45, 26 February 2023 (UTC)[reply]

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. --Redrose64 🌹 (talk) 11:55, 26 February 2023 (UTC)[reply]

"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)[reply]

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 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)[reply]

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)[reply]

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. --Redrose64 🌹 (talk) 20:42, 26 February 2023 (UTC)[reply]

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: <hr />

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Addition of line breaks with standard transclusion

This help document doesn't address the addition of trailing and leading line breaks when transcluding page text using Standard section transclusion.

Per Help:Transclusion#Standard section transclusion: This method may sometimes introduce a leading or trailing line break or newline, depending on the markup in the source and target pages. To prevent this, wrap the code used for transclusion in a {{trim}} template.

I may be bold and add an excerpt of this to this help page to preventing line breaks in this specific case.

If someone can also clarify what is meant by depending on the markup in the source and target pages so that I can explain further on the Help:Transclusion page. waddie96 ★ (talk) 11:48, 5 November 2024 (UTC)[reply]

@Waddie96: It's basically similar to WP:NOINCLUDE, the part beginning "It is important to remember that the effect". --Redrose64 🌹 (talk) 13:59, 5 November 2024 (UTC)[reply]

"Wikipedia:NOBR" listed at Redirects for discussion

Let us ignore syntax highlighters that do not accept <br>

wbr tag

Addition of line breaks with standard transclusion