Talk:Wikimark2

I have created this proposal and I think it has merit. However I am unsure of how to get feedback, where to post it, or whether I've even put it in the right place. I assume Meta is nice enough to allow the proposal in the main namespace, like Wikitax. I also think the proposal is enough worth considering to merit its own page, to coordinate its growth.

If there is a place to announce proposals like this, someone please do it for me. --Alfakim 22:26, 30 May 2006 (UTC)

Comments

There are lots of good things here, some of which would go well with existing Wiki markup. Things I like:

• -- = emdash (could be incorporated immediately)
• Automatic conversion of &nnn; notation. (could be incorporated immediately)
• Consistency of "in" links and "out" links. The [[Category:]] notation is one of the real banes of wikimarkup.

Things I don't like:

• *bold* notation. Looks like a recipe for trouble. You'd need nowiki tags to notate a dos file mask: *.* - doesn't strike me as intuitive. IMHO, more "intuitive" is to make every syntax element a doubled character - **bold**, //italic// etc. That would be a hell of a lot better than our apostrophes - **//Gone with the Wind//** instead of '''''Gone with the Wind''''' was a film that...
• Line breaking depending on ending of previous line is not intuitive to me - I would never, ever guess that that's what was going on.

Other comments:

• <<, >> for nowiki syntax sounds good. Presumably <<<<>> would produce a literal <<, while >> would produce a literal >>
• [[page|alt]] notation isn't bad enough to worry about - you catch on pretty quickly when learning wikimarkup, even if the arguments did strike me as "backwards" for a long time. And the "pipe tricks" are so handy that losing them would be a shame.
• Don't understand the section about inheritance. Stevage 07:56, 31 May 2006 (UTC)

How are interwiki language links handled? Is a link to the French version of a page an "out" link or an "in" link? Stevage 07:44, 31 May 2006 (UTC)

Interwiki isn't part of the article text, so it's an element added to the raw content. Hence an "in" link. Updated above. --Alfakim 13:46, 31 May 2006 (UTC)

Thanks for reading, I have some replies.

• You've made a very, very good suggestion with the doubled syntax elements. I shall change all tags now to doubles, thus making this language even more consistent.
• The line-breaking isn't meant to be intuitive; rather, it solves problems without the user realising, i.e. it's an automatic parsing error-fixer. A lot of people post on MediaWiki with stuff like:

here's my poem:

in the day,
flowers of may;
hay oh hay.
Yay!

Did you like it?

The new syntax would thus format this correctly for them, so long as they've punctuated correctly. manual line-breaks will be done differently.

• Inheritance meant we inherit those parts of the old wikitext language.
• I've defined a function for <<>> now; tell me whether you think the use of it is worth trumping "<< nowiki text >>".
• I am still considering pipe syntax. Pipes are currently used for tables, which clashes with their use for parameters. --Alfakim 15:29, 31 May 2006 (UTC)

Automatic dash conversion was included in MediaWiki 1.5 alpha 1 about a year ago, but it was disabled here. The Goings-on announcement about that feature didn't get archived, but the Vietnamese translation of it is still there. Perhaps there's some explanation at the mailing list as to why it didn't get enabled on the MediaWiki wikis. – Minh Nguyễn (talk, contribs) 01:23, 1 June 2006 (UTC)

Yes I remember that, but I never figured out why they disabled it. I cannot see a problem that could arise from it. --Alfakim 14:47, 1 June 2006 (UTC)

Decrement operators in programming languages? æle ✆ 18:39, 6 June 2006 (UTC)

Mediazilla:1485 discusses the issue. Apparently there wasn't necessarily an inherent problem, other than that people couldn't agree on what should translate to what, but the implementation screwed up with hyphens in markup. —Simetrical (talk • contribs) 22:44, 6 June 2006 (UTC)

I like the "in" and the "out" links very much. I could get used to the <<>> for wiki functions. I think it's a bad idea, however, to use the same symbol for the unordered list and for bold markup. It also seems counterintuitive to parse from the right. I don't like how the beginning and ending of tables is defined by a blank line. It seems like this would be a headache when working coordinating with templates. — It's dot com 03:10, 3 June 2006 (UTC)

Agreed. Suggestions? As for the tables, no, it would work just as easily (hardly) as we currently have it for tables in templates. As for the bold markup and the list markup, both are intuitive so i dont want to really get rid of that. in case you think it would cause parsing errors, it won't. parse direction simply avoids errors; so long as tags are closed properly (defined as strict) it'll be the same either way. if they ARENT closed properly, parsing from the right merely avoids errors. --Alfakim 12:53, 3 June 2006 (UTC)

