TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Thoughts on Markdown

66 点作者 sanqui大约 3 年前

8 条评论

bobbylarrybobby大约 3 年前
It&#x27;s a real shame that Markdown beat out AsciiDoc(tor). The original AsciiDoc project was even released before Markdown. But compared to Markdown, Asciidoctor makes it just as easy to write simple formatted text; makes it <i>far</i> easier to write complicated markup such as definition lists and tables; supports common article-authoring features like a table of contents, footnotes, and inclusion of other documents; supports the use of simple variables that get expanded when the document is rendered; supports anchors and CSS-style classes; provides an API for user-authored extensions (in Ruby, for Asciidoctor) to customize document processing; and renders to an intermediate format not coupled to any one output format.<p>I cringe whenever I have to write markdown. It&#x27;s <i>such</i> a bad format, and it&#x27;s a shame that people tried to keep bolting on additional features it wasn&#x27;t meant to support instead of just picking a better option. I wonder if John Gruber even knew about AsciiDoc when he started work on Markdown, and if he would have gone to the trouble if he had.
评论 #30434354 未加载
JNRowe大约 3 年前
Previous discussion from earlier today¹ with a hefty bunch of comments.<p>¹ <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30395130" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=30395130</a>
mawise大约 3 年前
These are good thoughts. The crux I&#x27;m taking away is two-fold: Markdown is great for the developer community, but not the broader authorship community; and the fragmentation of Markdown makes for a rough experience for anyone maintaining Markdown-based tools.<p>I decided to use Markdown for the first implementation of Haven[1]&#x27;s editor but I&#x27;m definitely keeping my eye on some of these newer block-based systems. There was a Joel-on-software post last month advocating for something similar[2].<p>One advantage I keep thinking about (but probably over-value) is graceful degradation without Javascript. You can still write Markdown in a `textarea` and submit it in a form. Is there a similar fall-back for these modern editing systems?<p>[1]: <a href="https:&#x2F;&#x2F;havenweb.org" rel="nofollow">https:&#x2F;&#x2F;havenweb.org</a> [2]: <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2022&#x2F;01&#x2F;27&#x2F;making-the-web-better-with-blocks&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2022&#x2F;01&#x2F;27&#x2F;making-the-web-bet...</a>
swyx大约 3 年前
I wrote a blogpost on &quot;6 Things Markdown Got Wrong&quot; last year and John Gruber actually weighed in! <a href="https:&#x2F;&#x2F;www.swyx.io&#x2F;markdown-mistakes" rel="nofollow">https:&#x2F;&#x2F;www.swyx.io&#x2F;markdown-mistakes</a>
评论 #30423948 未加载
mythz大约 3 年前
I&#x27;ve been exclusively using Markdown for all docs for several years which I&#x27;ve found to be the most productive format for writing docs. My preferred setup now being to use VS Code with a browser running a local instance of <a href="https:&#x2F;&#x2F;vitepress.vuejs.org" rel="nofollow">https:&#x2F;&#x2F;vitepress.vuejs.org</a> which instantly live reloads content on each save and renders our custom server components exactly as it looks when published.<p>Its biggest benefit is its extensibility which lets you embed interactive Vue Components directly in the docs, which we&#x27;ve made liberal usage of in our latest product release with tabbed components &amp; online project creator embedded directly in the release notes, e.g:<p><a href="https:&#x2F;&#x2F;docs.servicestack.net&#x2F;releases&#x2F;v6#todos-mvc" rel="nofollow">https:&#x2F;&#x2F;docs.servicestack.net&#x2F;releases&#x2F;v6#todos-mvc</a><p>A lighter weight extensibility option is to extend it [1] with custom block-level custom containers using markdown-it-container [2] which lets you create custom markup like this:<p>::: nuget `&lt;PackageReference Include=&quot;ServiceStack.OrmLite.PostgreSQL&quot; Version=&quot;6.*&quot; &#x2F;&gt;` :::<p>::: sh x mix postgres :::<p>Which gets rendered into custom copy widgets as seen in:<p><a href="https:&#x2F;&#x2F;docs.servicestack.net&#x2F;ormlite&#x2F;installation" rel="nofollow">https:&#x2F;&#x2F;docs.servicestack.net&#x2F;ormlite&#x2F;installation</a><p>Source:<p><a href="https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;ServiceStack&#x2F;docs&#x2F;master&#x2F;docs&#x2F;ormlite&#x2F;installation.md" rel="nofollow">https:&#x2F;&#x2F;raw.githubusercontent.com&#x2F;ServiceStack&#x2F;docs&#x2F;master&#x2F;d...</a><p>Markdown all text things!<p>Basically if it needs to capture text content, I&#x27;ll look for the Markdown version if it exists, which extends into my preferred TODO App: <a href="https:&#x2F;&#x2F;notable.app" rel="nofollow">https:&#x2F;&#x2F;notable.app</a> - a beautiful little App that manages a static directory of *.md files. My first TODOs replacement of using notepad.exe that&#x27;s stuck.<p>[1] <a href="https:&#x2F;&#x2F;vitepress.vuejs.org&#x2F;guide&#x2F;markdown.html#advanced-configuration" rel="nofollow">https:&#x2F;&#x2F;vitepress.vuejs.org&#x2F;guide&#x2F;markdown.html#advanced-con...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;markdown-it&#x2F;markdown-it-container" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;markdown-it&#x2F;markdown-it-container</a>
eternityforest大约 3 年前
If we are going to design something new, we should probably start with the WYSYWIG editor and only then design the actual data format.<p>If we want machine readable data we should think first about how it will be authored. Maybe our new format has Excel style tables, and Mustache templates that can read them, so that we can just drop in a table view widget in the editor and customize it, filter it, let users sort it, etc.<p>Maybe our tables have a type UUID for identifying what the table layout is.
ravenstine大约 3 年前
Markdown is mostly a failure. Yes, it&#x27;s more convenient than writing your README in docx or txt, but if you want to do anything with it off the narrow beaten path, you&#x27;ll inevitably have to extend it or give up.<p>For example, let&#x27;s say you want something that&#x27;s not supported by Markdown&#x27;s syntax, such as dictionary lists, but you want to be able to use Markdown&#x27;s text formatting syntax with it:<p>```markdown<p>&lt;dl&gt;<p><pre><code> &lt;dt&gt;*foo*&lt;&#x2F;dt&gt; </code></pre> &lt;&#x2F;dl&gt;<p>```<p>Most Markdown parsers don&#x27;t apply Markdown parsing of text nodes within HTML elements. This is why the argument that Markdown supports HTML doesn&#x27;t work, because it <i>literally</i> doesn&#x27;t work for why we are using Markdown in the first place... which is to avoid the verbosity of HTML.<p>This kind of thing really bugs me. No matter what, whenever I&#x27;ve tried using Markdown as a tool for constructing webpages rather than snippets&#x2F;comments within pages, I end up having to write a custom AST transformer to either get the parser to produce the right output or to prevent it from adding &lt;p&gt; tags around block elements that shouldn&#x27;t have them in the first place.<p>Maybe a formal standardization could be the first step to actually addressing such issues, but it&#x27;s questionable whether it&#x27;s worth the bother.
评论 #30423481 未加载
评论 #30423914 未加载
评论 #30422872 未加载
throwaway984393大约 3 年前
Markdown was not designed to make an end user&#x27;s life easier. It was designed to make it easier for somebody to write the most generic document imaginable. It&#x27;s part of the general disease of developers creating solutions solely for developers, at the expense of anyone who isn&#x27;t a developer.