On Sat, 2005-06-11 at 15:24 +0000, Ævar Arnfjörð Bjarmason wrote:
...you specifically disallow level one (=) headings which is insufficient, remember that not everything is an article where you get the first heading generated for you, special pages and other extensions might want to make their own first heading...
The syntax only says that you can have five levels; the highest of these is "==" (I don't want to have any single-character markup). There's nothing that says you can't make "==" headings look identical to (or even bigger than) H1s with styles.
I might even have a piece of metadata that says "move all headings on this page up one level".
- I like that one newline no longer terminates a list, however this
syntax will not be complete without allowing <p> since there will be no way to make paragraphs within a list item.
Paragraphs inside list items are not part of my content model, though perhaps they should be. You can achieve line breaks with \. I could be convinced either way, but if we want paragraphs inside list items, we'll have to come up with a syntax for it--perhaps \ on a line by itself could mean that.
- I don't like your definition lists because they're exactly the same
as the current ones and encourage using ":" for indenting, if you're going to indent something like
: Indent
<dl><dd>indent</dd></dl> is not the best way to render it, it may be legal XHTML to omit <dt> and take advantage of the fact that <dd> is indented by what would be approximately a tab in most (if not all) browsers, but it's certainly far from the way it should be done™.
There's nothing that says the parser can't treat ":"s without a ";" differently, and render them as paragraphs with an intend style instead of actual DLs. This is a rare concession to current use; I don't like it much either, but I think most people generally do.
- Using [[]] for external links means that in practice we won't be
able to have articles/pages with titles like "http://foo" although [htp:/fo] are all legal characters in page names (not really that big a disatvangage, and I like it better than [])
That's another coming spec--I assure you, it will be possible to have article titles with absolutely any combination of Unicode characters, although some may be a little tricky to work with.
- Just so we're clear you want [[stuff|like|this]] to generate
(approximately) <a href="stuff" title="this">like</a>? I don't really see the point, but I suppose it doesn't hurt since it extends the previous syntax gracefully.
And it keeps the syntax consistent with extensions and such.
I like where you're going with the image syntax but I don't like it *quite* enough to really like it, I'll explain: What I don't like about our current image syntax is that due to the way it's all cluttered up it's hard to extend, yours is better but IMO not quite good enough, for example I'd like to have (comments begin with #):
<<begin image>> file=pl_bulet.png style=frame # instead of just "frame", no "magic words", just attributes=values width=5em caption=Logo <<end>>
I like the idea of comments on variable lines.
Note however that since = has a special meaning caption would always have to come last if you wanted to write something like.
Just use "caption=You can...with caption&x3D;foo"
- I like the whole <<>> thing, but I'm not sure about the added
complexities of using it for comments too, how about <<comment like this>> (just an extension named comment that ignores its input) rather than << like this>> (i.e. to make << *.*?>> comments), or just the old
<!-- -->
I considered <<! This is a comment>> as well, but why add the character just to make it look more like HTML? The "noname" extension seemed like a reasonably understandable thing to do.
- I like // ** ^^ $$ and __, note however that since * is used for
both lists and bold the parser would have to break a case like..
I thought about that, and I don't think it's a big problem, because the only ambiguity arises when we're already inside a list (a line beginning with ** outside a list is clearly boldface, because you can't start nesting at level two). A line beginning with "**" inside a list is either a nested list item, or a boldface word at the start of an input line folded into the list item above. The ways to resolve that include just always making it mean a new list item and taking care not to put bold words there (they can always be avoided), or counting the **s on the line and making it a list item if there's an odd number (a bit magical, but I'm not terribly worried about rare cases like that).