I've create a Hugo blog Template used to create a Hugo blog quickly:
We should have Markdown-rendered websites
311–320 of 351 posts
Re: We should have Markdown-rendered websites
#312Earlier quoted context omitted.
> only a small subset of html's features. On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds. This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this fu…
Flavors of Markdown might be a superset, but as it is normally used, I don't think many would say that Markdown has all the abilities of HTML.
[deleted]
Re: We should have Markdown-rendered websites
#313Earlier quoted context omitted.
> only a small subset of html's features. On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds. This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this fu…
Flavors of Markdown might be a superset, but as it is normally used, I don't think many would say that Markdown has all the abilities of HTML.
The original Markdown spec is very clear that HTML is allowed. So MD itself is absolutely a superset of HTML
https://daringfireball.net/projects/markdown/syntax#html
But in practice people mostly use MD variants, such as the "GitHub Flavored Markdown Spec" which may have some limits on HTML usage
Re: We should have Markdown-rendered websites
#314Once upon a time I made a very minimal PoC markdown "browser" in a day or two. It basically had a navigation bar like a browser, only displayed markdown and would only follow links to other markdown documents. It was more of a project to play with React Native for macOS/Windows more than anything serious, but I think the general idea could be neat if implemented correctly in some native GUI toolkits.
Re: We should have Markdown-rendered websites
#315Earlier quoted context omitted.
> Why didn't we end up with SGML -> XML "compilers"? 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 dependin…
Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?
Both XML and HTML are implementations of SGML. SGML is the parent reference and includes things that aren't in either subset.
SGML was invented by IBM for "pubs," authoring documents electronically but shipping them as printed manuals.
Lacking the need for print (in HTML) and for display (in XML) lead to those versions.
Re: We should have Markdown-rendered websites
#316Earlier quoted context omitted.
Maybe I'm too young for all this, but that sure seems like something I've always wanted. Why aren't we using SGML for authoring HTML in 2022?
I was a big supporter of SGML-based languages: markup language written for humans to author. However, the trend in computing in late 90s and early 2000s was to come up with more easily parsed languages, thus came things like XML: a mark-up language tuned for computers to produce. But let's be honest here: parsing most XML can be done very simply, whereas supporting basic SGML was only possible with the OpenSP. SGML i…
Me, too, having worked at IBM and used SGML there. But JSON is what really killed XML. It can be harder to read, especially at first, but it's shorter and fulfills all the same roles.
Re: We should have Markdown-rendered websites
#317Markdown by definition compiles to HTML and must be rendered by a browser as HTML. This seems to be a widely overlooked fact in this thread.
It's fine to write MD, but know that it's a limited and shortcut form for the real HTML that will be output and rendered.
The short form is great for short stuff but to access the full power of HTML and CSS takes really messy spaghetti MD. And don't even start with JS or TS. Modern sites usually need code and that means web components and that means real HTML and all of CSS need to be present and accessible in an orthogonal way -- not some via MD syntax and some with HTML glommed-onto MD.
Re: We should have Markdown-rendered websites
#318We already do. They use static site generators to produce HTML (a good interchange format) from a customized form of markdown (which is not standardized at all and very customizable). This state of the world is totally fine - it works well for both viewers and content producers.
This gets at the key difference between the two. Markdown is for authoring and HTML is for presentation.
Re: We should have Markdown-rendered websites
#319Markdown is a convenient but deeply limited markup language with only a small subset of html's features. And yes, limitations are good because we want documents not web apps, etc, etc, but I mean "images can't have captions" limited, "navigation bars don't exist" limited. Actual important features of html don't exist in markdown, which is why almost every markdown platform ends up adding extensions and shortcodes. Wh…
Write a list in HTML and write one in Markdown. The difference in legibility is pronounced. Especially if you don't want weird whitespace things.
I don't find this illegible in the least.
Item one
Item two
Item three
Item four
Re: We should have Markdown-rendered websites
#320Markdown is a convenient but deeply limited markup language with only a small subset of html's features. And yes, limitations are good because we want documents not web apps, etc, etc, but I mean "images can't have captions" limited, "navigation bars don't exist" limited. Actual important features of html don't exist in markdown, which is why almost every markdown platform ends up adding extensions and shortcodes. Wh…
> only a small subset of html's features. On the contrary - Markdown is essentially a superset of HTML, so unless you're using a renderer that strips it from the input, you can have the best of both worlds. This property was super useful for a lightweight CMS I threw together a few years and which is still used by the original customer today. 99% of what they need to render is easily authored in Markdown, and this fu…
The original markdown parser supported html because it was basically just a preprocessor that added some syntactic sugar to html. The proposal here isn't just "what if browsers had a markdown preprocessor" (although I also think that would be questionable), but "what if browsers limited content down to only markdown, so that the web was all just clean, style-agnostic documents," and that clearly requires that markdown not support arbitrary html.