Going to try this out (when we show people wikka markup their face usualy dorps when you get to tables.. even with the advanced tables action)
Cheers

Great! Looking forward to any feedback. :)

I'll give it a try too, thanks for sharing this.

Excellent, looks good so far; my users will be quite happy when I show this to them.

Thanks!

Tormod, any idea regarding support for table headers and col-/rowspans ?

Not as it is, no. The way the formatter(s) are built up kind of hampers any solution. Any delimiter is parsed and written out before anything "within" is looked at. To make a good table markup thingy one would probably need a separate table formatter.

Additionally - I suspect the planned changes to the formatter/formatters will destroy this "hack". I'll have a better look at it ... soon... ;)

"Curse this active mind of mine."

DarTar: I'll probably manage to churn out a modification to SimpleTables that support table headers and col-/rowspaces within the next week (or two) - without changing the use of the basic table markup provided now.

terrific

Tormod, I applied the patch to my local 1.1.6.2. In spite of a minor problem with the patch itself (a section not matching the original code, so I had to copy some lines manually), the table formatter now works like a charm. Thanks for contributing this! With Marjolein and Nils, we were just discussing the possibility of adding further (optional) support for thead/tbody/tfoot, which would be great semantically and also for styling. But this is for later...

I pointed out this same 'glitch' with the patch utility at http://wikkawiki.org/CloneACLs ... repeated here ....
The other issue with he 'patch' utility is that the file being modified has to be reasonably close to the one you make the 'diff' file from .... In the case of this application, time has gone on since the last release ... you modified your files, Joe modified his differently, I went in a whole 'nother direction ... increasing the 'fuzzify' value only gets one so far at times ...

WazoO, I was not expecting this glitch because Tormod says the patch applies to 1.1.6.2, which is the version I used, not an arbitrarily modified file.

Hm. The linked patch works if I download (wget) it, but not if I copy the contents (or "grab"; which is copied and pasted into wikka in the first place) and paste into a new file. Diff says change in whitespaces but "-l" param in patch doesn't help ("diff wgetted_file copy_pasted_file -b" says is like). No idea why. Patch applies to 1.1.6.2.

Yes, but as stated, I've been modifying my 1.1.6.2. files to get back all the functions I'd added to the 1.1.6.1 version ... and I've changes a number of those files enough that the "patch utility" will not fly on a number of offered modifications here, as it simply can't 'find' the 'matching' code sections .. in some cases because I've inserted too many comment lines, other places where I might have inserted and later commented out lines of 'test' code .. any number of reasons, I was just making the point that the "patch utility" is based on the developer's base file and the end-user's file being reasonably close to matching .... probably works for 'most' folks, but .....

WazoO: Is there anything I can do to help you? Would the whole "wakka.php" work better?

?? I haven't played with this mod at all ... I hust noticed the reinforcement of a comment I'd made on someone else's offering that also went the "patch utility" mode. As I said, I'm still working at getting my 1.1.6.2 install to get a bit closer to what I had running under 1.1.6.1 after a number of months worth of 'tinkering' ..changing, modifying .. adding .. etc. .. but, thanks for the offer ...

Tormod, providing a link to the whole file could be interesting to users not familiar with patches. With your permission, I'd like to upload the patch to the SVN repository - credits will be added in the header. This will allow diff'ing and downloading the latest version of the formatter.

No problem. Consider it donated to to wikka. :)

Very much appreciated :) There might be further changes to the code before 1.1.6.3 is released, I suggest we keep the discussion on the development of this formatter on this page.

A suggestion from JavaWoman to add scope attributes to headers:

|=| => <th>
|=c| => <th scope="col">
|=r| => <th scope="row">

How does that sound? Adding support for thead/tbody/tfoot keeping an intuitive markup seems more complicated...

Scopes are done (testing), but will we now need <colgroup> and <col> elements?

OTOH thead/tfoot/tbody should be easy(er) to program, given practical delimiters.
I suggest (to start) that a tag on a line of it's own starts a new row group(?):
|#h| => <thead>
|#f| => <tfoot>
|#b| => <tbody>

|!|The Caption||
|#h|
|=|Name|=|Title||
|#f|
|=|Name|=|Title||
|#b|
||Jane Doe||Director of Missing Persons||
||John Doe||Secretary of Missing Persons||

It was rather that I was thinking it would be hard to *automatically generate* <thead> and <tfoot>; having a markup for it should work.

I like the proposed markup!

I still wonder if it would be possible for a simple table to automatically generate <thead>+<tbody> (forget about tfoot in that case), provided the table starts with a row (or rows) of only header cells; or generate a <tbody> only if there aren't any header rows (there could be a column, of course) - this if the specific markup hasn't been provided by the user, of course.

colgroup and col woudl be nice - any suggestions for markup?

I really like the way this is heading, with a clean, extensible marlkup to create accessible data tables! Great work, Tormod!

Thanks. No idea about the colgroups for now. Automatically generating a thead goes wrong in case you want:

th - td - td - td
th - td - td - td

