This is where I will store further ideas about Avocado. Some tags stuff things in attributes which might more naturally go in the content. An example is meta tags. For these, how about this: meta. Some further ideas about Avocado. The @content bit means "this is an empty tag in HTML: please stuff the things that would normally be inside this into the content attribute." Naturally, you don't get to use span-level formatting in the content in this case. So this would render as: ``` ```` At the header of a document, and when consecutive headings appear together, you often want a tag in the Avocado source to only take up one line, instead of that entire 'paragraph' to the next double line-break, as the default block syntax does. I could look for something that looks like a new block tag after each newline, but that's likely to break on the last word of sentences. Here's my solution: a single dot after a tag name means "run on to the end of the block"; double dot means "only this line is the content of the tag." This may be counter-intuitive. (In particular, it's more-or-less the exact opposite of what Textile, the language I got the block syntax from, does.) But it's no worse than my preferred SmartyPants mode of -- for em-dashes and --- for en-dashes, because that reflects the commonality of each: em dash should naturally be easier to type because it occurs more frequently in writing. Example: meta<@charset>.. utf-8 link.. /index.css script.. title. This is my amazing blog entry, with a title that spans multiple lines. Entities: hmmm. hmmm. I've thought of just importing the usual string syntax, \u2014 etc., but that kind of conflicts with using \ to escape tags. Or does it? Hmm. What about named entities, anyway? I'd like to support all the ones HTML does, and more. Perhaps \e{hearts} for named entities, or similar ... Huh, in fact, using HTML entity syntax doesn't conflict with my desire to make it easy to talk about HTML. Just use \& to talk about the entity for U+0026, and & to actually include it. Compared to &, that's much easier ... but still not consistent with "HTML syntax and Avocado syntax is disjoint". We need a mode to generate full documents from Avocado source, instead of just snippets. We're kind of there now, since you don't need and all that crap, but some people will want it. They could do it manually: html -> head -> title. Hello world, this is an example of a full document in the Avocado language body -> Here's a paragraph. Another paragraph. This could effectively be a whole document, as if it was at root level in this file. But you shouldn't have to do all that, if you want that stuff in your output. You also still need a DOCTYPE if your stylesheet is anything more than trivial, and you shouldn't have to set the charset yourself. (Avocado should just assume UTF-8 and allow you to override it if it's wrong.) Idea: two 'document modes': lightweight document, which produces simple markup, just a DOCTYPE and the charset, and full document, which includes , , , etc. In Avocado-1 I talked about a link syntax for internal links in wikis. A transclusion syntax would be cool, too ... {thing-to-transclude}, perhaps? Or maybe double up: {{thing-to-transclude}} Formally defining Avocado: I would like to formally define this language by defining the algorithm with which it should be parsed and transformed, like HTML5, rather than with a formal syntax like BNF.