Foolproof HTML

The article describes Markdown[1], basically. In my opinion, content should be written once and transformed to any format[2], including ConTeXt[3], docx, HTML, EPUB, or plain text. But here's a puzzler.

Every software developer defines and uses variables. If variables are so powerful, why do WYSIWYG word processors lack the ability to quickly and easily insert variable definitions?[4] In the screenshot, the left-hand side provides an editable variable definition hierarchy, the middle pane provides a Markdown editor, and the right-hand side provides a real-time HTML preview of the content with variables interpolated and substituted.

After variables, programming language integration--such as R[5]--comes naturally. Consider the following syntax (that could be hidden through a UI):

    `r#csv2md('data.csv',totals=TRUE)`

The function imports data from an external data source and converts it to Markdown. The HTML version can be styled, or piped through pandoc to create beautiful PDF output[6]. In the screenshot, the left-hand side shows the csv2md command (totals are calculated automatically for numeric columns), the middle pane shows an HTML preview (real-time), and the right-hand side shows a PDF produced from the same source document using pandoc and ConTeXt.

The CSV file could also be a JSON request over HTTP, or database query, meaning that the document is always up-to-date with the most recent data: a living document. This could be accomplished without having to change the source document, as well:

    `r#import(v$data$source,totals=TRUE)`

Here, v$data$source is a variable that defines a data source. In this case, the value might be 'data.csv', but could be 'protocol://host/app/api/json'. The variables themselves could be sourced from a YAML file, JSON data stream, or remote database.

This is what I've been working towards for the last several months.[7] There's more that this editor can do, but it's still in early beta stages, should anyone care to try it.

[1]: https://github.com/jgm/pandoc/issues/168

[2]: http://pandoc.org/

[3]: http://wiki.contextgarden.net/

[4]: https://raw.githubusercontent.com/DaveJarvis/scrivenvar/mast...

[5]: https://github.com/bedatadriven/renjin/

[6]: http://i.imgur.com/Qe6mTpx.png

[7]: https://github.com/DaveJarvis/scrivenvar

Very interesting! Thanks for the ref. I wrote about my own efforts along these lines, using Lisp lists is certainly a natural, logical starting point. There are a number of parallel systems in Scheme which I used in prior applications.

I fully agree sexpr syntax is both beautiful and efficient. The fly in the ointment is that doing anything substantial quickly becomes complex and requires dealing with a complex programming model to accomplish the task. That can be a daunting hurdle even for experienced users to surmount. It speaks to appeal of simplified interfaces, which may help but I'm pretty sure won't mitigate the problem altogether.

Of course every bit helps, having more tools can be a very good thing if we know how to apply the right tool for the task at hand.

I don't think this is all that helpful. If you use a moderately-decent text editor, it probably has a closing feature, and an autoindent feature.

If you're writing a new tag in emacs, you just need to write the opening tag, then press "C-c /", and it will close it for you. If you have a syntax error of this magnitude, the autoindenter will also help you realize. Just select the region (or the whole file) and press tab, see where the indentation stops making sense, and follow back to the opening tag by column.

There are heavy-handed approaches to this, but I find that default-configured emacs with these two tricks can reduce your error rate to effectively zero, without requiring you to learn a new tool just for [X][H]TML. I say "just" for HTML having spent about half of my working hours in HTML for two years full time. I think this is enough.

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.

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