Text: Support underline (needs research)

[jospoortvliet]

It'd be great to add underline when using _ like this works in discord. Right now, one _ adds <em> tags, two add a <b> tag, just like * does. I suggest to let _ add a <u> tag. You could let __ add a double underline, but that's a bit much perhaps.

[juliushaertl]

_foo_ is specified as emphasis in https://spec.commonmark.org/0.28/#emphasis-and-strong-emphasis and I think we should stick to the commonmark standard as good as possible. cc @jancborchardt

[jancborchardt]

Agree with @juliushaertl – _underscore_ is for emphasis and __double underscore__ is for bold, on Github too.

@juliushaertl you mentioned that underline is not even defined in Markdown at the moment though?

If we want to introduce it, which I’m not against, we should then do research of how other platforms do it, not just one. If anyone is up for it – check out Discord, Slack, Dropbox Paper (if they support it), Discourse, and others and see how they use _ underscore or other elements for underlining. :)

[jospoortvliet]

(_Edited by @jancborchardt to clean up, fix Discourse, and added reddit.)

• Github follows CommonMark and additionally has Github Flavored Markdown but no underline.
• Discourse follows CommonMark
• reddit follows CommonMark
• Discord follows CommonMark _except_ for using __ (two underscores) for underline instead of as bold (as ** already does that).
• CommonMark has endless technical discussions about what users expect/need vs how everyone should just learn to think semantic. Meanwhile real life users (eg medical professionals) simply expect bold, italics, underline and strike-through because every document editor has them. See https://talk.commonmark.org/t/revisting-underline-healthcare-documents/3078

I sympathize with the 'nerds' here ("why don't people get the separation of semantics and style") but sorry, not all our users are web developers, and users expect the basics of style. And that happens to include underline since Wordperfect in the 80's and even before.

[jancborchardt]

which in practice means everybody uses * and nobody uses _
I guess, as nobody actually uses _ instead of * and they wanted to offer underline, they went that way.

I have 2 issues with these assumptions:

• I actually use _ for italics, _if_ I ever use it, and the asterisks for bold. Not sure why, but e.g. this Markdown tutorial which comes up first when searching does it like that. (never used it tho) It’s just simpler to remember different symbols for different use-cases, and it makes it simpler to distinguish in the raw text. Point being: It’s not "nobody" and possibly a lot of people, whose italic text would suddenly be underlined. Not expected.
• What happens _if_ someone uses _ to mean italic/emphasis and not underline? (like me) Will it just display as underline, or will the Text app somehow modify existing documents too?

We could start small by doing it like Discord, which seems the minimally invasive approach. Additionally the person from the thread @jospoortvliet linked said:

None of them are ideal, though I prefer ___.

→ that is, 3 underscores.

What do you think @juliushaertl?

[jospoortvliet]

I'd be happy with the __ yeah, three seems excessive but also works. In any case, the feature works and that's a big deal for some...

[jancborchardt]

Btw @jospoortvliet you said above:

discourse uses _ for underline

But it seems Discourse does not support underline at all?

[jospoortvliet]

Huh, I tested this out when I sad it, but now I'm wondering what discourse forum did it - ours not (anymore), I'm not sure anymore. I tried it somewhere and it worked that way but I don't remember where that was. I thought on our own (help.nc.c) but it doesn't work... and there is no underline either. Not sure what/where/how...

[ryanprior]

Counterpoint: don't support underlining at all.

The argument has been made elsewhere better than I could make it, so I'll quote and link to the source:

In a printed document, don’t underline. Ever. It’s ugly and it makes text harder to read.

Underlining is another dreary typewriter habit. Typewriters had no bold or italic styling. So the only way to emphasize text was to back up the carriage and type underscores beneath the text. It was a workaround for shortcomings in typewriter technology.

Neither your word processor nor your web browser suffers from these shortcomings. If you feel the urge to underline, use bold or italic instead. In special situations, like headings, you can also consider using all caps, small caps, or changing the point size.

Not convinced? I invite you to find a book, newspaper, or magazine that underlines text. That look is mostly associated with supermarket tabloids. If that’s the impression you want to make with your writing, by all means, use underlining. If not, don’t.

From Butterick's Practical Typography

[jancborchardt]

@ryanprior as a fellow typography nerd, I can appreciate that. ;) However, the points with Discord using underline and healthcare professionals commonly using underline are very good ones. So we shouldn’t restrict it on principle if there’s actally people using it, especially for such an important field as healthcare.

We still won’t underline anything (except maybe links) in Nextcloud, so there’s nothing to worry about. :)

[brainchild0]

