Markdown Tutorial
markdowntutorial.com
markdowntutorial.com
https://duckduckgo.com/?t=ffab&q=markdown+cheatsheet&ia=answ...
In other news, website looks like crap on Firefox mobile.
It's probably a unsolvable problem unless: - everyone adapts to using common, more difficult to type, characters such as " or ? (but then how does the system differentiate between common figures of speech and formatting?) - everyone switches to US/ENG layouts, but we already had enough US-centric systems in the past and I don't know how many wouldn't see this change as a personal/national attack - the creation of a Fn keys standard, but that means all hardware producers would have to comply to eat (yeah) and mobile typing would become problematic, along with extra strain from having to press the "fn" modifier - your solution, which i find elegant, but adopted OS-wise instead of just inside an editor plugin. but then what if ctrl-1 is my shortcut for switching desktops, or closing windows?
Maybe the only cure is to accept defeat, create localized versions and create translators - after all this seems how languages work.
He's talking about physical keyboard layout, nothing you suggested will help with that.
Not in my purely anecdotal experience. While many (but not all) developers like markdown, I've yet to come across non-technical users who like it (tolerate it perhaps, but not like).
On Reddit, I frequently see mistakes caused by Markdown behaving unexpectedly. Common problems include:
- "How old are you?" "52." gets renumbered into "How old are you?" "1.".
- People using single linebreaks for poetry and song lyrics, and being confused when they get collapsed into a single line.
GitHub Flavored Markdown _does_ fix both these problems, but for some reason, regular Markdown is a lot more common, even when targeting non-technical users.
However, as Markdown is supposed to be nothing more than a superset of HTML, you can simply reach for CSS. It won't always render the best if you're moving from Markdown to physical medium, but that's largely dependent on the engine.
If this is an input to a website, for example, the webmaster really doesn't desire everyone to be able to reinvent the blink tag, or be able to express everything in rainbow fonts.
In which case Markdown shines, for it's ability to express simple markup, that can be safely expressed.
Not at all.
PS: By the way, you are currently commenting in text without colors - how do you feel?
You (and other posters) can ironize as much as they want, the truth is dealing with colored text in Markdown is equals to inputting raw HTML, as which point mixing the two markup languages is more painful than going raw HTML.
PS: Why not have the best of both worlds, that is, Markdown and Wikitext? Yes, you can; see Texti (Text with Formatting Instructions) - https://texti.github.io
Having hash line comments is probably a non-starter in a text format (the latex % syntax is probably a better idea indeed if you want line comments). Also the -- strikethrough -- syntax will probably conflict too much. You want comments to use a syntax which is otherwise nearly unused.
PS: The main missing feature (among others) in Markdown and that rocks Wikitext (and Texti too) is built-in (recursive) templates (with optional parameters) using the {{}} syntax.
[1]: I know % is not new because it's used in LaTeX but LaTeX is esoteric compared to Python, Ruby, Shell Scripts, Unix Configs, etc.
#1: That's the only reason.
It's kind of like:
1. FC Köln - that's a football club name (and not a list marker). Try it in markdown - same gotcha :-)
For some examples of modern html, see google's style guide for html, section 3.1.7 shows an example of a complete and correct document that may blow your mind. Also, the examples of tables and lists without closing elements:
> A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element, or an autonomous custom element.
https://html.spec.whatwg.org/multipage/syntax.html#syntax-ta...
This is so complicated. In the end it's easier for me to close the tag instead of second guessing if I may skip it or may not.
- https://en.wikipedia.org/wiki/ReStructuredText
- https://docutils.readthedocs.io/en/sphinx-docs/user/rst/quic...
A short feedback loop (e.g. live preview) should take care of that.