Template talk:Paragraph break

(Redirected from Template talk:Paragraph break/doc)
Latest comment: 3 years ago by RexxS in topic TemplateStyles redux

Using p tags

edit

Just dropping a note that this was briefly discussed here (permalink). 213.7.147.34 (talk) 21:43, 30 October 2014 (UTC)Reply

Regardless of how this template is implemented, I'm not sure I understand why using this template is better than using a <p> element within a list or anywhere else. The text following a <p> tag is implicitly placed by the browser into a <p> (paragraph) element. (Technically, it would be better if a closing </p> tag was placed at the end of the paragraph, but browsers will implicitly close the element.) Introducing an empty <div> element seems worse, in one sense, since it really is introducing an element without content. (On other hand, since a <div> is a generic element for a block of text, it doesn't have any inherent semantics.) isaacl (talk) 17:43, 1 November 2014 (UTC)Reply

the WikiMedia backend software will generate the p tags for you when you add newlines, in most cases. generally, you should just do that, rather than use this template. the reasons for using this template are (1) to add a paragraph break in places where the software fails to do so and (2) where it would be disruptive to a screen reader to have a <p> tag, since screen readers have a shortcut for jumping from paragraph to paragraph. this becomes excessive if this happens within citations, for example. Frietjes (talk) 20:57, 2 November 2014 (UTC)Reply
OK, that makes more sense than the current explanation in the documentation. I think some examples would be useful, though. As I understand your explanation, this template is intended to be used when the editor wants to insert a line break that is purely ornamental and does not actually denote a new paragraph (which of course makes the template name a bit of a misnomer), since having extraneous <p> elements would unnecessarily complicate navigation for those using assistive technology to jump from paragraph to paragraph. isaacl (talk) 22:45, 2 November 2014 (UTC)Reply
yes. I would support a better/shorter name. it is still, fortunately, very sparsely used. Frietjes (talk) 14:50, 3 November 2014 (UTC)Reply

@Frietjes:, @Isaacl: and @213.7.147.34:: I came here when an editor corrected a comment of mine from a <p> to a {{paragraph break}}. It does seem to have advantages where you are in a hurry to split paragraphs.

I am trying to understand this better too. I know just enough HTML to be dangerous :) I do often use <p> for a new paragraph for talk pages where I am the first commenter and need a new paragraph (as I did for this paragraph). I never cared for <br/> which looks ugly and has the connotation of "breaking" something, and reminds me of all the problems of Carriage Return-Line Feed on PC's vs. Newlines on Unix and how awful it was to move text from one platform to the other. I don't really know the difference in function between <p> and <br/>, and I would love to hear it explained, especially since both forms are advanced here without much explanation of the difference in meaning.

Now in addition we have you guys have pointed me to <div>. I'm not sure what that does either.
Since we are talking HMTL code and Wikicode, why is it that when I put <i>italics</i> or <b>bold</b> some bot eventually comes along and uglifies it to be ''italics'' and '''bold''' and worst of all nesting of <b>bold <i>italics</i></b> to '''bold ''italics'''' the nesting is eliminated and requiring us to carefully count the # of single quotes to figure out what is going on and where the bold and italics starts and ends? I have some more questions, but this is a good start! --David Tornheim (talk) 03:43, 8 April 2017 (UTC)Reply

