Foolproof HTML

S-expressions are a data structure, different from the DOM, but S-expression syntax is a syntax. Normally S-expression syntax is parsed to produce S-expressions, but can also be parsed to produce other things. S-expression syntax can be parsed to produce a DOM. The easiest way to do this is to parse S-expression syntax ino S-expressions, render those S-expressions into HTML code, and then use an off-the-shelf HTML parser to parse the HTML. But you could also write a parser that parsed S-expression syntax directly into a DOM if you wanted to. You could also write a transformation program that compiled S-expressions directly into a DOM without going through the intermediate HTML.

The answer to your question of how to add an attribute to an implied element is that it is not possible to do that in HTML. It is only possible to add an attribute to an implicit element of the DOM produced by parsing an HTML document that omits that element (because at that point the element is no longer implicit). The exact same thing is possible using S-expressions. For example, here's how you write tables in my library:

(:table (header header ...) (data data ...) (data data ...))

This string of characters is parsed by the Lisp reader to produce an S-expression that has a one-to-one correspondence with the string you see above. But then there is an extra processing step that transforms that into a different S-expression whose printed representation is:

(:table (:tr (:th header) (:th header) ...) (:tr (:td data) (:td data) ...) ...)

At that point you can manipulate that S-expression in the same way that you manipulate the DOM (because they are both just data structures). Once you're done, you convert the S-expression to a DOM. At the moment that is done by rendering to HTML, but as I noted above that is just an implementational convenience to take advantage of the fact that HTML->DOM parsers are available off the shelf. You don't have to do it that way (and indeed the world would be a better place if it were not done that way).

All of this is trivial when dealing with S-expressions precisely because of the strict 1-to-1 correspondence between data structure and visual representation that does not exist in SGML-derived languages. That is why writing code for SGML-derived languages using S-expression syntax is so advantageous. (Actually, this is true for any language, not just SGML-derived languages. It's just a little more obvious for SGML-derived languages because SGML syntax already kinda sorta looks like a data structure representation so it's a little easier to grasp what is going on.)

Emmet is a great plugin that has tag matching and all kinds of navigation/editing shortcuts too. Like those emacs shortcuts, it does reduce error rates and speed up editing signifigantly, at least for me, but I'm more interested in exactly a heavy handed approach. I'd like an app/plugin/whatever that makes it impossible to make many types of mistakes, even if it restricts what I can do.

I code html every day (and I do love it), but I'm a terrible and lazy typist. I make typos and mistakes constantly, so I'll take all the help I can get. So I'm trying to make something that will solve my specific woes in html/css development and I'm hoping someone else finds it useful too.

> > If you have a good strategy for validating your template files, I'd love to hear it!

> Use S-expression syntax instead of SGML syntax [emphasis added]

Note the use of the word syntax. I'm talking about syntax. All of your responses have been at best irrelevant or at worst wrong because you either don't understand what syntax is, or you chose to ignore it. It's damned annoying, particularly when you start making demonstrably false claims like, "it's nowhere close to the power of SGML as a text format" (https://news.ycombinator.com/item?id=13569991).

Actually, I spent 1.5 years building an editor in this style (see link in my original post here) while working at a grocery store :)

Unfortunately, while I can see now that I should have first been super focused on validating the concept—I instead just kind of ran with it, assuming it was going to work, and built this massive, probably over-engineered, framework for generating editors for given grammars (with my starting point being: not even knowing what a grammar was, thinking I'd have to invent some kind of 'linguistic constraint description' format ;) ).

As it stands the editing portion works well enough for a demo, but the program never reached the point where I could write code with it, so a lot of these questions are still un answered for me. I think doing the paper prototype on these edit actions would be a good pre-coding validation step.

I did check out Anvil briefly. My two second, potentially incorrect summary would be VB for web apps. Is that close? Are you guys doing anything special for working with text itself?