Highlighting text with the <mark> element

Extensions
21

I agree. I’d like to know what the con arguments are against it.

2 Likes
22

We did whitelist <mark> in Discourse recently, so you can use that if needed.

1 Like
23

Any idea of if there’s functionality to highlight lines of code that are of interest within a fenced code block?
i.e. i’d be looking to highlight a line like this but within a fenced code block. rather than showing the literal ` flags, I would want to see the background of the code turned yellow

within a fenced code block
<mark>looking to highlight a line like this</mark>
24

Any idea of if there’s functionality to highlight lines of code that are of interest within a fenced code block?
i.e. i’d be looking to highlight a line like this but within a fenced code block. rather than showing the literal ` flags, I would want to see the background of the code turned yellow

within a fenced code block
<mark>looking to highlight a line like this</mark>

You’d have to use a raw HTML pre block to achieve this. In commonmark code blocks, the contents are interpreted as plain strings.

1 Like
25

Just catching up on this one sorry. For CommonMark are we proposing the following?

  • ==highlight== equivalent of <mark>highlight</mark> renders highlight
  • ++success++ equivalent of <ins>success</ins> renders success
  • --failure-- equivalent of <del>failure</del> renders failure

The ==highlight== syntax def has quite a few implementations outside of CommonMark. Haven’t seen examples of ++ and -- but the fact we all have <ins> and <del> on the allowlists of tags makes me think there is demand…

Or just go with ==highlight== at this time?

1 Like
26

--failure-- is a nonstarter, since -- is widely used for en-dashes.

Pandoc and quite a few other implementations use ~~failure~~
for strikeout; this could be used for <del>.

See also Critic markup: GitHub - CriticMarkup/CriticMarkup-toolkit: Various tools to use CriticMarkup in your daily workflow
This uses { } characters, and for good reason; you might want to include a space next to a word in an insertion:

Lorem ipsum dolor{++ sit++} amet

and that wouldn’t work if we had bare delimiters with the usual left/right flanking constraints on matching.

I’d proceed with caution here.

1 Like
27

To work around this edge case, the { } characters could be omitted in the case of strings without space characters at the sides of the string:

Highlighted text with a preceding space: {== highlighted==}

Highlighted text without a preceding space: ==highlighted==

For emphasis, it appears to be impossible to add spaces to sides of the emphasised text. I can’t think of any reason why the author would want to do this, but perhaps some rule reuse for how inline text with spaces at the edges could be applied to the spec.

1 Like
28

Chris Alley via CommonMark Discussion
noreply@talk.commonmark.org writes:

For emphasis, it appears to be impossible to add spaces to sides of the emphasised text. I can’t think of any reason why the author would want to do this, but perhaps some rule reuse for how inline text with spaces at the edges could be applied to the spec.

There’s no good typographic reason to have emphasis starting or
ending with a space. (Same would apply to highlighted, I think.)

But there is a good reason, often, to have “inserted” or
“deleted” text that starts or ends with a space.

2 Likes
29

There’s perhaps a case to be made for generalised rules around Phrasing content. For example, if a span of phrasing content needs explicit start and end markers because of spaces, use { and } for these, combined by the specific Markdown character for that type of phasing content, but make the { and } only required in edge cases where the text starts or ends with a space.

30

Yes, it’s an interesting idea. { before a delimiter run could force it to be counted as “left-flanking”, and } after a delimiter run could force it to be counted as “right-flanking.”

Questions I’d have about this: Would this really be useful for anything besides ins and del? If not, it could still be motivated on grounds of uniformity. However, if we allow ++ without { then we lose compatibility with Critic Markup. Is it worth losing this to allow people to save a few characters? Arguably, the {..} provides a really helpful visual cue for insertions and deletions, which after all are not regular text formatting but more like metadata.

2 Likes
31

Was there ever a determination as to if/when <mark> will be added to the spec?

It seems most are in agreement of that portion but the remaining discussion points need to be continued.

32

@jgm @codinghorror I think the fair and responsible thing to do is to pin an announcement at the top of the forum that sets expectations with regards to CommonMark going forward, whether it is “The CommonMark spec is frozen with respect to features, but there are supersets of or extensible implementations of CommonMark that may support what you need” or something else.

33

Good idea, I have done that, thanks for the reminder!

1 Like
34

I don’t understand why this is so difficult!

As a writer/reviewer using Markdown I have a real need to be able to highlight text. I also am in total agreement with the use of a standard for Markdown (CommonMark being the obvious one). So why can’t we just get this done?

Regards,
Peter

1 Like
35

How about this ?

  • ==>highlight<== equivalent of <mark>highlight</mark> renders highlight
  • ++>success<++ equivalent of <ins>success</ins> renders success
  • -->failure<-- equivalent of <del>failure</del> renders failure
1 Like
36

This looks like a good solution… BUT please make it multiblocks able…

Like this:

==>this is block1
some text
some text
this is block2
some text
some text <==