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:

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… :wink:

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