Help talk:Line-break handling/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: 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 Manual of Style (dates and numbers). 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. — Dino guy  1000  23:26, 11 March 2008 (UTC)


 * 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.
 * 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.
 * 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.)
 * 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.
 * 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  tags, in favor of HTML entities ("&amp;lt;" and "&amp;#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...
 * — Dino guy  1000  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 "&amp;lt;" are probably more robust than using the  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.
 * — Dino guy  1000  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 ·, – 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, 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 ". 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
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP
 * WP:NOWRAP

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

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:

This also happens if you put two 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:

You can also use nowrap begin + wrap + nowrap end, but that also causes a space at the. Perhaps that is why 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:

This too will overflow in Firefox:

--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. 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  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:  or  . 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 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.

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

– ⊥¡ɐɔıʇǝoN oetica! 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. — Dino guy  1000  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 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. --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: . 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 &lt;source/>, &lt;code/>, or &lt;pre/> tag, except maybe for the occasional one-line snippet. And even in those cases, it's easy enough to just use &lt;nowiki/> or nowiki. — Dino guy  1000  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 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 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 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  , then I found my way here and opted for &amp;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 &divide; with /, shouldn't it replace  with   ? nagualdesign (talk) 01:31, 15 September 2010 (UTC)

Question on coding
Is there any difference between  and   ? 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  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,  is the correct "HTML wikimarkup". But MediaWiki was updated to also understand   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  all are faulty variants. And the variant   (without space) is not a recommended variant of the   tag, according to the World Wide Web Consortium (W3C), since it breaks older web browsers.
 * So I suggest we stick to the simple wikimarkup  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.
 * 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  in wiki code to   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,  is the preferred format, why does the edit toolbar give  ? PC78 (talk) 12:21, 6 August 2010 (UTC)

. We also enable HTML Tidy which will convert ,   ,   and the like to a proper . This is not done on editnotice pages and MediaWiki interface pages, where  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)
 * We currently output XHTML, where the newline tag is

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&#8209;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 (&amp;#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 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 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 (, and, ...). Should I use or  ? 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, 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 -- Red rose64 (talk) 14:20, 3 July 2013 (UTC)

wbr
will be allowed with MediaWiki 1.22/wmf13. --  Gadget850talk 07:22, 17 August 2013 (UTC)

Line breaks, October 2013
I'm not sure that [//en.wikipedia.org/w/index.php?title=Wikipedia%3ALine-break_handling&diff=578847492&oldid=576571190 this change] is appropriate. First some background:
 * 1) I had changed some instances of  into  in an article I was editing, User:Woodstone noticed and queried the merits of this change. Details at User talk:Mitch Ames. 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, that the tool's documentation should be updated to include the space before the slash.
 * 3) Remember_the_dot then [//en.wikipedia.org/w/index.php?title=Wikipedia%3ALine-break_handling&diff=578847492&oldid=576571190 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

Mitch Ames (talk) 09:26, 27 October 2013 (UTC)
 * 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?


 * XHTML permits both and . Which one you use is a matter of personal preference. There is no technical advantage to  over.
 * As far as I know, all Wikimedia Foundation sites use HTML Tidy.
 * The [//en.wikipedia.org/w/index.php?title=Wikipedia:Line-break_handling&oldid=576571190#.3Cbr.3E 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 is better than  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 and  are correct XHTML, but there used to be browsers that did not accept  (if I remember well Microsofts IE). If you inspect the output of WP, you will notice that it always has, as that is correct HTML. Therefore there is no advantage in changing existing  into . It makes the edit box less human friendly for the vast majority of editors that do not use syntax highlighting. &minus;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. Void tags may optionally include a space and optionally include a slash. Thus,,  and  are valid HTML5.
 * In XHTML, these are called empty tags and must be terminated with a slash. Thus only 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.
 * 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... --  Gadget850talk 15:05, 28 October 2013 (UTC)
 * I reverted the edit, because rather than clarifying things, it seemed to muddy them; it also put undue emphasis on the XHTML forms.
 * The tag was the only valid form up to and including HTML 3.2
 * HTML 4.0 documented the form, and also permitted the  form for compatibility with XML parsers; in XML, the space is optional
 * XHTML 1.0 permitted only the 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 and  are equally valid HTML5
 * Wikipedia serves HTML5, and has done so for over a year now. Changing to  (or vice versa) is unnecessary; changing  to  (or vice versa) is pretty much pointless. However, changing invalid forms such as  or  to either of the valid forms should be performed wherever the invalid forms are found. -- Red rose64 (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, not -- 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 or   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 or  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 " or 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  before the  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  and other empty elements with no slash, but also unclosed non-empty elements including (but not limited to)           . 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. -- Red rose64 (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 to . 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: is consistent with MediaWiki extensions such as . —Remember the dot (talk) 03:27, 29 October 2013 (UTC)
 * But not really relevant. is an extension tag- early in extension development someone decided to use markup that mimicked XHTML, but it is not HTML.
 * As noted, both and  are equally valid, and converting from one form to the other is generally a meaningless edit, except for consistency on a particular page. --   Gadget850talk 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? -- Red rose64 &#x1f339; (talk) 22:26, 18 July 2017 (UTC)

does not wrap bullets properly... What happened to and other similar templates?
- Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/C 21:17, 7 March 2018 (UTC)

2018 change to recommended "br" syntax
Is there a discussion somewhere demonstrating consensus for this change by ? 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: Where before there was no such directive to "correct" all to. I can't believe there wasn't a huge thread hashing it out and showing agreement before making a change like this. - Paul T [//en.wikipedia.org/w/index.php?title=User_talk:Psantora&action=edit +]/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 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. -- Red rose64 &#x1f339; (talk) 16:49, 5 April 2020 (UTC)