Wikipedia talk:Line breaks usage
This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||
|
Don't-use people
[edit]Supporters of the rule "Don't use (single, manually entered) line breaks" include:
- Justfred - "Don't put in arbitrary line breaks where they don't belong."
- Rotem Dan (very strongly, I think the markup text should look as close as possible to the text displayed, this eases on finding a specific point in the text by looking at the rendred paragraphs.)
- Eloquence, [use line breaks] makes no sense (see below)
- Martin (after swinging back and forth, I think I'm generally against this now)
- Tannin Extra line breaks make editing painful.
- Zoe (also very strongly.)
- Hephaestos [single, manually entered line breaks] leave minor changes floating completely out of context with the rest of the material.
- Patrick Changing text into list elements or indenting it becomes cumbersome, the line breaks have to be removed.
- John Owens hates cleaning up when a line break ends up in the middle of a would-be wikilink. (But I'll usually leave them be if they're at least at ends of sentences instead of every 80 characters or less.)
- Camembert (if line breaks are added, the result is awful to read in the edit window, makes some editing trickier, and if anything makes the diff function less useful, not more, because diffs are shown out of context, making them harder to find in the article)
- Oliver P. (Yes, what he said. And what Martin said below. I can't come up with anything original, sorry.)
- bdesham -- yes, what Camembert said. I'd like to add that I find this really, really, really, really annoying.
- ABCD – what bdesham said
- Vsmith Never used 'em or gave this a thought 'til someone griped at me. Seems a holdover from archaic pre-hrml time? Plus I agree with all those above.
- Bcat (talk | email) 17:22, 17 July 2005 (UTC)
- EldKatt (Talk) I don't think small diff pages (the only major argument I can see) is worth the price of out-of-context diff pages and a generally hard-to-read source. A paragraph is a paragraph, and I like my paragraphs looking like paragraphs. The idea of having all sentences aligned makes particularly little sense to me.
- Ben Arnold I've never seen anyone do this random-line-breaks-in-a-paragraph thing, but I'm sure it would be tidied up by the next editor if they did. Seems really weird and difficult to use/read.
- ElAmericano Per everybody.
- This sounds nice in theory but is impractical in long articles. More importantly, it's highly dangerous to rely on peculiar software features. Xiner (talk, email) 01:01, 3 March 2007 (UTC)
- DRAGON Elemental (EXACTLY what Camembert said. It makes editing harder, and breaks context diffs - so it's a no-brainer!) —Preceding undated comment added 11:50, 5 April 2011 (UTC).
- 5CR1PT (talk) And I would also argue that it makes Wikipedia more future-proof and (a tiny bit more) format-agnostic for cross uses via solutions like Pandoc. And one never knows, maybe one day Mediawiki parser will be moved to the more user-friendly Markdown markup language? :)
Use people
[edit]Supporters of the rule "Use (single, manually entered) line breaks" include:
- tbc
- Damian Yerrick
- LDC
- Bryan Derksen
- Eclecticology
- Kowloonese (strongly; it is silly to spend timing doing what the browser does for you, i.e. the formatting. So my main concern left is the quality of the "diff" result.)
- "it is silly to spend timing doing what the browser does for you" sounds like an argument against this rule, not for it --Camembert
- The browser does the HTML layout for you. It doesn't do the wikitext diffs for you. This argument is about the wikitext, not the result after converting to HTML and normalizing whitespace per HTML rules. --Damian Yerrick (talk | stalk) 03:16, 3 March 2007 (UTC)
- "it is silly to spend timing doing what the browser does for you" sounds like an argument against this rule, not for it --Camembert
- Rossami (I recognize the potential format problems, but judicious use of linebreaks can make downloading the diff pages much faster. I routinely work on dial-up and this is a big problem for me.)
- zeno (there is no problem at all for using line breaks in normal paragraphs, e.g. after the end of a sentence - of course I could be convinced of the "Don't use" rule - atm I am just not convinced)
- Error -- I use a line per sentence when adding text. Not in :, or * (like here). But people like to group them back when I'm not looking.
- Nyenyec - I'm color blind and for me no line breaks make it extremely hard to find the changed sections in a large paragraph. Therefore I use a line per sentence when I write.
- User:EdwardOConnor
- Martin Geisler I consider the lack of support for linebreaks in lists a serious defect in the Mediawiki parser --- the long lines makes the text harder to read. (PhpWiki has had support for this in a long time.)
- DavidCary 20:25, 29 November 2005 (UTC) : I also use a line per sentence when adding text, like User:Error. See below.
- rossb (talk) : it makes the diffs so much easier to check.
- Dave3457 Line breaks help the reader absorb the information. Sometimes a new paragraph is not appropriate but you still want to communicate that the present sentence is a new line of thought. If the diff software doesn't deal with them then why not get it to? That being said they should not be over done. Also they should always be at the end of a sentence and the next sentence should start on a new line in the edit window. —Preceding undated comment added 08:15, 17 February 2010 (UTC).
- jeh (talk · contribs) I agree with most of the people in this section. Line breaks not only make the diffs easier to check and less likely to be "confused," they also reduce clutter in the edit window. Jeh (talk) 00:28, 13 October 2012 (UTC)
- Aymatth2 (talk) 14:15, 5 November 2013 (UTC) Three reasons:
- When I start an article I often rearrange text until I am satisfied with the sequence. My mouse coordination is not great. If each sentence is on a line or lines by itself I find it easier to select a sentence, then cut it and paste it somewhere else.
- I prefer not to overcite. Two or three sentences may have a cite like {{sfn|Smith|2003|p=136}} at the end of the last. Before moving one of these sentences somewhere else, I have to copy the cite to the end of it too, which is easier with line breaks at the end of each sentence.
- Diffs are easier to understand
- Batternut: Judicious sentence-ending line breaks eases dealing with big paragraphs - diffs are better and editing is easier. The arguments against such usage are very weak: indenting a paragraph - almost never necessary; convert to list item - bad style, rarely useful; whitespace in the text entry area a waste of space and distracting - not with judicious sentence-ending line breaks; appearance of the source differs from rendered - it's wildly different anyway; may confuse new editors - just weasel words!
- 7dare (talk) 10:49, 29 January 2019 (UTC): Strongly, they allow for a certain point in the source to be found much more easily if each line in the source begins at the beginning of a sentence. It avoids making the source into an intimidating monolithic block.
- Ita140188 (talk) Source code is much clearer, especially when there are references at the end of each sentence. Diffs are also clearer --Ita140188 (talk) 18:58, 19 February 2019 (UTC)
- Sirjohnperrot: A straightforward means of improving readability and typographical appearance when used appropriately for sentence ending.Sirjohnperrot (talk) 19:53, 18 June 2020 (UTC)
- Sangdeboeuf: Makes parsing changes in diffs easier, since each sentence (or clause) in the old version is matched with the corresponding sentence in the new version. Especially helpful when paragraphs are very long and/or contain many references, since users will not have to scroll past huge blocks of unrelated wiki-markup. Especially especially helpful when paragraphs are long and diffs are minor and hard to spot, such as changing punctuation marks. Per WP:CREEP, it should be up to users' discretion whether or not to use. —Sangdeboeuf (talk) 04:29, 8 July 2021 (UTC) edited 08:30, 2 December 2021 (UTC)
Other people
[edit]Supporters of neither rule, both rules, agnostics, etc:
- doom I reluctantly agree that avoiding embedded linebreaks in paragraphs is probably the right way to do it with the wikipedia software, it would be better if the software did not impose the need to be finicky about details like this.
Now, I agree fully with this guideline and all (even though I keep forgetting to practice it :), but I do have one possible objection/question; isn't a soft line break one of those line breaks inserted automatically by word wrapping and a hard line break one of those line breaks inserted by hitting the enter/return key? If that's indeed the case, we want to use hard line breaks and not soft line breaks. If it isn't the case, then never mind. Bryan Derksen
- Maybe the word "soft" should be removed from the rule; many people (myself included) may not have a clear view of the difference between soft and hard breaks. This is really about nice formatting in general. One principle in that would be to avoid excessively long paragraphs; if that's done the "diff"'s will fall into place. Eclecticology
(Justfred) Force users to edit their text in a specific way because the diff function doesn't support sentances, only paragraphs? And use the fact that the formatter ignores single soft line breaks? This seems wrong to me. A paragraph is a paragraph. Don't put in arbitrary line breaks where they don't belong. For that matter, I'd like it if the formatter understood single-linebreak-separated lists without needing br tags. I'd prefer if it were as close to WYSIWYG as possible. --justfred
- I guess this is just a recommendation. The user can write any way they want to if they don't care about the extra burden on the systems and other users. It is a courtesy not a mandate. The diff function needs to work harder and slow down the server if it needs to process a long paragraph versus a short sentence. Other users can read the diff report easier if the context is narrowed down to just one sentence. The download time of the diff page is faster if the diff blocks are smaller by eliminating all the unchanged sentences around the changes. Yes, I agree that if the diff function is smart enough, we can do away with this workaround. But given the situation, this is a good compromise. -- 63.192.137.21
This policy is perhaps obsolete now Wikipedia has spiffy side-by-side diff output. -- Tarquin 12:47 Jul 30, 2002 (PDT)
- What it all comes down to is "write short paragraphs for ease of online reading", but that sound point is pretty well hidden in all the verbiage, ironically. Ortolan88
No, that wasn't the intent of the rule at all. What we wanted to encourage is frequent hard breaks in the source text (that is, the text in the edit box), which make no difference at all in how the article is displayed, but make it easier to edit in many ways: First, some editors (particularly in the Unix world) don't handle long lines well. It makes diffs faster and smaller and easier to read, even with the new features. And it makes it easier to find sentences within a paragraph, and to rearrange sentences. --LDC
It makes editing extremely tedious and the text becomes difficult to read unless your edit box width happens to be set to the same size as the person who edited the text before you. Often when the text is edited, the extra bits are added without adjusting the lengths of the rest of the lines. This leads to some lines being much longer than other, and this is really difficult to read. It's only a problem for editors, but that is important enough to me. Don't you think? Of course you could ask everyone when adding a few words to re-edit the entire paragraph so as to maintain the arbitrary maximum line size typically of 80 chars. But this is tedious. Note that while a few editors don't deal well with long lines all editors deal badly with this kind of short line as used here: it ends up taking a whole bunch of extra space and you end up with a bunch of wasted white space on the right hand side. This happens to me with LDC's edit above - and wasted space is bad UI design. That's why we should write like, well, normal people. This is one of those instances where just because you can do something, doesn't mean that you should. Martin 00:27 5 Jun 2003 (UTC)
- As an example - the above response is mis-indented (it should be at a single level of indentation, as a reply to LDC. However, fixing this is hideously tedious, and it's the single manual line-breaks that make it so. I could solve the problem by indenting LDC's comment instead.... but that's got the same problem. Remind me again how manual line breaks make pages easier to edit? Martin
I have also found several instances in articles where a line break is put in the middle of an internal link; this breaks the link. - Hephaestos|§ 18:58, 21 Mar 2004 (UTC)
one line per sentence
[edit]I also use a line per sentence when adding text, like User:Error. But I avoid adding line breaks in the middle of a sentence. My best excuse is that it helps me edit for improved readability -- it makes long sentences (which always hurt readability) stick out like a sore thumb. Also it helps me entirely avoid the Full_stop#Spacing_after_full_stop controversy. Probably the real reason I do it is a relic habit from old wiki software whose "diff" made it difficult to find minor changes in a long paragraph. But what irks me is people who clutter up Recent Changes, making no change other than adding or deleting these invisible-to-the-reader linebreaks (or other whitespace). --DavidCary 20:25, 29 November 2005 (UTC)
This makes it easier to follow the Wikipedia:Guide_to_writing_better_articles#Use_short_sentences_and_lists guideline. --DavidCary 08:01, 20 January 2006 (UTC)
This ballot is problemetic. I support one line per sentence but I am against random line breaks in the middle of a sentence or paragraph. My vote does not fit anywhere precisely, so I voted for use line breaks. I bet many who voted may have to face similar dilema. IMO, this voting result is not representative of what people really think. Kowloonese 20:03, 2 February 2006 (UTC)
Proposed conversion into a redirect
[edit]This page seems to cover the subject in rambling and unnecessary detail. I propose replacing the page with a redirect to Wikipedia:How to edit a page. Please let me have your thoughts. jguk 11:34, 31 Oct 2004 (UTC)
Userbox
[edit]Would somebody care to make Wikipedia:Userboxes for these choices? --Error 03:17, 11 March 2006 (UTC)
<br> vs <br />
[edit]I understand that the <br>
tag is invalid XHTML, but it is converted to <br />
upon rendering by MediaWiki. So it's really an aesthetic difference, and in my opinion, <br>
looks much cleaner. (For example, m:Help:Editing#Most frequent wiki markup explained (permanent link) uses it in one of its wikitext examples.) Is there any consensus on Wikipedia as to which one is preferred? Thanks. —dto (talkcontribs) 06:40, 2 November 2006 (UTC)
- Lol, do some reading will you. In XHTML you need to close tags which are supposed to be self-closed for the code to pass validation. Just like <p> isn't valid without a subsequent </p>, you need to write <img src="" />, <br /> etc. STUPID 213.112.137.148 13:16, 17 March 2007 (UTC)
- But dto's point is that MediaWiki converts the HTML 4
<br>
to the XHTML<br />
when preparing the page for rendering. So it really doesn't matter what you enter, just as the difference between[[tag]]s
and[[tag|tags]]
does not matter. --Damian Yerrick (talk | stalk) 16:21, 17 March 2007 (UTC)
- But dto's point is that MediaWiki converts the HTML 4
Which should we use? <br>
or <br />
?
Let's examine this step by step:
1: Writing the XHTML code <br/>
without a blank is even against the recommendations of the World Wide Web Consortium, instead it should be written as <br />
since then HTML parsers can understand it too. HTML parsers will simply regard <br />
as a "br" with an unknown parameter "/", while they will regard "br/" as an unknown tag name. So we should definitely not teach people to write <br/>
, but possibly <br />
.
2: The "HTML" codes we use here at Wikipedia are not XHTML markup nor are they HTML markup, instead they are "HTML wikimarkup", since MediaWiki processes them just like wikimarkup.
3: Wikipedia mainly uses wikimarkup. The reasons for that is simple: Most people that edit Wikipedia are people who never have made a web page, so they know nothing about HTML, XHTML or CSS. So for them (and even for us old webmaster geeks) it is easier to use wikimarkup.
4: So far I have seen the documentation for MediaWiki talks about "HTML in wikitext" and never mentions "XHTML in wikitext". Also up until recently all documentation listed <br>
as the code for forced line breaks. But some months ago some XHTML enthusiasts went around and edited a lot of the help pages to show the <br />
or even the <br/>
.
So which should we use? <br>
or <br />
?
Well, let's first ask another question: Which markup should we use for bold text?
'''Bold'''
<b>Bold</b>
<span style="font-weight:bold;">Bold</span>
I think we all know that the wikimarkup '''Bold'''
is the recommended one. Mainly because it is simpler to use, especially for the majority of editors that don't know HTML and CSS.
The same goes for <br>
vs <br />
. The HTML wikimarkup <br>
is easier for the majority of editors to use, and it is shorter.
Sure, we have a "teaching opportunity" to teach people to use the <br />
, but there is a very high risk that they instead will use the <br/>
and that would be a bad thing. And believe it or not, many beginners have problems telling "/
" and "\
" apart. So they might even try to use the <br\>
...
So again, the <br>
is easier for the majority of editors to use, and it is shorter.
--David Göthberg (talk) 23:19, 14 March 2008 (UTC)
Consolidation?
[edit]Please note that this page has been nominated to be consolidated with the primary Manual of Style page. Please join the discussion at the MOS talk page in order to discus the possibility of merging this page with the MOS. Thank you.
— V = IR (Talk • Contribs) 14:08, 27 March 2010 (UTC)
MoS naming style
[edit]There is currently an ongoing discussion about the future of this and others MoS naming style. Please consider the issues raised in the discussion and vote if you wish GnevinAWB (talk) 20:52, 25 April 2010 (UTC)
Move
[edit]Wikipedia:Don't use line breaks → Wikipedia:Manual of Style (line breaks) — Consolidating naming per Wikipedia_talk:Manual_of_Style#Poll Gnevin (talk) 16:24, 24 May 2010 (UTC)
Oppose: This appears not to be a style guideline, but rather a page consisting of two opposing essays.—DCGeist (talk) 22:31, 25 May 2010 (UTC)
- Remove from the MOS? Gnevin (talk) 12:32, 26 May 2010 (UTC)
- I've marked as essay, no serious edits in over 2 years Gnevin (talk) 13:53, 26 May 2010 (UTC)
Visual Editor
[edit]I think it is worth mentioning something about the mw:Visual editor, because it will likely make it largely unnecessary to use the wiki code. So, there would be less reason to worry about it. Helder 12:28, 4 June 2012 (UTC)
Line breaks. br variants discussion elsewhere
[edit]Please see Help talk:Line-break handling#Let us ignore syntax highlighters that do not accept <br>
It is a detailed discussion with participation from editors, developers, admins, etc.. Most people in that thread want <br> used, not <br />. See also: KISS principle.
See also MOS:SIMPLIFY: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly." --Timeshifter (talk) 08:41, 11 February 2023 (UTC)
To avoid an edit war
[edit]@Remsense So as to not cause an edit war here, let's we move discussion here:
My edit was to allow the reader the ability to see the newline term as well as the linebreak term, hence I left the linebreak easter egg pipe link (begrudgingly), and added "also known as a newlines" (whereas it should have technically been linebreaks, also known as newlines,). In your edit summary you state that The wikilink does, in fact, show the reader the term 'newline'
. I'm going to assume good faith here, and maybe I'm mistaking you meaning then that the reader should click on the link labelled linebreak and then see the newline article load; per MOS:EASTEREGG this is discouraged as the user will be surprised to be pipelinked (not redirected) to a completely differently named page than the link label suggests they'll see.
Secondly, you reverted my {{key press}} addition, only to add it yourself later? And to call it "correct before".
Also I kindly caution your future revert conduct as I found it obstrusive to Wiki experience and editing: Checkout WP:DONTREVERT: Do not revert unnecessary edits (i.e., edits that neither improve nor harm the article)
. Unless you can prove the reverted edit must actually make the article worse
. And check WP:PARTR: You could also discuss an edit directly with the editor who made it, on that editor's talk page, and request that the editor modify their own work. Or convince you that it's best as it stands.
Or at least have the kindness to message on their talk page before reverting and explaining your concern, especially if they're a seasoned user like myself. Come on man. waddie96 ★ (talk) 23:24, 5 February 2025 (UTC)
- WP:DONTREVERT is an essay I am well aware of and do not happen to find compelling whatsoever. I prefer the relevant advice in the lead of Wikipedia:Be bold, which is also more compelling as site policy. More importantly, I am not sure where I have indicated a lack of good faith, unless the common conflation of that with "being told that one is wrong and why" happens to be at play here.
- If you pull out your phone, you will in all likelihood note that the keyboard has a Return key, not an ↵ Enter key. There's actually some reason for that: more precisely, Return is the key that is guaranteed to type a carriage return (plus linefeed). It's pretty minor, but ↵ Enter is not guaranteed to have the same function, strictly speaking. Remsense ‥ 论 23:32, 5 February 2025 (UTC)
- Your description of carriage return is outdated to typewriters. Per Enter key, the
two [are] closely related keys with overlapping and distinct functions dependent on operating system and application.
- Seeing as you seem so unwilling to discuss, and still continue an edit war is a lack of good faith. On WP, no-one is right and wrong, we have our own opinions and through discussion and consensus reach an resolution. But you have literally frankly stated that you simply think you are "right" and I am "wrong".
- To WP:BEBOLD, I will go ahead and edit the page with additions as I see helpful with your new information you gave me, I appreciate it.
- I kindly warn you that your next revert will violate the WP:3RR. waddie96 ★ (talk) 23:53, 5 February 2025 (UTC)
- Please re-read what I wrote. The distinction is not outdated, as your quotation quite plainly corroborates. Not sure where you got the idea that I am unwilling to discuss, given I have already begun doing so. Once more, it is not constructive to conflate my not agreeing with you and expressing why I think you're wrong with a failure to assume good faith. Apologies, but that's clearly reflective of an actual failure to assume good faith on your part. Remsense ‥ 论 23:56, 5 February 2025 (UTC)
- Your obstructive nature is stalling this discussion: you have not addressed the removal of the MOS:EASTEREGG despite my explanation above, you have not addressed why reverting my entire contribution and then readding a key press of your liking was preferrable over partial reversion or just fixing it, you are also ignoring my pointing out that you are unwilling to discuss with your clearly stated preconceived idea that you are "right" with the statement:
More importantly, I am not sure where I have indicated a lack of good faith, unless the common conflation of that with "being told that one is wrong and why" happens to be at play here.
waddie96 ★ (talk) 00:07, 6 February 2025 (UTC)- It is not inherently obstructive for others to hold the position that you are wrong.
- I don't find the EGG to be egregious whatsoever, especially on a project page. Should really go without saying, but I reverted your changes in their entirety because I think they are regressions in their entirety. Remsense ‥ 论 00:13, 6 February 2025 (UTC)
- If you edit your comments please re-sign them with an edit note after your initial timestamp, as you made over 4 to 5 edits to your comment with no change in timestamp or an edit note with a new timestamp. waddie96 ★ (talk) 00:12, 6 February 2025 (UTC)
- I'll pass on that, but thanks for the reminder. Remsense ‥ 论 00:13, 6 February 2025 (UTC)
- Your attitude is so low. It's this type of attitude that makes editing suck for some Wikipedians. waddie96 ★ (talk) 00:16, 6 February 2025 (UTC)
- It is sometimes difficult to work with people who disagree with you. Remsense ‥ 论 00:22, 6 February 2025 (UTC)
- Your attitude is so low. It's this type of attitude that makes editing suck for some Wikipedians. waddie96 ★ (talk) 00:16, 6 February 2025 (UTC)
- I'll pass on that, but thanks for the reminder. Remsense ‥ 论 00:13, 6 February 2025 (UTC)
- Where I get the idea: Is as mentioned above: You explicitly mentioned
being told that one is wrong and why
not I have a different opinion. Don't change your position now and deflec this on me. waddie96 ★ (talk) 00:13, 6 February 2025 (UTC)- They are exactly equivalent here. You have given some reasons underlying your opinion, but those reasons happen to be wrong. Remsense ‥ 论 00:23, 6 February 2025 (UTC)
- Wrong in your opinon. waddie96 ★ (talk) 00:23, 6 February 2025 (UTC)
- I don't extrapolate you as wrong. I disagree with your opinion. You however see mine as wrong. Point blank. You cannot think outside the box here? waddie96 ★ (talk) 00:24, 6 February 2025 (UTC)
- Then tell me where I am wrong, quoting policy and reference my addition/removal/change relating to that policy. waddie96 ★ (talk) 00:25, 6 February 2025 (UTC)
- That's how arguments work, yes.
- You're wrong about the Enter/Return conflation as stated above, and there's nothing about the link that is confusing, misleading or problematic. My best guess is that you are disregarding what problems WP:EGG is actually written to address, and instead favor the maximal interpretation of what it happens to say.
- Either acknowledge my concerns or don't, but I'm not going to abide by arbitrary escalating conditions just because you demand I do so. Remsense ‥ 论 00:45, 6 February 2025 (UTC)
- They are exactly equivalent here. You have given some reasons underlying your opinion, but those reasons happen to be wrong. Remsense ‥ 论 00:23, 6 February 2025 (UTC)
- Your obstructive nature is stalling this discussion: you have not addressed the removal of the MOS:EASTEREGG despite my explanation above, you have not addressed why reverting my entire contribution and then readding a key press of your liking was preferrable over partial reversion or just fixing it, you are also ignoring my pointing out that you are unwilling to discuss with your clearly stated preconceived idea that you are "right" with the statement:
- Please re-read what I wrote. The distinction is not outdated, as your quotation quite plainly corroborates. Not sure where you got the idea that I am unwilling to discuss, given I have already begun doing so. Once more, it is not constructive to conflate my not agreeing with you and expressing why I think you're wrong with a failure to assume good faith. Apologies, but that's clearly reflective of an actual failure to assume good faith on your part. Remsense ‥ 论 23:56, 5 February 2025 (UTC)
- Your description of carriage return is outdated to typewriters. Per Enter key, the