Page MenuHomePhabricator

Provide magic word for 'soft' newline insertion from template markup.
Open, Needs TriagePublicFeature

Description

Problem:
Under certain use-cases the Mediwiki parser may try to wrap paragraph tags in the wrong place during the construction of complex layouts involving templates utilising certain HTML constructions.

Currently without 'soft' newlines placed at certain locations , under certain situations the parser effectively generates badly formed HTML (see T134469 and related.)

When generating HTML/markup from a LUA script, it is very easy to resolve this by appending '\n' to the appropriate strings which when passed to the Parser, results in cleanly formed HTML. (I used this approach successfully in https://en.wikisource.org/wiki/Module:Cl-act, function begin_internal to resolve a long standing issue, in relation to formatting concerns in some test cases (https://en.wikisource.org/wiki/Template:Cl-act-p/testcases#Testing_start_and_end_version_for_higher_level. )

Insertion of these 'soft' newlines, which are useful in ensuring the paragraph wrapping is more correct, is more problematic from template calls. Whilst in some template code it is possible to insert 'blank' lines in the template code to simulate a 'soft' newline, this can be confusing for template editors, and is sensitive to those line-feeds being removed in error as templates are updated or amended.

What is being requested :

A means of requesting a 'soft' newline by means of a magic word , such as {{#br}} from template markup, which has the same effect as the insertion of blank line within the template markup ( and analogous to the appending of '\n' in the LUA script.)

Why?:
Having the ability to insert the 'soft' newlines with a magic word, rather than a blank line is easier to read and maintain, as well as allowing template developers and maintainers to be less confused about where newlines (and thus potential P wrapping) should be taking place or should have taken place within templates they are writing.

Test case:

Wikitext (in template):

{{#ifeq:{{{inline}}}|yes|<span>{{{1}}}</span>|<div>{{#br}}{{{1}}}{{#br}}</div>

If invoked, this would generate (for inline=yes)

<span>{{{1}}}</span> which is acceptable for inclusion with in a P or SPAN,

(for inline=no)

<div>
{{{1}}}
</div>

Which the parser should correctly wrap as :

<div><p>{{{1}}}</p></div>

for inlne=no and 1=<span style="font-weight:bold;">This is to test the DIV SPAN P wrapping behaviour</span>

Should give as output

<div>
<span style="font-weight:bold;">This is to test the DIV SPAN P wrapping behaviour</span>
</div>

which should be appropriately wrapped by the parser to become.

<div>
<p><span style="font-weight:bold;">This is to test the DIV SPAN P wrapping behaviour</span></P>
</div>

Event Timeline

Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptMay 20 2020, 2:26 PM
ShakespeareFan00 renamed this task from Provide magic word for 'soft' newline insertion (obviating need for blank lines) from template markup. to Provide magic word for 'soft' newline insertion from template markup..May 20 2020, 2:32 PM

{{#ifeq:{{{inline}}}|yes|<span>{{{1}}}</span>|<div>{{#br}}{{{1}}}{{#br}}</div>

Why can't you use <br> instead of {{#br}} here?

ShakespeareFan00 added a comment.EditedMay 20 2020, 4:35 PM

That would place a hard-newline<br> into the output, potentially resulting in undesirable additional white-space, and
crucially would not necessarily insert the context change that the parser (in it's current form needs to see to correctly insert the P opening and closing tag)

using a hard BR over a soft-break would generate :
<DIV><br>{{{1}}}<br>div>
which means that the P wrapping isn't attempted. (That is reasonable in a simple case.)

However If paramater 1 was for example (the line feeds are significant, and as it's an unnamed parameter preserved):

<SPAN style="font-weight:bold> Example: </span>
And this is the continued text on the next line.

Would generate:

<DIV><br><SPAN style="font-weight:bold>Example: </span>
And this is the continued text on the next line.<br><div>'

This works, but will generate additional blank lines before and after the content.

A contributors intent here could reasonably be that "<SPAN style="font-weight:bold>Example: </span> And this is the continued text on the next line. " was one self-contained paragraph.

(continued below)

ShakespeareFan00 closed this task as Invalid.May 20 2020, 4:45 PM
Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptMay 20 2020, 4:45 PM
This comment was removed by ShakespeareFan00.
ShakespeareFan00 added a comment.EditedMay 20 2020, 4:53 PM

Someone with appropriate expertise (I don't have it) should sit down and fully document what's actually happening in the parser in various instances.

ShakespeareFan00 reopened this task as Open.May 20 2020, 4:54 PM
ShakespeareFan00 added a comment.EditedMay 20 2020, 5:40 PM

With BR you get :=

<div><br /><span> content</span> 
content<br /></div>

No paragraph wrapping is attempted. and you get an additional (possibly undesirable white-space line before and after the content. Ugly and not good coding style.

<DIV>
<SPAN> content</span> 
content
</div>

works

Generating:

<div>
<p><span> content</span> 
content
</p>
</div>

which is typically what a template writer wants to happen.

<DIV<SPAN> content</span> 
content</div>

Which is what potentially happens without the soft line break in some situation, doesn't it generates :

<div><span> content</span> 
<p>content
</p>
</div></div>

Which is the "wrapping glitch" in the linked ticket.

From this it is clear that that to have the desired behaviour of wrapping the DIV around the P. The DIV's opening and closing must be on a single line.

Conventionally in wikitext based templates this has been done by inserting 'soft'-newlines..

i.e the template code for a DIV based template might be

<div>
{{{1}}}
</div>

But without directly indicating the 'soft' line-feeds this could in certain situation collapse to

<div>{{{1}}}</div>

which again risks invoking the 'glitch' in the linked ticket depending on what the value of {{{1}}} is.

by having the {{#br}} as an explicitly requested 'soft' line break,

<div>{{#br}}{{{1}}}{{#br}}</div>

the generated output from the template concerned is always going to place the opening of the DIV, parameter {{{1}}} , and the closing of the DIV tag on separate lines, regardless of how that construction might be being produced within a template, or in paramaters which in more complex templates would be a good thing, and in my view less error prone.

(The example I gave in the original posting was much simplified, For a real world example where something like this would assist would be https://en.wikisource.org/wiki/Template:Lang block , https://en.wikisource.org/wiki/Template:Lang and https://en.wikisource.org/wiki/Page:Beowulf_(Wyatt).djvu/115. In Lang the generated code should be

<DIV> 
....
</DIV>

but the way the code is currently written it doesn't gneretae that. Having the magic word {{#br}} to indicate the required 'soft' newline would be a straightforward and easy insertion into the code, and would be less complicated than having to figure out where a line-feed/carriage return/newline should be placed in the template logic to get the same effect, and whose inadvertent removal would change how the template worked.)

As I said initially, in LUA I can append a '\n' where needed. There should be a clean, error-free way to do this in normal templates as well.

DIV{{#br}}content{{#br}}DIV

being less error prone than

<DIV>
content
</DIV>

(with apologies for the convoluted process involved in providing the expanded explanations)