with no look-ahead the best guess here is to make the first row a thead.

My 2 cents: automatic generation of thead/tbody is likely to (a) generate errors in tables with a complex layout and (b) slow down performance, if the regex becaume too conditional. So a simple and distinctive markup as the one you suggest seems to me a better option. Consider also that one can add multiple <tbody> to a table, which couldn't be generated by automatic parsing.

As for the abbr attribute, maybe we could use round brackets?

|=c(Bananas)|Yellow oblong fruits||=c(Apples)|Round green fruits||

Tormod,
If in the case of 'th - td - td - td' you cannot detect that it's not a whole row of th cells, then indeed you cannot automatically generate a <thead>.

Let's stick with the markup solution for now - that should at least be possible.

(As long as we have a good markup, a late formatter might be able to generate more automatically - but that would depend on a comlpete overhaul of the formatter.)

DarTar, I like the idea for the abbr attribute - but we need to consider some further attributes needed for complex tables:
- header cells should be able to get an id (actually this true for each table markup element)
- data cells should also be able to get a headers attribute (to refer to a list of header cell ids)
- there's also the axis attribute (categorization); applies to both header and data cells

Markup ideas anyone?

Uploaded to SVN repository patch adding thead/tbody/tfoot support and CSS selectors.

Another (important) markup extension: allowing th's spanning over multiple rows/columns.
How to combine in a sensible way the |=|, |=r|, |=c| markup for headers with the |n|, |,n| markup for spans?

Maybe just:

|=2| //header spanning two columns with no scope
|=,2| //header spanning two rows with no scope
|=c2| //header spanning two columns with 'col' scope
|=r,3| //header spanning two rows with 'row' scope

is that intuitive/robust enough? Looking at these examples, I'm wondering whether the "," is a good option for distinguishing span values.

Ehm, apologies - the above is already possible in the latest version of the formatter... (we should give extensive examples on how to combine the different attributes supported by the formatter).

markup ideas for scope=rowgroup and scope=colgroup:

|=R|
|=C|

or maybe:

|=rg|
|=cg|

As for markup for further parameters, let's consider that we need to find a solution *consistent* with all wiki markup supporting parameters (this includes potentially many kinds of formatters: code blocks, spans, floats).

A simple solution would be to use round brackets, following the convention used for codeblocks:

%%(php;15;filename) %%

If the order is not enough to determine what parameter a value refers to, then maybe we should add explicit "parameter: value" statements:

|=r(id: main;abbr: Head)|This is a header||(headers: main;id: mycell) Here goes some cell content||

But I wonder how many users (who know XHTML) will use this markup instead of ""embedding a table as HTML"". See also the relevant discussion at: http://wikkawiki.org/WikkaExtensibleMarkup

Even more markup ideas, after a quick chat with Marjolein.
For grouping, we could stick to the |#x| convention (already in use to groupe rows), and have:

|#h| => thead
|#b| => tbody
|#f| => tfoot
|#c| => col
|#g| => colgroup

For further accessibility attributes, instead of using the full attribute name (as suggested in my previous comment), we could use only a single letter to identify the attribute, for instance:

a => abbreviation
i => id
h => headers
etc.

Some examples:

|(i:d35)|data|| => data cell with id "d35"

|=(i:fruit)|header|| => header cell with id "d35"

|=(a:Apples)|Round Green Fruits|| => header with abbreviation

|(h:fruit, quantity)|data|| => data cell referring to headers with id "fruit" and "quantity".

|=(i:fruit;a:Apples)|Round Green Fruits|| => header with abbreviation "Apples" and id "fruit"

To keep things even more consistent, we might even move the scope and span attributes *inside* the brackets.

|=(c)|header|| => header with col scope
|=(r)|header|| => header with row scope
|=(rg)|header|| => header with rowgroup scope
|=(cg)|header|| => header with colgroup scope
|=(c)|header|| => header with col scope
|=(cg2)|header|| =>header spanning two columns with 'colgroup' scope
|=(rg,2)|header|| => header spanning two rows with 'row' scope

To conclude, a final nice example:

|=(rg,2;a:Apples;i:id)|Round Green Fruits||

which should be, by now, self-explanatory :D

Tormod, nightmares?

Sure. I feel this is working itself over from SimpleTables to ComplexTables. I can work with this, but I'm thinking about how to make something that the average page_creator will find simple, and the average visitor will find readable (xhtml standards + basic accessability). Headers (attributes) are almost right out: they are only needed for extremely complex tables - scopes will do nicely - and I should make them work on td's too. I'll think some on this.

Hi!

Long time since anyone wrote anything here so... I really need this table markup now! :)
So, what's the status? Is it mature enough to use or are there any bugs? If so, is someone working on them?

I am currently using v1.1.6.2, can I take this table formatter code and implement it in that version now?

Thanks!
Andreas

Andreas, I've been using it extensively on both the OpenNIC wiki (http://wiki.opennic.glue, if you're pointing to an OpenNIC server) and my own personal wiki. It does everything I ask of it with few complaints :)