Help talk:Line-break handling/Archive 1

Archive 1

Some initial notes and ideas

Some months ago we created several new {{nowrap}} related templates and CSS classes, since we had problems to handle line wrapping here at Wikipedia. But now people seem very confused about which nowrap handling method to use when and how. So now I made this how-to guide to explain things. (I hope it will not confuse people even more?)

Since this page might also be read by beginners I added a section about "Causing line breaks", mainly as background information. I hope we can keep that section short.

My intention is that the section "Preventing and controlling word wraps" should be the main focus of this how-to guide.

Some other notes:

• Page names I have considered for this page: Wikipedia:Line break handling, Wikipedia:Word wrap handling, Wikipedia:Line wrap handling and Wikipedia:Nowrap handling.

• Some shortcuts I have considered for this page: WP:NOWRAP, WP:WRAP, WP:NOBR, WP:NBSP, WP:BR and WP:BREAK. (Shortcuts that were already taken are striked out.)

• WP:NBSP links to the very related text Wikipedia:Manual of Style (dates and numbers)#Non-breaking spaces. We should probably link from there to this page. Done.

• We should test the existing {{wbr}} template and if it works well perhaps write something about it here. Didn't work well.

--David Göthberg (talk) 21:07, 11 March 2008 (UTC)

As you pointed out above, the MOS has some stuff to say about spaces and line breaks. We should poke around and see if any other policies have sections concerning this, and be careful to make sure this guide conforms, linking back to those policies where appropriate. We can then link from those policies to here for more general information. On a semi-related note, I added a note to the disambig text at the top of WP:BREAK about this page, but it may be removed, so keep an eye out and feel free to start a talk page discussion there if it does. Other than that, I'll be proofreading the main policy page and making corrections and tweaks as necessary. One final note, could you post a full list of whitespace-related templates here on the talk page? That could help shape the text of the main page. —Dinoguy1000 23:26, 11 March 2008 (UTC)

1. Sure, you can look around for anything related in the policies and guidelines. But what I have seen so far about line wrap handling in the policies and guidelines have mostly been friendly technical advice similar to what this how-to guide contains. But note, this how-to guide isn't a policy or guideline, its a technical how-to guide.
2. Agreed, we should link both to and from any related guideline pages and other pages too. My original purpose of this page was to link to it from all the different nowrap templates.
3. Personally I don't like such shortcuts at all. But I added the WP:NOWRAP shortcut since I expected that people soon would create a shortcut anyway, and then I wanted the shortcut to at-least have a good name. So I have no opinion about the disambig link you made from the WP:BREAK page. (Although I like disambig links in general, they help me as a reader pretty often.)
4. Yes, the page needs proofreading and probably improvements of the explanations too. I bet for starters it has many language errors, after all I am not a native English speaker. The current page is just the first rough version.
5. Eh? "Post a full list of whitespace-related templates here on the talk page"? I guess you mean many of the templates in Category:Wikipedia formatting templates (and those that not yet have been moved there who are still in the old Category:Formatting templates). Yeah there might be more templates like the {{wbr}} lurking around, perhaps not being categorised at all.

--David Göthberg (talk) 04:03, 12 March 2008 (UTC)

Hmm... in that case, I suppose it isn't necessary to worry about it so much.

Heh, I don't see what you could have against the shortcuts, I personally find them quite useful.

Actually, you've done a pretty good job on it. There weren't all that many grammatical errors that I could find – mostly missing commas – but other than that, it was better than some contributions I've seen from native English speakers. One other major thig I did was getting rid of all the <nowiki/> tags, in favor of HTML entities ("&lt;" and "&#123;" for "<" and "{", respectively).

I suppose so... I was referring to the templates similar to {{nowrap}} or {{nowraplinks}}, though if most of them are in a single category, there's probably little point to listing them here...

—Dinoguy1000 17:49, 12 March 2008 (UTC)

Oh, thanks for the work over of the text! (I do have a spell checking add-on in my Firefox, so I am cheating. :) I saw you added some nice improvements, I especially liked the anchor links to the sections. And yeah, the "&lt;" are probably more robust than using the <nowiki> tags, but I tend to be lazy about that...

--David Göthberg (talk) 19:24, 12 March 2008 (UTC)

Hey, no problem... Most of the time, I use IE (not by choice, though), so I usually can't use a spellchecker.

Yeah, I picked up on the anchor links by looking at policy pages (specifically WP:CFD) and wondering how redirects could point directly to sections.

—Dinoguy1000 20:06, 12 March 2008 (UTC)

To-do ideas

