Table Syntax

* [DokuWiki|http://www.wikimatrix.org/wiki/dokuwiki:tables]
* [JSPWiki|http://www.jspwiki.org/wiki/HowToCreateATable]
* [MediaWiki table syntax|http://meta.wikimedia.org/wiki/Help:Table]
* [WikkaWiki|http://www.wikicreole.org/wiki/Talk.Tables#section-Talk.Tables-WikkaMarkupForAccessibleTables]: [specs|http://wiki.tormodh.net/SimpleTable] [examples|http://docs.wikkawiki.org/SandBox]

------
This would be the DokuWiki variant: Problem for me - charet is kind of hard to type on a german keyboard: Charet and than hiting space, it would introduce yet another character that first time users have to look up at their keyboard. It also is not looking like a block for me that is belonging together. 

{{{
^Hading 1  ^ Heading 2
|Cell 1.1  | 1.2
|Cell 2.1  | 2.2
}}}


what about this one
{{{
* Hading * Heading 2
| x1     | x3
| x2     | x4
}}}

--[Christoph] 04-Sep-06

------
If people are open to bigger changes, a strict subset of the table syntax we've discussed for the OLPC document format would be:

{{{
|* Heading 1 *|* Heading 2 *|
|   Cell 1.1  |   Cell 1.2  |
|   Cell 2.1  |   Cell 2.2  |
}}}

Otherwise, we could adopt a bit of the OLPC syntax, and come up with something like:

{{{
|* Heading 1 |* Heading 2
| Cell 1.1   |  Cell 1.2
| Cell 2.1   |  Cell 2.2
}}}

--EPAstor 04-Sep-06

i like the second one, first one could be optional, like with headings where trailing equals signs are optional, but what would happen if i would like to use bold in cells 

{{{
|* Heading 1 |* Heading 2
|**Cell 1.1**|  Cell 1.2
|**Cell 2.1**|  Cell 2.2
}}}

kind of confusing. I think we are using way to many stars anyway (in case unordered lists will begin with *)...

--[Christoph]

I see your points... For using bold in cells, I'd hope that we'd tend to write something more like this:

{{{
|* Heading 1    |* Heading 2
|  **Cell 1.1** |  Cell 1.2
|  **Cell 2.1** |  Cell 2.2
}}}

But if not, I think that's still okay. As for using too many asterisks... they're all in different contexts. Since header cells in tables generally look a lot like bold (but aren't, exactly), I think it's actually a good idea to reuse the same character that we use for the bold marker for header cells. As for unordered lists... single asterisks will only mean something at the very start (and very end) of a table cell, and I don't think we're allowing lists inside table cells, so I think we're okay.

--Eric

!! Proposed OLPC table format

{{{
||             TC Music             ||
|------------------------------------|
|* Parent company *|  TC Music, LLC  |
|*     Founded    *|     1990's      |
|*   Founder(s)   *|   Tom Bradley   |
|\                /| Concett Bradley |
}}}


I like the line seperating the heading from the actual cells,
what about having something like this (making that optional to beautify tables in markup)?
{{{
||Heading Col 1 ||Heading Col 2
|--------------------------------
| Cell 1.1      | Cell 1.2
| Cell 2.1      | Cell 2.2
}}}
--[Christoph]


I like the idea  of a syntax for drawing horizontal lines between rows.
It is similar to the LaTeX table syntax:
{{{
| row n ...
|-
| row n+1 ...
}}}
will draw a line between rows n and n+1.
However, this approach would require a type of table which does not print any lines at all per default.
WackoWiki knows [two different types|http://wackowiki.com/WackoDocumentation/WackoFormatting?v=mmp#h7705-9]  of tables, one with lines and one without lines.
--[PeterMenzel]

!! Not Wysiwyg

I like the syntax I have seen first on Helmut Leitner's ProWiki. It consists of an element introducing the column labels, and then lines of "label: cell content" until you get to the element closing the table. Oddmuse uses the following:

{{{
<table a, b, c>
a: one
b: two
c: three
a: more
b: text
c: etc.
-----
}}}

But basically it would also be possible to use something like the following if you prefer the pipe symbol only (and no english text in markup rules):

{{{
|a|b|c|
a: one
b: two
c: three
a: more
b: text
c: etc.
||||
}}}

This syntax allows for multiple paragraphs and other markup inside cells, which is the greatest benefit.
I find the near wysiwyg style of table editing to be suitable only for the most trivial of tables.

For Oddmuse, the first row is always rendered using table headers instead of ordinary table cells. If a cell is left out,
cells span columns automatically. It also has some more features you can read about on the [Long Table Markup Extension|http://www.oddmuse.org/cgi-bin/oddmuse/Long_Table_Markup_Extension] page.

-- [AlexSchroeder]

Here is a cut&paste from Microsoft Excel.

{{{
1	2	3
4	5	6
}}}

So if allowed both tab & | as cell delimiters, could then be more user-friendly in allowing direct pastes from other applications. 

It would also require an explicit start & end table tokens. 

-- [JaredWilliams], 2006-09-28

That's [InvisibleMarkup], and it's hard to edit existing tables.
Excel can open and save CSV files, and the "|" markup is a special case of CSV -- using pipe instead of a comma (which is usually replaced with a semicolon anyways), so importing/exporting to/from Excel is still simple.

-- [RadomirDopieralski], 2006-09-28

Yes, CSV was my first thought at markup, as I thought Excel used comma delimited. Would prefer a direct cut&paste though. InvisibleMarkup wouldn't be a problem, as it'd be converted to | for subsequent edits anyway. 

-- [JaredWilliams], 2006-09-28

------
!! Wikka markup for accessible tables

As a developer of [WikkaWiki|http://wikkawiki.org], I'd like to contribute my 2 cents to the present discussion. After a long debate and a review of existing table markups in many opensource wikis, we are about to implement an extensible table markup for Wikka to produce ''accessible data tables''. This means providing support for all the attributes that are required for accessibility in XHTML, like thead, tfoot, tbody, summary, caption, scope etc. Text formatting using wiki markup is available within the table.

Obviously, basic use of table markup doesn't need all these attributes but we think it's essential for a wiki to ''be able'' to produce accessible data tables ''if required''.

The criteria we kept in mind while implementing this markup were the following:
* use easily extensible tags (so, for instance, avoid giving whitespace a function that depends on the specific element in which it's used)
* use tags that do not conflict with either natural languages or other wiki markup (so as to allow all the richness of natural languages and wiki markup ''within'' the table)
* avoid tabs because they are unsupported in textareas on many browsers
* always close markup to avoid ambiguities for humans and for the parser

The simplest possible example of table markup for Wikka, producing a 1x1 table is

{{{
||hello||
}}}

Headers can be added as follows:

{{{
|=|Header|=|
||hello||
}}}

Complex, XHTML-valid and accessible tables can be created with element id's, row headers, column groups, row and column spans, captions, summaries etc.

{{{
|!|(u:The Summary;i:mytable)||
|?|The Caption||
|=|Name|=|Number|=|(x:2)Span||
||John Smith||1||This||That||
||Jane Doe||2||That||This||
}}}

Optional per-element CSS support is also available using braces immediately after the element delimiter:
{{{
|=|Header|=|
||{color:red}hello||
}}}

(we are planning to extend this brace-markup to add styling hooks for any other HTML element in the page)

This markup will be available as of the next stable release (1.1.7).

A short summary of the table markup specs is available here: http://wiki.tormodh.net/SimpleTable
Some real-world examples are available here: http://docs.wikkawiki.org/SandBox

Full documentation on this feature will be available on the documentation server as soon as the next release is out.

I'd personally advocate against using a specific syntax for border vs. borderless tables because this means mixing content and presentation (however practical this option may sound to the end user). Borders should be taken care of IMO by a dedicated kind of markup, dealing with styling and allowing the user to select different options available in the stylesheets. Also, shouldn't line breaks follow the same syntax for ordinary line breaks?

-- [DarioTaraborelli], 2006-11-14

----

I like the simple syntax proposed, but I see some issues:

# it's hard to distinguish a cell following an empty one from a header cell
# it's not clear what a double pipe ({{{||}}}) at the end of a row means
# it's not clear what more than two pipes ({{{|||...}}}) mean
# it doesn't make sense to have forced break defined only inside table cells

Personally, I wouldn't like to have backslashes in the syntax at all, as they're often used as escape chars and create confusion.
A bit OT, but may I suggest {{{%%%}}} for line breaks, like in [phpwiki|http://phpwiki.sourceforge.net/phpwiki-1.2/index.php?TextFormattingRules]?

Reserving double pipes for header cells requires to mark empty cells differently. Maybe some spaces between pipes?

-- [[MicheleTomaiuolo]], 2006-11-23

I don't understand why we use a "compromise" for tables that is used by two implementations, when we have two other variants used by five or six implementations? It seems like we're using the variant that two out of thirteen use. Not good.

I suggest doing away with header cells. If users want them, let them use bold within table cells. Or implementations can automatically make the first row into header cells. There's no need for special header markup.

If this is indeed about simple tables, then we don't need a way to adde linebreaks within table cells.

The proposal should say whether other markup within table cells is allowed, disallowed, or implementation-dependent.

-- AlexSchroeder, 2006-12-01

-------
Michele, Alex,
thak's for your feedback. Here's some reasoning why i think it would be useful to have those features, although i could live with it, not having it in the next version of creole:

!Seperate Header Syntax
Without an seperate header syntax it will be hard to control the header display by css, and imho this should be possible. If we don't define it we deprive advanced engines/implementations of the possibility.

''it's not clear what a double pipe ({{{||}}}) at the end of a row means'' - it simply sould not be interpreted, or interpreted as the end..

{{{
||A||B||
}}}
so for example the behavior of JSPWiki is wrong, as it interprets it as a new cell:
||A||B||

This is a frequent error of endusers in JSPWiki: They want to ''close'' a row like this
{{{
||A||B||
|1|2|
}}}

''it's hard to distinguish a cell following an empty one from a header cell'' - it's required to have a space if it  sould be a empty cell
{{{
| |previous is an emty cell
|| this cell is rendered as a heading...
}}}

For me the question is if we want to give engines the possibility to render headings differently. After we have decided on this we can discuss what is the best syntax for it (not necessarily double pipes)

Since I am for a seperate header syntax, here's a suggestion: combine [headings] syntax of creole with table syntax of creole. This assumes that you would like to make cells bold that are not headings, but you never would like to use heading syntax other than in heading cells (That's why i don't suggest bold syntax))
{{{
|= Heading1 |= Heading 2 |= Heading3 |
|cell1      | cell2      |cell3      |
}}}
then we could interpret two pipes as emty cell... 

Also like DarioTaraborelli shows in his example above, two pipes have a special meaning in other markup which would make it hard to mix markup...


!Line breaks in cells:
You want to split long cells quite frequently in more complicated tables. Sometimes you would like to reduce the width of the table display, because only a certain line is causing the table to be wider than expected. But i guess this is already to advanced. 

We don't have dedicated characters for [linebreaks] in creole so far, so we should leave out that syntax in cells, since it introduces inconsistancy. One could rely on the browser to break the lines in cells while resizing the browser frame, or use the native syntax of his wiki to do advanced tables...

!To sum up:

* we either use no heading syntax at all or we define a better way of defining a header cell, since it is hard to distinguish empty cells from headings with the double pipe syntax and it does not mix well with existing markup...
* we do not specify a [linebreak] syntax in cells unless we have discussed linebreak syntax in more detail in creole (currently you define line breaks symply by using return, which is more visual, but produces other problems like this here..)

--[Christoph] 4. Dec 2006

You didn't comment on the idea of using the first row of a cell as headers always -- you just said you prefer a different syntax for headers. Can you elaborate on this? Is it ever useful to have a table without headers, or is it ever useful to have headers in any row but the first?

--AlexSchroeder

Cross tables [Cross_tab|http://en.wikipedia.org/wiki/Cross_tab] should have headers in the first row and first column, imo.

-- JaredWilliams

Yes, that was my idea, where you have ''row'' Headings: 

This code in JSPWiki
{{{
||               ||boxers||briefs
||heavy Wiki user|70%    |5%
||light Wiki user|25%    |35%
||non Wiki user  |5%     |60%
}}}

creates this display

||               ||boxers||briefs
||heavy Wiki user|70%    |5%
||light Wiki user|25%    |35%
||non Wiki user  |5%     |60%

This matrix representation should be possible, since it is a good use case for a tables - present a complex issue in a readable way.

Using tables without headings... I would rather go without heading syntax and help myself with using bold syntax than define the first row of a table always to be the heading...

again, i think this one here would not look that bad at all ;)
{{{
|=                |=boxers|=briefs
|=heavy Wiki user |70%    |5%
|=light Wiki user |25%    |35%
|=non Wiki user   |5%     |60%
}}}

could you live with something similar to this?

--[Christoph]

I think that in this case I'd be using my "complex table" extension instead of relying on the "simple table" extension. That allows me to use CSS to highlight the various cells in just the way I want.

I do agree that your last example looks not bad, and I could implement something like it. I'm just not convinced that it is a good idea, because it is new (and we should prefer NotNew). Perhaps it should remain ExtensibleByOmission -- not specify table headers at all.

-- AlexSchroeder

Removed special table header syntax and line breaks in tables from [Creole 0.3].

-- [Chuck Smith]

I was wondering, how much of markup is allowed inside table cells exactly? In particular, are links allowed? I have a problem with the pipe symbol in links and images...
-- RadomirDopieralski, 2007-02-05

My opinion is that Creole should only specify which markup //must// be supported in tables (as in other elements), without preventing languages to support also other markup ([[Extensible By Omission]]).

The same stands for links, headings etc.

Radomir, you're right. I didn't think to the pipe in links and images. I'm going to change the priority of rules in PEAR Text_Wiki_Creole. I think support for links (at least) should be required.

-- [[Michele Tomaiuolo]], 2007-02-05

This shows how just discussing things without actually implementing them can lead to missing important details :(

I think that we should explicitly state that pipes between {{{{{{}}} and {{{~}}}}}} tags, and also, if images and links are supported inside tables, between {{{{{{}} }}}and {{{[[]]}}} tags, are not interpreted as cell separators.
-- RadomirDopieralski, 2007-02-05

Just to clarify. I asked to specify a little better how those corner cases should be interpreted. I'm ok with the clarification provided by Christoph (thanks!). Either ways, {{{||}}} or {{{|=}}}, are fine with me. But definitely I'm for specifying a syntax for header cells (at least as a suggested extension).

-- [[Michele Tomaiuolo]], 2007-02-07

The {{{|=}}} looks saner to me -- and consitent with the headings markup. {{{||}}} is used by various engines for headigns, empty cells, cells spanning multiple columns or jus normal cell separators.

-- RadomirDopieralski, 2007-02-08

Should we also add the option to write {{{|= cell header =|}}} to keep it consitent with [[Headings]]?

-- RadomirDopieralski, 2007-02-27

Hmm, yes. What do the others think?

-- ChristophSauer, 2007-02-27

I agree. I already implemented tables this way.

-- [[Michele Tomaiuolo]], 2007-02-27

I disagree. To be consistent, you need to accept {{{|= cell header =}}} (without trailing pipe)
at the end of a row. Then you have to check what follows {{{=}}} if you want to have a table
like
{{{
|= n=1 =|=   n=2   =|
|  a+b  |a^2+b^2+2ab|
}}}

Unnecessarily complicated.

-- [[YvesPiguet]], 2007-02-28

Right, you need to strip the trailing = even when there is no pipe at the end. Thank you for pointing that out.

But I don't really think it is complicated -- it just one "=?" in the cell-parsing regexp, right?

-- [[Radomir Dopieralski]], 2007-Feb-28

It's one more thing to specify, to explain and to test, while it doesn't add anything.
Trailing equals are more justified in heading for compatibility reasons. But I'd accept to
remove them.

-- [[YvesPiguet]], 2007-Feb-28

I don't think you have to explain it to the users -- on the contrary, it would require explanation if they weren't behaving the same as headings. [[MakeTheMachineWorkHarder]], remember?

-- [[Radomir Dopieralski]], 2007-Feb-28