Stream: implementers
Topic: Underlined texts
Axel Biernat (Jan 14 2019 at 14:18):
Working on the FHIR interface for an EHR solution was crossing a text style issue. Seeing that the markdown data type is using GMF there is a particular downside with it. GMF specification https://github.github.com/gfm/ doesn't cover underlined text. However we see such when users are writting various texts.
Does anyone has seen same issue and what is your way to deal with it?
Eric Haas (Jan 14 2019 at 19:08):
Well underlines get confused with links so I think that its good they are not in GMF,
here is a better answer:...
There are no mention of "bold" or "italics" in the markdown syntax document. What there is, is an emphasis section, which describes how the use of underscore and asterix -marked spans (*, _, **, __) should produce code wrapped in <em> and <strong> tags.
Axel Biernat (Jan 15 2019 at 08:28):
Sure, have seen this and similiar statements. But really wondering when facing of a situation were to provide FHIR support to existing system how to deal with it. Most of EHR system have to a certain extend basic styling capabilities for writing text. Usually italic, bold, underline maybe bullet points too. Not having such semantic meaning in legacy data it means that a idenitical representation is not possible. Know I sound picky here, but after many conversations with physicians about text styling I see here a reasonable need.
Grahame Grieve (Jan 15 2019 at 13:43):
it's a problem that you should take up with the CommonMark spec - say, at talk.commonmark.org
Johannes Faber (Jan 16 2019 at 10:02):
Hm, not sure how taking it up to CommonMark might help since they had this discussion several times already and there are valid reasons not to include it in CommonMark. I'm wondering what the recommended way would be to deal with Axel's use case. An extension? Using the narrative with xhtml? Wouldn't it make sense to allow xhtml in strings as well?
Grahame Grieve (Jan 16 2019 at 11:55):
we won't allow xhtml. Allowing it in narrative has raised many questions....
Grahame Grieve (Jan 16 2019 at 11:55):
what are commonmark's reasons?
Axel Biernat (Jan 16 2019 at 13:16):
Basically this is coming from HTML specs I guess. Read HTML5 specification you can read that <u> tag should avoided due to same visualisation as links. <u> has marked as dated in HTML4 afaik.
Would use of this tag a possibilty even so?
Grahame Grieve (Jan 16 2019 at 13:43):
I wish that I knew the answer to this. We don't allow raw HTML for extremely good reasons. We wouldn't define our own extensions to commonmark for very good reasons
Grahame Grieve (Jan 16 2019 at 13:51):
but I see the problem
Grahame Grieve (Feb 19 2019 at 01:35):
https://talk.commonmark.org/t/revisting-underline-healthcare-documents/3078/2
John Silva (Feb 19 2019 at 03:25):
Wow, that was a long discussion --- but it does point out the "conflicting concerns". One person makes the point, which I've heard before in the HTML world is "keep the display styling separate from the semantics of the mark-up. This allows client visualizers to use whatever is appropriate for communicating the content's semantics (think of an audio for visually impaired readers -- I think this is one of the classic examples of why display needs to be separated from semantics in HTML). I'm not sure if the suggestion of the "____" markup works in this case or not but there was another more verbose markup that does.
Grahame Grieve (Feb 19 2019 at 03:34):
well, in principle, of course, I completely agree about separating semantics and display. But legacy documents don't work that way
John Silva (Feb 19 2019 at 04:22):
Oh, I didn't see the mention of 'legacy documents' in that discussion thread.
Grahame Grieve (Feb 19 2019 at 04:50):
not explicitly, no, but that's what it's all about
Last updated: Apr 12 2022 at 19:14 UTC
