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:
1 Like
I prefer:
==highlighted text==
6 Likes
{} is too “programmish”. == seems to be enougth.
2 Likes
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.
1 Like
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.
2 Likes
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"`
and
```
x === "foo"
```
will work fine so long as === is treated in the same way that * and _ are handled for code blocks.
1 Like
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.
1 Like
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:
Markdown:
Some text, of which only [a portion will be highlighted](# "Take a note at the same time"), along with a note.
Rendered:
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.
I’m reviving this topic, because I find it relevant (and others too).
I believe the double equal sign == makes sense for the <mark> element.
This syntax is notably supported by some Markdown editors, such as Typora, iA Writer (see this update), which makes for an interesting convention.
2 Likes
This looks great - for highlighting, mark, and even underline.
Underline is from the era of typewriters. In HTML, underline is frowned up on because it looks like a hyperlink but is not. The suggestion by CSS experts is make it text-decoration: none and background-color: yellow So, wherever underline is needed, it should be replaced with mark or highlighted text.
Another +1 vote for this syntax for highlighting
==Highlighted Text==
Kindly make this as a standard.
3 Likes
Yes, we need a standard to highlight text. And ==syntax like this== seems to be a good way to do that. It looks like it has been highlighted with a highlighter pen.
Also, as @loupbrun has already mentioned, Typora and other Markdown editors already support this syntax.
1 Like
obsidian.md and Quilt also support ==this syntax==.
3 Likes
You can use insert and delete as sort of hack-y workarounds for now.
You can use <ins>insert</ins> and <del>delete</del> as sort of hack-y workarounds for now.
ins and del are hardly related to mark at all.
Agreed, that’s why I said hack-y workarounds… 
the most common syntax for <mark> is == and is used in many editors. Can’t see why this should not be accepted as a standard for the <mark>
3 Likes