HTML form elements

[tshort]

I really like where Active Markdown is heading. The main thing that would make it more immediately useful to me is standard data entry options, including:

• checkboxes
• radio buttons
• textareas
• inputs
• select boxes
• select boxes with fill-in inputs
• buttons

The more that Active Markdown pages look like regular web pages, the better.

Here's one extension for form elements for Showdown. I used that in an experimental worksheet-like interface to the Julia language (see here). You probably want to stick with your [name]{something: } notation.

I dislike the Tangle-style inputs currently in Active Markdown. It's not obvious for first-timers that those are even inputs. Even once you realize how they work, they seem clunky.

[tshort]

For some additional ideas on how to incorporate additional form elements, you might want to check out mdpad, a system not unlike Active Markdown. For form elements, I've been experimenting with YAML syntax along with either jQuery.dForm or jsonform. Also, in another issue, you mentioned doing a Showdown extension. I tried that, and it wasn't too bad.

Here are some differences between Active Markdown and mdpad:

• mdpad isn't reactive; it just recalculates everything on the page from top to bottom.
• mdpad supports form elements and YAML data input.
• mdpad pages don't need to be compiled.
• mdpad is JavaScript not CoffeeScript.

[alecperkins]

I’ve thought a bit about how to do more traditional form elements. The sticking point is preserving simplicity in the notation. It’s actually possible to add regular form elements now, just by including the HTML in the document, since Showdown passes it through (which Active Markdown itself relies on). There isn’t any glue, though, so it’s up to the document author to retrieve the values from the forms.

Perhaps the best approach is a middle ground, with some built-in binding and reading of regular form elements. With something like <input name="someforminput">, the CoffeeScript could then automatically have the value available at @someforminput, the way the other elements work. This way, it assists lower-level power usage, while still keeping the notation simple. Also it could just include or adapt wmd, which has a really nice notation for forms, and then provide the glue. The drawback either way is that there is now potential confusion between form elements and control elements, but that is probably acceptable given the power. The wmd notation is generally different enough.