Of course you could probably write an s-expression serialization of XML as a macro, and then you could start writing things like:
(html
(head (title "My page")
(script :type "text/javascript" :src "/static/page.js"))
(body (p "Stuff")))
Actually for a while I had a JS tool which I was using called "build.js" which would just build DOM components like this. (It was therefore JSON-serializable too, but I never really had an occasion to use that.)
There is something nice about HTML which is a bit lost here: HTML (and LaTeX for that matter) allow unquoted text, with fewer escape characters. They are markup languages, which s-expressions crucially lack. (On the other hand, XML & family lack the ability of Lisps to make the first token anything other than a symbol.) There was briefly a plot called NML / Enamel and some others -- DTML and TML I believe -- which would instead write:
>>
>>
This is actually an emulation of a C-type syntax with a Lisp-type semantics: the idea is that you have in some sense two syntactically different channels into your expressions, one which comes before the pipe character | and one that comes after. The stuff that comes after is allowed to be marked-up text; the stuff that comes before is some sort of node list, and perhaps has certain conventions (one could imagine instead using a Clojure-style `:type "text/javascript"`, which would limit you to what XML attributes can do -- short text only, symbolic keywords).
That is, one could hypothetically rewrite this in some C-ish syntax which would look like:
html {
head { title { My page }
script(type {text/javascript} src {/static/page.js}) {}}
body { p { Stuff }}}
and again, if you wanted to limit yourself to XML, the parens above could then say instead `type: "text/javascript" src: "/static/page.js"` but it doesn't have to be that way.
Some crazy ideas for anyone building a new language to think about.