3 ms·
Hm... I think this post is trying to solve a different problem. Markdown solves the problem of having content (paragraphs, lists) syntax free. This post: > W
by skierscott 10y ago
Hm... I think this post is trying to solve a different problem.
Markdown solves the problem of having content (paragraphs, lists) syntax free.
This post:
> What if you had to write a language where you can make mistakes, but there are no errors? Where your parser just silently accepts anything you give it. Where you'll have to carefully compare your intentions to the parsed output to figure out what went wrong.
> Do you write HTML?
> What I just described was how browsers handle HTML. They will happily accept anything you give them and try their best to make sense of it. They could swap out element places, change attributes, or do whatever if there's a typo in your code.
Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content.
- thangalin 10y ago> Looks like they're trying to make make an easy-to-write HTML for all HTML, not just content. Yes. I know it's a long thread, but pandoc issue 168 and the proposed "foolproof" syntax are, in essence, addressing the same issue. They both strive to shroud the nuances of HTML syntax in simpler clothing. Computationally, there's insignificant difference between this (proposed syntax): ; --- div {.foo} ; Ipsum dolor sit amet And this (foolproof syntax): div class:foo Ipsum dolor sit amet What Markdown doesn't have, as you allude to, are data bindings necessary to drive an interactive experience. Although, with a little ingenuity, a processor could provide data binding with a Markdown-compatible syntax, such as: ; --- input {.email} ; Email ; --- shuttle {.from} ; Available List ; --- shuttle {.to} ; Selected List From a high enough perch, they both look the same.
- sakamies 10y agoWestoncb said it quite elegantly: "I think the core idea involved is a shift away from using text as a model for representing programs; instead, interact with more abstract representations of code, and render those abstractions as text. This allows your editor to have better understanding of the language you're using, so syntax becomes a property of a language's visualization rather than something totally central to it (and now you don't have to memorize it!)." Foolproof HTML of course tries to do that only for HTML, but I do hope I can expand it to CSS, JSON and maybe generalize it later on. So I'm not advocating for any specific syntax, but rather a way to edit html so you don't need to care about the syntax. The HTML syntax would still be there in the .html (or .erb, .php or whatever your template language is) the same as it has always been, but you could visualize it in a way that's most comfortable to you and edit it as a structure, so it would be impossible to produce syntax errors. This could end up being a text editor plugin or a stand alone app, some sort of library or kind of anything, but I'm prototyping interactions and ideas as a standalone web app because that's what I'm good at.