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.