So...

Who's going to make the parser? :o) (never underestimate the hideous complexity of Parser.php) (although maybe this time we can get proper tag balancing and some unit tests) — Ambush Commander^(Talk) 22:52, 31 May 2006 (UTC)

No idea who would make the parser. I understand PHP and how it all works - and I'm considering that as I write this page - but I'm no way good enough to write it myself. This page is currently just here for discussion and to design the language. If it gets any kind of support, we can think about writing the parser THEN. --Alfakim 14:45, 1 June 2006 (UTC)

infered line breaks

This change does not add value and will in fact break too often, notably when a break is infered from a line ending with comma. Why infering breaks? it's not needed. Let's keep the empty line as the only explicit paragraph break. otherwise we'll get plenty of articles edited with external editors that force line breaks at any place in the middle of a paragraph.

Why not keeping the convention already used in email where line length is also constrained? Let's not introduce a kludge with a future requested backslash at end of lines that must not break!

---

Also why changing both bold and italic (currently marked with single quotes)? It seems that introducing ** as the bold mark will now conflict with the * used in bulleted lists! Hmm... what about ++, %%, $$, !!, ??

86.221.102.98 15:35, 4 June 2006 (UTC)

Good points. The inferred linebreaks MIGHT be a problem, so perhaps you are right that they should be removed. (Support, anyone?). The ** and // italics and bold tags are used as intuitive. Lots of programs (eg Google Talk, Word) already use ** to mark bold. An alternative might be:

+italics+

++bold++

+++bold italics+++

Discuss! --Alfakim 14:46, 7 June 2006 (UTC)

What about migration? other syntaxes

It seems that such change will have a huge impact on migrations.

So may be it could be implemented by not changing the existing articles, but only marking those that have been edited with the new syntax (an attribute in the database?), and by offering a way for users to edit it in the previous syntax for some time (notably for those users that are running maintenance scripts and various external tools and bots performing typographical corrections).

Be aware that this will take time for users to make the correct shift to the new syntax. And converting the whole database will take too much time and will probably introduce many errors, because there may already exist lots of articles where the new reserved sequences are already used, and that will require manual conversion to make the correct changes for the newer syntax.

Why not using the MIME type attribute of articles and medias to store the syntax type used when editing the articles? And why not finally adopting a XML-only syntax for articles, that will be simpler for the server to parse (notably for templates)? The wiki syntax may be generated from the XML source for editing, and the interpreted version will be stored in XML format.

Editing in XML format will be possible but saving XML will be accepted only if it respects the strict XML conformance. A good XML based syntax to support would be DocBook...

Finally, it should be possible to edit an article in ASCII only (for program sources or texts that remain to wikify), without having to worry about syntax on first edit. When saving, the equivalent wiki format will be generated, and the user will be able to add enrichments like bold, titles, joining paragraphs, etc. The first viewed version, if not edited will be saved as if it was a <pre> section, i.e. with a leading space on each line, and with all special characters correctly quoted to avoid special semantics.

So for me it seems more important to keep the syntax as it is now, but to accept alternative syntaxes for new articles, and to offer tools to make the conversion when necessary. All those alternative syntaxes should be kept in the database as is, without requiring any conversion.

There are for example competing syntaxes for wikis using other softwares, that would really like to switch to MediaWiki, if it could support their existing syntax. Or may be they are already candidates to close their site soon (with interesting results that should be kept somewhere when the site will close soon), and find a place to publish their content somewhere else, such as a MediaWiki server, where it could be used as a test, for later integration of articles in Wikipedia, or Wikibooks, or Wikisource.

The conversion of syntax from various public sources is troublesome, and if MediaWiki could support several syntaxes, it would ease the migration, without having to edit the imported articles.

86.221.102.98 16:16, 4 June 2006 (UTC)

You make many good points, although i'm not a whizz on the xml and mime stuff. Anyway:

1. Converting to new syntax. I've tried to design this so there won't be a problem. This new syntax just rearranges the old one. There may be errors where new syntax has been used accidentally in the old, but i think this would be easily corrected.
2. Option for old syntax. Not sure. It's a good idea to wean people into the new one, but i hope the new one is enough like the old one (and makes enough sense) for the crossover to be easy enough.

