Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We should have Markdown-rendered websites

ipfs.io

Post reply on HN
Print view View original

321–330 of 351 posts

Re: We should have Markdown-rendered websites

#321

Post by martyalain »

It's said that the father of LISP, John McCarthy, lamented the W3C's choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. » The {lambda way} project could be an answer, small and simple: http://lambdaway.free.fr/lambdawalks/

In lambdatalk such a HTML code

    Page Title

    
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    Ut ac lorem ut massa euismod vestibulum.

    
Nullam rutrum blandit eleifend. Aenean a varius diam.
    Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
is written like this

    _h1 Page Title

    _p Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum.

    _p Nullam rutrum blandit eleifend. Aenean a varius diam.  Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
And you can also compute 3x4 writing {x 3 4} or compute the factorial of 100, compute a Fast Fourier Transform, draw complex graphics, ... it's a true programming language with a coherent syntax, unlike Markdown.

Re: We should have Markdown-rendered websites

#322

Post by martyalain »

bccdee wrote: post #70

Markdown 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…

It's said that the father of LISP, John McCarthy, lamented the W3C's choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. » The {lambda way} project could be an answer, small and simple: http://lambdaway.free.fr/lambdawalks/

In lambdatalk such a HTML code

    Page Title

    
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    Ut ac lorem ut massa euismod vestibulum.

    
Nullam rutrum blandit eleifend. Aenean a varius diam.
    Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
is written like this

    _h1 Page Title

    _p Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut ac lorem ut massa euismod vestibulum.

    _p Nullam rutrum blandit eleifend. Aenean a varius diam.  Morbi sodales velit nunc, vel vestibulum lorem tempus sodales.
And you can also compute 3x4 writing {x 3 4} or compute the factorial of 100, compute a Fast Fourier Transform, draw complex graphics, ... it's a true programming language with a coherent syntax, unlike Markdown.

Re: We should have Markdown-rendered websites

#323

Post by martyalain »

tannhaeuser wrote: post #239
nerdponx wrote: post #237

Earlier quoted context omitted.

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?

> 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…

It's said that the father of LISP, John McCarthy, lamented the W3C's choice of SGML as the basis for HTML : « An environment where the markup, styling and scripting is all s-expression based would be nice. »

The {lambda way} project could be an answer, small and simple: http://lambdaway.free.fr/lambdawalks/

Re: We should have Markdown-rendered websites

#324

Post by toastal »

bccdee wrote: post #320
inopinatus wrote: post #287

Earlier 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…

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 markdow…

That would be the worst world. I love that we have semantic and accessible elements and Markdown is pretty bad in both those categories.

Re: We should have Markdown-rendered websites

#325

Post by toastal »

falcolas wrote: post #29
falcolas wrote: post #5

OK. Which flavor of markdown should we get every browser manufacturer to use?

My personal preference would be GitHub flavored markdown, since as a coder it includes a lot of very useful non-standard markups. The compromises it makes on the non-deterministic markup elements are acceptable as well.

Like how they're introducing admonitions syntax by overloading the blockquote sigil that makes it difficult or impossible to nest, has a heavy English bias, and doesn't even transform the underlying element making the use of blockquote unsemantic. They also just skipped the CommonMark RFC and other implementations throwing their weight into the ring with no regard for prior art. I also don't think a corporation, Microsoft, needs to be in charge of the spec either. No thank you.

Re: We should have Markdown-rendered websites

#327

Post by toastal »

euroderf wrote: post #135
falcolas wrote: post #5

OK. Which flavor of markdown should we get every browser manufacturer to use?

Many Markdown dialects are adopting YAML metadata, so why not start a file with (for example) --- Dialect: GFM ---

All dialects of Org Mode, AsciiDoc, reStructuredText, HTML files, ODF files, EXIF data on images support metadata in file--it's the norm. The fact that Markdown's spec doesn't support metadata by default and most "dialects" don't this ad hoc syntax (YAML of all broken things) shows that Markdown not suitable for most kinds of documents.

Re: We should have Markdown-rendered websites

#329

Post by divan »

hoppyhoppy2 wrote: post #293
divan wrote: post #222

Earlier quoted context omitted.

> markdown is designed to transform to HTML Is it though?

>Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML). From 2004 https://daringfireball.net/projects/markdown/

> Thus, “Markdown” is two things: (1) a plain text formatting syntax; and (2) a software tool, written in Perl, that converts the plain text formatting to HTML.

I believe nowadays most people refer to (1) instead of Perl tool, when talking about Markdown.

Personally I use Markdown *a lot* for Flutter apps, where text is rendered natively. Also use it for legal documents, which are converted to PDF via pandoc. Another project I have is a console app that also shows formatted help text written in Markdown. In all these cases there is no HTML whatsoever and no 'text-to-HTML conversion tool'. Yet it's all Markdown, so no need to reduce its applications to HTML, let alone claiming that it's designed "to transform to HTML".

Post reply on HN