Researching on html tags that best matches these concepts
<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)
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
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.
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.
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
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.
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)
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.
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).
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.
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.
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.
<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.
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.
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.
It could break existing implementations where the web designer did not expect that class to be applied to <em> elements.
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).
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.
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}.
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?
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.
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.
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.
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.
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.
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.
