- Why not keep {{}} for inclusion to be consistent and use <<>> for style?
I could go either way; the thing that tipped the scale for me was that using curlies for this will make the "math" extension difficult to use.
- I don't like keeping magic links (e.g. ISBN), just because they
show up out of nowhere (i.e. magically). Why not [[ISBN:1234...]]?
I'm not real fond of them either, but you might have a user mutiny on that one.
- I don't like superflous named arguments for links all that much as
it's increasing the complexity (more than one way to do things, it will confuse people, more stuff to translate, rememer, etc)
I just wanted the argument syntax to be the same for extensions, links, and such.
- Don't like multi line inclusions, but if you have to do it, I would use this:
<<begin applet applet=conway_life.class size=400x300 pattern=none
That's a little harder to parse, and doesn't seem any simpler to me (although it's a bit easier to type).
- In the raw example, where does <<raw end, because math is getting
interpreted?
Like all extensions, it ends at >>.
- I *really* don't like styles using, and especially using {{}} for
them. I know many people, including myself, who are used to the current syntax will bug out at that. Why give one more choice, instead of using the the other markup? If people want to use markup, fine, let them use full HTML (for MediaWiki, I'd be OK with not enabling HTML for Wikimedia). I don't want to open up an artile for editing and have to figure out what {{u}}, {{i}}, etc do, especially when they're nested. One set of markup should be enough, for anything else use HTML.
Styles aren't just about a new way to do boldface and such (it just happens to do that as well--can't be avoided). It's about finally getting rid of all HTML markup, and making it possible for users to edit the text of an article without having to muck with all the style data that power users have put in; it also enables shared styles for multiple pages.
The big example is something like the taxonomy table on the right side of species articles. It's nothing but template inclusions, and those templates are mostly markup. Even I would have a hard time adding a line of text somewhere in that box if I thought it was needed.
With the new syntax, the table could be in a template or in the text itself, with a style tag pointing to a sheet that does most of the cosmetic stuff--and which is shared by all similar articles, but the wikitext itself would be mostly content easier to edit.
The separation of content and style is a BIG win-win, and has to happen in one form or another. I've settled on using CSS as is because typically the folks who want fancy styles are the power users who are used to CSS anyway.
- Again, for the styles I don't like one set to begin the markup and
one to end it. I know it makes the syntax easier probably, but having to hunt down to which style an end tag belongs would be a pain in long articles.
They must be nested properly, but you can always use {{end bigtable}} if you need to clarify, because comments are accepted there. Most of them don't need to be terminated explicity anyway--that was an ease-of-use thing I really wanted.
- I really like the ////. ****, $$$$, ____, ^^^^, but I don't like
terminating them by spaces, require begin and end for consistency.
It's only superscript and subscript I do that way, and I could be convinced to eliminate that shortcut.
- Not sure how I feel about the character entities not being
interpreted. I always hate seeing them as it makes editing more difficult, but I don't know if they are needed in some cases. I personally almost never use them. Some people may have trouble finding the character to copy and paste when the keyboard doesn't support it.
What I mean is that they aren't used for markup--they are just passed on as plain text, so that, for example, << does not cause the parser to start an extension, it just puts two less-than signs into the text.
Thanks for the feedback!