| > <script /> is invalid. <br /> is valid. <br></br> is invalid. OK, then the best way to handle that is to let the HTML-renderer know that different tags need to be rendered differently if they're empty. Are there any cases where you would ever want to distinguish between the various kinds of empty tags? ((:tag/ :attr "value")) => <tag attr="value" />
((:tag :attr "value") "..." (:/tag)) => <tag attr="value">...</tag>
No, that's not what you want. Let's start with this general form:((:tag attr value ...) content ...) => <tag attr=value ...> content ... </tag> Let's assume we have no attributes so I don't have to keep typing those. Then we have: ((:tag) content ...) => <tag> content ... </tag> In this case (no attributes) we can unambiguously remove the parens around (:tag) and get: (:tag content ...) => <tag> content ... </tag> Now if we have no content we get: (:tag) => <tag></tag> All this is still completely regular, no special cases. But now if we write (:br) we get <br></br> which is not what we want. So we need to tell the renderer that some empty tags get rendered one way, and other empty tags get rendered another way. CL-WHO does this. Notice that we have not actually typed any / characters. This is important. The role played by / in HTML is played by the close-paren in sexpr syntax. If we re-introduce the / into our new syntax we will have a hopeless mess. > So a leading `nil' would be treated as a special case That is exactly right. If (and this is a big if) we want to be able to write something equivalent to both <tag/> and <tag></tag> in the same document we have to be able to distinguish between those two things in the markup somehow. I just looked this up and the distinction that HTML makes between <tag /> and <tag></tag> is that the former content is EMPTY while the latter content is "" (i.e. the empty string). So really the Right Thing would be: (:tag) => <tag /> (:tag "") => <tag></tag> That will work, but now we have to remember to add an empty string in some situations, e.g.: ((:script :src "...") "") Personally I would find this annoying, so I would choose to go with the lookup table. |