--Alfakim 14:50, 7 June 2006 (UTC)

Other ideas: linking

Another thing to consider is to allow the autodetection of possible links in articles when saving it: words are parsed, and if they match an article name (not a redirect), the first occurence in the article will be marked with the detected links.

We have articles for a, of, the, and and. It could get confusing. æle ✆ 18:41, 6 June 2006 (UTC)

A bit dodgy. I like to define links myself. --Alfakim 14:51, 7 June 2006 (UTC)

Other idea: a new namespace for synonyms

To sovle the problem of the detection of ambiguous article names that link to multiple pages, and that should better not be used as the target of links, why not having a synonym namespace (for example "=:"). The content of pages in this namespace would bne what is currently found in synonym pages, or diambiguation pages. In pages of this disambiguation namespace, the links to the articles would also start with a short prefix like [[:=:Article name]], while other links used in that page for explaining the role would be normal links.

This would allow easy cross reference of all articles linked from the same disambiguation page of the special namespace. Conflicting articles would be easier to link with it, and it would be easier for the various articles related to the same synonym to be found.

Some examples:

The small abbreviation and codes are often creating synonyms; these synonyms must be explained with an extra reference to the standard in which the code is referenced, but the code itself will point to a unambiguous article like a country name, a language name, an actual word of the language, a small article about a trademark or company or product name, or the complete name of a timezone...

For this we need a disambiguation page named [[=:IO]] for the ambiguous code IO. When using the search functiuon in Wikipedia, it will first look into this namespace before looking into the article namespace. When someones types "IO" he will then see the disambiguation page [[=:IO]] where he will find the various meaning of this as a [[ISO 3166]] code pointing to [[=:British Indian Ocean Territory]], or as meaning [[=:Input/output]] in [[computing]] technology.

Sounds a bit too complicated and unintuitive. Also, namespaces aren't controlled by the syntax. Namespaces which function specially are even MORE not controlled by the wikitext syntax. The change you describe above is really not related to a new wikitext, and should probably be discussed as a seperate proposal. It's interesting but i see that it might have some problems. --Alfakim 14:52, 7 June 2006 (UTC)

This is great but could be more forward thinking

I love this markup as a person who doesn't even know html (although I have been forced to pick up a little). I think this addresses most of the usabilty concerns of the curent markup. However it addresses none of the concerns that are currently unaddressed by wikimarkup. Wikimarkup is actually rather limited. Most wikipedia editors probably do not realize this as WP has adopted a publishing style that is within those limitations. This is not good enough for other applications. WP articles have disregard alot of formatting options to focus on content. Even at other projects this can swallowed since formatting is usually of minor importance. However the flaws become obvious when you start working with poetry. Formatting cannot be ignored. I do not understand the infered line breaking section, but I think it is not enough for poems. We need a way to force line breaks, especially if html is not allowed. Also we currently rely on a template to make proper indentations. The complex reason we cannot use wikimarkup are found here, the solution discussed (editing the stylesheet) was not implemented. The above template was created afterward. Centering text is another issue. Even relatively centered text would be agreat improvement. Text sizing also. I am sure there are other things as well that I cannot think of right now. Something that would help make index pages, although we can always use tables if nothing else. But open up some older books especially and look at variety of formatting that was used not so long ago. Think about other applications as well, I am sure Wikisource is not the project that feels hampered.--BirgitteSB 02:40, 5 June 2006 (UTC)

Every single thing you mention can be done with HTML, specifically via insertion of appropriate CSS style traits in divs. Quite simply, the functionality that you want is so complex that it would be insane to make a completely new markup language to cover it all.

1. Force line break. <br />.
   This follows a forced line break. (br stands for "break".)