• Add a "Test your page" section about testing the result by dragging the web browser window width, and using several browsers.
• Add a "Dots, bullets and dashes" section about {{·}}, {{ndash}} etc. About how to use them in both link lists and normal text.
• Add a "Style" section:
  • Stating things like that nowrapped sections should never be very long since that will break on small screens and handheld screens.
  • Show less controversial wrapping style examples, like that formulas and equations may be completely surrounded by {{nowrap begin}}+{{nowrap end}}, unless they are humongous... (Of course such formulas should really use TeX.

--David Göthberg (talk) 04:41, 13 March 2008 (UTC)

Nah, that would amount to instruction creep.

--David Göthberg (talk) 05:15, 13 March 2008 (UTC)

POV, pedagogy and links

I guess it is time for a rant:

Remember that this page is a learning tool. It will hopefully be read by a lot of beginner editors, most of which have no idea about the inner workings of templates and never heard of things like CSS classes. So try to keep things simple and only introduce complicated concepts after the simpler concepts. After all, most editors just need to know how and when to use the nowrap templates, they don't need to understand what makes them tick. (What makes them tick is described on their own doc pages under "Technical details" and should not be in this how-to guide.)

Avoid the "sea of blue" effect. As the Manual of Style puts it: "Make links only where they are relevant to the context: It is not useful and can be very distracting to mark all possible words as hyperlinks. Links should add to the user's experience; they should not detract from it by making the article harder to read."

Should this page be written in a neutral point of view (NPOV)? No, since this is not a Wikipedia article, it is a Wikipedia project namespace how-to guide. It should instead teach best practises. It should not teach things like "You can even use the incorrect <some code>". And yes, it is perfectly okay that this page is mostly based on original research and doesn't have references.

--David Göthberg (talk) 20:01, 13 March 2008 (UTC)

Simplified section links

Based on the code by User:Dinoguy1000: I added simplified id's to the rest of the section headers that have special characters in their names. So now it is much easier to link to those sections. (Can be good from other pages or talk pages.) Here is a complete list of links to the sections:

• WP:NOWRAP#Causing line breaks
• WP:NOWRAP#Preventing and controlling word wraps
  • WP:NOWRAP#nbsp
  • WP:NOWRAP#nowrap
  • WP:NOWRAP#nowraplinks
    • WP:NOWRAP#Nowraplinks shortcomings
  • WP:NOWRAP#nowrap begin
  • WP:NOWRAP#nobr
• WP:NOWRAP#See also

--David Göthberg (talk) 02:47, 14 March 2008 (UTC)

Firefox bug

Ouch, I just discovered that the Firefox "expanding out of the box" bug doesn't only apply to {{nowraplinks}}. It applies to any span-nowrap tag, such as the one used in {{nowrap}}. That is, any span-nowrap tag that is immediately followed by text without any spaces between. And it doesn't matter if there is a link inside the span-nowrap tag or just normal text. Here is a code example:

{| class="wikitable"
| 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
{{nowrap|[[Salt|some link]]}}SomeText 
| 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
{{nowrap|some text}}SomeText 
|}

And here is how it renders. If you have Firefox, try dragging your web browser window so it gets smaller and smaller and see how the text in both cells will overflow:

some linkSomeText some linkSomeText some linkSomeText some linkSomeText

some textSomeText some textSomeText some textSomeText some textSomeText

This also happens if you put two {{nowrap|something}}{{nowrap|something}} next to each other without any space between them.

If you use spaces between the nowrap protected text and the normal text, then if doesn't overflow. Like this:

some link SomeText some link SomeText some link SomeText some link SomeText

some text SomeText some text SomeText some text SomeText some text SomeText

You can also use {{nowrap begin}} + {{wrap}} + {{nowrap end}}, but that also causes a space at the {{wrap}}. Perhaps that is why {{nowrap begin}} doesn't overflow in Firefox?

--David Göthberg (talk) 11:03, 22 March 2008 (UTC)

Note that when it comes to this bug then a non-breaking space   counts as a "normal" character, not as a space. That is, the bug also occurs if you use non-breaking spaces. Like this:

{| class="wikitable"
| 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
{{nowrap|[[Salt|some link]]}} SomeText 
| 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
{{nowrap|some text}} SomeText 
|}

This too will overflow in Firefox:

some link SomeText some link SomeText some link SomeText some link SomeText

some text SomeText some text SomeText some text SomeText some text SomeText

--David Göthberg (talk) 05:59, 10 April 2008 (UTC)

I found a discussion between Sardanaphalus and Psantora regarding this bug at the talk page of Psantora. Here is a copy of my explanation from there:

I stumbled over your discussion here. As perhaps both of you know this "expanding out of the box" bug is a Firefox bug. So first of all you need to use Firefox to see it. Since we talked before I have learnt more about it and written down parts of it here: Wikipedia talk:Line break handling#Firefox bug. And yes, {{·}} actually does provoke the bug. However, the width of the text you add after each nowrapped string matters. And since {{·}} is fairly narrow (only one non-breaking space and a dot) it only shows the bug a little. That is, the dots usually do not flow outside the box, they just touch the box border. So if that should be considered a problem or not is a matter of taste. Personally I usually don't convert lists to use {{nowrap begin}}+{{·w}}+{{nowrap end}} that only has that minor problem, but I also do not convert lists back to {{·}} just to get the simpler {{·}} code, since {{nowrap begin}} etc renders better.

The bug only becomes a serious problem when one has nowrap protected strings followed or surrounded by several other characters. Like for instance nowraplinks protected links with text around it, like this: [[Some link]] (2008){{·}} or "[[Some link]]"{{·}}. Those two texts have 9 and 4 characters respectively outside the link before the real space. That's enough many characters to expand outside the box and become a real problem.

--David Göthberg (talk) 05:48, 10 April 2008 (UTC)

Thanks as ever for your input, David. I hadn't clocked that ultimately the problem is a bug in Firefox. I don't know whether or not the Firefox developers are aware of it and planning to address it, but if so, that'd be good news as I agree {{·}} would be preferable. I hardly know anything about the world of software development, so I'd be grateful if either of you could point me toward what looks the most appropriate place to make enquiries; there seem to be various possibilities (forums, webpages, perhaps even irc?). Thanks. Sardanaphalus (talk) 14:27, 10 April 2008 (UTC)

I assume you mean you want to report the bug to the Firefox developers? I have been thinking of doing that for some time too. So I took a quick look over at bugzilla.mozilla.org and searched for "nowrap", it turned up at least two bug reports that clearly is the exact same bug:

• Bug report 225946
• Bug report 278891

And there are several other "nowrap" bug reports that seem related. I am going to get myself an account over there so I can write comments at those bug reports telling them those two bugs are the same bug. And also link back here to Wikipedia:Line break handling and it's talk page.

But even if the next version of Firefox is fixed we still have to handle the bug for the next two years or so. And we have the problems with wrapping in several Internet Explorer versions which means we need to use {{nowrap begin}} etc in many places anyway.

By the way, I will copy parts of this discussion to Wikipedia talk:Line break handling#Firefox bug.

--David Göthberg (talk) 15:28, 10 April 2008 (UTC)

Okay, I have reported the bug at bugzilla.mozilla.org. But ouch! The bug was first reported to the Firefox devs at bugzilla.mozilla.org in 2001, then again in 2003 and 2005. But those reports were really bad and confused. (I didn't make a new report, instead I wrote a little at the existing bug reports. But I should probably add a better explanation.) I guess we might have to wait several years before they fix it...

--David Göthberg (talk) 17:10, 10 April 2008 (UTC)

The current proposal for ,, as markup for the hard space

Editors may be interested in this new section at WT:MOS, where I propose this talkpage for continued discussion of the proposal that we use ,, as markup for the hard space. Here is the current text of the proposal, as recently modified following discussion at WT:MOS:

Myself, I'll be taking no further part in this in the foreseeable future. But I do hope that other editors will continue their good work on it, and that new editors will join in the effort.

–_⊥^{¡ɐɔıʇǝo}Noetica!^T– 11:41, 27 March 2008 (UTC)

(Is this where we are supposed to comment?) I am very happy with this proposal. Thanks for the good work, it looks as if you got all the details right. --Hans Adler (talk) 12:58, 27 March 2008 (UTC)

So what's going on with this? —Random832 (contribs) 17:06, 28 March 2008 (UTC)

We are resuming discussion on the proposal after a long interruption, using this page as a venue. The proposal is quite self-explaining; is there any further information that you require? I should be glad to help if I can do so. Waltham, The Duke of 19:17, 28 March 2008 (UTC)

I've read through the proposal a couple of times now, and I've gotta say, it's pretty solid, straightforward, and simple, and I'd really like to see it implemented. —Dinoguy1000 20:04, 28 March 2008 (UTC)

• Yes, I agree – these missing "hard space"s between numbers and abbreviations are something I've become more and more aware of recently. It would also provide an alternative to the {{ndash}} template I've used in this comment. If folk have got used to seeing double/triple primes for italics and bold, I reckon they can adapt to double commas. Thanks to any/all for drawing up the proposal. Sardanaphalus (talk) 12:28, 30 March 2008 (UTC)

If you pull up the source in your browser on "X !", you'll see that the Mediawiki software just inserted an invisible no-break space character. I'm wondering if it would serve our purposes well to get permission for a style bot that wanders around and inserts the same no-break space characters in places where they are almost certain to be an improvement, such as in "p. 1" and "8 sq ft". That might change the argument to make it easier to win, from "Please grant us this special software for this new purpose that people haven't cared about much before" to "Please insert the double-comma in place of the current no-break space character, so that we don't get invisible no-break spaces building up over time in the text, as a result of people not realizing that there was a special character there that needed deleting." WP:STYLE1.0 is a good place to talk about style-standardization bots. - Dan Dank55 (talk) 20:18, 30 March 2008 (UTC)

I think that strategy would be a violation of Wikipedia:Do not disrupt Wikipedia to illustrate a point.

By the way, I checked, there was an invisible space between the "X" and the "!" in the rendered wiki page. How did you make it so that happened? Or why did it happen? But when I added this text and previewed it disappeared and instead the quotes changed to ". But when I saved the text the invisible space was back. (Previous sentence added later.) Weird.

--David Göthberg (talk) 22:57, 30 March 2008 (UTC)

No, running a style-standardization bot without wide consensus from the wikiprojects, or without going through the WP:BOT approval process, would be disruptive; I'm not proposing that we skip any of the required steps. And, if everyone is largely in agreement where the hard spaces should go, it doesn't disrupt Wikipedia to insert them. My point is that, when we go to bugzilla to ask for new markup, it would be a very good idea for the no-break spaces that need replacing with ",," already to be in wide use, to prove the need for the new markup.

The special case of no-break spaces in "X !" and "X ?" was done for the French Wikipedia people, since ! and ? often require a leading space in French, and they didn't want it to wrap. It serves as evidence that the Mediawiki people are willing to write rules for automatic insertion of no-break spaces. - Dan Dank55 (talk) 23:41, 30 March 2008 (UTC)

P.S. And, while there's no particular need to use WP:STYLE1.0 for help with the no-break spaces issue, I have in fact covered two of the required steps already, if you want to take advantage. I've already been to WP:VPP to get approval to gather consensus on style-standardization bots (see discussion at the top of WT:STYLE1.0 if you like), and I've already been to the Wikiproject Council, and they now have a noticeboard available, which they believe is a good, non-spammy way to widely notify wikiprojects about matters of general interest. - Dan Dank55 (talk) 23:50, 30 March 2008 (UTC)

The proposal looks really good. Just one question (please give a link if it has already been answered): have you searched through the WP article database to see if there are any existing uses of ,, that would be affected? Doesn't seem likely, but life is full of surprises... If there are a few cases, that doesn't mean the proposal is wrong, but that the existing ,, would need to be escaped with < nowiki >. --Itub (talk) 16:44, 1 April 2008 (UTC)

That step was taken months ago, and yielded absolutely nothing—not even the proposal's own discussion page. And I have just checked again. I fear that this is beyond the capabilities of Wikipedia's search engine. Waltham, The Duke of 17:16, 1 April 2008 (UTC)

One possible case is programming languages in which you can skip optimal parameters in a function: function(a,b,c,,,f). But it's better style to use spaces after the commas anyway. Of course that's extremely rare, and probably not worth worrying about. --Hans Adler (talk) 19:00, 1 April 2008 (UTC)

That should be a moot point anyways, as I can't think of any situation in which code wouldn't be surrounded by a <source/>, <code/>, or <pre/> tag, except maybe for the occasional one-line snippet. And even in those cases, it's easy enough to just use <nowiki/> or {{nowiki}}. —Dinoguy1000 17:02, 2 April 2008 (UTC)

The vast majority of search engines don't add punctuation characters to their index. Therefore you won't find anything using Wikipedia search or Google. One way to make sure is to take the complete database dump and do a full substring search on it (it could be done using database software or a tool such as grep). --Itub (talk) 08:18, 2 April 2008 (UTC)

If anyone here would do that, a lot of people would be grateful.

In the meanwhile, I shall ponder the propriety of the usage of the word dump for the entirety of Wikipedia's content. :-D Waltham, The Duke of 02:34, 3 April 2008 (UTC)

:) - Dan Dank55 (talk) 03:39, 3 April 2008 (UTC)

• I'd like to emphasise the importance of this proposal. Its significance, in fact, goes beyong the immediate improvement in MediaWiki's functionality—if we can get something moving here, it will foreshadow more changes to the system, which are much needed after years of relative stasis. TONY (talk) 14:04, 5 April 2008 (UTC)

As a first step, what do you guys think of increasing the number of no-break spaces currently in Wikipedia, before we get the double-commas? I think it's a necessary step. I don't think a "good argument" for why Wikipedia articles should have a lot more no-break spaces (no matter what the markup) is good enough at WP:VPP or bugzilla; they need to see that it has been done already, and that it had wide acceptance. Obviously this could be tedious, but a limited-scope bot (with approval from WP:BOT of course) might help. By hand or by bot, one good place to start sticking no-break spaces in would be in current and recently passed and failed GAN articles, since editors of those articles just recently volunteered their articles to MoS scrutiny ... it would deflect any potential criticism that we're a bunch of marauding wikignomes, inserting new punctuation without being asked. Before we get the double-comma, I would think the invisible no-break space (the one auto-inserted in "X !") would be the least likely to raise a fuss; the fact that it's not great for long-term use because it could build up invisibly in text would give us a great argument for why ",," would be better. Thoughts? - Dan Dank55 (talk) 19:35, 5 April 2008 (UTC)

Bugzilla request for no-break spaces, copied from WT:MoS: "See Bugzilla:13619 for a proposal to add non-breaking spaces automatically. — Omegatron 02:40, 9 April 2008 (UTC)"

- Dan Dank55 (talk) 03:03, 9 April 2008 (UTC)

That doesn't seem to have gone far, does it? Waltham, The Duke of 19:25, 16 April 2008 (UTC)

I don't draw any conclusion from that; nothing in WT:MoS is going far. I'm either talking to myself or answering help questions. I must say, it's much nicer hearing the birds chirp than the usual elephant stampede, but I'm getting a bit lonely. - Dan (talk) 20:06, 16 April 2008 (UTC)

Horizontal scrolling trick for long words

I wonder if we should suggest this as a general solution, or not. Here's an example of <div style="overflow:auto"> in practice:

Lopadotemachoselachogaleokranioleipsanodrimhypotrimmatosilphioparaomelitokatakechymenokichlepikossyphophattoperisteralektryonoptekephalliokigklopeleiolagoiosiraiobaphetraganopterygon

It's not elegant, but it gets past the problem of no soft hyphens in MediaWiki. The hard-coding of line breaks is possible, but will have little relationship to the text and browser window size in use by a reader. Note that in such articles only the body text can be given this treatment; the article title will still run off the right margin. --Dhartung | Talk 00:32, 8 April 2008 (UTC)

Unfortunately the "overflow:auto" markup seriously breaks the entire page in older web browsers. That is, in my older web browsers every paragraph on this page now becomes as wide as your "Lopadote" word. I now have to scroll sideways a lot to read each paragraph on this page, making this page pretty unreadable in older browsers.

So I find it better to manually line break such words down to a width below 800x600 pixels. That means in newer browsers (and I hope on the handhelds too since they are new) if they run in less resolution than that only that word will stick out to the right and the user has to use the window scroll bar to read that word. While on the older browsers the page will look okay at any resolution from 800x600 and up. And it will also be better for the old browsers even at lower resolutions such as 640x480, since then all the paragraphs on the page will "only" be 800 wide instead of say 2000 wide.

For users with newer browsers I don't see much difference in using the window scroll bar or the scroll bar next to the word. But for the users with older browsers this pretty much makes the difference between being able to read the page or not.

And by the way, from what I remember last time I tested: It is not MediaWiki who removes the soft hyphens. You can add Unicode soft hyphens and they do get rendered in the XHTML output from MediaWiki, just that even some modern web browsers do not understand them correctly. Some render them as visible spaces, some as visible hyphens, and several don't line wrap at them. So we can not use them.

So sorry. I think we have to stick to manually line wrapping long words such as URLs.

--David Göthberg (talk) 11:33, 8 April 2008 (UTC)

Is there a guideline about what browsers we try to support? Just curious. --Dhartung | Talk 06:18, 10 April 2008 (UTC)

He, good question. I haven't seen any such guideline apart from Wikipedia:Accessibility. But as far as I have understood people here at Wikipedia want to support "all" browsers, even handhelds and screen readers for the blind and so on. (Some of my friends actually read Wikipedia from their mobile phones.) And people often mention that third world users probably often use old computers who can not run the more modern web browsers. (That is, they can not run newer Internet Explorers. They could run Firefox...)

Personally I test in the three browsers I have installed: Internet Explorer 5.5, Firefox 2.0 and Opera 9.02. If it works in all three of them then usually it works in most other browsers too. That IE 5.5 from 2001 is the last IE version that works on my Swedish WinME as far as I know. Yes, some people are still using computers that can not run WinXP but that runs Win98 and WinME fine.

By the way, you are right about that this how-to guide probably should contain some kind of recommendation or discussion about how to handle really long words such as URLs.

--David Göthberg (talk) 07:11, 10 April 2008 (UTC)

Oh, that word fits perfectly on my widescreen browser. —MC10 (T•C•GB•L•EM) 22:21, 11 August 2009 (UTC)

In-line equations

I'm not sure that this is the right place to pose this question, but here it is! :)
I was editing a page because a simple in-line equation (1 ⁄ e) was breaking. At first I tried <nobr>, then I found my way here and opted for &nbsp;. (Nice editing, by the way, to whomever came up with the section in a nutshell banner!)
The thing is, while I was trying out different things I changed the back-slash to a division symbol, using the Math and logic section of the editor. When you click on the symbol it inserts the character into your wiki mark-up, but it is subsequently transposed into a back-slash, rendering the click here to insert math symbol functionality useless (as all keyboards have a back-slash key).
Anyway, what I was wondering is, if WP must replace ÷ with /, shouldn't it replace 1 ÷ ''e'' with 1 / ''e'' ?
nagualdesign (talk) 01:31, 15 September 2010 (UTC)

Question on coding

Is there any difference between <br> and <br/>? I've seen both used, and I've even seen editors fight over which one is correct. I've always been of the assumption that they basically the same and I often use the former to eliminated needless code space. Is there an actual preferred version?  BIGNOLE  (Contact me) 12:13, 24 October 2009 (UTC)

Short answer: Both work fine, but just like you I prefer the shorter and easier to type <br> tag.

Long answer: Ah, excellent question. It comes up every now and then at different places. I have a standard text I use to respond to that, my apologies for the perhaps slightly hard tone in it:

Well, <br> is the correct "HTML wikimarkup". But MediaWiki was updated to also understand <br /> some years ago so that it would be easier to copy and paste text from other free sources without having to modify each br tag in those texts.

Remember that wikimarkup should be as easy as possible so that normal people (non-webmasters) can edit Wikipedia. Wikipedia then parses and converts the wikimarkup to whatever is the current standard for web page rendering. And today (2009) that happens to be XHTML 1.0 Transitional. Tomorrow it might be something totally different, like PDF. Oh wait, we already do render to PDF for those that want that!

And note that the very similar <br \>, <br\>, </br>, </ br>, <\br> and <\ br> all are faulty variants. And the variant <br/> (without space) is not a recommended variant of the <br /> tag, according to the World Wide Web Consortium (W3C), since it breaks older web browsers.

So I suggest we stick to the simple wikimarkup <br> tag and not change all our 18 million pages every time the web standards change.

By the way, the "HTML tidy" function in MediaWiki's page rendering does fix some of the other faulty ways to write the br tag when it renders a page, that's why you get away with some variants like <br \>.

In April 2009 Brion Vibber, lead developer of MediaWiki, said:

In my experience XHTML 1.1 and later are a dead end; HTML 5 is where all the action is in browser support development.

There’s also no particular advantage for the “strict” DTD variants; good clean code can be written with or without it, but the “strict” deprecations are often arbitrary and require jumping through more hoops to replicate simple features.

So in a not too distant future the MediaWiki page renderer might be converting <br /> in wiki code to <br> in the rendered pages. Again, wikimarkup is not the same thing as rendered page code.

--David Göthberg (talk) 16:09, 24 October 2009 (UTC)

LOL, awesome. I'll have to save this explanation if I ever have to defend it in the future. Thanks.  BIGNOLE  (Contact me) 18:00, 24 October 2009 (UTC)

Question: if, as I understand from the above, <br> is the preferred format, why does the edit toolbar give <br />? PC78 (talk) 12:21, 6 August 2010 (UTC)

We currently output XHTML, where the newline tag is <br />. We also enable HTML Tidy which will convert <br>, </br>, <br/> and the like to a proper <br />. This is not done on editnotice pages and MediaWiki interface pages, where <br> will cause problems. The use of invalid XHTML also cause problems when an article is ported to a wiki that does not use the HTML Tidy option. ---— Gadget850 (Ed) ^talk 17:21, 30 December 2010 (UTC)

Line-breaking spaces

There's plenty of information on WP about non-breaking spaces and how to render them, but I couldn't find anything about the converse: I helped to write Template:Etymology, and noticed today that the first 2 or 3 words of an etymology weren't wrapping at line-breaks. After a little detective work I realized that I'd used non-breaking spaces (&nbsp's) in the mark-up in order that the spaces weren't ignored as whitespace, but they shouldn't really be non-breaking. So I ended up changing &nbsp's to &emsp's, then to &ensp's and finally to &#32's. The last one was a guess! As far as I can tell, they're the only line-breaking equivalent of &nbsp's - &emsp's and &ensp's are both too thick - but I don't know how &#32's render on different browsers.
Please could someone include something in this article about the use of &#32's?
Thank you in advance. Regards, nagualdesign (talk) 01:50, 10 March 2011 (UTC)

I also recently made use of a non-breaking hyphen (‑) in an Arabic-English transliteration, as‑simt, as I thought it looked wrong when wrapped. Are there any guidelines for this?

I realize these suggestions may represent instruction creep, but I always feel a bit naughty when I find my own solutions. Some sort of instruction would be reassuring.

nagualdesign (talk) 02:43, 12 March 2011 (UTC)

Soft hyphens and zero-width spaces?

First, is there a written policy of no soft hyphens in Wikipedia? Please provide a short explanation of the reason, and link to the policy from this article. Second, is the zero-width space (&#8203;) allowed? I've found it useful. --Traal (talk) 01:24, 2 November 2012 (UTC)

Wiki markup formatting

[Line breaks in the wiki source (not reader visible, just for editors)]

Since a question about line break tags in source was mentioned above it doesn't seem too off-topic to ask if there is any sort of formatting guideline for editors when writing wiki source? I find large blocks of wiki-markup and citations hard to read unless they contain spaces and line breaks. The citation templates for include examples with lots of line breaks in the wiki markup, and others with just a few spaces between parameters. The readability of markup is important because when editing I will try to improve citations by remove extra junk from URLs, or filling in citations with extra details such as author or date that others may not have filled in.

I'm hoping there are existing guidelines, expecting other editors to politely not strip spaces and line breaks out of articles doesn't work. It seems only polite to at least try and abide by the formatting of previous editors. Some editors even try to explain their stripping of line breaks by suggesting there is a "shortage of space", and are probably not aware about the compression used when web pages are sent by webservers (compression that makes it especially pointless to worry about spaces and line breaks). If the built in Wikipedia editor and diff tool were better it might help, but removing the line breaks also makes it difficult to check diff between revisions.

All I'm really asking that in an article that is not stable, and has not even reached the level of good article (GA) there will still be people working on it and to avoid wholesale stripping of indentation, spaces and line breaks. (On an article that is more stable and well written and citations mostly properly filled out already I don't mind so much about line breaks being removed.) I hope there is already a guideline I can point to next time an editor thinks it is appropriate to strip out all the line breaks. -- 109.77.175.76 (talk) 04:09, 12 January 2013 (UTC)

I have read the essay Wikipedia:Don't use line breaks. It seems to be a good faith reason why some editors feel so strongly about stripping line breaks, but it doesn't seem to be entirely applicable, and maybe the editors I've encountered are just overdoing it a bit. To be clear I'm not talking about mid-sentence line breaks (like a programmer might use to avoid using more than a certain number of characters per line) I'm talking about things like formatting citations with line breaks (sometimes) and (more often) subdividing a the big blocks of wikimarkup in a paragraphs with an occasional line break in the markup (say between two experts, each having a few sentences and references on the same topic). -- 109.77.175.76 (talk) 04:26, 12 January 2013 (UTC)

As to citations: This is usually referred to as vertical or horizontal format. See Template:Cite web#Usage for an example. Discussions at WP:CITEVAR have consensus that it applies to underlying technical styles such as this. As to your other issues, some examples would be helpful. --— Gadget850 (Ed) ^talk 12:14, 12 January 2013 (UTC)

I am familiar with and understand the examples (I prefer the vertical format). What I don't see is any explanations about when vertical or horizontal should be used, it seems to be personal preference only. There isn't even any kind of polite note telling editors not to go arbitrarily changing from one format to the other, but I think I may have seen a guideline somewhere that asked editors to follow the style already set on articles? As you say Cite:VAR covers changing from one citation style to another, I suppose that might cover switching from horizontal to vertical too. (Some editors set a very low standard for what they claim is "consistent", which is really annoying when you try to tidy an article in good faith and fill in missing citation parameters.)

I'll try to find appropriate examples of the indentation stripping I'm talking about, but I want to avoid using the most recent cases that have bothered me because I'm trying to get a general answer, a policy I can deal with one way or the other, not just a moderators deciding on a case by case basis. -- 109.77.175.76 (talk) —Preceding undated comment added 17:27, 12 January 2013 (UTC)

The guideline is WP:CITEVAR. --— Gadget850 (Ed) ^talk 17:34, 12 January 2013 (UTC)

Rereading it, that guideline seems close enough. Maybe not enough. Will try that for now. Thanks anyway. -- 109.77.175.76 (talk) 17:41, 12 January 2013 (UTC)

What is the preferred format for break tags ?

Hi,

On Wikipedia talk:WPCleaner, different users are giving a different opinion on what syntax should be used to replace an incorrect break tag (</br>, <br/> and <br.>, ...). Should I use <br> or <br /> ? Both are correct in HTML5, only the second one is correct in XHTML but MediaWiki doesn't try to enforce XHTML anymore. By default, my preference would go to <br />, because I find it cleaner. --NicoV ^{(Talk on frwiki)} 13:05, 3 July 2013 (UTC)

This is probably best discussed in one place. I'll comment at Wikipedia talk:WPCleaner#.3Cbr.3E tag --Redrose64 (talk) 14:20, 3 July 2013 (UTC)

wbr

<wbr> will be allowed with MediaWiki 1.22/wmf13.[1] --  Gadget850 ^talk 07:22, 17 August 2013 (UTC)

Line breaks, October 2013

I'm not sure that this change is appropriate. First some background:

1. I had changed some instances of <br> into <br/> in an article I was editing, User:Woodstone noticed and queried the merits of this change. Details at User talk:Mitch Ames#Line break. In summary, I changed them to keep this syntax highlighting tool happy, per that tool's documentation.
2. I suggested to the author of the syntax highlighter tool, at User talk:Remember the dot#Line breaks and slashes, that the tool's documentation should be updated to include the space before the slash.
3. Remember_the_dot then updated WP:LINEBREAK.

Note that I am not an expert in HTML/XTML or variations thereof, so I make no assertions about what the "correct" syntax is or should be. However, looking at the new version of WP:LINEBREAK

• Should the section heading include the space? If HTML Tidy adds the space, then presumably that space is more "correct".
• The statement that "On most wiki pages, HTML Tidy automatically converts..." is perhaps inaccurate - in particular the term "wiki", which encompasses more than Wikipedia, the Wikimedia Foundation sites collectively, and even the MediaWiki software. We might be able to say that "On most Wikimedia Foundation sites, HTML Tidy ...", but anything more general than that is questionable.
• "Sloppiness" - can we be a little more specific (and perhaps a little less disparaging)? Exactly what should the editor use on those pages that HTML Tidy does not work on?

Mitch Ames (talk) 09:26, 27 October 2013 (UTC)

• XHTML permits both <br/> and <br />. Which one you use is a matter of personal preference. There is no technical advantage to <br /> over <br/>.
• As far as I know, all Wikimedia Foundation sites use HTML Tidy.
• The previous revision said that "HTML Tidy...can cause invalid HTML and problems rendering the page." This was poorly worded, which is why I clarified that sloppiness can cause problems. By sloppiness I meant invalid XHTML, which ruins the ability of an XML parser to process the page.

If you feel strongly that <br /> is better than <br/> then feel free to change this page to reflect that, and feel free to make any other changes that make the page's meaning more clear. I'm pretty open about it. —Remember the dot ^(talk) 21:28, 27 October 2013 (UTC)

Technically both <br/> and <br /> are correct XHTML, but there used to be browsers that did not accept <br/> (if I remember well Microsofts IE). If you inspect the output of WP, you will notice that it always has <br>, as that is correct HTML. Therefore there is no advantage in changing existing <br> into <br />. It makes the edit box less human friendly for the vast majority of editors that do not use syntax highlighting. −Woodstone (talk) 12:15, 28 October 2013 (UTC)

• Wikipedia now renders HTML5. In HTML5, the break tag is a void element- that means that there is only a start tag and no close.[2] Void tags may optionally include a space and optionally include a slash. Thus, <br>, <br/> and <br /> are valid HTML5.[3]
• In XHTML, these are called empty tags and must be terminated with a slash.[4] Thus only <br /> is valid.
• HTML Tidy is used to clean up HTML errors. As noted, it is not enabled for some namespaces and it actually introduces problems at times. Tidy currently renders all variants of the break tag as <br />.
• We must also remember that articles are ported to other sites, and that the wmf versions of MediaWiki that we currently use are not available outside the WMF projects, thus other wikis still render XHTML. HTML Tidy is an option that may not be enabled on those wikis.
• That leaves the question of which tag is best documented... --  Gadget850 ^talk 15:05, 28 October 2013 (UTC)

(edit conflict) I reverted the edit, because rather than clarifying things, it seemed to muddy them; it also put undue emphasis on the XHTML forms.

• The <br> tag was the only valid form up to and including HTML 3.2
• HTML 4.0 documented the <br> form, and also permitted the <br /> form for compatibility with XML parsers; in XML, the space is optional
• XHTML 1.0 permitted only the <br /> form - the XHTML documentation is inconsistent as to whether the space is optional or mandatory
• HTML5 has the same rules as HTML 4.0, and so both <br> and <br /> are equally valid HTML5

Wikipedia serves HTML5, and has done so for over a year now. Changing <br> to <br /> (or vice versa) is unnecessary; changing <br/> to <br /> (or vice versa) is pretty much pointless. However, changing invalid forms such as </br> or <br\> to either of the valid forms should be performed wherever the invalid forms are found. --Redrose64 (talk) 15:11, 28 October 2013 (UTC)

Woodstone:

• The browsers that did require the space fell into disuse about a decade ago. If I remember correctly, Netscape was the problematic one.
• Wikipedia outputs <br />, not <br> -- see all the discussion about HTML Tidy.

Redrose64:

• The page is now back to saying that HTML Tidy can cause invalid HTML and problems rendering the page. At minimum this error should be corrected. The page also no longer makes clear that <br/> or <br /> must be used in the MediaWiki namespace (and everywhere on wikis without HTML Tidy) or XML parsers will break.
• The XHTML standard is clear that the space is optional. The section you cited states "This appendix is informative" (in other words, not a requirement). You are also correct that the space is optional in HTML5.
• As noted at the beginning of this section, the syntax highlighter gadget maximizes performance by only recognizing the closed form. You can argue that the highlighter should take the performance penalty and check every tag against a list of void tags, however, the performance is bad enough as it is and I am not inclined to change this behavior.

At the end of the day, my opinion is that the closed form <br/> or <br /> should always be preferred, but I recognize that others feel differently and I'm willing to just leave this page alone. —Remember the dot ^(talk) 17:35, 28 October 2013 (UTC)

Why should it make it clear that "<br/> or <br /> must be used in the MediaWiki namespace (and everywhere on wikis without HTML Tidy)"? Wikipedia does not serve XML - it serves HTML5 (you can tell by the <!DOCTYPE html> before the <html> when viewing the page source): the space and the slash are therefore both optional. HTML permits a certain amount of "sloppiness" that XHTML does not - this is not just <br> and other empty elements with no slash, but also unclosed non-empty elements including (but not limited to) <colgroup> <dd> <dt> <li> <option> <p> <td> <tfoot> <th> <thead> <tr>. HTML Tidy adds in any missing closing tags for these elements, not to make valid HTML, but to make valid XHTML. But the need for HTML Tidy is reduced since we switched away from XHTML.

As the WMF Staff are so fond of telling us at WP:VPT, when there is an incompatibility between the standard Wikipedia interface and a user-written gadget, it's the gadget that should be fixed. Adjusting the Wiki markup on a page purely so that a syntax highlighter behaves in a different manner, and which has no noticeable effect on the rendered page, might be seen as disruptive. --Redrose64 (talk) 20:29, 28 October 2013 (UTC)

It's a lot easier to find an XML parser than it is an HTML5 parser, which is why Wikipedia serves HTML5 that is also valid XML. If we insert malformed XML into a MediaWiki page then we make it a lot more difficult and less efficient to do web scraping. Yes, I know that web scraping is a somewhat ugly business anyway, however it's sometimes the only way to implement a specialized tool.

Your other question is really just the question of whether having a syntax highlighter gadget that performs well is worth letting its users change <br> to <br/>. That's a matter of opinion, there's no way for me to convince you. —Remember the dot ^(talk) 00:05, 29 October 2013 (UTC)

Another interesting point I just noticed at Wikipedia talk:WPCleaner#.3Cbr.3E_tag: <br /> is consistent with MediaWiki extensions such as <references />. —Remember the dot ^(talk) 03:27, 29 October 2013 (UTC)

But not really relevant. <references /> is an extension tag- early in extension development someone decided to use markup that mimicked XHTML, but it is not HTML.

As noted, both <br> and <br /> are equally valid, and converting from one form to the other is generally a meaningless edit, except for consistency on a particular page. --  Gadget850 ^talk 10:50, 29 October 2013 (UTC)

Okay, to summarize, the advantages of the closed form are:

• If editing MediaWiki pages or on a wiki without HTML Tidy, it makes sure XML parsers continue to work
• It's consistent with the ref and references tags
• It's consistent with the edit toolbar
• It allows the syntax highlighter gadget to perform quickly

The advantages of the open form are:

• It's more recognizable to people who are accustomed to writing HTML5 code and don't care about XML parsers

If we're going to pick a preferred form, I think the choice is clear. At minimum though, I wouldn't get mad at people who convert the open form to the closed form for one of the above reasons. —Remember the dot ^(talk) 18:50, 29 October 2013 (UTC)

Page break

I had made a page desine in html with lots of new text heading and content in it, my query is- i want to break text and move to next page in ipad. can I give page text command in span? because if I am giving this command to para in mid, the line breaks and the remaining text start from new line. Is there any query for it. — Preceding unsigned comment added by 115.111.50.254 (talk) 11:01, 11 September 2014 (UTC)

Edit code

How would I edit the Wikimedia code to respect single line breaks everywhere, instead of just in the poem tag? Techni (talk) 14:46, 18 July 2017 (UTC)

What exactly do you mean, where would you want to do this, and why would it be beneficial? --Redrose64 🌹 (talk) 22:26, 18 July 2017 (UTC)

{{hlist}} does not wrap bullets properly... What happened to {{·wrap}} and other similar templates?

Moved to Template talk:Navbox § Hlist wrapping

 - Paul^T+/_C 21:17, 7 March 2018 (UTC)

2018 change to recommended "br" syntax

Is there a discussion somewhere demonstrating consensus for this change by @SMcCandlish:? The edit summary was This hasn't been updated in years., which is 100% true, but I'd like to read the rationale for this decision. This seems like a pretty big change by adding this section:

While forms without the / (such as <br> and <br >) will work properly in the renedered page, they break several of the available syntax highlighers for wikicode in the editing view, and so should be avoided. Please correct occurrences to <br /> as you encounter them, though preferably as a part of a more substantive edit.

Where before there was no such directive to "correct" all <br> to <br />. I can't believe there wasn't a huge thread hashing it out and showing agreement before making a change like this. - Paul^T+/_C 00:34, 6 March 2019 (UTC)

Don't be hyperbolic, please. Information pages are regularly updated to provide current information without people having an RfC over it.  — SMcCandlish ☏ ¢ 😼  11:15, 6 March 2019 (UTC)

Image

Question: Do any of these templates for preventing line breaks work for images because all of them seem to cause a line break. Mn1548 (talk) 14:51, 17 March 2019 (UTC)

Wikipedia:Line break listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Wikipedia:Line break. Please participate in the redirect discussion if you wish to do so. UnitedStatesian (talk) 12:42, 12 April 2019 (UTC)

Automatic line-breaks

Is it me or shouldn't this article include information on how to make browsers trigger line-breaks automatically? As does running text, sometimes it is useful for other purposes aswell, e.g. tables. EnTerbury (talk) 05:17, 5 April 2020 (UTC)

What is this word "aswell"? It's not in my dictionary. --Redrose64 🌹 (talk) 16:49, 5 April 2020 (UTC)

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:

{{single notice|nothankyou=yes|banners={{Twinkle standard installation}}|see also = * {{tl|Uw-copyright-new}}, a less strongly worded user warning

* {{tl|Welcome-copyright}}, combining a welcome message with a less strongly worded message on copyright}}

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 how I added a second list item here.

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:

{{single notice|nothankyou=yes|banners={{Twinkle standard installation}}|see also = * {{tl|Uw-copyright-new}}, a less strongly worded user warning __NEWLINE__ * {{tl|Welcome-copyright}}, combining a welcome message with a less strongly worded message on copyright}}

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)

CapnZapp, 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)

