The newline added to a template, magic word, variable, or parser function that returns line-start wikicode formatting (*#:; {|) causes unexpected parsing
Open, HighPublic

Description

Author: wiki.warx

Description:
assume there is tamplate named color with content #002255 (normal color definition) if its transcluded this way:

<span style="color:{{color}}"></span>

It works perfectly - it gives

<span style="color: #002255;">test</span>

But if you use it in a table (or anywhere else not inside tag attribute) it crashes:

{| style="color:{{color}};"
|-
| test
|-
|}

gives:

<table>
<ol><li>002255;"
</li></ol>

<tr>
<td> test
</td></tr>
</table>

same:

<p>test {{color}} test</p>

gives:

<p>test 

<ol><li>002255 test</p>
</li></ol>

This has even broken tag nesting!!!


Version: unspecified
Severity: major
URL: http://test.wikipedia.org/wiki/Newline_through_parser_functions
See Also: T25674

There are a very large number of changes, so older changes are hidden. Show Older Changes

herd wrote:

Update summary to catch more dupes

herd wrote:

*** Bug 19144 has been marked as a duplicate of this bug. ***

herd wrote:

*** Bug 20574 has been marked as a duplicate of this bug. ***

herd wrote:

*** Bug 20592 has been marked as a duplicate of this bug. ***

rockmfr wrote:

On a page named "*", "a{{PAGENAME}}a" gives "a<ul><li>*</li></ul>a" instead of "a*a". This particular regression was caused by r29205. So I'm assuming that this whole class of bugs are all being tracked in this one bug?

We ran into this particular problem on enwiki at [[MediaWiki:Histlegend]]. No workaround yet.

catlow wrote:

Can this behaviour not at least be disabled for such pseudo-templates as PAGENAME?

*** Bug 22086 has been marked as a duplicate of this bug. ***

happy.melon.wiki wrote:

This behaviour is unjustifiable. The original bug has a trivial workaround: judicious use of newlines where appropriate. The 'solution' creates problems with no reasonable workarounds, such as noted in comments 6, 7, 10, 11, 20 above. However longstanding the feature, this functionality is broken.

Unless there are serious counterarguments, I intend to undo the newline-insertion added for bug529, WONTFIXing that and FIXing this. CCing Tim for parsery-ness.

You realise it will break many, many templates if it's removed, right?

happy.melon.wiki wrote:

In the same way the original fix presumably broke many templates, given all these unexpected side effects, yes. However, those breakages can be fixed, unlike some of the breakages it causes. And since the syntax without the bug529 is valid regardless, templates can be fixed any time, before or after they become broken. No one can fix {{talkpage}} on [[Talk:*-algebra]] (http://en.wikipedia.org/w/index.php?title=Talk:*-algebra&oldid=340022974) with this parsing in place.

No, the original fix did not break many templates. It was 2004, there weren't many templates to break back then.

It's not as easy as you make out to produce line starts without the bug 529 hack. Look at what happens when an extension breaks it:

http://lists.wikimedia.org/pipermail/mediawiki-l/2010-January/033103.html

If the problem is parser function and variable output, then we can fix that specifically and leave template output as it is.

happy.melon.wiki wrote:

testcases

It's generally trivial: just add a linebreak in the calling table:

{|

-

{{template-with-block-level-wikimarkup}}

-
{{template-without-block-level-wikimarkup}}
}

If the outer markup expects block-level content, it should be on a new line. The comment you refer to is just putting the cart before the horse to try and fix this in the subtemplate; templates generating extra whitespace is a big enough problem as it is. Of course, their specific problem is with the newline position of the #ask: parser function getting lost somewhere, but their implementation puts the contents of the #ask on a newline whether or not that's desired. Linestart status should be decided from the top down, where people can actually see what the transclusions are doing, not blind-guessed from the inside out. However, as was pointed out in that thread, adding anything; be it an nbsp, <nowiki/> tag, etc, reproduces the effect they wanted.

In the testcases attached, the existing implementation (with the hack) breaks cases 5, 6, 7 & 8. Without the hack, cases 1 and 3 break, assuming that block-start functionality is always desired. If the inner template should sometimes exhibit block-level functionality and sometimes not, of course, there's no way to produce that with the hack in place, although that's an unlikely situation.

Attached: bug12974.html

We could add a bug 529 tracking category to the parser output to determine how the hack is being used on Wikimedia wikis.

IAlex added a comment.Apr 5 2010, 11:08 AM
  • Bug 23033 has been marked as a duplicate of this bug. ***
IAlex added a comment.Apr 5 2010, 6:36 PM
  • Bug 5590 has been marked as a duplicate of this bug. ***
  • Bug 23355 has been marked as a duplicate of this bug. ***
He7d3r added a comment.May 3 2010, 8:44 PM

Is the code for headers (=) a "line-start" code too?

It is appearing undesired line breaks in the headers here:
http://en.wikipedia.org/w/index.php?title=Special:ExpandTemplates&input=__TOC__%0D{{:User:Heldergeovane/Test/Template+for+titles%0D|Title+1%0D|Title+2%0D}}

and here:
http://en.wikipedia.org/w/index.php?title=Special:ExpandTemplates&input=__TOC__%0D{{:User:Heldergeovane/Test/Template+for+titles2%0D|Title+1%0D|Title+2%0D}}

The code of [[User:Heldergeovane/Test/Template for titles]] is:

{{#if:{{{1|}}}|<h1>{{{1}}}</h1>}}

Section 1.1

Text 1.1
{{#if:{{{2|}}}|<h1>{{{2}}}</h1>}}

Section 2.1

Text 2.1

And the code of [[User:Heldergeovane/Test/Template for titles2]] is:

{{#if:{{{1|}}}|={{{1}}}=}}

Section 1.1

Text 1.1
{{#if:{{{2|}}}|={{{2}}}=}}

Section 2.1

Text 2.1

Helder

(In reply to comment #32)

Is the code for headers (=) a "line-start" code too?

No

It is appearing undesired line breaks in the headers here:
http://en.wikipedia.org/w/index.php?title=Special:ExpandTemplates&input=__TOC__%0D{{:User:Heldergeovane/Test/Template+for+titles%0D|Title+1%0D|Title+2%0D}}

I fail to see the “undesired line breaks”. The only line breaks I see there are those you explicitly added yourself (and I do not even think they present any problem). If you remove them from the input, they disappear from the output:

http://en.wikipedia.org/w/index.php?title=Special:ExpandTemplates&input=__TOC__%0D{{:User:Heldergeovane/Test/Template+for+titles|Title+1|Title+2%7D%7D

http://en.wikipedia.org/w/index.php?title=Special:ExpandTemplates&input=__TOC__%0D{{:User:Heldergeovane/Test/Template+for+titles2|Title+1|Title+2%7D%7D

I forgot to mention that the example is based in a case where the number of parameters used is superior to 100, so it is desired to have one in each row (as in the example). The problem is that the line breaks are breaking the TOC, which shows

  • 1 Section 1.1
  • 2 Section 2.1 ----

instead of

  • Title 1
    • 1 Section 1.1
  • Title 2
    • 2 Section 2.1 ----

This should not be happening, I mean:
<h1>Title
</h1>
should also make "Title" to appears in the TOC, as it does in
<h1>Title</h1>

Besides this, the code

{{:User:Heldergeovane/Test/Template with parameters

FIRST
SECOND

}}

should result in the same output as this:

{{:User:Heldergeovane/Test/Template with parameters

1=FIRST
2=SECOND

}}

without any undesired line breaks. Here is a link showing the differences:
http://bit.ly/bVLioV

Helder

  • Bug 26000 has been marked as a duplicate of this bug. ***

In some case, you can use <code>&#35;</code> for #, because the entity is replaced after the braceSubstitution.

happy.melon.wiki wrote:

(In reply to comment #37)

In some case, you can use <code>&#35;</code> for #, because the entity is
replaced after the braceSubstitution.

Ew, god, please no. Escaped entities are escaped entities, they should never be being interpreted as wikimarkup; if they are, that's a separate bug.

(In reply to comment #38)

(In reply to comment #37)
> In some case, you can use <code>&#35;</code> for #, because the entity is
> replaced after the braceSubstitution.
Ew, god, please no. Escaped entities are escaped entities, they should never
be being interpreted as wikimarkup; if they are, that's a separate bug.

That is why I say, in same case. For the Template:Color it is possible (comment 0), because the # is not wikimarkup there. Using

{{SUBJECTPAGENAME{{#if:yes|&#58;Talk:Foo/bar}}}}

does not work (comment 10), because the &#58; is for wikimarkup (for the parser function)

As HM said in comment 27, all you need generally is a preceding nbsp or <nowiki/>:

style="color:<nowiki/>{{#if:yes|#000;|#fff;}}"

...or something to that effect.

happy.melon.wiki wrote:

I fixed this in r80430. The newline is now only added when the brace construct begins with a wikitable element {|

brion added a comment.Jan 26 2011, 1:20 AM

I've provisionally reverted this in r81012. As noted in code review comments, this alters various existing edge cases, and causes unexpected changes in behavior for constructs that are already in use in pages and tables.

As we're in the middle of settling down work on trunk into the 1.17 deployment and release, I'd strongly recommend revisiting this in a few weeks when things have settled down.

Definitely recommend going ahead and testing things and checking to see what the best machine strategies for fixing up old code are, if these are the correct changes to make.

Punting this to the new parser Brion has under development.

*** Bug 10781 has been marked as a duplicate of this bug. ***

a.d.bergi wrote:

*** Bug 19302 has been marked as a duplicate of this bug. ***

*** Bug 35129 has been marked as a duplicate of this bug. ***

  • Bug 36215 has been marked as a duplicate of this bug. ***
  • Bug 38697 has been marked as a duplicate of this bug. ***

Bumping the importance - so many dupes and so many broken/non-working things because of this.

*** Bug 40294 has been marked as a duplicate of this bug. ***

Note that the worst case of this problem, unusability of things like {{PAGENAME}} on pages like “*Foo” was specifically solved in Bug 26781 with commits r80511 and r80512.

This bug is causing unexpected behaviour in {{#invoke:}} as well. In my case, I found this when writing [[Module:UrlToWiki]] that converts URLs into interwiki links. When the module generates the text for a link that uses the colon trick, the parser generates an unwanted new line. I made a demonstration module as well:

https://test2.wikipedia.org/wiki/Module:User:Mr._Stradivarius/colonbug
https://test2.wikipedia.org/wiki/User:Mr._Stradivarius/colonbug

Allow me to join the voices of those calling for this to be fixed. There would be a simple workaround for templates which rely on this behaviour should it be fixed, but as it is the bug makes certain things impossible.

Anomie added a comment.Aug 5 2013, 3:45 PM
  • Bug 52548 has been marked as a duplicate of this bug. ***
  • Bug 56562 has been marked as a duplicate of this bug. ***

Happy-melon: This issue has been assigned to you in January 2010.
Could you please provide a status update and inform us whether you are still working (or still plan to work) on this issue?
Only in case you do not plan to work on this issue anymore, should the assignee be set back to default? Thanks.

happy.melon.wiki wrote:

(In reply to comment #55)

Happy-melon: This issue has been assigned to you in January 2010.
Could you please provide a status update and inform us whether you are still
working (or still plan to work) on this issue?

I pretty much *had finished* working on this, deployed a fix, etc; then Brion reverted. Essentially my code was rejected.

Only in case you do not plan to work on this issue anymore, should the
assignee
be set back to default? Thanks.

I'd say this should either be WONTFIXed if it's actually not going to happen, or my fix should be reinstated (I'd expect it still applies fairly cleanly, the Parser code is *very* stable). There's no reason for anyone *else* to be working on it.

Change 99133 had a related patch set uploaded by Bartosz Dziewoński:
Stop prepending newlines to templates starting with *#;:

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

This behavior has annoyed me for long enough. I say we should break the wikis and fix it (after appropriate community nudging is done, and probably after we run a diff of resulting HTML on a large enough subset of pages – Parsoid testing infrasctructure can probably help here a lot).

I tried reapplying Happy-melon patch from r80430 in Ifc6080cb linked above, fixing a few minor merge conflicts on the way and one larger one, and hopefully not breaking too many unrelated things in the process.

It is naturally failing parser tests right now due to how many other things changed in these three years, but that's nothing insurmountable, I can fix the tests myself if there is any chance of this actually getting merged again someday.

Changes to this behavior will also very likely break a lot of existing content for a small gain in usability. This is also the reason why it was reverted in the past.

Removing the newline insertion would also make life for Parsoid harder. Example case:

{{random}}{{echo|* foo}}

The newline context of * foo now depends on the expansion of the random template. This makes independent parsing, correct WYSIWYG and efficient updates for template expansions very difficult to impossible. The newline insertion hack happens to help us here, even if the original author probably didn't think about future parser development affected by this.

My preference is to focus efforts on better DOM-based templating rather than spending a lot of time moving sideways with wikitext templating.

Anomie added a comment.Jan 7 2014, 6:45 PM

I don't think having the ability to have template output beginning with "#" and similar characters is a "small" gain in usability. This sort of thing seems to come up on enwiki every few months as new people run into this bug.

(In reply to comment #56)

I pretty much *had finished* working on this, deployed a fix, etc; then Brion
reverted. Essentially my code was rejected.

Looking at the history on this bug and the comment on r81012, it doesn't seem so much "no" as "not right now, we're trying to release 1.17" and then it never got followed up on after. And then Brion was supposed to be working on a new parser, etc.

Possibly the biggest help would be to identify what exactly on the wikis would be broken by making this change.

  • Bug 60444 has been marked as a duplicate of this bug. ***
Anomie added a comment.Feb 4 2014, 2:35 PM
  • Bug 60827 has been marked as a duplicate of this bug. ***

Someone hit this problem today on IRC (discussed privately).

A template with a link to IRC (although it will affect any protocol) and a parameter to supply the port.

Example:

[irc://{{{server|}}}{{#if:{{{port|}}}|:{{{port}}}}}/{{{channel}}} #{{{channel}}}]

If you specify a port, the colon in the port breaks the link, as it's being interpreted as a definition list.

But if you try to escape it wrapping the colon inside nowiki tags, the link is broken anyway since the < character is interpreted as the end of the link.

See this test https://www.mediawiki.org/w/index.php?oldid=943856

I'm pretty sure that particular instance could be worked around by using [[Template:Colon]] on wikis that've created it, but that's very much not an ideal solution.

greg added a comment.Jun 24 2014, 5:39 PM

Brad gave a pretty good summary in comment 60, with this as a good next step:

(In reply to Brad Jorsch from comment #60)

Possibly the biggest help would be to identify what exactly on the wikis
would be broken by making this change.

Matma: Can you do this? The current behavior also annoys you, so you might be inclined to help move this bug forward.

For the record, as of today there are 23 duplicate bugs for this issue.

Setting status to Assigned (from patchtoreview) since the next step isn't necessarily reviewing the (old) patch, but working out what will break if it's merged.

(In reply to Greg Grossmeier from comment #65)

Matma: Can you do this? The current behavior also annoys you, so you might
be inclined to help move this bug forward.

I'd love to help, but I don't think I can test a representative sample of all articles in all Wikimedia wikis on the hardware and the Internet connection available to me.

Isn't there a whole infrastructure for Parsoid testing and comparing the results to current parser? I think it'd make sense to use that intead.

(In reply to Bartosz Dziewoński from comment #66)

Isn't there a whole infrastructure for Parsoid testing and comparing the
results to current parser? I think it'd make sense to use that instead.

There is [[mw:Parsoid/Setup]] and mediawiki/services/parsoid/tests/dumpGrepper.js, which could be run on any Wikimedia Labs instance over the Wikimedia projects dumps, but last time I tried I wasn't able to make it work and I ended up using bzgrep instead. :-)

It may get easier if someone familiar with parsoid improves the docs and/or testing infrastructure for this sort of things, but in the current state assessing the effects of such a whitespace change certainly is not a few hours' job.

Ciencia_Al_Poder set Security to None.
Ciencia_Al_Poder awarded a token.
Ciencia_Al_Poder removed a subscriber: Unknown Object (MLST).

Here's a thought: instead of parsing dumps, how about adding a tracking category, similarly to what we did with duplicate template arguments? Whatever the number of pages affected ends up being, it's going to be big, so we would end up needing to make several dump parses at regular intervals as pages get fixed. Using a tracking category will enable volunteers to fix the pages without having to worry about people updating the dump parse results.

A tracking category would also make it easier for non-Wikimedia wikis to fix their pages before upgrading their MediaWiki installations. If we just scan for affect pages on Wikimedia wikis without taking any other measures, then people on other wikis will lose out if they don't have the knowledge or resources to make their own scans.

The downside would be that most of the pages included in a tracking category would be transclusions of the pages with the problem, rather than being directly affected, as this behaviour is most often seen in templates. But that can be mitigated by looking only at transclusions in the template namespace, with tools such as CatScan.

(By the way, this bug has been mentioned on enwiki's technical vilage pump again.)

Anomie added a comment.Jan 5 2015, 3:27 PM

Another disadvantage to adding a tracking category could be the difficulty in determining whether this behavior actually makes a difference to the resulting HTML in any particular instance, potentially leading to many false positives.

Blahma added a subscriber: Blahma.Mar 5 2015, 2:12 AM

Run across this bug today while working with {{#invoke:String|…}}. This bug forces me to make nasty obfuscations in my code that sometimes hang on the level of workability. And I guess that the more we use Lua/Scribunto, the more we will bump into annoyances caused by this bug.

In my specific case, I receive a string from the user and need to left trim it to start with the first asterisk I find in it. This bug breaks the simple {{#invoke:String|match|{{{1}}}|%*.*}} which, to implement the space-prepending workaround, needs to be replaced with {{#invoke:String|match|{{#invoke:String|replace|{{{1}}}|*| *|1}}| %*.*}}

The latter code is less comprehensible and doubles the number of invokes and level of nesting (and as I am processing lists of values with this code, parser time actually matters to me). Also, because I actually need to do further String processing on the output of this invoke, I find myself needing to keep that extra starting space on my mind at every moment and to inflate any sub/find/replace String operations accordingly (so as not to start working from index 1 as is the default, but index 2). I probably do not need to add that any nesting call to a String operation that may possibly return a "dangerous" value must again be sanitized in this way, which means that you may easily run into nesting workarounds in workarounds. Very bad practice, I think :-(

ssastry added a comment.EditedJul 9 2015, 7:37 PM

I think the problem here is that we need different (contextual) behavior for different templates.

For templates that are expected to be used in attribute context (as in the {{color}} example), or in templates that are expected to be used in phrasing content (http://www.w3.org/TR/2011/WD-html5-20110525/content-models.html#phrasing-content-0 ), the add-a-newline behavior breaks expectations.

For everything else, newline addition seems the right behavior.

I think this goes back to various discussions that we've had in the Parsoid context -- about how to enforce content model requirements on template output. This has several benefits beyond the resolution of the conflicting requirements in this task (better visual editablity, improved parsing performance, ability to edit popular templates without causing load spikes on the parse cluster, and improved ability to reason about templates and their usage -- as demonstrated in this bug report).

One of the ideas that came up in our conversations (that @tstarling had, I think) was to rely on some form of magic words that provide content model hints (potentially enforceable rules in the parser) at the start of template wikitext. This idea came up in the context of ideas / solutions to enforce DOM-scoping on template output (https://www.mediawiki.org/wiki/User:SSastry_%28WMF%29/Notes#DOM-scoping_of_template_output, https://www.mediawiki.org/wiki/Parsoid/domparse ) without having to introduce new markup in wikitext.

So, I think, if we pursued this idea further of introducing content-model (and other contextual-use) hints to the parser in templates, we might be able to have our cake and eat it too.

I do want to add the caveat here that I haven't fully thought through all the implications, but I am putting this out as an early idea for consideration.

cscott added a comment.Jul 9 2015, 7:42 PM

It may be that the inAttribute serializer flag added by https://gerrit.wikimedia.org/r/219869 might help in some situations. For example, @Ciencia_Al_Poder's example with the inadvertent definition list might be suppressed if we are inAttribute. Not a 100% solution, but it might help.

Ireas removed a subscriber: Ireas.Aug 20 2015, 9:18 PM

At this point, this is a "feature", not a "bug". Changing it would break many many many pages on wikipedia.

Changing it would break many many many pages on wikipedia.

{{citation needed}}

Last time anyone was actually going to do anything here, it stalled out on someone figuring out how many templates actually depend on this behavior. Did you actually do that to determine "many many many", or are you just guessing?

If you look at the code history, "fixes" for this were attempted several times, and each time had to be reverted. No one has attempted to clean up WP since, so it's reasonable to assume that the number of uses has only increased.

Further, labelling this as a "bug" is somewhat problematic, since it was added deliberately on January 3, 2008 by @tstarling to fix T2529: Templates inside of tables appear incorrectly (with the comment, "Bug 529: if the template begins with a table or block-level element, it should be treated as beginning a new line. This behaviour is somewhat controversial.") If it were reverted, "templates inside tables" would be incorrect again. And even at the time (2008) this was a fix for a *regression* -- so this has been the behavior of templates for even longer than that.

This has been a part of wikitext syntax for over 7 years now, and there are a number of parser tests explicitly verifying this behavior. It is not a *bug*. It allows you to use wikitext inside a template which requires a "start of line" context: specifically, * # : ; {|.

On the other hand, it's reasonable to wonder if we could do things more gracefully. Alternative template mechanisms (for instance, T114445: [RFC] Balanced templates) may choose to opt-out of this behavior, if there are good alternatives.

Another "solution" would be to start a large-scale wikilint project aimed at cleaning up cases where this feature is used, so it could then be turned off. The difficulty with that approach (as my 2015 wikimania talk pointed out) is that it's not clear what the "proper" replacement should be in all cases.

Further, labelling this as a "bug" is somewhat problematic, since it was added deliberately on January 3, 2008 by @tstarling to fix T2529: Templates inside of tables appear incorrectly (with the comment, "Bug 529: if the template begins with a table or block-level element, it should be treated as beginning a new line. This behaviour is somewhat controversial.")

Tim added that comment in http://mediawiki.org/wiki/Special:Code/MediaWiki/27667 (the original parser rewrite), the commit you linked just moves it. But the code was there earlier, added in 2004 by Wil Mahan (http://mediawiki.org/wiki/Special:Code/MediaWiki/5479).

I don't think that this stops being a bug just because it's eleven-years-old code, though. If you look at T2529, all it asked for was more robust syntax for nested tables, and instead we got this :(

If you look at the code history, "fixes" for this were attempted several times, and each time had to be reverted.

I see only one attempted fix. And as is already noted in T14974#173936, that was reverted because trying to deploy 1.17 was causing major issues and extraneous changes would just confuse the situation, not because of any known problem with the attempted fix itself.

Further, labelling this as a "bug" is somewhat problematic, since it was added deliberately on January 3, 2008 by @tstarling to fix T2529: Templates inside of tables appear incorrectly (with the comment, "Bug 529: if the template begins with a table or block-level element, it should be treated as beginning a new line. This behaviour is somewhat controversial.")

Incorrect. It was added in r5479. The revision you link is fixing a regression that was probably introduced in r12925, where the if block that r29205 is moving the code in question out of was added.

This has been a part of wikitext syntax for over 7 years now, and there are a number of parser tests explicitly verifying this behavior. It is not a *bug*.

As I've said elsewhere in a different context to the same bogus argument, just because someone can write a test proving that a behavior exists doesn't make that behavior not a bug.

It allows you to use wikitext inside a template which requires a "start of line" context: specifically, * # : ; {|.

Or you could just put the template that needs a "start of line" context at the start of a line.

I'm not sure what we're arguing about here. You're right, this behavior seems to have been added on 25 September 2004 in r5479. So it's over a decade old now.

I'm all for starting a wikiproject to identify and replace templates which depend on this behavior. I'm just saying that you can't "fix this bug" without fixing the content first.

It allows you to use wikitext inside a template which requires a "start of line" context: specifically, * # : ; {|.

Or you could just put the template that needs a "start of line" context at the start of a line.

That would probably require also a <nowiki /> before the newline and the content of the parameter. Surprisingly, this <nowiki/> is often needed when using row syntax inside {{#if: }} constructs (with {{!}}), which makes the current situation very inconsistent :S

As discussed in T14974#1442616 I think we can mitigate the problem being discussed here by relying on the balanced-templates RFC. So, if a template is meant to be used in block context, forcing a newline break (current behavior) seems right. But, if a template is marked to be used in inline context, not forcing a newline break seems the right thing to do. I think this will provide the most benefit as requested in this bug report with the least breakage. This could reduce the impact of the change, but yes, we would still need to verify how page rendering changes before turning it on.

It allows you to use wikitext inside a template which requires a "start of line" context: specifically, * # : ; {|.

Or you could just put the template that needs a "start of line" context at the start of a line.

That would probably require also a <nowiki /> before the newline and the content of the parameter. Surprisingly, this <nowiki/> is often needed when using row syntax inside {{#if: }} constructs (with {{!}}), which makes the current situation very inconsistent :S

The fact that {{#if: }} consumes whitespace is a design problem of {{#if: }}. It doesn't make sense to burden the entire template substitution mechanism with unspecified whitespace insertions just to work around that limitation.

I'm just saying that you can't "fix this bug" without fixing the content first.

Very true. And to fix the content, we need to have some way of tracking which pages are affected. This is where this bug has been stalled, as far as I'm aware.

Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:19 PM

As the latest person to get bitten by this bug, can I press for some progress. If the category suggested by Tim in six years ago, and Mr Stradivarius one year ago can be implemented, then we can at least get some idea of the magnitude of the misfeature use. Conversely if they can't let us find another way forward.

I don't think it is unreasonable to expect a mature piece of software to "just work", and while I have sympathy for grand plans involving document object models, if we can't display something beginning with *, :, ; # we need to resolve that issue sooner rather than later. All the time we are wasting volunteers efforts, and discouraging them.

Add Comment