Magnus Manske wrote:
So, you want an unordered list of tables, right? But what, exactly, makes that different from a single table? You'll have table rows stacked upon each other either way; the only difference would be getting rid of the bullet things, which doesn't strike me as particularly bad in this context.
It will also make the wiki source more readable.
Not quite what I was thinking: What I want is an unordered list with a mix of text and a table in each item. Something similar to this:
* apricot +-----+---------------+---------------+ | | AmE | BrE | +-----+---------------+---------------+ | (1) | ["{.pr@.kAt] | ["{.pr@.kQt] | | (2) | ["eI.pr@.kAt] | ["eI.pr@.kQt] | +-----+---------------+---------------+
Both (1) and (2) are standard and are listed in most dictionaries.
* arctic +-----+------------+------------+ | | AmE | BrE | +-----+------------+------------+ | (1) | ["Ar.tIk] | ["A:.tIk] | | (2) | ["Ark.tIk] | ["A:k.tIk] | +-----+------------+------------+
The debate is whether or not the <ct> cluster is pronounced [kt] or just [t]. M-W lists both, with (1) first, but OED only lists (2). Generally, the same pronunciation for the <ct> cluster is used for both ''artic'' and ''antarctic''. However, M-W lists (2) first for ''antarctic''.
The wiki syntax for tables will prove to be most useful in many circumstances, I am sure. However,
* Tables are supposed to only be used for presenting tabular information, not for layout. I don't think that the word itself and the description are tabular information, and so they shouldn't be in a table. * Do we really want tables that extend across the entire page? * This solution also requires using the colspan= option for first and last row in the table for each word, which arguably decreases the readability of the wiki source. * Would make every cell holding a pronunciation as wide as the longest pronunciation. * If we can embed tables in tables, why shouldn't we be able to embed tables in unordered lists?
I think, in general, being able to extend the content of a list item across multiple lines of wiki source would be convenient. For example, on the current page I have a <br> between the pronunciations and the description text, but I think the wiki source would be more readable if I just put it on a separate line.
As for how to implement it, maybe the syntax could be that if a line containing a list item ends in a , then the next line is also part of that list item, and if the next line begins a table, the whole table is part of that list item. I haven't studied the PHP for processing wiki syntax, so I don't know how hard that would be to implement, though.
I just want to reiterate that I think the wiki syntax for tables is a really great idea! I just wish I could use them on this page. Magnus, again, thanks for taking the initiative and making tables available in wiki syntax.
-- David [[User:Nohat]]
David Friedland wrote:
I was experimenting with the table markup on test and ran into a situation which I didn't seem to be able to solve using the table markup.
There is a page I have been working on [[List of words of disputed pronunciation]] onto which I have put pronunciations in IPA and SAMPA. The way I have them now is just one after another, separated by nubers in parentheses (as a label for each pronunciation) and commas.
After some discussion on talk, it seems there needs to be different versions of each pronunciation, IPA vs. SAMPA, AmE vs. BrE, etc. Such a matrix of pronunciations is tabular information perfectly suited for a table. Unfortunately, each word is in an unordered list (lines starting with *) and the syntax for those lists requires all text for each item be placed on one line. Thus it seems impossible to mix the wiki syntax for unordered lists and for tables.
So:
(1) Should there be a way to mix lists and tables using wiki syntax? (2) Should a different approach to organizing this page be taken?
I suppose it would be possible to put everything in a giant wiki table, but that would be using tables for layout and not for just tabular information, which seems like the wrong approach.