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:
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.
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"`
and
```
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:
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.
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.
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.
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>