Perryprog 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 enter/return)" (to quote the help you link to). The result I get when I replace the enter/return with <br /> 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 enter/return that actually is interpreted as such by Wiki list markup. In the line just above this, what should I replace <br /> with? Best regards, CapnZapp (talk) 15:40, 11 December 2020 (UTC)

CapnZapp, 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.

• 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
    you do this.

Perryprog (talk) 16:21, 11 December 2020 (UTC)

Perryprog: I am asking if there is another way to insert a enter/return 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 enter/return 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 enter/return. 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:

• Palm trees
• Date nuts

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.

So <br/> doesn't work. Neither does {{pb}}, nor <p>. 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)

CapnZapp, 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=):

{{Single notice|see also=
*Foo
*Bar}}

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)

CapnZapp, 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.

• Like
• This

Perryprog (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)

CapnZapp, 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 ↵ Enter - 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? --Redrose64 🌹 (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, this diff. 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)

CapnZapp, 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 my edit. 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 blist". So, {{blist|Cat|Dog|Ferret}} emits

• Cat
• Dog
• Ferret

- is that what you are looking for? --Redrose64 🌹 (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. {{singlenotice|see also={{blist|Cat|Dog}}}}) 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 enter/return 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)

CapnZapp, 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 hit enter 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)

CapnZapp, I was responding to "I couldn't get nested templates [...] to work". Currently the example you have there ({{singlenotice|see also={{blist|Cat|Dog}}}}) seems to work 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 just now. 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)

CapnZapp, no worries :). We all have those moments. Perryprog (talk) 14:31, 15 December 2020 (UTC)