I would agree that it is unnecessary to support underlining, largely being a tool for preparing manuscripts using pen or typewriter, to indicate that the typesetter should choose some appropriate typeface distinct from the main document text, such as is unavailable historically except in commercial printing.

In an environment where italics and bold can be used without effort, we should agree that underlining loses its historic function.

I would also agree that as users will be accustomed to single and double underscores demarcating emphasis and strong emphasis, and as documents from external sources will also use the same convention, these elements should be rendered similarly as in other environments.

Triple underscores should further be treated no differently from triple asterisks, as doing otherwise will break compatibility.

Aside from these observations, a conceptual problem emerges when we ask whether MarkDown supports underlining, which is the same problem that emerges when the question is asked of italics and boldface. MarkDown does not support any physical stylization, only logical document structure. Stylization is a display issue. However, since generally emphasis and strong emphasis are rendered using italics and boldface, most display environments will prefer this convention unless constrained by a compelling consideration to the contrary.

Ideally, it is not particularly optimal that the toolbar icons in a MarkDown editor show bold or italic symbols, but I am at this moment looking at such icons in the GitHub editor, which is currently one the most widely-used MarkDown applications. I suppose that this particular convention is entrenched to the degree that it is of little use to complain about it idealistically.

Various platforms were mentioned that use nonstandard conventions and extensions. Remember that most of these platforms are closed environments. The user creates content within a page served by a particular site, such as the content is persisted only in a database for the site, is owned by the operators of the site, and is rendered only by the display logic operating on that site. The walled-garden environment affords greater flexibility to depart from conventions.

A general-purpose file editor will consume content created by many users and many editors, and similarly will create content consumed elsewhere.

The case of the medical conventions is an interesting one. I would say that if a subset of the population absolutely cannot live without underlining, then support should be configurable per user, and provided in the most restrictive and interoperable way possible as acceptable by those users. As was explained in the reference above, however, the standards body will take such concerns into advisement, so there seems to be little reason to adopt a homegrown solution ahead of such decision.

[jancborchardt]

Underlining is expected by people because regular word processors offer it, and we should not leave it out just because the Markdown spec made an oversight.

Again, we have a whole field of professionals using underline in their day-to-day work. Standards should be built based on what is actually used and what people need, not the other way around.

[brainchild0]

I understand the incentive to consider users' needs, but please consider all of the users. It is unhelpful to alter the effect for everyone to achieve a nonstandard, ad-hoc solution for a single display feature for a single group. If the standards body moves toward a solution, then a user preference to enable use of such an extension might be appropriate. The professionals in question either will be using MarkDown generally, or not, and even they are not served if the effect they seek is different in NC Text as from another editor.

Not to be too contrarian, but it may be a mistake to characterize lack of support for underlining as an omission by oversight, or even as any omission. Again, MarkDown expresses logical not physical document features. Either regular or strong emphasis might be displayed as underlining, or might not, depending on the considerations relevant to the display environment. Calling lack of support for underlining an oversight in MarkDown is like calling lack of support for background color an oversight.

I also think that there is a danger in a MarkDown editor that tries to mimic word processors. The latter still exists for those who want one. But conflating them will divide the users into two group, those who expect a MarkDown editor, and those who expect a word processor, and will inevitably leave both groups disappointed.

[jancborchardt]

I’m not going to discuss it to death. A considerable amount of people expects underline, and the solution proposed above stands https://github.com/nextcloud/text/issues/75#issuecomment-503210114

Standards are always developed over time, just like Markdown does. There’s CommonMark, there’s GitHub flavored markdown, etc which show that there’s further things needed.
It’s the same with CSS where browser manufacturers implement some feature that is objectively needed, and the standard follows. This is completely normal.

[brainchild0]

I understand, but if you begin to consider seriously a course that is likely to create display and editing disparities across applications, please also consider offering user-level configurability to let users choose the behavior of the application based on their needs.

The comment in the CommomMark thread gave the following suggestion:

Another solution is that you could use consistent attribute syntax 1 which seems most likely be turned into a CommonMark extension. E.g.

[My underlined text.]{ .clinical-term }

If you're looking for something that might eventually converge into a convention, perhaps this approach is best. And it does keep with the logical-oriented design of MarkDown.

[brainchild0]

If you're intent on special syntax for underlining, then you might use the == tags, currently used by some MarkDown flavors for highlighted text. Essentially, this metaphor is the same as the one medical professionals are employing for underlining, to designate certain text as important without changed the amount of space used for that text. You can supply a toggle switch for display as underline or highlight, the latter possibly being less distracting to the eyes in some cases because it lacks the additional lines inserted between pieces of text.