5 ms·
I honestly don't understand the point of markdown. * this* isn't any easier than <i>this</i> to me. Of course, I may be biased.
by VikingCoder 13y ago
I honestly don't understand the point of markdown.
* this* isn't any easier than <i>this</i> to me.
Of course, I may be biased.
- untog 13y agoNo, our style guide clearly states that you should be using <em> now, not <i>. ...OK, an exaggeration. But it's much simpler than HTML. If people input with HTML then you're going to need to filter which tags you do and don't want to pass through. Markdown just gets rid of stuff like that. Not to mention automatic paragraphing.
- y0ghur7_xxx 13y ago> But it's much simpler than HTML. I don't know. Everybody knows HTML. It's pretty easy. > If people input with HTML then you're going to need to filter which tags you do and don't want to pass through. That's a solved problem¹²³. > Markdown just gets rid of stuff like that. And you can only use a subset of HTML. I guess there are pros and cons. > Not to mention automatic paragraphing. <p>...</p> ¹https://code.google.com/p/owasp-java-html-sanitizer/ https://code.google.com/p/owasp-java-html-sanitizer/ ²https://github.com/rgrove/sanitize https://github.com/rgrove/sanitize ³http://code.google.com/p/google-caja/wiki/JsHtmlSanitizer http://code.google.com/p/google-caja/wiki/JsHtmlSanitizer
- DanBC 13y agoYou'd change your mind about "everybody knows HTML" if you say the HTML I produce. Little things like <em> or <i>, and browsers being very tolerant of appalling HTML, mean that a lot of people only sort of know HTML. I do wosh that BBCode or Markdown had better standards.
- patrickk 13y ago> You'd change your mind about "everybody knows HTML" ... Absolutely. You could've stopped there without any further caveats. The comment above I think is HN arrogance, assuming that the rest of the web is at a certain minimum level of tech literacy. So many people post facebook updates or online comments and don't what what HTML is. I know someone (relatively young, uses the internet daily) who doesn't know what a browser is. That aside, if given the choice, I would voluntarily use Markdown for comments all day long, no contest. For example a bullet/unordered list[1] needs so many awkward tags, whereas a Markdown list is much simpler, and much more intuitive for those who don't know HTML[2]. [1] http://www.w3schools.com/tags/tag_ul.asp http://www.w3schools.com/tags/tag_ul.asp [2] http://www.reddit.com/r/reddit.com/comments/6ewgt/reddit_markdown_primer_or_how_do_you_do_all_that/c03nik6 http://www.reddit.com/r/reddit.com/comments/6ewgt/reddit_mar...
- VikingCoder 13y agoI honestly feel that "white-space: pre-wrap" would get you there for 99.9% of the internet, who never even use markdown. How about the other 0.1%? Well, why not a WYSIWYG editor (similar to that on Stack Overflow) that generates HTML? I mean, what are we, barbarians?! I'll note that the source to your Reddit article is 322 lines long! That'a lot to remember!
- patrickk 13y agoWell for reddit comments, the vast majority of the comments I typically make will make use of quotes, bold, italics or lists (the comments that include markdown), I use stuff like tables quite infrequently. So even remembering a small subset of the markdown will make my comments much more readable. I learn the features I use regularly, from reading other comments, that's how I picked up markdown originally. I'm learning Python, I don't expect to learn all the features, hopefully I will learn a small subset, enough to be dangerous! > Well, why not a WYSIWYG editor (similar to that on Stack Overflow) that generates HTML? Absolutely, this is a good solution also. I personally like knowing the markdown features, I guess, but that's just me ;-) There is an extremely similar feature in the RES addon which allows live preview, not possible on a smaller screen though. It even includes a helpful list of markdown features for the newbie.
- themodelplumber 13y ago<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0//EN" "http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd"><html http://www.w3.org/Math/DTD/mathml2/xhtml-math11-f.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><!--This http://www.w3.org/1999/xhtml"><!--This file was converted to xhtml by LibreOffice - see http://cgit.freedesktop.org/libreoffice/core/tree/filter/source/xslt http://cgit.freedesktop.org/libreoffice/core/tree/filter/sou... for the code.--><head profile="http://dublincore.org/documents/dcmi-terms/"><meta http://dublincore.org/documents/dcmi-terms/"><meta http-equiv="Content-Type" content="application/xhtml+xml; charset=utf-8"/><title xml:lang="en-US">- no title specified</title><meta name="DCTERMS.title" content="" xml:lang="en-US"/><meta name="DCTERMS.language" content="en-US" scheme="DCTERMS.RFC4646"/><meta name="DCTERMS.source" content="http://xml.openoffice.org/odf2xhtml"/><meta http://xml.openoffice.org/odf2xhtml"/><meta name="DCTERMS.issued" content="2014-04-10T12:09:56.750408000" scheme="DCTERMS.W3CDTF"/><meta name="DCTERMS.modified" content="2014-04-10T12:10:53.104205000" scheme="DCTERMS.W3CDTF"/><meta name="DCTERMS.provenance" content="" xml:lang="en-US"/><meta name="DCTERMS.subject" content="," xml:lang="en-US"/><link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" http://purl.org/dc/elements/1.1/" hreflang="en"/><link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" http://purl.org/dc/terms/" hreflang="en"/><link rel="schema.DCTYPE" href="http://purl.org/dc/dcmitype/" http://purl.org/dc/dcmitype/" hreflang="en"/><link rel="schema.DCAM" href="http://purl.org/dc/dcam/" http://purl.org/dc/dcam/" hreflang="en"/><style type="text/css"> @page { } table { border-collapse:collapse; border-spacing:0; empty-cells:show } td, th { vertical-align:top; font-size:12pt;} h1, h2, h3, h4, h5, h6 { clear:both } ol, ul { margin:0; padding:0;} li { list-style: none; margin:0; padding:0;} <!-- "li span.odfLiEnd" - IE 7 issue--> li span. { clear: both; line-height:0; width:0; height:0; margin:0; padding:0; } span.footnodeNumber { padding-right:1em; } span.annotation_style_by_filter { font-size:95%; font-family:Arial; background-color:#fff000; margin:0; border:0; padding:0; } * { margin:0;} .P1 { font-size:12pt; font-family:Liberation Serif; writing-mode:page; } .T1 { font-style:italic; } <!-- ODF styles with no properties representable as CSS --> .Endnote_20_Symbol .Footnote_20_Symbol { } </style></head><body dir="ltr" style="max-width:8.5in;margin-top:0.7874in; margin-bottom:0.7874in; margin-left:0.7874in; margin-right:0.7874in; writing-mode:lr-tb; "><p class="P1">I don't get the point either. Plus, Markdown has its <span class="T1">own</span> set of annoying rules. Most software will already export to HTML, too, like LibreOffice.</p></body></html>
- hrktb 13y agoI am not a fan of markdown, but I think it shines in niche uses. For instance typing two "*" or 5 "<>/" are a completely different experience on an iPad for instance. For a sublime text plugin it seems irrelevant, but if you edit your files in different environments it's a boon. It's also a lot more parseable and sanitizable than html, and doesn't need much escaping when moved around.
- bowerbird 13y agoi think most people will tell you that it _is_ easier. first, it's one character, as opposed to three or four. and, as you get into longer tags, like "em" or "strong", so grows the amount of excess typing you'll need to do. (i won't mention "blockquote", but you know that i could!) second, it's the _same_ on both sides, not different. and there's no question about the direction of a slash, which is not intuitive to people who don't code .html. third, let us recall that some structures, like lists, need internal "li/li" tag-pairs on each individual item, as well as the "ul/ul" tag-pair located on the outside. fourth, all the brackets/tags are intrusive when editing. your mind has to "look past" the markup to see the text, and those distractions make writing more difficult than it already is, and there's no reason to put up with that. fifth, the distraction gets even worse if you want to have curly-quotes, because there's crap like “this”; and let’s all agree we don’t need that garbage! sixth, .html can get downright complicated, very quickly. can you tell me how "pre", "code", and "keyboard" differ? probably not, not just off the top of your head, anyway... and what's the abbreviation tag again? i always forget it. and seventh, you mean i have to put a "p" tag on _every_ paragraph? _every_ one? can't it just do _that_ for me? it's pretty obvious that blank line means "new paragraph". i mean, seriously, sometimes computers are _so_stupid!_ so, um, yeah, actually, light-markup is a _lot_ easier. still... if _you_ prefer to write in .html, be my guest! but me? well, i've got way more important things to do. -bowerbird
- VikingCoder 13y agoPicture a WYSIWYG or maybe a preview-below editor, much like the Stack Exchange ones, but outputting HTML behind the scenes rather than markup. Now there's no character to type for italics, you highlight what you want in italics, and push the button. Or type Control-I. <i> and </i> magically appear. Pretty soon, you might even learn what they mean. A "make bullet" or "make numbered" list button. An indent/unindent button. Much like GMail Compose or Google Drive. Most of the time, people don't bother with even Markup. All those asterisks and double-asterisks. Many people just post links, rather than that paren / brace stuff like on Reddit. Yes, HTML can get downright complicated. The vast majority of the time, people don't even Markup. As for p tags, the site could have white-space: pre-wrap style applied to all comments. Boom. And again, markup is nice and all. So is Notepad. But I like HTML, and I like IDEs. And to be clear, I'm not saying a site would allow all HTML tags (that would be suicide with the first <script>), but would whitelist them. Then, there's no CPU time to render Markup into HTML. So, there's that.
- frou_dh 13y agoThe point is to enshrine the conventions you'd likely use anyway if the world was plain text. With HTML it's obvious that the plain text is an intermediate representation that always expects to be further interpreted.
- DanBC 13y agoIt's a shame that existing conventions got broken. bold, _italic_. Underlining is only used by typewriters or for links and is barbaric and should be avoided for almost all other uses.
- shurcooL 13y agoI see typos like this pretty regularly. https://github.com/go-gl/glfw3/commit/c48f1acb53fec41115b7317914b8243f7a92377c#commitcomment-5974207 https://github.com/go-gl/glfw3/commit/c48f1acb53fec41115b731...
- VikingCoder 13y agoDetecting that kind of problem is not hard. When someone is posting a comment, or even while they're editing it, you could point it out to them.
- shurcooL 13y agoI don't understand the motivation of that argument. Writing assembly isn't hard either, is it. If they make a mistake, you can point it out to them.
- VikingCoder 13y agoYou're asserting users screw things up. Fine, I'm saying that showing a user they screwed up is neither a technology challenge, or a user interface challenge. If I type squirtle right now in my browser, Chrome underlines it in red. Everyone's used to this. Showing <code><code> with the second code underlined in red, to tell the user to change it to </code> is neither technically difficult, or confusing to users. My point being, you seem to be arguing that markup is hard to make mistakes in. I'm retorting that helping users correct their HTML mistakes is not hard, and is a valid response to the problem that <code><code> poses.
- shurcooL 13y agoThat is a much better articulated argument, thank you. I'm happy to say I agree that your retort's point is valid.
- frade33 13y agoyou are biased because you created HTML? s/ Markdown was and is for html moms. Whereas, I would often type <h2>heading</h2> in the .doc files. never-mind.