231–240 of 351 posts
Earlier quoted context omitted.
just hit reader mode
My browser doesn't have one, and even if it did the point is that it should look good without any effort.
You can also do default user stylesheets.
This is a positive point for things being pretty well set up today.
Earlier quoted context omitted.
I can't meaningfully distinguish any of these criticisms from some you could have made about HTML earlier. None of these are deal-killers.
The difference is 30 years of websites and tools being built on HTML. There's an opportunity cost to consider: is formatting simple websites in Markdown and rendering them natively that much more valuable than simply writing them in HTML or using a Markdown-to-HTML tool that it's worth the cost of creating standards, implementing them in browsers, etc. as opposed to putting those efforts elsewhere? If you were starti…
We need to bring text editing into the 21st century where rich text is standardized across all platforms and devices. We can send multicolored emoji to just about any device on the planet, but we still can't bold, italicize, underline or color basic text. It's straight up insane.
Think about it: There is no such thing as "plain text", it's just encoding we don't see.
Even if you're a die-hard keyboard jockey, unless you're looking at your command line and mentally parsing raw ANSI encoding like \e[1mBold, you're not using "plain text". There's tons of encoding underneath every text editor and terminal program, you just don't see it. We already have a standard encoding for rich-text, we need to start using it. It's called HTML, and every device with a screen on the planet knows how to display it. We just need to hide the tags everyone bitches about just like vi hides a highlighted line's \e[43mYellow codes. We should never need to see it.
Any place we're able to enter text should support rich text, from boot up screen through to apps. And underneath it should all be HTML. It's like the display compositor on macOS. None of us think about the fact it uses PDF under the hood, right? We're not debating whether it should be done using SVG. It's invisible. This debate should have been settled decades ago.
I've been writing about this in detail for the past several weeks. I swear the tech industry has lost its collective minds. At this point I'm truly wondering if Markdown is some sort of cult. We need to kill these lightweight markup formats with extreme prejudice and start solving the real problem.
Thus, instead of
- Fruits
- apple
- orange
you must write
- Fruits
- apple
- orange
(edit)
...we allow headings to "lazily" span multiple lines:
> ## My excessively long section heading is too
> long to fit on one line.
...if you open a code span and don't close it, it extends to the end of the paragraph. That is similar to the way fenced code blocks work in commonmark.
> This is `inline code.
This doesn't really make sense, for a couple reasons... There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Meanwhile, markdown is designed to transform to HTML, which browsers already render. Adding a markdown-to-html plugin/step to your web server or publishing process is not exactly the most burdensome thing, relative to everythin…
> markdown is designed to transform to HTML Is it though?
Earlier quoted context omitted.
The fatal flaw of HTML (and XML for that matter) is that the tags have the same visual weight as the text they're delimiting, which makes for a sense of clutter even in your minimal example. Markdown really scores here, by having a pleasing plain text representation as a goal from the outset, and I've love to see it used more widely for web pages. I'd also love to see it more widely used for offline reading, too - th…
HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a element is replaced by , and moreover define that an asterisk appearing within content is replaced by , toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else re…
As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing.
Or are there some SGML features that cannot be represented with an equivalent in XML?
Earlier quoted context omitted.
> There are many flavors of markdown. We'd need a standards body, compatibility suites, etc., and for all the browser vendors to adopt it. Well, if it were to be adopted by vendors, the many flavors would be a non-problem. They can just agree on a flavor and be down with it. There's CommonMark anyway, they can just use that.
Except that CommonMark has its own very annoying things. Like loose lists. Multiple lists of bullet points ends up an ugly mess with CommonMark.
Earlier quoted context omitted.
HTML is based on SGML, and SGML has short references to handle lightweight custom syntaxes. For example, you can define that an asterisk appearing in your content within a element is replaced by , and moreover define that an asterisk appearing within content is replaced by , toggling emphasized text tags. So SGML very much acknowledges the need for lightweight markup, but the SHORTREF feature, like everything else re…
Why didn't we end up with SGML -> XML "compilers"? As I understand it, XML is intended to be equivalent to SGML, with less syntactic flexibility to make it easier to parse. So once you've done the hard work of parsing SGML, it seems like it should be straightforward to emit the same data as XML for further machine processing. Or are there some SGML features that cannot be represented with an equivalent in XML?
We did; both the osx command-line tool of the venerable SP/OpenSP package, as well as sgmlproc (sgmljs) with output_format=xml does exactly that: output canonical XML markup with shortrefs resolved, omitted tags inferred, attribute values put in quotes and attribute names preprended where not already present, conditional marked sections included or omitted depending on parameter entities, and also entity references expanded, etc. But SGML can also output HTML proper, unlike XML.
SGML mostly has additional authoring features over XML indeed, but a number of additional concepts as well: much more powerful notations (used as general extension mechanism such as for math or parametric macro expansion) and stylesheets ie. link process declarations with state-dependent assignment of attributes and pipelining to yield markup projections, transforms, and views.
Earlier quoted context omitted.
For people considering adding Markdown support to web browsers or other publishing tools, please consider adopting Djot instead: https://github.com/jgm/djot It's very similar to the Markdown syntax we all know and love/hate, but fixes many inconsistencies in the spec, and also makes it possible to parse a document in linear time, with no backtracking. It is also much fuller-featured than commonmark, with support for…
The primary goal and appeal of Markdown is that it is easy to write . Optimizing for parsing is creating a fundamentally different product. Standardization of the spec is good. Requiring quirky behavior and blank lines that hurt reading is bad.
> Requiring quirky behavior and blank lines that hurt reading
Really? The linked spec says, referring to a blank link in indented lists:
> reStructuredText makes the same design decision.
And as a design goal:
> your document [must be] readable just as it is, without conversion to HTML and without special editor modes that soft-wrap long lines. Remember that source readability was one of the prime goals of Markdown and Commonmark…
Or this, which made me celebrate:
> anything that is indented beyond the start of the list marker belongs in the list item.
In Markdown it’s really hard (aka impossible) to get sections to respect the indentation level they belong to. What a simple rule here: inside a list, items belong to their list item. Beautiful!
Other great quotes:
> we don't need two different styles of headings or code blocks.
> avoid using doubled characters for strong emphasis. Instead… use _ for emphasis and * for strong emphasis
> code span parsing does not backtrack. So if you open a code span and don't close it, it extends to the end of the paragraph
Sanity. Sanity introduced to an ambiguous spec. It’s wonderful.
This bit made me a little unsure:
> although we want to provide the flexibility to include raw content in any output format, there is no reason to privilege HTML. For similar reasons we do not interpret HTML entities, as commonmark does
While Markdown was meant to transform to HTML, I wish it was a spec renderable without a HTML or web browser layer. So I like this. Equally though one use case I personally have is Markdown to static HTML and it’s useful having HTML tags present and handled. So my understanding of this part of the spec is confused (what does “interpret” mean?) but if it means no support for inline HTML that is indeed a pity.