Re: [lmi] Empty paragraphs in HTML-MST

[Greg Chicares]

On 2019-07-25 22:22, Vadim Zeitlin wrote:
> On Thu, 25 Jul 2019 14:52:33 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Motivation: MST files often contain blocks like this example:
> GC>   <p>{{SampleText}}</p>
> GC> which does the right thing if 'SampleText' is nonempty. However,
> GC> for certain products, 'SampleText' is deliberately empty, in
> GC> which case the example above expands to '<p></p>', printing an
> GC> empty paragraph that consumes vertical space [0]. We'd like to
> GC> suppress that effect.
[...]
>  I see 2 ways to do it, globally:
> 
> 1. Avoid generating <p></p> in the HTML in the first place.
> 2. Keep generating <p></p> but render it as nothing.
> 
>  I haven't tested it yet, but I think (2) should be doable, and purely in
> lmi code, i.e. without any wxHTML modifications: we already use a custom
> tag handler for <p>, so we could just remember every wxHtmlCell we create
> in this handler and then, after finishing generating, go through the list
> of all these cells and either remove them entirely or just reset the
> margins used around them (which is what, I'm 99% certain, accounts for the
> space taken by empty paragraphs).

Interesting--I hadn't thought about the margins.

Generating <p></p> (2) and then filtering it out does seem inelegant.

>  However I think (1) would be nicer, both because it seems more elegant and
> because it would work for all tags, not just <p>.

Okay, (1) is more elegant and also more general.

> But implementing this
> would be more involved, I think (although I could be wrong if I run into
> some trouble with the approach outlined above), as it would require us to
> finally add support for some kind of functions/helpers to our MST syntax.

Okay, (1) is costlier, but it seems to be well worth the cost. Once we
add MST helpers, we'll probably wish we had supported them sooner.

> In fact, pure Mustache does support functions using the same syntax we
> already use for sections, e.g. we could implement support for something
> like
> 
>       {{#WrapInP}}{{UltCreditingRateFootnote}}{{/WrapInP}}
> 
> where WrapInP() would be mapped to a function defined in C++ code that
> would simply return "<p> + input + </p>" if input is non-empty and an empty
> string otherwise. But if this looks too heavy, we could implement support
> for something like
> 
>       {{WrapInP UltCreditingRateFootnote}}
> 
> or
> 
>       {{UltCreditingRateFootnote|WrapInP}}
> 
> instead (both syntaxes are not really standard but used in some templating
> system or other, so not totally unfamiliar neither).

Either of those simpler alternatives seems much preferable. If I had
to choose, I think I'd pick the first, {{WrapInP my_footnote}}, because
Verb-Object seems more readable than Object-Verb.

And, if literals are allowed as the 'Object', they could be much longer
than the 'Verb':
  {{Paragraphize "This is a literal footnote that goes on and on and on...
  ...and on and on and on."}
in which case a 'Verb' written at the end would be hard to see.

I think (1) and (2) are reversed in the next paragraph:

>  I believe that (2) would make more sense, especially if we want to use
> functions in other cases, e.g. for abbreviating the value to some number of
> characters. But if you need something immediately right now, (1) might be
> faster to put in place.

...but I have no doubt that the option that uses helpers is much better,
and you seem to prefer it, too, so let's proceed with that option.