Yes, please do something about this issue, even (for the time being) just adding a magic word to configure behaviour of the template, would be helpful.

And another problematic case:
[[{{parent template}}]]  ( {{parent template}} giving ":Category:Foobar" )

This won't work either:
[[{{parent template}}]]  ( {{parent template}} giving "<nowiki />:Category:Foobar" )

I would suggest "normal" priority. This issue gives template editors many headaches, and often results in template codes much more complex than necessary. Thus, let's not forget this issue even further than now.

We're going to make this a child task of {{#balance}} for now, because when we add a warning people are going to want to know what to do to suppress the warning -- and the thing we're going to want people to do is opt in to balancing (to get their desired start-of-line context).

In T14974#4006494, @cscott wrote:

We're going to make this a child task of {{#balance}} for now, because when we add a warning people are going to want to know what to do to suppress the warning -- and the thing we're going to want people to do is opt in to balancing (to get their desired start-of-line context).

What is {{#balance}}?

If template returns #ccc and is used as style="color:{{template}}", {{#balance:inline}} would break the template, as it wraps the output with <span>...</span>.

In T14974#4008110, @Od1n wrote:

If template returns #ccc and is used as style="color:{{template}}", {{#balance:inline}} would break the template, as it wraps the output with <span>...</span>.

Understood. That is just an initial list of types in that proposal. Types could also be string, css, number, etc. for example. The wrapping can then be sensitive to the type and use-context.

...or just "attribute string" (output is html-escaped to be safe to include in attributes, no bare quotes allowed) or "attribute list" (validated to be valid attribute name=value pairs). I'm not convinced we should necessarily be validating number formats, css rules, etc. (Inspired by the set of template types available in spacebars, which impressed me as a good minimal-but-safe-and-structured template engine).

But yeah.

Why would we keep a template like this when the probably appropriate way to deal with it is TemplateStyles?

@Izno Correct me if I'm wrong but the TemplateStyle is a recent feature able to handle a CSS set of rules that can be shared between all template calls, but that can't be used to declare on runtime a CSS rule.

I think this is an issue currently discussed on c:Template_talk:Information. I recently rewrote c:Template:Information in Lua. The Lua code was trying to mimic perfectly the behavior of the old template, producing the same html for most files. We run into troubles when one of the fields to the template was another template using wiki tables ("{| ... |}"). Those rendered correctly when used in the old wikicode based template, but not in the new Lua one. The patch we used was to slap "\n" before and after every field in the template. It makes all infoboxes look strange (extra space around each field of the template), but at least all the transclusions of the template render correctly (AFAIK). Placing "<nowiki/> in front of each field did not fix the issue. One solution I am exploring is for lua to test if the content of each field contain "{|" (and possibly other strings) and only add "\n" when detected. Other proposed solution involve changes to CSS files. Help with potential solutions would be appreciated as we can not experiment very much, since the template is used on 51M file pages and we are trying to keep edits to the minimum.

Change 559542 had a related patch set uploaded (by C. Scott Ananian; owner: C. Scott Ananian):
[mediawiki/services/parsoid@master] Test case for implicit newline insertion when expanding templates (T14974)

https://gerrit.wikimedia.org/r/559542

MAIL non presidiata
ACCOUNT non pi? in utilizzo

:(

See T314593: Cosmetic newlines around <noinclude> tags should not be parsed as semantic newlines.

There's also the problem where MediaWiki still incorrectly surrounds a an <bdi></bdi> element (used as a *mixed-content* element whole content may be inline or block) by forcing its inclusion within a paragraph (within a dummy and undesired <p></p> HTML element, possibly also causing another block element containg it to be terminated too early). This causes problems for contents that should be purely inline and even totally invisible in the rendered page.

Some templates use <div style="display:none">...</div> with the assumption that it is always invisible, but then those templates cannot be used inline (e.g. they break paregraphs or list items and the list containg them, by inserting a separating paragraph, with also additional vertical margins). We should avoid "div" elements for that case, but "span" is not so versatile as its content-model is not mixed. Now if we want to use "bdi" (the only element allowed in Mediawiki to have mixed content, i.e. capable of containing inline or block elements), MediaWiki assumes that this is an inline element... and wants to make it part of a block, inserting it in a paragraph.

Examples of this are templates inserting "tags" for storing some data intended to be processed by machines for Wikidata. Shouldn't we have a Mediawiki-specific element that is to be completely invisible (it would generate a `<bdi style="display:none" data="..."></bdi> element) that the Mediawiki parser (or its last "TidyHTML" step) considers to be left as is (i.e. never embedded inside any other automatically-added element as it is warrantied to be always invisible?

Side note: a "bdi" element can occur anywhere even in the middle of a word, it does not have any effect on the directionality of surrounding text, or on line wraps. Even copy-pasting text containing a bdi element without any text content (only attributes) into a plain-text editor will not add anything, it is really invisible.

So that would be a use case for some <data someID="..."> element in MediaWiki, that would pass though the "HTML Tidy" step and converted into <bdi style="display:none" data-someID="..."></bdi> (the data would fit in the data attribute whose attribute name contains the given id, and where any backslash, newlines or double quotes in the data would be escaped in the attribute value; otherwise HTML-escaping using character entities are also possible for HTML transparency: such embedded data is supposed to be never read by humans, but only by machines, so a basic escaping in it will not be a problem for machines). That data element would accept no CSS style or class attributes, it is purely intended to be invisible, the CSS style="display:none" attribute is automatically added for the generated <bdi> element by the HTML generator in the last phase, but it could also generate some CSS class="mw-data" attribute instead).

Such thing would be useful for various purpose, including "micro-tagging" for semantics, or could be used as internal tracking metadata, or could facilititate the work of wiki editors. The "data" attributes can be used on any valid HTML elements, these attributes can have an extension chosen freely (as long as it is a valid HTML identifier) and appended after an hyphen, and they are also usable in CSS selectors if needed to perform efficent queries inside the DOM (e.g. for use in Javascript with jQuery). For embedding really-invisible data and generate valid HTML5, only the <bdi> element is valid and suitable for that purpose, and it is the only one accepted and supported (partially) by Mediawiki. But using a MediaWiki-specific <data> element would make things easier to handle in the MediaWiki parser and its HTML generator.

Such data element could also be used as a debugging tool for templates/modules, to contain some tracing info.

Note: this data element is also not equivalent to an invisible <input type="..." value="..."> element (which is visible to HTML input forms) or to a <meta> element (meant for web page headers and that are not freely insertable in the page content, but used by the HTML generator). It is a requirement that the chosen HTML element (that the data element will map to) has a "mixed" content-model, for full HTML5 conformance (and "bdi" is the only one well supported in browsers which has all the nice features for being fully invisible to human readers, especially when its inner content is empty (no child elements, only HTML attributes are permitted).

The MediaWiki <data> (or equivalently <#tag:data>) element should probably not accept any common HTML layout attributes like dir, style or class (they would have no effect at all anyway and the two last could conflict with the attributes generated by the parser when convertint the MediaWiki <data> element into an HTML5 <bdi> element). If such attributes are passed they would become data-dir, data-style, data-class. However I may see a use case for accepting the lang attribute specifically as a reserved identifier treated differently (and pass it "as is"), as a possible way to offer some functionality in selectors with jQuery that are not possible with 'data-someID' attributes.

It may eventually also accept an id attribute, only for such selectors, but it could cause conflicts with anchors used in page navigation and would make them partly "visible" to the human user, unless they are converted to another data-id attribute that is also usable in selectors for jQuery via a simple adjustment of the selector syntax.

Beside that, we could use multiple attributes in the same data element for different but simulteneous tagging purposes. E.g. <data lang="en" a="x" b="y"/> would become <bdi class="mw-data" lang="en" data-a="x" data-b="y"></bdi>.

If the MediaWiki data element has a content, that content would be remapped into the (unextended) data attribute of the generated HTML element (with proper escaping). E.g. <data lang="en" a="x" b="y">{ "text", 2 }</data> would become <bdi class="mw-data" lang="en" data-a="x" data-b="y" data="{ &quot;text&quot;, 2 }"></bdi>

So in summary, such "data" element will be a MediaWiki-safe replacement for an empty "bdi" element that will only hold invisible data. It will never be visible but will be processable by a machine (or by client-side Javascript tools that may transform hem to make them visible on demand: it will have enough attributes to perform all we want, including with selectors on all these attributes that can be used in jQuery). MediaWiki will recognize this data element easily, will neither consider them as inline or block elements, will not embed them into any undesired block elements, but will just HTML-ize them on the final conversion step into empty 'bdi" elements with converted data attributes.

@Verdy_p Can you explain in 2 sentences or less how that is relevant to this task?

I just noticed something surprising, and it's making me ponder. 🤔

I encountered the following in a template:

* foo
{{#if:true|* bar}}
* baz

Because of the issue at hand, I expected the result to be (erroneously two lists):

* foo

* bar
* baz

But actually (and I don't know why), the result is a collapsed list:

* foo
* bar
* baz

Additional information:

To confirm that automatic newline insertion still happens, I tried the following:

* foo{{#if:true|* bar}}
* baz

Which, as expected, results in:

* foo
* bar
* baz

I also tried, while investigating, manually inputting in page wikisource:

* foo

* bar
* baz

Which (as expected, as of today) doesn't get corrected to a collapsed list when previewing.

Looking at the relevant code: https://gerrit.wikimedia.org/g/mediawiki/core/+/c3631a24f1eae9b064fef27c89baccf8af191e0c/includes/parser/Parser.php#3347

…I think the check for !$piece['lineStart'] makes the newline insertion not happen if the expression being expanded is already at the start of a line. This would explain what you're seeing.