![]() |
Daily pageviews of Help:Line-break handling
A graph should have been displayed here but
graphs are temporarily disabled. Until they are enabled again, visit the interactive graph at
pageviews.wmcloud.org |
This is the
talk page for discussing improvements to the
Line-break handling page. |
|
Archives:
1Auto-archiving period: 360 days
![]() |
![]() | This help page does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
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:
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)
![]() | This help request has been answered. If you need more help, you can , contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse. |
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)
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:
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)
One method of multiple paragraphs.
Is like 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:
* Date nuts
...but in all three examples the second asterisk remains unconverted because it isn't on a new line, like in this case:
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)
|see also=
):{{Single notice|see also=
*Foo
*Bar}}
blist
". So, {{
blist|Cat|Dog|Ferret}}
emits |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){{
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)
An editor has identified a potential problem with the redirect
Wikipedia:NOBR and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 November 21#Wikipedia:NOBR until a consensus is reached, and readers of this page are welcome to contribute to the discussion.
XtraJovial (
talk •
contribs)
01:35, 21 November 2022 (UTC)
This page is not a policy or guideline. I don't think we should be making life more complicated for average editors by discouraging them from using the simpler <br>.
Therefore I suggest syntax highlighters be changed to accept <br>, or to ignore it, or to ignore all the <br> break forms.
This is in response to this note from Jonesey95 on my talk page:
Please do not remove slashes from br tags. Please do not do this. It interferes with the proper functioning of syntax highlighters. Please see H:BR for an explanation. – Jonesey95 ( talk) 18:41, 7 December 2022 (UTC)
I have seen this discussion elsewhere, and in most cases help pages end up going back to using <br> because helping average editors is more important in many people's eyes than pleasing the few people using the problematic syntax highlighters. -- Timeshifter ( talk) 08:57, 8 December 2022 (UTC)
<br>
is a known issue, see
mw:User:Remember the dot/Syntax highlighter#Parsing - feature requests for that may be left at
User talk:Remember the dot, see
mw:User:Remember the dot/Syntax highlighter#Reporting bugs. --
Redrose64 🌹 (
talk)
18:19, 8 December 2022 (UTC)
<br>
form. Altering the guidance and then asking the various software providers to comply with the changed guidance will not yield a swift response. Yes, <br>
is valid HTML but so is <br />
, and is really not that much more difficult to type. Over the last twelve years or so I have got so used to it that I type in the space and slash instinctively, just as I do for <hr />
, <img ... />
, <link ... />
, <wbr />
and
several others. --
Redrose64 🌹 (
talk)
00:02, 9 December 2022 (UTC)
What the proposal actually says is placed on the wrong page, yes. But the proposal that is left unsaid, I agree with: let us ignore syntax highlighters. If they want to remain unable to understand <br>, that's their problem. Meanwhile, the world will keep on using <br>, pretty much regardless of what our page says. So why not simply change it to accept <br>? Honestly, any piece of software that still can't handle <br> probably should be ignored. CapnZapp ( talk) 20:09, 12 December 2022 (UTC)
and so should be avoided.should no longer be in
... they can break several of the available syntax highlighters for wiki code in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided.. The default syntax highlighter supports <br> just fine, and from memory I don't believe the wikEd highlighter had issues with it either (but I used that one a long time ago). The only one I can recall being an issue is Remember the dot's (which is the one offered as a separate gadget). That editor has previously refused to make the relevant change, so I do not think we should be basing any of our help or guidance text based on that highlighter accordingly. HTML is not XML and has not been XHTML in over a decade. Izno ( talk) 20:36, 12 December 2022 (UTC)
and so should be avoided.
<references/>
, <section/>
and its many translations, etc.) that must be closed with a slash. I suspect that MediaWiki does not support implicitly closing these tags for pretty much the same reasons that I don't want to support implicitly closed tags in the syntax highlighter gadget. (And no one else has stepped up to support this in the gadget's code either.) That said, I really don't care about it as much as I used to, and I want to respect community consensus, so I've
added a voidTags
config parameter to the syntax highlighter which can contain a list of implicitly self-closed tags. You can set this parameter on a per-site basis in
MediaWiki:Gadget-DotsSyntaxHighlighter.js by following the instructions at
mw:User:Remember the dot/Syntax highlighter#Site defaults. The list is empty by default, which will hopefully keep its impact on performance negligible by default, and also hopefully make it clear that the user or site administrator will have to keep the list up to date if new self-closing tags are added or removed. Happy holidays, and let there be peace on Earth, or at least on Wikipedia. —
Remember the dot (
talk)
22:15, 25 December 2022 (UTC)
See MOS:SIMPLIFY ( Wikipedia:Manual of Style#Keep markup simple): Excerpt: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly."
See also: KISS principle.
The <br /> or <br> section of Help:Line-break handling needs to be completely rewritten. I may get around to it if someone else does not do it first. -- Timeshifter ( talk) 00:52, 13 February 2023 (UTC)
<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/>
."See Special:Diff/1144939614. Redrose64 edit summary: "I am still seeing unnecessary alterations, so describe exactly what happens (checking page source, it seems that MediaWiki now favours the <br/> form without space) - have tested this at Special:Diff/1144937008"
That was tested in a sandbox that is overwritten soon. Here is the test in a permanent sandbox:
When I look at the page source from my Firefox browser I see that the emitted HTML is <br /> and not <br/>
But none of that matters in what we recommend average editors use. Most people in this thread agree that we should recommend the simplest form: <br>
KISS principle. We are not stopping people from using other forms. Those forms may actually be simpler for them since that is what they are used to using in their other programming. But they are a small subset of Wikipedia editors. -- Timeshifter ( talk) 13:08, 16 March 2023 (UTC)
That was tested in a sandbox that is overwritten soon, yes, that is why I supplied it as a diff - it will be available indefinitely.
When I look at the page source from my Firefox browser- are you using the browser's "inspect" feature, or the true "View page source" feature? In Firefox, the source displayed by "inspect" is sanitised.
<br>
, <br />
, and <br >
to <br/>
. It also converts the invalid form </br>
to <br/>
."<br>
, <br >
, <br/>
or <br />
makes absolutely no difference at all to the display of the rendered page. There are two reasons for this: (i) the MediaWiki software converts three of them to the fourth when the page is served to the client; (ii) even if the MediaWiki software did not do that, all major browsers (and most others) treat all four versions identically. So there is no reason to alter one of these to any other. That said, when editing a page and certain syntax-highlighting tools are in use, the <br>
and <br >
forms can give a less-satisfactory experience compared to the <br/>
and <br />
forms. So some people will alter an unslashed form to a slashed form when making an edit for another reason; but the space is always optional. --
Redrose64 🌹 (
talk)
11:52, 17 March 2023 (UTC)By the way, I like my outdents messy. :)
CJDOS, Redrose64. The syntax highlighter in question was discussed higher up. Its author refuses to make it work by default. People have to take extra steps. I am guessing it is done this way because the extra code that is required would slow it down too much for his liking. The extra work required to deal with the many variations of various bits of HTML that MediaWiki accepts but his syntax highlighter does not.
Many in this thread have said that Mediawiki should not change, but that his syntax highlighter should change, since only a relatively few people use it. Versus the millions of Wikipedia editors who come and go, and prefer things simple.
I have done a lot of editing at Fandom/Wikia. The standard default source mode editing window I am using comes with a syntax highlighter. It has no problem with <br>.
<br> is used most of the time on Wikipedia. So there is little improvement to the syntax highlighter here when a relatively few coders and programmers use the slashed forms. A single use of <br> in the edit window here breaks the syntax highlighting.
So this whole effort is pointless, and only makes the average editor unnecessarily confused. We should recommend the simplest form, <br>, as we did in the past. -- Timeshifter ( talk) 17:14, 17 March 2023 (UTC)
<br />
in the HTML.<br>
is more
simple than <br />
, really? It is two characters longer. Are we going to start changing "colour" to "color" because the latter is more "simple"? Or even take this very section header: do you think it is easier to figure out what <br />
means given that you know what <br>
means, or to figure out what <br> means? I would actually argue that <br />
is more intuitive: it follows the general principle that a slash ends the effect of a given HTML tag. Add me to the list of people that think we should encourage <br />
, but only as a
WP:COSMETIC change.
House
Blaster
talk
01:38, 16 April 2023 (UTC)
MOS:SIMPLIFY: See: <wbr> in this section: Help:HTML in wikitext#Formatting. <wbr /> is not mentioned there.
I changed the <wbr> and soft hyphens section of Help:Line-break handling. <wbr> is now used there instead of <wbr />
See diff and this version of the help page. -- Timeshifter ( talk) 19:19, 23 February 2023 (UTC)
<wbr>
in this section:
Help:HTML in wikitext#Formatting. <wbr />
is not mentioned there, though Wikipedia will accept that variant."though Wikipedia will accept that variant, it's not Wikipedia; it's web browsers - and I don't know of any that won't treat
<wbr>
and <wbr />
as exact equivalents. It's part of the HTML spec that
void elements (such as br and wbr) do not have end tags, and may be written either with or without the slash (see
section 8.1.2.1 item 6). So I see absolutely no reason to discourage the <br />
and <wbr />
forms. --
Redrose64 🌹 (
talk)
20:10, 25 February 2023 (UTC)
<img />
is forbidden, not because of the slash but because the img element as a whole is not in the whitelist - for that reason, <img>
is also forbidden. There are more than fifty elements defined in the HTML 5.2 spec which are not whitelisted. --
Redrose64 🌹 (
talk)
22:48, 25 February 2023 (UTC)I think that help pages should point out the simplest HTML first. MOS:SIMPLIFY. We can then mention other less-simple HTML such as tags with a blank space and a slash. And everything else. But we should also point out that using the simplest HTML helps new editors. Complex HTML should actively be discouraged.
See Wikipedia talk:Line breaks usage (from 2006-2008) and the section titled: <br> vs <br />. I especially like this example from David Göthberg in 2008:
Well, let's first ask another question: Which markup should we use for bold text?
I think we all know that the wikimarkup |
The last 2 bolding methods should be actively discouraged. -- Timeshifter ( talk) 00:09, 26 February 2023 (UTC)
<span style="font-weight:bold;">Bold</span>
<b>...</b>
instead of '''...'''
. Similarly, people shouldn't be admonished for using <wbr />
instead of <wbr>
- Wikipedia handles both just as well as each other, and so do all browsers. Neither form is more "correct" than the other. --
Redrose64 🌹 (
talk)
11:55, 26 February 2023 (UTC)
There are many templates that allow HTML markup to be used without putting it in articles directlyfor instance. For editors with zero HTML experience, this is useful information for sure. For editors with HTML experience, on the other hand, it is fortunate that this sentence is offering a solution, not telling us we must use it, since if you already know to do it in HTML, having to learn about Wiki templates whose function is only to "hide" HTML (while introducing a new programming hurdle that is arguably just as high to everyone except maybe Wiki grognards...!) would be a pain. So while saying "MOS:SIMPLIFY is prescriptive" is true, it actually has to prescribe something for it to be prescriptive in practice. (Still not sure whether we actually disagree; posting this mostly for clarity) CapnZapp ( talk) 15:31, 26 February 2023 (UTC)
You wrote: "You keep pointing to 'keep it simple'.... but both variants are arguably equally simple to use and understand!"
For the vast majority of editors <br /> means adding a space and a slash to <br>. So <br /> is not simpler. So help pages should recommend the simpler version for most people. Some, not all, HTML coders may think both are equally simple since they may no longer even think about it. They are not prohibited from using <br /> though I wish they would think about the average editor.
Same for <wbr /> and <wbr>.
As I said before, and we apparently disagree, I believe the first sentence in MOS:SIMPLIFY "Other things being equal, keep markup simple" is also prescriptive. By itself. -- Timeshifter ( talk) 16:04, 26 February 2023 (UTC)
Be mindful between asking and telling, is all I am saying. As Redrose stated, The thing is, some people take
H:LINEBREAK and
H:HTML as describing the only permitted forms, and actively alter all other forms
. Please don't be those people, and please don't write help pages as if addressed to those people.
This discussion started because you didn't just say I changed the <wbr> and soft hyphens section of Help:Line-break handling.
You also justified those changes with MOS:SIMPLIFY: See: <wbr> in this section: Help:HTML in wikitext#Formatting. <wbr /> is not mentioned there.
This made my alarm bell go off - could it be that Timeshifter is misreading our Manual of Style's instruction to keep markup simple to mean detailed instructions on what HTML to use and not to use? To that end, I explained to you that the MOS is not saying that <wbr /> is somehow wrong.
Again, if you made the edit because you want to recommend "simple" forms to beginners, that's fine. But if you made the edit because you think that <wbr /> is somehow wrong, or that our MOS discourages it, then you need to think again. Don't waste your time changing fully functional HTML, and most of all, don't tell editors they're writing the wrong HTML code - specifically: don't tell editors they're not writing HTML that isn't simple enough. Wiki markup is indeed its special code language, but when editors reach its limits and resort to HTML, the manual of style does not prescribe details. All it does, is make sure everybody agrees that when and if wiki markup is sufficient, use that in preference to using HTML. Do not interpret some forms of HTML as "simpler" than others - some sticklers for standards will inevitably misunderstand this to mean Wikipedia should only contained "well-formed" HTML. This obscures the greater goal - that Wikipedia does not ask coders to learn a special dialect of HTML for Wikipedia. If you need to use HTML, any HTML that's good enough for browsers is good enough for us. (With a well-defined set of exceptions)
Again, not saying you do any of this. Just making sure we're on the same page. Had you just made your edits, I probably wouldn't have responded. But with your justification I felt the need to set the record straight. Cheers. CapnZapp ( talk) 14:09, 27 February 2023 (UTC)
![]() |
Daily pageviews of Help:Line-break handling
A graph should have been displayed here but
graphs are temporarily disabled. Until they are enabled again, visit the interactive graph at
pageviews.wmcloud.org |
This is the
talk page for discussing improvements to the
Line-break handling page. |
|
Archives:
1Auto-archiving period: 360 days
![]() |
![]() | This help page does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
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:
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)
![]() | This help request has been answered. If you need more help, you can , contact the responding user(s) directly on their user talk page, or consider visiting the Teahouse. |
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)
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:
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)
One method of multiple paragraphs.
Is like 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:
* Date nuts
...but in all three examples the second asterisk remains unconverted because it isn't on a new line, like in this case:
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)
|see also=
):{{Single notice|see also=
*Foo
*Bar}}
blist
". So, {{
blist|Cat|Dog|Ferret}}
emits |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){{
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)
An editor has identified a potential problem with the redirect
Wikipedia:NOBR and has thus listed it
for discussion. This discussion will occur at
Wikipedia:Redirects for discussion/Log/2022 November 21#Wikipedia:NOBR until a consensus is reached, and readers of this page are welcome to contribute to the discussion.
XtraJovial (
talk •
contribs)
01:35, 21 November 2022 (UTC)
This page is not a policy or guideline. I don't think we should be making life more complicated for average editors by discouraging them from using the simpler <br>.
Therefore I suggest syntax highlighters be changed to accept <br>, or to ignore it, or to ignore all the <br> break forms.
This is in response to this note from Jonesey95 on my talk page:
Please do not remove slashes from br tags. Please do not do this. It interferes with the proper functioning of syntax highlighters. Please see H:BR for an explanation. – Jonesey95 ( talk) 18:41, 7 December 2022 (UTC)
I have seen this discussion elsewhere, and in most cases help pages end up going back to using <br> because helping average editors is more important in many people's eyes than pleasing the few people using the problematic syntax highlighters. -- Timeshifter ( talk) 08:57, 8 December 2022 (UTC)
<br>
is a known issue, see
mw:User:Remember the dot/Syntax highlighter#Parsing - feature requests for that may be left at
User talk:Remember the dot, see
mw:User:Remember the dot/Syntax highlighter#Reporting bugs. --
Redrose64 🌹 (
talk)
18:19, 8 December 2022 (UTC)
<br>
form. Altering the guidance and then asking the various software providers to comply with the changed guidance will not yield a swift response. Yes, <br>
is valid HTML but so is <br />
, and is really not that much more difficult to type. Over the last twelve years or so I have got so used to it that I type in the space and slash instinctively, just as I do for <hr />
, <img ... />
, <link ... />
, <wbr />
and
several others. --
Redrose64 🌹 (
talk)
00:02, 9 December 2022 (UTC)
What the proposal actually says is placed on the wrong page, yes. But the proposal that is left unsaid, I agree with: let us ignore syntax highlighters. If they want to remain unable to understand <br>, that's their problem. Meanwhile, the world will keep on using <br>, pretty much regardless of what our page says. So why not simply change it to accept <br>? Honestly, any piece of software that still can't handle <br> probably should be ignored. CapnZapp ( talk) 20:09, 12 December 2022 (UTC)
and so should be avoided.should no longer be in
... they can break several of the available syntax highlighters for wiki code in the editing view (mis-highlighting all text in the page after the occurrence of that tag), and so should be avoided.. The default syntax highlighter supports <br> just fine, and from memory I don't believe the wikEd highlighter had issues with it either (but I used that one a long time ago). The only one I can recall being an issue is Remember the dot's (which is the one offered as a separate gadget). That editor has previously refused to make the relevant change, so I do not think we should be basing any of our help or guidance text based on that highlighter accordingly. HTML is not XML and has not been XHTML in over a decade. Izno ( talk) 20:36, 12 December 2022 (UTC)
and so should be avoided.
<references/>
, <section/>
and its many translations, etc.) that must be closed with a slash. I suspect that MediaWiki does not support implicitly closing these tags for pretty much the same reasons that I don't want to support implicitly closed tags in the syntax highlighter gadget. (And no one else has stepped up to support this in the gadget's code either.) That said, I really don't care about it as much as I used to, and I want to respect community consensus, so I've
added a voidTags
config parameter to the syntax highlighter which can contain a list of implicitly self-closed tags. You can set this parameter on a per-site basis in
MediaWiki:Gadget-DotsSyntaxHighlighter.js by following the instructions at
mw:User:Remember the dot/Syntax highlighter#Site defaults. The list is empty by default, which will hopefully keep its impact on performance negligible by default, and also hopefully make it clear that the user or site administrator will have to keep the list up to date if new self-closing tags are added or removed. Happy holidays, and let there be peace on Earth, or at least on Wikipedia. —
Remember the dot (
talk)
22:15, 25 December 2022 (UTC)
See MOS:SIMPLIFY ( Wikipedia:Manual of Style#Keep markup simple): Excerpt: "Other things being equal, keep markup simple. This makes wikitext easier to understand and edit, and the results seen by the reader more predictable. Use HTML and CSS markup sparingly."
See also: KISS principle.
The <br /> or <br> section of Help:Line-break handling needs to be completely rewritten. I may get around to it if someone else does not do it first. -- Timeshifter ( talk) 00:52, 13 February 2023 (UTC)
<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/>
."See Special:Diff/1144939614. Redrose64 edit summary: "I am still seeing unnecessary alterations, so describe exactly what happens (checking page source, it seems that MediaWiki now favours the <br/> form without space) - have tested this at Special:Diff/1144937008"
That was tested in a sandbox that is overwritten soon. Here is the test in a permanent sandbox:
When I look at the page source from my Firefox browser I see that the emitted HTML is <br /> and not <br/>
But none of that matters in what we recommend average editors use. Most people in this thread agree that we should recommend the simplest form: <br>
KISS principle. We are not stopping people from using other forms. Those forms may actually be simpler for them since that is what they are used to using in their other programming. But they are a small subset of Wikipedia editors. -- Timeshifter ( talk) 13:08, 16 March 2023 (UTC)
That was tested in a sandbox that is overwritten soon, yes, that is why I supplied it as a diff - it will be available indefinitely.
When I look at the page source from my Firefox browser- are you using the browser's "inspect" feature, or the true "View page source" feature? In Firefox, the source displayed by "inspect" is sanitised.
<br>
, <br />
, and <br >
to <br/>
. It also converts the invalid form </br>
to <br/>
."<br>
, <br >
, <br/>
or <br />
makes absolutely no difference at all to the display of the rendered page. There are two reasons for this: (i) the MediaWiki software converts three of them to the fourth when the page is served to the client; (ii) even if the MediaWiki software did not do that, all major browsers (and most others) treat all four versions identically. So there is no reason to alter one of these to any other. That said, when editing a page and certain syntax-highlighting tools are in use, the <br>
and <br >
forms can give a less-satisfactory experience compared to the <br/>
and <br />
forms. So some people will alter an unslashed form to a slashed form when making an edit for another reason; but the space is always optional. --
Redrose64 🌹 (
talk)
11:52, 17 March 2023 (UTC)By the way, I like my outdents messy. :)
CJDOS, Redrose64. The syntax highlighter in question was discussed higher up. Its author refuses to make it work by default. People have to take extra steps. I am guessing it is done this way because the extra code that is required would slow it down too much for his liking. The extra work required to deal with the many variations of various bits of HTML that MediaWiki accepts but his syntax highlighter does not.
Many in this thread have said that Mediawiki should not change, but that his syntax highlighter should change, since only a relatively few people use it. Versus the millions of Wikipedia editors who come and go, and prefer things simple.
I have done a lot of editing at Fandom/Wikia. The standard default source mode editing window I am using comes with a syntax highlighter. It has no problem with <br>.
<br> is used most of the time on Wikipedia. So there is little improvement to the syntax highlighter here when a relatively few coders and programmers use the slashed forms. A single use of <br> in the edit window here breaks the syntax highlighting.
So this whole effort is pointless, and only makes the average editor unnecessarily confused. We should recommend the simplest form, <br>, as we did in the past. -- Timeshifter ( talk) 17:14, 17 March 2023 (UTC)
<br />
in the HTML.<br>
is more
simple than <br />
, really? It is two characters longer. Are we going to start changing "colour" to "color" because the latter is more "simple"? Or even take this very section header: do you think it is easier to figure out what <br />
means given that you know what <br>
means, or to figure out what <br> means? I would actually argue that <br />
is more intuitive: it follows the general principle that a slash ends the effect of a given HTML tag. Add me to the list of people that think we should encourage <br />
, but only as a
WP:COSMETIC change.
House
Blaster
talk
01:38, 16 April 2023 (UTC)
MOS:SIMPLIFY: See: <wbr> in this section: Help:HTML in wikitext#Formatting. <wbr /> is not mentioned there.
I changed the <wbr> and soft hyphens section of Help:Line-break handling. <wbr> is now used there instead of <wbr />
See diff and this version of the help page. -- Timeshifter ( talk) 19:19, 23 February 2023 (UTC)
<wbr>
in this section:
Help:HTML in wikitext#Formatting. <wbr />
is not mentioned there, though Wikipedia will accept that variant."though Wikipedia will accept that variant, it's not Wikipedia; it's web browsers - and I don't know of any that won't treat
<wbr>
and <wbr />
as exact equivalents. It's part of the HTML spec that
void elements (such as br and wbr) do not have end tags, and may be written either with or without the slash (see
section 8.1.2.1 item 6). So I see absolutely no reason to discourage the <br />
and <wbr />
forms. --
Redrose64 🌹 (
talk)
20:10, 25 February 2023 (UTC)
<img />
is forbidden, not because of the slash but because the img element as a whole is not in the whitelist - for that reason, <img>
is also forbidden. There are more than fifty elements defined in the HTML 5.2 spec which are not whitelisted. --
Redrose64 🌹 (
talk)
22:48, 25 February 2023 (UTC)I think that help pages should point out the simplest HTML first. MOS:SIMPLIFY. We can then mention other less-simple HTML such as tags with a blank space and a slash. And everything else. But we should also point out that using the simplest HTML helps new editors. Complex HTML should actively be discouraged.
See Wikipedia talk:Line breaks usage (from 2006-2008) and the section titled: <br> vs <br />. I especially like this example from David Göthberg in 2008:
Well, let's first ask another question: Which markup should we use for bold text?
I think we all know that the wikimarkup |
The last 2 bolding methods should be actively discouraged. -- Timeshifter ( talk) 00:09, 26 February 2023 (UTC)
<span style="font-weight:bold;">Bold</span>
<b>...</b>
instead of '''...'''
. Similarly, people shouldn't be admonished for using <wbr />
instead of <wbr>
- Wikipedia handles both just as well as each other, and so do all browsers. Neither form is more "correct" than the other. --
Redrose64 🌹 (
talk)
11:55, 26 February 2023 (UTC)
There are many templates that allow HTML markup to be used without putting it in articles directlyfor instance. For editors with zero HTML experience, this is useful information for sure. For editors with HTML experience, on the other hand, it is fortunate that this sentence is offering a solution, not telling us we must use it, since if you already know to do it in HTML, having to learn about Wiki templates whose function is only to "hide" HTML (while introducing a new programming hurdle that is arguably just as high to everyone except maybe Wiki grognards...!) would be a pain. So while saying "MOS:SIMPLIFY is prescriptive" is true, it actually has to prescribe something for it to be prescriptive in practice. (Still not sure whether we actually disagree; posting this mostly for clarity) CapnZapp ( talk) 15:31, 26 February 2023 (UTC)
You wrote: "You keep pointing to 'keep it simple'.... but both variants are arguably equally simple to use and understand!"
For the vast majority of editors <br /> means adding a space and a slash to <br>. So <br /> is not simpler. So help pages should recommend the simpler version for most people. Some, not all, HTML coders may think both are equally simple since they may no longer even think about it. They are not prohibited from using <br /> though I wish they would think about the average editor.
Same for <wbr /> and <wbr>.
As I said before, and we apparently disagree, I believe the first sentence in MOS:SIMPLIFY "Other things being equal, keep markup simple" is also prescriptive. By itself. -- Timeshifter ( talk) 16:04, 26 February 2023 (UTC)
Be mindful between asking and telling, is all I am saying. As Redrose stated, The thing is, some people take
H:LINEBREAK and
H:HTML as describing the only permitted forms, and actively alter all other forms
. Please don't be those people, and please don't write help pages as if addressed to those people.
This discussion started because you didn't just say I changed the <wbr> and soft hyphens section of Help:Line-break handling.
You also justified those changes with MOS:SIMPLIFY: See: <wbr> in this section: Help:HTML in wikitext#Formatting. <wbr /> is not mentioned there.
This made my alarm bell go off - could it be that Timeshifter is misreading our Manual of Style's instruction to keep markup simple to mean detailed instructions on what HTML to use and not to use? To that end, I explained to you that the MOS is not saying that <wbr /> is somehow wrong.
Again, if you made the edit because you want to recommend "simple" forms to beginners, that's fine. But if you made the edit because you think that <wbr /> is somehow wrong, or that our MOS discourages it, then you need to think again. Don't waste your time changing fully functional HTML, and most of all, don't tell editors they're writing the wrong HTML code - specifically: don't tell editors they're not writing HTML that isn't simple enough. Wiki markup is indeed its special code language, but when editors reach its limits and resort to HTML, the manual of style does not prescribe details. All it does, is make sure everybody agrees that when and if wiki markup is sufficient, use that in preference to using HTML. Do not interpret some forms of HTML as "simpler" than others - some sticklers for standards will inevitably misunderstand this to mean Wikipedia should only contained "well-formed" HTML. This obscures the greater goal - that Wikipedia does not ask coders to learn a special dialect of HTML for Wikipedia. If you need to use HTML, any HTML that's good enough for browsers is good enough for us. (With a well-defined set of exceptions)
Again, not saying you do any of this. Just making sure we're on the same page. Had you just made your edits, I probably wouldn't have responded. But with your justification I felt the need to set the record straight. Cheers. CapnZapp ( talk) 14:09, 27 February 2023 (UTC)