@Mz7: Thanks for making me aware of this template. Maybe you might know the answer to some of my questions? Also, to everyone, I made a slight change to the documentation to clarify the code for Example 1 the same way Example 2 was done [1]. I think the first ref of Example 1 does not work the way it is claimed to work (i.e. the two paragraph end up on the same line instead of separate paragraphs, at least that's what my browser Firefox does). --David Tornheim (talk) 03:56, 8 April 2017 (UTC)Reply

@David Tornheim: Right, so, I'm not an expert on HTML either, but I'll give your questions a shot. (To others: please correct me where I'm wrong.) For a while, I too used <p> to make paragraph breaks. But I was told by MusikAnimal that this is actually invalid HTML. I think he said it needs a closing </p> tag, which can be cumbersome, so he recommended this template ({{pb}}), and I've been using it ever since. I know that web browsers can still interpret invalid HTML and make a good guess as to what you really mean, but it's best to avoid it when possible.
With regards to the difference between <br /> and <p>, I think the relevant distinction is between a "line break" and a "paragraph break". As I understand it, early computer text programs did not automatically "wrap" text to the size of your screen. Notice how my text here automatically moves to a new line whenever the text reaches the right of the window—we almost take this behavior for granted now, but my understanding is that this was not always the case. <br /> is a way to force a "line break", which presents the characters that follow the break on a new line. A "paragraph break", as I understand it, is for separating paragraphs. Unlike the line break, which looks exactly like how the text moves down a line when it hits the right edge of your screen, the paragraph break adds a subtle gap to more visibly separate two paragraphs. <p>...</p> is a way to indicate paragraph text in HTML, as I understand.
A <div> tag is, I believe, just a generic way to divide up HTML content. Apparently an empty div section <div></div> produces the equivalent of a paragraph break. Now, the reason why a bot will automatically convert your HTML <i>italics</i> and <b>bold</b> to wikimarkup ''italics'' and '''bold''' is simply because wikimarkup is simpler than HTML. It's just what most editors have grown accustomed to using, I suppose, and plus I think it is the native markup language of MediaWiki, the software that runs Wikipedia. Mz7 (talk) 04:33, 8 April 2017 (UTC)Reply
There is a subtlety when entering HTML-like tags in wiki text: although an unclosed <p> is invalid HTML, that doesn't mean it has to be invalid wiki text, since by the time the MediaWiki parser is done with it, the generated output is valid HTML (the parser adds a closing tag). Regarding the differences between various markup: a <p> element is semantic, labelling its contents as a paragraph (which can have specific formatting styles applied to it and referenced by screen readers); a <br> element has no semantics and is just intended to change the text layout. A <div> has no semantics by default, but it is by default a block element, so it is intended to designate a paragraph-like element. So semantically speaking, as I mentioned previously, an empty <div> element isn't a great option if the following text really is a new paragraph. isaacl (talk) 05:01, 8 April 2017 (UTC)Reply
@Mz7: I was partially wrong, <p> can be valid HTML, under certain conditions. The real reason why I've been using {{pb}} is because <p> by itself is not respected by a very popular syntax highlighter, so the whole wikitext following the unclosed tag will lack any syntax highlighting. This isn't a really strong argument for using {{pb}}, though. I am not sure if MediaWiki adds the closing p tag, but even if it doesn't your browser will. The concept of invalid HTML is purely a nitpick in this case and in general will not disrupt the layout of the page, so frankly you can ignore my concerns if you so wish. Also at some point this year we'll have a much smarter and efficient syntax highlighter (phab:T101246) that will respect unclosed p tags :) MusikAnimal talk 17:47, 8 April 2017 (UTC)Reply
At one time, the MediaWiki software (that's what generates web pages from Wikipedia page sources) served XHTML, which was a stricter version of HTML 4.01 (plus some extensions which need not concern us); in XHTML, every opening tag has to be balanced by a matching closing tag, such as <p>...</p>. For the last few years, MediaWiki has served HTML5, which essentially uses the HTML 4.01 rules concerning tag omission - under certain circumstances, closing tags may be omitted when the context implies its presence, and one of the optional closing tags is </p>.
The difference between the various elements mentioned above is primarily semantics.
  • The br element forces a newline in running text, but does not subdivide a block of text.
  • The p element starts a new paragraph, which consists of a single block of text that does not contain other blocks (such as tables or lists).
  • The div element creates a "meaningless" semantic division - it groups together related parts of a document.
A <div>...</div> may enclose one or more <p>...</p>, but a <div>...</div> may not be placed within a <p>...</p> since the opening <div> tag implies the closure of any open <p> - in other words, an invisible </p> is assumed to precede the <div>. --Redrose64 🌹 (talk) 23:06, 8 April 2017 (UTC)Reply

Recent discussion: Any doc updates needed?

edit

With the closing of Wikipedia:Templates for discussion/Log/2016 May 28 § Template:Paragraph break on 4 June 2016, did the discussion include any points of information that should be summarized in this template's documentation?

Sorry all I can do is point this out, but my real-life limitations won't allow me to do more. Thanks in advance! —Geekdiva (talk) 09:52, 20 September 2016 (UTC)Reply

templatestyles

edit

Izno after your change, articles like Veganism now say templatestyles stripmarker in |quote= at position 1 . you can find more by searching for templatestyles in articlespace. Frietjes (talk) 19:52, 15 August 2018 (UTC)Reply

That's one I'll have to look in to... --Izno (talk) 03:29, 16 August 2018 (UTC)Reply
@SlimVirgin: Is that the problem you were seeing or were you seeing something somewhere else? --Izno (talk) 03:30, 16 August 2018 (UTC)Reply
Izno, yes, that was it. SarahSV (talk) 03:55, 16 August 2018 (UTC)Reply
I think the template that needs to be fixed is Module:Citation/CS1. I don't know if there is a reasonable solution, but I'm pretty sure quote is not put into the metadata, so it should just accept the stripmarkers. Growing pains. :) I'll go poke them. --Izno (talk) 03:57, 16 August 2018 (UTC)Reply
{{mono}} is doing it too for a handful of pages in the title parameter--which shouldn't have any styling. Those should be removed instead probably. --Izno (talk) 04:01, 16 August 2018 (UTC)Reply
Follow at Help talk:CS1#TemplateStyles (any?) templates in CS1 if desired. --Izno (talk) 02:08, 17 August 2018 (UTC)Reply

TemplateStyles redux

edit

This template really needs to work with WP:TemplateStyles. At present it produces unsightly output when used in a list – a common use to avoid breaking the comment when using bullet points in threaded discussion. We need it to fix the following problem:

When used in normal paragraphs it works properly:

Normal example
First "chunk" of text.
More of the same "chunk".

Second "chunk" of text.

Third "chunk" of text.


But this is what we get on a talk page using bullets:

Bulleted example
  • First Comment
    More commentary by the same editor. --sig1
  • Second Comment. --sig2
  • Third Comment. -- sig3


The extra margin-top:0.5em inline-coded into the template produces obvious, ugly extra spacing between the two parts of the comment in the first list item. It looks like the further commentary by the first author belongs with second comment, which is jarring. The solution to this is to use TemplateStyles to remove the extra margin-top when the {{pb}} is inside a list element. I've created Template:Paragraph break/sandbox using Template:Paragraph break/styles.css and amended the latter to deal with the issue. This is what we get using the sandbox version:

Sandbox normal example
First "chunk" of text.
More of the same "chunk".

Second "chunk" of text.

Third "chunk" of text.
Sandbox bulleted example
  • First Comment
    More commentary by the same editor. --sig1
  • Second Comment. --sig2
  • Third Comment. -- sig3

I understand there may be some problem when using {{pb}} with references, but I'm not familiar with the specifics. @Izno and Sarah: Does that problem still exist? --RexxS (talk) 01:38, 8 February 2021 (UTC)Reply

No, |quote= can now accept arbitrary templatestyles templates: Title. Double quotation HTML. The other parameters with metadata are still checked: Mono content. {{cite book}}: templatestyles stripmarker in |title= at position 1 (help).
That said, pb should not be used there in retrospect because |quote= is wrapped in <q> and pb introduces a <div>, which is invalid HTML (wow, it took me a while to realize). --Izno (talk) 01:46, 8 February 2021 (UTC)Reply
errm … sorry but I don't know what the original problem was. I am a dino of small brain, lacking in psychic powers. I don't understand why {{pb}} should be used in |quote=, as I would imagine that {{ubl}} or {{blist}} would be semantically correct for multiple items in those sort of cases (i.e. I expect the items would be list items). Can you explain simply enough for me to understand, please? --RexxS (talk) 02:54, 8 February 2021 (UTC)Reply
Hi RexxS, I haven't noticed problems with {{pb}} recently, and I don't remember what the problem used to be, sorry. SarahSV (talk) 04:06, 8 February 2021 (UTC)Reply
I don't know what the original problem was > "Does that problem still exist" > "No, para: quote can now accept arbitrary templatestyles templates". It's right above here. --Izno (talk) 04:18, 8 February 2021 (UTC)Reply
Okay, I followed the above thread to Veganism. It uses bundled references (such as "WatsonInterviews") consisting of multiple citations separated by {{pb}} and it looks like the 0.5em top-margin is required. That's unfortunate because the references are an ordered list, so the changes in the sandbox would remove that. It looks like we'll just have to live with the uneven gaps in discussions. Although I suppose we could amend the CSS to just remove the margin in unordered lists? Let's try that. --RexxS (talk) 05:13, 8 February 2021 (UTC)Reply