Highlights, Strikeout, Underlines, Spoilers

[mofosyne]

For non textual markups presentation (basically stuff that doesn’t modify the actual characters itself):

Syntax

Translatable to HTML tags (Has direct correspondence to the semantic meaning of a html tag):

1. Striked Through: --striked through text--

• Tag: <s>

• Strikeout thread

• HTML: <s>striked through text</s>

2. Highlight: ==highlighted text==

• Tag: <mark>
• HTML: <mark>highlighted text</mark>

CSS representation for those that are mostly presentational or has no tag associated.

1. Underline: _underlined text_

• ClassName: .underline

• Underline Thread

• HTML: <em class="underline" >underlined text</em>

1. Underline: __underlined text__

• ClassName: .underline

• Underline Thread

• HTML: <strong class="underline" >underlined text</strong>

1. Spoiler: >>! Spoiler Text !<<

• ClassName: .spoiler
• spoiler syntax thread
• HTML: <span class="spoiler" >Spoiler Text</span>

For reviewing purpose please refer to Reviewing Markups instead

---

Potential HTML tags

Researching on html tags that best matches these concepts

<u>

<u>

The HTML Underline Element (<u>) renders text with an underline, a line under the baseline of its content.

yea I know it ment for misspelt words and emphasis on certain Chinese letters. Well in this case, screw W3, it makes an underline and has always been in html’s history. ( APNG FTW btw)

<mark>

http://www.w3schools.com/tags/tag_mark.asp

Highlight parts of a text:
<p>Do not forget to buy <mark>milk</mark> today.</p>

<s>

http://www.w3schools.com/tags/tag_s.asp

Mark up text that is no longer correct:
<p><s>My car is blue.</s> My new car is silver.</p>

My car is blue. My new car is silver.

[vitaly]

Underline is not semantic.

[mofosyne]

Underline is not semantic.

Well it is used in many editing programs, like word processors (e.g. openoffice ). If we are to support these as well, then ideally we need to support underlines as well. At the very least instead of using <u> we could use the class .underline in html (which means it would be treated as an optional styling to be activated as needed).

---

Hmmm… would it be a good idea to not use tags, but rather classnames instead for highlights, strikeouts and underlines?

tldr: Maybe class="underline" rather than <u> is safer. Since it’s apparently considered as presentation elements rather than semantic

[vitaly]

IMHO, you mix underline and ins/mark (++).

Underline in word & office is ancient crap, like registration form with duplicated email and password fields. When this things were done, nobody thinked about semantic data representation.

[chrisalley]

I am quite opposed to supporting underlined text without semantic meaning. For the same reason that Markdown does not support fonts, colours, and other presentational features. We have CSS for that. @mofosyne, word processors could potentially use a Markdown + CSS combination.

<mark> and <s> are interesting. I’ve personally never used either. It would be good to see a real need for these before extending the Markdown syntax.

[mofosyne]

The case for <mark> via >>|| highlighted ||<<

I can imagine in emails, you have certain parts of the email you really need people to read in yellow highlight (As in bigger and more eye-catching than bold). The fact that <mark> is not over used is a good thing in this context, as it is more jarring and forces you to read that text.

The case for <s> via >>--strike though--<<

You can express ironic statements, or show a visual ‘edit history’ to the public. The <del> tag is not suitable as it is meant for showing “diffs” along with <ins>. So <s> is more semantic and is versatile.

The case for .spoiler via >>! spoiler !<<

It’s a quick way to designate a section as something that contains spoiler material that should be hidden unless the user desire to see it. CSS name should be .spoiler

