markdown formatting on labels for choices?

[enketo-issue-mover]

From @danbjoseph on April 10, 2018 21:58

@pierregrandidier noted in this ODK forum post that formatting on the labels for choices doesn't appear to work

Copied from original issue: kobotoolbox/enketo-express#983

[enketo-issue-mover]

From @MartijnR on April 10, 2018 23:16

Thanks!

It would be feasible for inline choice labels (i.e. in the XForm body), but not for all labels because Enketo doesn't do the markdown transformation on the client. It does this on the server (and external data is not known at that time, internal data may also present an issue). The negative performance impact of moving that transformation to the client would be significant. Will consider this further.

[lognaturel]

I do miss this when building forms for Enketo.

What I miss even more is formatting of dynamic content used as a label or hint. For example, it can be helpful to output a summary of data entered by the user. For ODK Collect it's possible to build up a string with formatting using a calculate with concat. I believe that styling is applied before dynamic content is injected for the same reason. Does that sound right or is that a separate issue?

[MartijnR]

I believe that styling is applied before dynamic content is injected for the same reason. Does that sound right or is that a separate issue?

I think that issue is different but with a similar solution. The original issue (for both static and dynamic choice lists) requires moving markdown processing to the client and including this in the itemset.update. And the solution for your issue above would do the same but for output.update.

The performance problem I referred to above would be mostly with initial loading of forms (and perhaps with updating huge choice lists), unless you can somehow avoid checking every single text string for markdown syntax. A consequence of not having a real concept of pages (compared to Collect).