2. Indentation. <div style="text-indent: length;"<text</nowiki>. length can be in: em (width of a lowercase m in the font), ex (height of a lowercase x in the font), px (pixels), or—in general less usefully—in, cm, mm, pt, pc (inch, centimeter, millimeter, point, pica). (The latter measurements are typically converted to pixels for browsers, which don't know how big your monitor is, but may be interpreted literally by printers.) For instance:
   This is indented 1in with respect to the containing list element.
   This is indented 2.5em.
   See [1]. Editing the stylesheet could be useful, but is certainly not necessary: the relevant style attributes can be included directly inline, perhaps by a template if standardization is desired.
3. Centering. <center>text</center> works. CSS aficionados prefer the longer and clumsier <div style="text-align: center;">text</div>. Either one will typically result in a linebreak; if this must be avoided, there may be a way around it using a table or CSS boxes.This is HTML-centered.
   This is CSS-centered.
   I'm not sure what you're contrasting with "relatively-centered". I believe CSS can center with respect to things other than the containing element, but I have to know exactly what you want.
4. Text-sizing. <span style="font-size: size;">. Possibilities for size are at the W3C site. This is "larger". This is "x-small". This is "16pt".

When it comes down to it: if there's formatting you want that HTML and CSS can't do, there's no way to do it, because the page (like all Web pages) is written in HTML and CSS. I don't think it would be useful to try to rewrite such complex languages, because you aren't going to be able to simplify them much but you will force everyone to relearn them.

(I'm not watching this page, so drop a note on my talk page if you want me to respond.) —Simetrical (talk • contribs) 22:30, 6 June 2006 (UTC)

Yes I realize these things can be done. Some of them rather easily others not. The proposal however does say: Text placed between <singular triangular brackets> is always HTML - alternatively, no HTML is allowed, full-stop. If HTML is not allowed these funtionalities will be lost. I do not see why some them can not be made more intuitive any case. Are they really more insane than tables?--BirgitteSB 23:51, 6 June 2006 (UTC)

Yes, they're more insane than tables. There are 115 properties in CSS. Disallowing HTML is doable, although perhaps unnecessary; disallowing CSS is ridiculous. —Simetrical (talk • contribs) 06:35, 7 June 2006 (UTC)

About forward thinking

You're discussing NEW functions to wikitext, whereas I have been focussing on just making existing functions easier and more intuitive. So you're right that this isn't very forward thinking. To introduce new functions might require higher approval (there's a reason, i suspect, why extra formatting isn't allowed - as you say, we're focussing on content). I think we should first focus on redesigning the current wikitext before expanding it. --Alfakim 14:57, 7 June 2006 (UTC)

I would say the reason some extra formatting has not been allowed is it was not of much importance to an enclyopeadia, but Wikimedia has grown beyond that now. I cannot think of a better time to think about new functions than when a re-vamp is underway. In any case after looking at the CSS examples above, I think we should forget about disallowing HTML. The CSS way of producing the basic HTML that I have actually managed to learn is not acceptable for a wiki where editors are not expected to be web designers.--BirgitteSB 16:49, 7 June 2006 (UTC)

Okay then. But i still think we should focus on the revamp first. Rewrite all the functions of the old wikimarkup into this newer, more consistent language, THEN add extra stuff. --Alfakim 20:16, 7 June 2006 (UTC)

{{Media:

Shouldn't it be [[Media:, because it's a link? æle ✆ 18:42, 6 June 2006 (UTC)

Well it's both. [[Media:]] would be a very simple link: Media:. Inline, and so on, linking to the page for that media file. {{Media:}} actually inserts a little box the way you see it in articles, the clicking of which directly opens the file. So in this latter sense it becomes an inserted element. --Alfakim 14:58, 7 June 2006 (UTC)

Support

I strongly support many ideas here, but beleive the dounting task of reeducating contributors might kill it from the start. Can we possibly have two editor screens, possibly even javascript based so that wiki markup gets converted from legacy to new form and back with a single click? --Yurik 14:35, 7 June 2006 (UTC)

Well, most of Wiki2 is the same as the original, there are just changes to make it more consistent. There would be a few months where there might be problems. So i think it could be achieved by allowing either syntax to be used for a while (a radio button somewhere), followed by a slow move into all-new. --Alfakim 15:00, 7 June 2006 (UTC)

No accidental interpretation

What I like in the current wiki markup is that there are few cases when it accidentally interprets something as markup when I intend it as text. This is why double square brackets are required to make a link: so that you can write single square brackets easily and don't have to escape them. On the other hand, double square brackets are not required for external links because it's not so frequent that you want to write a bracket and an url scheme like "[http://" when you don't mean a link.

Now this is what I don't like in your proposal. You recommend that angle brackets be always interpreted as html markup. That's wrong, because then you must escape every occurrence of angle brackets. The same applies to the backslash character.

I also don't like the rule that empty cells in a table implying row spanning, which you contradict to right in the example at column spanning. This exampls shows greatly that you do write such a thing accidentally, so it shouldn't be interpreted as markup. – B jonas 15:12, 7 June 2006 (UTC)

I didn't notice that contradiction and will fix it. As for your points, I can't see anywhere in an article that you really need double square brackets, that's exactly why they are used. This new syntax allows single square brackets as just text (which ARE used). So i'm not sure i see your point.

I believe B jonas was talking about <<angle brackets>> which are used in French as "quote marks" are used in English. Please corrrect me if I am wrong.--BirgitteSB 17:00, 7 June 2006 (UTC)

Good point, although I believe the French use a proper character, not a double triangle like that. Nevertheless, if they do, then such usage will be sufficiently rare to merit escaping; even if they are not escaped, all that will happen will be that the text cant use markup, which is usually the case for a quote anyway. So my point is, yes, i see what you mean, but it's a minimal problem. --Alfakim 20:12, 7 June 2006 (UTC)

Table parameters

I have defined parameters as "stuck to the closing tags and seperated by pipes". This is not the case for tables yet. Table parameters avoid pipes so they dont interfere with template code. However, is this unintuitive? Perhaps all parameters should follow the same pattern. If so, a cell's parameters ("align=right" etc) would be thus:

 
!! 1:1 |right!! 1:2 !! 1:3 |c2!!
!! 2:1       !! 2:2 !! 2:3    !! 2:4
 

Yes/no? --Alfakim 15:37, 7 June 2006 (UTC)

Too important to miss; implemented. --Alfakim 20:05, 7 June 2006 (UTC)

Comments on the autoparameter for links

Interesting idea. A lot of these pieces could be extremely useful. I agree with a lot of the comments already made here, so I won't reitereate them, but one I don't see: I'd rather you flip the external link pipe trick. That is, let [[http://www.wikipedia.org]] leave [2], and let [[http://www.wikipedia.org|]] leave http://www.wikipedia.org. This is because having the link collapse into something small is far more common a thing to want than the other way around, and should thus be simpler to type. Drawbacks: less intuitive, but then I think that I'd rather have the ease of use once I'm past the learning curve. Thanks for the page, these are some great ideas! Snoutwood (talk) 17:38, 7 June 2006 (UTC)

I disagree. It's very rare that you actually want a link like this - [3] - in your text. In nearly every case you're going to want a full URL or else an inline ref that cites it properly. Eg:

• Links: http://www.foo.com

...blah blah as seen online. Blah blah...

--Alfakim 20:07, 7 June 2006 (UTC)

It's perhaps not so common in articles, but it's massively common elsewhere (say, for example, talk pages and noticeboards). In articles, you generally would want a full piped link with an entirely different title. Almost never do you want the full URL (i.e., http://www.wikipedia.org) to be shown. Thus, it shouldn't have the easiest markup. The most common usage should have the simplest markup. Snoutwood (talk) 21:44, 7 June 2006 (UTC)

Some more comments

• Code types - Requires slight rewording, as currently the links don't show, as they can't insert a link text.
• Wiki-functions - Nice idea, if it can be parsed, and can be written without the need of an escape character.
• External links. Not all URI-s contain ://. Also, while I would love to drop the heritage []-function, putting this into ordinary links means you need something to tell the parser you are actually making pages about web sites. Possibly you're defniing a leading : again, here.
• Media - A link to Media:foo.ogg does not actually insert the sound. Description should probably match intended functionality.
• Categorisation and interwiki (called "interlanguage" here) - These do not insert or link anything into the raw text. They are probably wiki-functions.
• Subst - Obviously, though you could allow legacy-functionality, it should have a consistent implementation as well. The test for usefulness will come from checking that the consistent implementation is indeed easier to use.
• Leading space as a nowiki wikifunction shortcut - This is quite handy, and would also be quite an irritation. Unless you go for no spaces allowed all around, don't break consistency here. <<| <<! <<- <<=
• Wiki function arguments - As can be seen from the examples, this no space rule reduces readability. Don't. If it's there for a problem, a different solution is needed.
• Example for Category - Appears to have the same limitation as the current implementation. May be intentional, but still. (<<Category Proposals|W>>)
• Autoparameter for links - This will not help us link within a namespace in any way. We don't just want it to strip stuff, we also want it to prefix the link with the Namespace the page is in, if no Namespace is present.
• Autoparameters for external links - Beep. That's an inconsistency. So, I expect it's really going to strip the protocol etc., the pseudo namespace, while a real argument creates the note style? And of course, this being the same link as the internal link, this means this argument will be available there as well, which will allow real notes.
• Escape - No. Escape characters are for programming, not for writing. If you need them, it means you've lost consistency or clarity.
• Text styles - The advantage of the wiki syntax is it's silence. Yours draws away the attention that should be on the text.
• Third-level point inexplicably ending with 2 asterisks - Neither the code, nor it's representation comes out right here.
• Headers - These imply text styles and should likewise be tag-styled.
• Automatic line break
  • Would break up any text where the author decided to start on a new line for whatever reason, just in case she did so for one specific reason.
  • You're example here shows you actually want this to trigger on punctuation that is no line ending. While everybody understands the problem you're trying solve, though they may not know the solution, most people will not even understand the problem you're introducing. New line, which in itself isn't even visible, is going to behave differently depending on what was on the previous line.
• Indentation - Don't work backwards. Right indent should be indicated before the text. Probably shouldn't be line based all.
• Blockquote . Bad choice of words. A blockquote is not an indentation style. Itmight actually take the whole page width on a page where normal text leaves an annotation margin.
• Dashes - Automatic conversion is everybody's favourite, until it does what they don't want.
• Tables
  • Not actually any more readable than the current version.
  • <<br>> creates a new line in the cell; that doesn't help to create a new row.
  • Aliasses - Aliassing all attributes and style attributes will create quite a monster. So if you make a choice, what is your reason for what you do implement?
  • Row control - This breaks up the piping; what does that mean for text inserted between other !!-s?
  • Spanning - Needs a disambiguation for a non-existant cell with top and left neighbours.
  • Fake first row - Beep.
• Mark 2 - This is probably an improvment to some, but it will be considerably set-back for others. If you want to be able to use this mark-up, look for a way to introduce a choice of mark-ups.

Aliter 22:59, 7 June 2006 (UTC)

Generally excellent, some flaws

1. The entire idea of <<tag>> markup is not good. You're talking tags that are often used to enclose large amounts of text, so it would be easy to lose track of nesting or to encounter a >> and think "Wait, what's that closing?". The excellent point about SGML-style tags is that closing tags are unambiguous, which is critical for such large spans. (The alternative used in programming, signalling attachment by indentation, would work equally well but is impractical here.) Keep SGML-ish things like </nowiki>, don't introduce such confusing markup.
2. Using double brackets for both internal and external links is a good idea. However, if the target is a URL, a space should optionally be permitted as a separator between target and text. This is because URLs can be long and unwieldy in the edit window, and if you force the first word of the displayed text to be tacked on to them following a pipe, they'll get even longer and more unwieldy. Space as a URL delimiter is entirely unambiguous and should be kept.
3. lc and uc are pretty pointless. Use CSS instead.
4. An escape character as simple as a slash isn't really acceptable in plain text. Characters will be acting up for no discernable reason. Use the lengthier but clearer <nowiki>, or HTML escape codes if you want something shorter but indecipherable.
5. The change to headers really makes no difference in terms of simplicity.
6. Inferred line breaks, I'm sorry, don't make a lot of sense.
7. > for indentation may not be as good an idea as the current :. The former is already used for all HTML and other SGML-style tags, so conflicts may arise unnecessarily (remember how single linebreaks are completely ignored).
8. Your scheme for auto-hyphenation is probably the best I've seen. I don't think there would be any case where it would give an incorrect result. (En dashes for things such as date ranges would, of course, still have to be entered manually.)
9. Problems with your approach to tables:
   1. You make no provision for easy use of header cells (since ! is used for everything).
   2. You force all cells in a row to be on the same line in the edit window (which is perfectly fine for the tiny cells you use for demonstration, but impractical for lengthy cells: the option has to be there).
   3. The <<table ... >> is a minimal improvement, if any, over the current {|.
   But there are good points that should be adopted:
   1. Implicit row-starting. I think the best way to handle this would be to have ||/!! starting a new line to indicate a new row. If row properties are desired, the old |- should be used.
   2. Automatic row- and column-spanning. The current parser assumes omitted cells are meant to be blank, which is probably less likely.
   The misinterpretation of pipes isn't inherent to the use of pipes for tables; it's a simple bug (Mediazilla:4060) which will certainly be killed in a parser rewrite like this.

Other than that, I basically think this would all be somewhere between good and excellent. Hopefully we can get some enough community support that this is lumped in with the parser rewrite.  :) —Simetrical (talk • contribs) 04:54, 8 June 2006 (UTC)