The case for <blink> via ``>>_- blink here _-<<`

To annoy w3

[chrisalley]

I’m not going to dignify the <blink> proposal with a response.

Using >>-- for <s>. The benefit of using the proposed syntax isn’t clear. The HTML version is less typing.

I think you could make a case for a Markdown syntax for <mark>, along with <cite> but think the proposals should look like what they mean, otherwise we’re moving away from Markdown’s emphasis on readability above all else. The HTML versions, although verbose, express their meanings relatively clearly.

[mofosyne]

Hmmm… try typing this in notepad

<s> strike through </s>
>>-- strike though --<<

Notice that the bottom version is much easier/faster to type, even if it’s longer, because it’s just two sets of repeating characters.

I would argue that >>|| Highlight ||<< is more perceivable (and intuitive) as a highlight compaired to <mark> Highlight </mark>. This is since along with the strikeout tags, it is meant to provide an optical illusion of a filled box over the text.
(Along with the optical illusion of a strike through line)

This is based on the concept of: !wikipedia Illusory contours

The >><< is included for parser safety.

---

Visual illustration of two approaches

depth ordering >>||frequently accompany illusory contours.||<< is often credited with the discovery of illusory contours around the beginning of the twentieth century,[1] however illusory contours are >>--present in art--<< dating to the Middle Ages. Gaetano Kanizsa’s 1976 Scientific American paper marks the resurgence of interest in >>__illusory__<< contours for vision scientists.

depth ordering <mark>frequently accompany illusory contours.</mark> is often credited with the discovery of illusory contours around the beginning of the twentieth century,[1] however illusory contours are <s>present in art</s> dating to the Middle Ages. Gaetano Kanizsa’s 1976 Scientific American paper marks the resurgence of interest in <u>illusory</u> contours for vision scientists.

[mofosyne]

Underline in word & office is ancient crap, like registration form with duplicated email and password fields. When this things were done, nobody thinked about semantic data representation.

Hence we probably just implement it as a <div> with class=".underline" so that the user will have to explicitly add support for it in css if they need it.

If we are not to include it, what should office workers do or type instead to replicate their typical usage for underlines. If there is an alternative, then that is something that should be covered in the FAQ in “where is underline?” (e.g. how would you write a registration form field? That could perhaps be printed in paper and viewed in a computer screen).

[chrisalley]

I think it’s the >> which bothers me. It feels out of place in Markdown for an inline element. What do others think?

By the way, MultiMarkdown uses {==this text is highlighted==} for <mark>. Perhaps we could go even more minimal and use ==this text is highlighted==. Visually, the text looks like it has been highlighted with a highlighter pen.

Would it clash with any existing syntax?

[mofosyne]

Well the biggest concern that other people had with --- for strikethrough (proposed before) that made me add >><< is that they said that there is a danger that the syntax might clash with the horizontal rule.

Also how do you tell if the person wants a trailing space, e.g. === this has a trailing highlight===. But then again… unlike reviewing markup syntax… it is unlikely that missing a space to be a big deal. Well I guess it can work, if we adopt the same rule as the bold syntax, and require no space. This is so we can deal with people typing stuff like --- as an em dash.

Amended Proposal

--striked through text--
==Highlighted Text==
__Underlined Text__
>>! Spoiler Text Here !<<

for empty underlined fields (e.g. for signatures)

>>________________<<

edit: I think to be on the safe side, we should require three characters
edit2: scratched that… its annoying typing 3 chars actually. Hope it’s still safe.

[chrisalley]

Also how do you tell if the person wants a trailing space, e.g. === this has a trailing highlight===. But then again… unlike reviewing markup syntax… it is unlikely that missing a space to be a big deal. Well I guess it can work, if we adopt the same rule as the bold syntax, and require no space.

When highlighting something, you would normally be highlighting specific content. I can’t think of any use cases where it would be desirable to highlight trailing spaces, but if there are cases this could be a problem.

[mofosyne]

Sweet, well then first post is edited then. >><< is removed. Spoiler syntax looks a bit lonely tho

[chrisalley]

Hence we probably just implement it as a <div> with class=".underline" so that the user will have to explicitly add support for it in css if they need it.

<div> for block elements, <span> for inline elements. But I think <em> is often what people mean when they underline something, in which case writers could change the styling of <em> to be underlined and use the _underscore emphasis syntax_ to write it.

If we are not to include it, what should office workers do or type instead to replicate their typical usage for underlines. If there is an alternative, then that is something that should be covered in the FAQ in “where is underline?” (e.g. how would you write a registration form field? That could perhaps be printed in paper and viewed in a computer screen).

For a registration form you could use an HTML <input type="text"> and style it like a print form. While not ideal to type, it is at least semantic.

[mofosyne]

1. Underline: _underlined text_

• HTML: <em class="underline" >underlined text</em>

1. Underline: __underlined text__

• HTML: <strong class="underline" >underlined text</strong>

At the very least, it gives _ something to do (to be enabled if needed by say… a picky officeworker), besides being just another alias of *.

---

Fair enough about just using html for registration form field. I guess for printed registration form, you could still type ______ so it shouldn’t really matter.

[chrisalley]

Underline: underlined text HTML: <em class=“underline” >underlined text</em>

Underline: underlined text
HTML: <strong class=“underline” >underlined text</strong>

At the very least, it gives _ something to do (to be enabled if needed by say… a picky officeworker), besides being just another alias of *.

Three objections:

1. It could break existing implementations where the web designer did not expect that class to be applied to <em> elements.
2. It still violates the separation of concerns principle. Better to use a semantic class name like “alternative-emphasis” if you want to have multiple emphasis styles in the same document (you could add this class with the generic attribute syntax).
3. Markdown has always supported multiple ways of expressing the same HTML element. See lists, headers, links, and now in CommonMark, code blocks. Giving the writer a choice based on their own aesthetic style is an appealing part of Markdown; while I personally don’t use _, redefining it would take away an existing option and might upset some writers.

[mofosyne]

1. that’s a fair point
2. no problems with alternative classname, as long as it exists for _. Generic attribute syntax is not suitable however since you do not want to have to keep typing [_underlined_]{alternative-emphasis}.
3. it’s not exactly a redefinition of _, it’s more like providing the option for users to differentiate in css the difference between _ and * for users where the distinction does matter. The only changes to markdown’s _ html output is an addition of a classname.

###tl;dr: Behaviour of this to markdown is essentally identical, with the exception of an inclusion of classnames. Allows for differentiation between _ and * in CSS to whom that matters. Classname indeed can be ‘alternative-emphasis’ for _, though what would *'s classname be instead?

[chrisalley]

Generic attribute syntax is not suitable however since you do not want to have to keep typing [underlined]{alternative-emphasis}

Would *emphasised text*{.alternative-emphasis} or _emphasised text_{.alternative-emphasis} work?

Edit: I get what you’re saying about not wanting to type that syntax, but alternative emphasis seems like a rare feature. If underlining is common, just make it the primary emphasis style. The question we should be asking is why writers need so many emphasis styles. <em> and <strong> already provide two.

[mofosyne]

1. In a sense it provides a importance modifier to the emphasis tag. E.g. I seen it used in a registration form used to “double emphasis” the boded sentence. Take for instance:
   This sentence has double the impact compared to Just boding this other sentence . Thus catching more attention.

2. Catering to certain people style. If we want this to be common, we do need to cater to people like office workers, who may not necessarily care about the fact that “underline is not semantic”. When they type underline, they expect underlines. While I may sympathise with the ideal of avoiding confusion with hyperlinks, I do not expect there to be any harm with allowing for users to at least customize their css to modify only the _ syntax.

3. Remember, that common mark is not purely for programmers, but for ordinary users as well. And we can’t simply expect the majority to conform to our desire for a fully semantic web. Instead we should aim for “least surprises”. Making a class distinction is a good compromise. We don’t have to encode it into the official recommended CSS file, just allow the possibility to target _ in CSS is flexible enough.

This becomes especially useful once we have generic declaration sytax. Since we could specify css overrides. E.g. this block syntax:

!css: .underline{ text-decoration: underline; }

And by default, just set .underline class as empty initially, but enabled when needed in a site by site, or per document, or user posting preference basis.

[chrisalley]

In a sense it provides a importance modifier to the emphasis tag. E.g. I seen it used in a registration form used to “double emphasis” the boded sentence. Take for instance:This sentence has double the impact compared to Just boding this other sentence . Thus catching more attention.

For the registration form example, an HTML <form> with <label>'s and <input>'s would be more semantic.

For double emphasis, a semantic approach would be to use triple astrisks in Markdown (see Example 292 in the spec) and then style it to be bold and underlined:

<style type="text/css">
  strong em {
    text-decoration: underline;
    font-style: normal;
  }
</style>

<strong><em>This sentence has double the impact</em></strong>

[quote=“mofosyne, post:19, topic:825”]
Catering to certain people style. If we want this to be common, we do need to cater to people like office workers, who may not necessarily care about the fact that “underline is not semantic”. When they type underline, they expect underlines. While I may sympathise with the ideal of avoiding confusion with hyperlinks, I do not expect there to be any harm with allowing for users to at least customize their css to modify only the _ syntax.[/quote]

I agree that many users will not care about content being semantic, but I don’t think we should be encouraging the behaviour by supporting it via CommonMark syntax.

It’s similar to how Markdown does not encourage line breaks (paragraphs are usually what should be used) and how you must explictly leave the alternative text of an image blank if you’re going to disregard blind users.

Remember, that common mark is not purely for programmers, but for ordinary users as well. And we can’t simply expect the majority to conform to our desire for a fully semantic web. Instead we should aim for “least surprises”. Making a class distinction is a good compromise. We don’t have to encode it into the official recommended CSS file, just allow the possibility to target _ in CSS is flexible enough.

The semantic web isn’t just for programmers. It has other advantages such as portability. By only declaring the meaning of content (not the presentation) you allow your HTML or Markdown file to be styled completely differently depending on the designer’s intention (seperate from the writer’s meaning). I encourage you to have a look at the examples on CSS Zen Garden to see just how powerful this is.