Highlighting text with the <mark> element


To keep these topics focused, I have moved discussion of the HTML <mark> element to a new topic. Here is my original proposal for supporting highlighting via a CommonMark extension:

A proposal to support the <mark> tag with Markdown
Highlights, Strikeout, Underlines, Spoilers

I prefer:

==highlighted text==


{} is too “programmish”. == seems to be enougth.


Potentially, == can conflict with sugar like “progress bar”: ===50%===, but i don’t think that will be a problem. Can’t imagine another cases.


To avoid that conflict, there could be rule: exactly two = on either side of the highlighted text.

Another potential problem: == is used in many programming languages as a comparison operator. Although, code should be inside of a code block, it might trip up writers who casually put code in the middle of a sentence without using ```. All the more reason to use code blocks and inline code correctly.


Implemented both mark & ins in remarkable dev branch


if you really need to reduce chance of conflict. Then this is an option. Triple equals. Usage in programming is rather rare.

===safer highlighting===

note: btw if you didn’t notice. You cannot do === this kind of highlight===. Not safe.


Triple equals is used in JavaScript as a strict comparison operator.

I think double equals is fine for highlighting syntax. If the writer gets unexpected results, it is a good incentive to use a code block or inline code instead.


What does that have to do with a highlighting extension? If a user is displaying some JavaScript, they’ll use ` to surround their JS, or put the code in a code block:

`x === "foo"`


x === "foo"

will work fine so long as === is treated in the same way that * and _ are handled for code blocks.


My point is that it’s a similar scenario to using == without a code block. Code should be in a code block, but the writer may forget.


I know I’m treading into dangerous waters here, both because this is my first post and because I’m resurrecting a 2 year old thread, but here I go…

Could a solution to the highlighter issue simply leverage the existing link notation with a special case, like this:


Some text, of which only [a portion will be highlighted](# "Take a note at the same time"), along with a note.


Some text, of which only [a portion will be highlighted](# "Take a note at the same time"), along with a note.

This would allow the user to annotate with a highlight and include a note at the same time. It has the added advantage of being backwards compatible with standard link markup, so non-compliant renderers wouldn’t choke on it or show the raw markup, they would simply render it as a link – just like it is here.

The thing to work out is what the anchor should be. If it was [text](mailto:author@example.com "Notes") then the author would be clear; but this would clobber real mailto: links. Perhaps [text](#author@example.com "Notes") would be better?

Just some thoughts. I would love to see some kind of annotation support in Markdown; if it were backward compatible, I think it might stand a better chance of wider acceptance.