(anonymous guest) (logged out)

Copyright (C) by the contributors. Some rights reserved, license BY-SA.

Sponsored by the Wiki Symposium and the Nuveon GmbH.

 
This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

Table Syntax


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 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 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 Wikka, 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

Add new attachment

Only authorized users are allowed to upload new attachments.

« This particular version was published on 14-Nov-2006 16:27 by Dario Taraborelli.