from_name: Jan Hidders

subject: [Wikipedia-l] Proposal for table syntax

in_reply_to: <B96F0A7F.24E3%cunctator@kband.com>; from cunctator@kband.com on Thu, Aug 01, 2002 at 03:55:43PM -0400

body:
On Thu, Aug 01, 2002 at 03:55:43PM -0400, The Cunctator wrote:
> On 8/1/02 3:27 PM, "Jan.Hidders" <hidders at uia.ua.ac.be> wrote:
> > I didn't interpret the example that way, but rather as a table with
> > properties of Bill Clinton. If you want a table of presidents and their
> > favourite instrument you would write this:
> >
> > [|  '''President''' ||  '''Instrument''' |]
> > [|  Bill Clinton    ||  Saxophone        |]
> > [|  Harry Truman    ||  Piano            |]
> > [|  Abe Lincoln     ||  Bag pipes        |]
> >
> I'm pretty sure Lincoln played the fiddle.

Oops. You're right. So now it's your turn: Name three Belgian prime
ministers and their favourite music instruments. :-) It's also Ok if you
name one famous Belgian that invented a music instrument. Without checking
Wikipedia first, of course.

-- Jan Hidders


list: wikipedia-l

source: pipermail-mbox

from_name: tarquin

subject: [Wikipedia-l] Sysop status

body:
Brion VIBBER wrote:

> tarquin wrote:
>
>> Before I too jump on the application bandwagon ;) -- what can sysops
>> do that mortals can't?
>
Could I have sysop status please?
I'd like to be able to copy wiki text from the policy pages. I might
also need to rename pages on Meta.

...
BTW, didn't someone mention a while ago that the incidents of crossed
wires between the US admins of the 'pedia and the people on the European
versions were due in part to differences in culture -- the Europeans
perceiving the Americans as a little brash and pushy?
I have a funny feeling we've just seen that in action again here: the
above message I sent earlier is, in British English a fairly direct
request ;-)


subject: [Wikipedia-l] New wiki markup

in_reply_to: <200208011924.g71JOLT10383@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Aug 01, 2002 at 12:24:21PM -0700

body:
On Thu, Aug 01, 2002 at 12:24:21PM -0700, lcrocker at nupedia.com wrote:
>
> So here's a radical proposal: take more advantage of CSS to allow us
> gurus to prettify articles without complicating the wikitext.  Create
> some method of attaching an inline stylesheet to a page or group of
> pages, and put things like image floats, table backgrounds, padding,
> fonts, and so on in the style sheet, and leave the wikitext alone.
>
> Of course, that will require some way for the stylesheet to identify
> elements in the wikitext.  We can auto-number things like images and
> tables, and use IDs, e.g., "#image1 {float:left; padding-
> right:10px;}", etc.

What happens if somebody inserts a new table/figure? You renumber? And the
complexity step from doing no formatting to doing a little formatting becomes
relatively big.

Couldn't we just try a little harder to come up with a WikiWiki markup?
There is already table markup that does column-spanning, border
selection and alignment of text in cells. With a little effort we could
probably also add cells that span rows and background colors.

And how about

  << float left <<
  >> float right >>
  >> center <<

for tables and figures?

And do we really need colored text?

-- Jan Hidders


subject: [Wikipedia-l] Wiki Table syntax already a feature request

body:
Daniel Mayer wrote:

>Here is the idea:
>
><wiki table, center, thin line>
>|{light blue} ^ '''Mailing label''' ^|/
>|Name:         |John Doe             |/
>|Address:      |2000 Main Street     |/
>| Postal Code: |123456               |/
></wiki table>
>
>
>The above wiki table seems a lot more intuitive to me
>than either the HTML table or the other wiki table
>syntax proposals.
>
>
>
actually, that idea isn't very different to mine.
* different tokens -- but my tokens were just examples
* there's information about the row in the row -- mine had all
formatting info contained in the head

I think they're minor differences


subject: [Wikipedia-l] New wiki markup

body:
>
>
>Let for formally solicit proposals: folks, give me a clean,
>unobtrusive, user interface for (1) specifying spans and divs in
>wikitext with class and/or id; (2) attaching a stylesheet to a page,
>and being able to edit it.
>
>
>
>
same as the [[image:--- namespace and the proposed [[math:-- generated
images, and the [[fr:-- links at the top of a page: use

[[style:chemistry]]
at the top of a page


from_name: Toby Bartels

subject: [Wikipedia-l] Sysop status

body:
Jeroen Heijmans wrote:

>Also, because much of the deletions that do occur do not comply with the Wikipedia
>policy on permanent deletion of pages (especially rule 6), I'm sometimes confused.

I don't think that it's possible for a deletion not to comply with rule 6;
it's *failures* of deletions that don't comply with that rule.
That's because, unlike other rules, it says *to* delete,
which the other rules say *not* to delete.
That is, it doesn't say to delete *only* pages with names
that will never become the names of encyclopaedia articles;
it says to delete those (leaving open the possibility of others),
except where that conflicts with the other, restraining rules.
(Hence the language about keeping the other rules in mind.)
At least, that's the way that *I* read it.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Sysop status

body:
Lee Daniel Crocker (?) wrote:

>Secondly, Wikipedia is dynamic in nature, and I don't think we should
>play by the same rules as static websites in terms of keeping old
>links alive.  Certainly in some cases it's warranted; if someone
>moves "James Earl Carter" to "Jimmy Carter", and the old one has been
>around for a long time (not just a few days), then it's reasonable to
>expect that there may be external links to it and there's no reason
>not to leave the redirect.  But if it is, say, a misspelling, I'd
>rather just delete it.  We are under no obligation to keep our
>mistakes around forever, and if someone links to it and finds it
>broken, we have done him a service by forcing him to correct it.
>Likewise, if someone creates a page and I think it needs a different
>title, if I catch that error within a day or two and move it, I'll
>just delete the old title.  There's not point in cluttering the
>database with a redirect that's just a mistake, and hasn't been
>around long enough to accumulate links.

As a member of the Redirect Don't Delete Party,
I've no inherent opposition to deleting pages
that have only been around for a few days.
It's these pages that have been here since February that bother me.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Proposal for table syntax

body:
Tarquin wrote:

>http://meta.wikipedia.com/wiki.phtml?title=Wiki_markup_tables

I like the look of Tarquin's proposal the best.
I do worry that it isn't sufficiently powerful;
I have some comments in the talk page already about that
(although my specific example may be moot because of other developments).
So it needs work, but it looks nice.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] Year in Review Backwards

body:
Jheijmans wrote:

>Some time ago, I posted a question on the talk page of Year in Review,
>regarding the use of the Year in Review/Backwards pages, which are all
>orphan pages. I received one reaction (from Toby) voting for deletion
>after I put it on the votes for deletion page, but it was not deleted by
>any sysop. Now that I am one myself, I can do that, but I want to bring
>this topic to the attention for one last time. Unless I receive
>reactions, I'll delete the pages.

Well, as a member of the radical Redirect Don't Delete Party,
I actually think that they should be redirected to their forward versions.
However, I ain't gonna lose any sleep over this one ^_^.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


subject: [Wikipedia-l] suggestion: truncated watch list

body:
Eclecticology wrote:

>Tarquin wrote:

>>Could the WatchList page be limited to a number of days like RecentChanges?
>>Mine is getting rather long & it takes a while to generate.
>>Maybe a truncated WatchList page could give a link to a complete
>>watchlist which would be displayed as a dumb list with no dates &
>>times of edits (which I presume is what causes the load on the server)

>At the risk of being slightly sarcastic, wouldn't a better solution be
>to edit your own WatchList to remove things that you no longer really
>need to watch?

No, I want a long Watchlist too, and I agree with Tarquin.
I want to know if *any* of these pages is edited, however minorly,
but I don't want to wait for them to load on the special page.
For my money, adopting the format of other special pages,
listing only the past 3 days or the past 30 edits by default,
will be quite sufficient; no need for new formats like dumb lists.

-- Toby Bartels
   <toby+wikipedia-l at math.ucr.edu>


from_name: Hr. Daniel Mikkelsen

body:
On Thu, 1 Aug 2002, Daniel Mayer wrote:

> <wiki table, center, thin line>
> |{light blue} ^ '''Mailing label''' ^|/
> |Name:         |John Doe             |/
> |Address:      |2000 Main Street     |/
> | Postal Code: |123456               |/
> </wiki table>

I think this looks really ugly, and if I were a computer novice, I would reel.
Do we seriously need to define colors? We haven't needed color in any of the
text, why should we need it in tables?

Alignment is possibly a concern, but things like "thin line" just looks
useless. Face it, if Wikipedia will ever become a slick and nice looking site,
it will not be because the article authors can define layout and form - it will
be because someone can use the separated-from-form content in a novel/slick
manner.

If one need to show a color, why not use a picture?

I liked the idea posted earlier here,

||
| Blah. | Blah.
||
| Blah. | Blah.
||

-- Daniel


from_name: Brion VIBBER

body:
Toby Bartels wrote:
> No, I want a long Watchlist too, and I agree with Tarquin.
> I want to know if *any* of these pages is edited, however minorly,
> but I don't want to wait for them to load on the special page.
> For my money, adopting the format of other special pages,
> listing only the past 3 days or the past 30 edits by default,
> will be quite sufficient; no need for new formats like dumb lists.

I sometimes use my watchlist like a bookmark list to hold things that I
might want to jump to later -- particularly things in the non-article
namespaces which can't be gotten at through the search function.

A dumb/long list is nice because I can use my browser's text search on
the titles listed in it; but the need for this would largely go away if
I could search in Wikipedia: and User:.

(Sure, I could just use the 'bookmark' function of my browser, but that
would be cheating, wouldn't it?)

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Parsing TeX

body:
Jens Frank wrote:

>I've hacked the phpwiki code to add a new namespace
>[[math: ]] so you can write formulas like [[math:a^2+b^2=c^2]] or
>[[math:\sum_{n=0}^{\infty}\frac{1}{n}=\infty]].

>The code will make TeX create an image (PNG) of the formula. Those
>images will be cached, they will be created only once and will be
>shared between articles. ( [[math:E=m c^2]] might be used on many
>pages ).

I really like this idea!  Some comments:

Be sure to include the TeX source as ALT text in images.

We only need to implement math mode, since everything else is already covered.
I'd look at LaTeX2HTML, with renders math formulas differently from the rest.
We should be able to get by with copying just what is used to make its GIFs
(except that we would render them as PNGs instead, of course).
LaTeX2HTML doesn't process TeX (or even LaTeX) in full generality,
yet it seems to be very popular for putting math papers on the web.
This suggests that we can get a fast program that handles limited markup
but which is sufficient for everything that we need to do.

It might be nice to have something to implement simple <var> tags still,
for the case of an isolated variable name floating among some text.
$$...$$ will still work for that, or any similar idea.

Some will suggest using $$...$$ for the general math formulas.
Aside from the fact that this looks funny to TeXers
(since TeX properly uses $...$ inline, which we can't do),
I think that using explicit namespace syntax is a good idea,
assuming that we really do store the gifs in such a namespace.
The syntax is just as easy to use, and it's best to let
the workings of the system be transparent when this is user friendly.
The only thing that $$...$$ has over [[math:...]] is
in the situation of a very short formula like a single letter,
and there it's better to use <var> instead of a gif *anyway*.

(Contrary to popular opinion, I've never suggested $$x \leq y$$.
What I suggested was $$x$$?≤?$$y$$, which won't fool any TeXer
into thinking that it's actual TeX; the markup is merely *inspired* by TeX.


from_name: bderksen

subject: [Wikipedia-l] Table syntax (if you build it, they will come)

body:
>===== Original Message From "Poor, Edmund W" <Edmund.W.Poor at abc.com> =====
>There's no known way syntax for table layout that works equally well for
>novices and experts. So, why not encourage authors to upload any tabular
>information as a file? Then one of our vast programming staff can
>convert it.
>
>Many computer users are familiar with creating tables (A) in Word or
>Excel; or (B) ASCII tab-delimited or comma-delimited format.

A version of this is already in place; I've gone around and converted a number
of preformatted ASCII tables into HTML ones. Preformatted ASCII is ugly, but
as an interim measure I've got no problem with it.


from_name: Pierre Abbat

subject: [Wikipedia-l] Tolkienavatar.jpg

body:
Should the monkey be deleted?

phma


from_name: Poor, Edmund W

body:
There's no known way syntax for table layout that works equally well for
novices and experts. So, why not encourage authors to upload any tabular
information as a file? Then one of our vast programming staff can
convert it.

Many computer users are familiar with creating tables (A) in Word or
Excel; or (B) ASCII tab-delimited or comma-delimited format.

If we make it easy for contributors, they will contribute lots of good
stuff.

Ed Poor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020802/46aa0eeb/attachment.htm


from_name: lcrocker at nupedia.com

body:
> A dumb/long list is nice because I can use my browser's text
> search on the titles listed in it; but the need for this would
> largely go away if I could search in Wikipedia: and User:.

That's coming soon.


subject: [Wikipedia-l] Parsing TeX

body:
>> The only thing that $$...$$ has over [[math:...]] is in the
>> situation of a very short formula like a single letter, and
>> there it's better to use <var> instead of a gif *anyway*.

> I disagree strongly. That would mean that if I have a formula
> with one letter variables and two letter variables the first
> would be written as <var> and the second as TeX within the same
> text. Always using LaTeX will look better and is more consistent.

Formulas should be seen as "inclusions", so I prefer the [[math:
syntax overall.  The software should look at the formula inside
the brackets, and choose how to output it.  In particular, if it
detects Mozilla it should output MATHML instead of calling TeX.
Maybe if it's just a variable name, it could just output a <var>.


from_name: Karen AKA Kajikit

subject: [Wikipedia-l] Year in Review Backwards

body:
Jeroen Heijmans wrote:
>
> Some time ago, I posted a question on the talk page of Year in Review,
> regarding the use of the Year in Review/Backwards pages, which are all
> orphan pages. I received one reaction (from Toby) voting for deletion
> after I put it on the votes for deletion page, but it was not deleted by
> any sysop. Now that I am one myself, I can do that, but I want to bring
> this topic to the attention for one last time. Unless I receive
> reactions, I'll delete the pages.

Personally i dont see any point to their existence... I'd say go ahead a
nd delete them

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


subject: [Wikipedia-l] Parsing TeX

in_reply_to: <20020802075607.GA4335@math-lw-n02.ucr.edu>; from toby+wikipedia-l@math.ucr.edu on Fri, Aug 02, 2002 at 12:56:07AM -0700

body:
On Fri, Aug 02, 2002 at 12:56:07AM -0700, Toby Bartels wrote:
>
> (Contrary to popular opinion, I've never suggested $$x \leq y$$.

Sorry for that, I started that rumour, it seemed like a logical
generalization of your idea and as such not a bad suggestion.

> What I suggested was $$x$$?≤?$$y$$, which won't fool any TeXer
> into thinking that it's actual TeX; the markup is merely *inspired* by TeX.

I would not be so sure: $$ *is* LaTeX mark-up.

> The only thing that $$...$$ has over [[math:...]] is in the situation of a
> very short formula like a single letter, and there it's better to use
> <var> instead of a gif *anyway*.

I disagree strongly. That would mean that if I have a formula with one
letter variables and two letter variables the first would be written as
<var> and the second as TeX within the same text. Always using LaTeX will
look better and is more consistent.

-- Jan Hidders


from_name: Daniel Mayer

subject: [Wikipedia-l] 'Old Hands' -- spreading the power around

body:
Jimbo wrote:

>1. Not-logged-in -- you can edit pages, etc.,
>but you're penalized in some minor respects.
>The reason for this is that it's more productive
>for people to choose a consistent identity,
>rather than possibly having a different ip
>number every day.  And if you remember '24',
>it's a pain to have to refer to someone by a number.
>
>2.  Logged-in -- you can do anything that's not
>'royally destructive', i.e. anything that's not
>irreversible, EXCEPT edit some protected pages.
>Again, we like to keep the number of protected
>pages to a low level to just dissuade some of
>the more annoying and lame vandalism attempts,
>like putting spurting penis pictures on the homepage.
>
>3.  Old-hand/sysop -- should be granted in
>an apolitical manner based on being essentially
>"legit" -- sysops should be able to do a tiny
>number of destructive (irreversible) things,
>IF we need to have those abilities for some
>reason.  (For example, some kinds of deletes do
>need to be irreversible for legal reasons.)
>This status should be granted more or less
>automatically, and whatever privileges it give
>should, by strong social custom, NEVER be used
>"in anger", i.e. to "pull rank to win an argument".
>There are only technical reasons to even have
>such a status.

Perhaps I should expose my ulterior motive -- I want
to see an 'old hand' status established so that a
framework will be in place so that we can begin the
process of phasing-out "sysop" status -- maybe
entirely. This would be done by porting function after
function to 'old hands' as these functions become non-
irreversible and coded procedures are established to
handle these functions in the wiki way. Let me
explain:

The move feature used to be buggy, so it was limited
to a select few people for practical reasons. It isn't
buggy now so I would like to see this feature be
usable by anyone with an account older than 30 days
and who has edited more than 30 pages in the article
namespace (LDCs idea of having a valid email address
seems like a good additional requirement). The only
reason to have the 30/30 (or whatever) requirement is
because there is a bit of a learning curve about how
to use Wikipedia and what our policies and guidelines
are with article naming. And if somebody has been
around for more than 30 days and has edited more than
30 articles without running into serious trouble I
think it is reasonable to also allow them to edit the
main page and any policy pages that are protected
(actual policy changes would have to be done through
this list or its successor though).

Blocking IPs could eventually be ported to 'old hand'
too. Here is one possible way to do that: There could
be a warning feature, similar to some instant
messaging programs, where if a person is warned by
several 'old hands' within a certain amount of time
they will be blocked from editing for an amount of
time commensurate with the number and frequency of
warnings (there could be anti-warning function too to
negate unfair warnings -- all this should also be
logged). In this way Wikipedia will be watched 24
hours a day instead of being exposed at certain times
of day when sysops are not around. As it is, one sysop
blocks an IP which is highly personal to the person
being blocked -- thus potentially dangerous if the
blocked person is deranged and motivated. Even though
I don't use my real name in Wikipedia, I use it here.
It would be easy for any deranged maniac to find out
where I work starting with that information. I don't
like this situation.

Deletion, protection and promotion/demotion to from
user/'old hand' status could similarly be eventually
ported as these features become non-irreversible
and/or methods are developed for their collective use.
The above is just a set of initial ideas on how things
/might/ proceed. The details can be worked out for
each sysop feature as it is ported to 'old hands'.

In this way Wikipedia would be self-healing and
self-maintaining without having to have users of rare
and special rank.

I don't like being a cop and I don't like the fact
that we even have a quasi-Cabal -- that's why I want
to phase it out by eventually allowing the majority of
active, logged-in users to collectively perform
sysop-like functions (spreading the power around). But
this should be a slow process so that we can develop
procedures on how to perform sysop functions in a more
open and dare I say democratic manor that will not
hamper our success in the wiki way.

--mav

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] What a wiki table syntax needs to do to work with current table layouts

body:
JeLuF wrote:

>One of the tables I like in wikipedia is this one:
>http://www.wikipedia.com/wiki/Beryllium
>
>I think this is a very apropriate way to present the
information,
>some kind of fact sheet. tarquin's proposal needs to
get some
>kind of markup to mark the labels (which are then
rastered with
>background color according to selected skin).

Thank you. Although I think that particular
implementation is a bit fat -- it takes up nearly half
of the text area on low res screens. I am in fact far
more proud of the taxonomy tables that I helped
develop -- which use nested tables with invisible
borders, have embedded images, heading fill color and
a list in the final cell to make adding taxon group
members easy
(see: http://www.wikipedia.com/wiki/Typical_owl for an
example)

But here is the rub; any wiki syntax that is enacted
will need to have nested tables, the ability to have
embedded images, lists and heading color fill or I
won't be able to use or promote them for the element
articles, taxonomy tables or even the country tables
(I'm involved with all three projects and considering
helping with the US Presidents tables). The colors for
the elements and taxonomy tables have specific
meanings associated with them and the nested tables
are needed to present different types of information
(I guess this can be replicated without nesting, but
in HTML at least that requires a /more/ complicated
table).
In my view then, the goal of any wiki table mark-up
should be to recreate the typical owl table in the
most easy to learn and code wiki markup possible. The
details on how to do this are not as important to me
as the results.

--mav

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


from_name: Larry Olin Horn

subject: [Wikipedia-l] New wiki markup

references: <200208012219.g71MJAB32102@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Aug 01, 2002 at 03:19:10PM -0700

body:
Most of the suggestions are for a single solution
that handles both simple and complex table needs,
with the complex end of the scale being pretty messy,
no matter what the particular syntax.

Although this goes against the OneTrueWay to do anything,
I'd suggest having both a "simple table" markup and an
"extended table" markup.

The simple table would cover, I believe, many editors'
needs while keeping the syntax very easily editable by
anyone.

The extended table markup would only come into play where
the editor thought that formatting needs overrode easy
accessibility.

Simple Table: (view this with a fixed-width font, if possible)

">" in first physical column to indicate row
"|" to delimit table columns; doesn't have to start next to ">"
not ">" in first physical column indicates end of table

>       |  cell1    | cell2  |
>       |  cell3    | cell4  |

>   | new table | content here | another column |
>   | blah      |  blah        |     blah blah  |

*possibly*, let spaces around "|" indicate alignment:
     |left-aligned     |   (text touching only left bar)
     |    right-aligned|   (text touching only right bar)
     | centered        |   (white-space on both sides)

so editor could still align bars for good visual effect
in the edit box, w/o a lot of special alignment markers
to clutter up content

Extended Table:

(one of the complex schemes proposed or to be proposed)

loh


subject: [Wikipedia-l] New wiki markup

in_reply_to: <200208012219.g71MJAB32102@ross.bomis.com>; from lcrocker@nupedia.com on Thu, Aug 01, 2002 at 03:19:10PM -0700

body:
On Thu, Aug 01, 2002 at 03:19:10PM -0700, lcrocker at nupedia.com wrote:
> > What happens if somebody inserts a new table/figure? You renumber? And
> > the complexity step from doing no formatting to doing a little
> > formatting becomes relatively big.
>
> That's why I'm throwing the suggestion out there--to get feedback.

I know, but I think it is an inherent problem in your proposal. You can only
solve this by associating identifiers with different parts. But note that
you then have to associate these with not only figures and tables but also
rules of tables and even cells in tables. Think of the table of Elements, for
example. There is no way you can do that in an unobtrusive way and, again,
your approach would force people who want to do only a little formatting to
do cascading style sheets.

I also don't support your premisse that we need a lot of formatting for
beautiful articles. I write in LaTeX and it makes my articles look good
without me doing much formatting. Moreover, I see a few reasons why we don't
want a lot of formatting in Wikipedia: less formatting means (1) less
browser-dependency (2) a more consistent looks of pages and (3) less
problems when we export articles to other formats.

> I really hate MoinMoin syntax.  It's every bit as ugly and complex as
> HTML, without the benefits.

Any table markup that allows you to do some formatting is going to look
awful with all the bells and whistles. The advantage wrt. HTML is that
simple tables are going to look really simple, and having a mark-up for
tables that discourages a lot of formatting tricks may actually not be a bad
thing.

As far as Tarquin's proposal is concerend, I also like it, but it has the
inherent problem that you cannot do nested tables. For that you need to flag
the beginning and end of a table (or a table rule), that's why I made my
proposal.

> Let for formally solicit proposals: folks, give me a clean,
> unobtrusive, user interface for (1) specifying spans and divs in
> wikitext with class and/or id; (2) attaching a stylesheet to a page,
> and being able to edit it.

Ok. Since I hate to be only negative I thought a little about this. The
simplest I can come up with is something like:

  {<identifier>{ .... }}

which would define a DIV with class <identifier>. All definitions for this
identifier would then hold for things inside such a DIV, i.e., that's what
you prefix the rules with. So a table could look like (I'm choosing my
tablesyntax here, but any one would do):

{pres-tab{

[| '''President'''   | '''Instrument''' |]
[| Truman            | Piano            |]
[| Abe Lincoln       | Violin           |]

}}

You can also imagine special styles for table rules and even cells:

{pres-tab{

[| President   | Instrument       |]
{red-rule{
[| Truman  {green-cell{ | Piano }}  |]
}}
[| Abe Lincoln | Violin           |]

}}

It looks awful of course but you sometimes need stuff like that to do for
example the Elements table. Normal tables will look very simple, though.

You could even use it for colored fonts:

{redfont{ A♥ Q♥ 10♥ 5♥ 3♥ }}

or pretty much anything really.

Once you introduce such a style on a page there will be special links for
every style used in the page on the bottom of the edit page that lead to a
special style-edit page. It might also be intresting to introduce "global"
styles that can be used in all pages.

Of course this all looks very much like XML with a slightly different
notation. That is intentional.

-- Jan Hidders


from_name: Gareth Owen

body:
"Poor, Edmund W" <Edmund.W.Poor at abc.com> writes:

> So, why not encourage authors to upload any tabular information as a file?

Because that serves no-one any good.  It would suddenly become an absolute
PITA to make even minor changes to any tabular data.

> Then one of our vast programming staff can convert it.

In their copious free time, presumably...

> Many computer users are familiar with creating tables (A) in Word or
> Excel; or (B) ASCII tab-delimited or comma-delimited format.

But I'd imagine that few want to go through a download-edit-upload cycle for
every change.
--
Gareth Owen
"Wikipedia does rock.  By the count on the "brilliant prose" page, there
 are 14 not-bad articles so far" -- Larry Sanger (12 Jan 2001)


from_name: Jens Frank

body:
On Fri, Aug 02, 2002 at 12:21:22AM -0700, Toby Bartels wrote:
> Eclecticology wrote:
>
> >Tarquin wrote:
>
> >>Could the WatchList page be limited to a number of days like RecentChanges?
> >>Mine is getting rather long & it takes a while to generate.
> >>Maybe a truncated WatchList page could give a link to a complete
> >>watchlist which would be displayed as a dumb list with no dates &
> >>times of edits (which I presume is what causes the load on the server)
>
> >At the risk of being slightly sarcastic, wouldn't a better solution be
> >to edit your own WatchList to remove things that you no longer really
> >need to watch?
>
> No, I want a long Watchlist too, and I agree with Tarquin.
> I want to know if *any* of these pages is edited, however minorly,
> but I don't want to wait for them to load on the special page.
> For my money, adopting the format of other special pages,
> listing only the past 3 days or the past 30 edits by default,
> will be quite sufficient; no need for new formats like dumb lists.

The time is spent looking which pages have changed, not in formating
the list. (Despite you sitting on a very slow internet connection
and having to wait for the download).

Regards,

JeLuF


body:
> Here goes:
> [br=1,cs=0,al=r,cp=2||
> [al=c,bc=pink|                         ''Owls'''
|]
> [al=c| Northern spotted owl |]
> [al=c,bc=pink| '''[[Scientific classification]]''' |]
> [|
> [al=c||
> [| [[Kingdom (biology)|Kingdom]]: || [[Animalia]] |]
> [| [[Phylum]]: || [[Chordata]] |]

...

> [| a simple table || with two columns |]
> [| and two        || rows             |]

The more I think about it, the more I'm convinced that CSS is the way
to go.  It's not even a browser issue, really: browsers that can't
handle CSS probably can't handle the things it's being used for
anyway,
and by definition they lose no content, only style, so I think that's
fine.
Your table syntax is nice if we really need nested tables, so adding
my
style syntax (which requires relaxing the "start of line" requirement
a
bit to skip over style tags that precede elements), we get:

{species}
{pink}[| '''Owls''' |]
{cent}[| Northern spotted owl |]
{pink}[| '''[[Scientific classification]]''' |]
[|
[| [[Kingdom (biology}|Kingdom]]:   ||  [[Animalia]]   |]
[[ [[Phylum]]:                      ||  [[Chordata]]   |]

...

|]

And hopefully, the stylesheet that defines {species}, {pink} and
{cent}
can be re-used by all the articles on different species, and different
specialized stylesheets can be produced for things like elements if
needed.  And exactly the same syntax is used for images, lists,
headers,
and everything else.

{right}[[image:spottedowl.jpg]]

{nobullets}* Item
* Item
* {red Item}

{smaller}== Major heading ==

{roman}# Item
# Item

{quote
Long excerpt from book, indented and italicized...
}

...etc...

Of course, weaning wiki away from HTML will require a gentle
transition.


body:
On Friday 02 August 2002 14:44, Daniel Mayer wrote:
> Perhaps I should expose my ulterior motive -- I want
> to see an 'old hand' status established so that a
> framework will be in place so that we can begin the
> process of phasing-out "sysop" status -- maybe
> entirely. This would be done by porting function after
> function to 'old hands' as these functions become non-
> irreversible and coded procedures are established to
> handle these functions in the wiki way. Let me
> explain:
>
> The move feature used to be buggy, so it was limited
> to a select few people for practical reasons. It isn't
> buggy now so I would like to see this feature be
> usable by anyone with an account older than 30 days
> and who has edited more than 30 pages in the article
> namespace (LDCs idea of having a valid email address
> seems like a good additional requirement). The only
> reason to have the 30/30 (or whatever) requirement is
> because there is a bit of a learning curve about how
> to use Wikipedia and what our policies and guidelines
> are with article naming. And if somebody has been
> around for more than 30 days and has edited more than
> 30 articles without running into serious trouble I
> think it is reasonable to also allow them to edit the
> main page and any policy pages that are protected
> (actual policy changes would have to be done through
> this list or its successor though).
>
> Blocking IPs could eventually be ported to 'old hand'
> too. Here is one possible way to do that: There could
> be a warning feature, similar to some instant
> messaging programs, where if a person is warned by
> several 'old hands' within a certain amount of time
> they will be blocked from editing for an amount of
> time commensurate with the number and frequency of
> warnings (there could be anti-warning function too to
> negate unfair warnings -- all this should also be
> logged). In this way Wikipedia will be watched 24
> hours a day instead of being exposed at certain times
> of day when sysops are not around. As it is, one sysop
> blocks an IP which is highly personal to the person
> being blocked -- thus potentially dangerous if the
> blocked person is deranged and motivated. Even though
> I don't use my real name in Wikipedia, I use it here.
> It would be easy for any deranged maniac to find out
> where I work starting with that information. I don't
> like this situation.
>
> Deletion, protection and promotion/demotion to from
> user/'old hand' status could similarly be eventually
> ported as these features become non-irreversible
> and/or methods are developed for their collective use.
> The above is just a set of initial ideas on how things
> /might/ proceed. The details can be worked out for
> each sysop feature as it is ported to 'old hands'.

I don't think that sysop status should go away. I agree with the warning
idea. Here's what I think the hierarchy should be:
Not logged in: Can edit articles but cannot upload images.
Logged in: Can upload images. (Since not logged in users don't see the upload
page, it won't show up on search engines, and the junk upload problem should
go away.)
Old hand: Three different old hands together can block an IP address or a
user. Maybe three old hands voting to delete the same article, with no
intervening edits of the article, can delete it.
Sysop: Can block an IP or a user by himself. Can delete articles.

phma


body:
On Thu, Aug 01, 2002 at 04:05:56PM -0700, lcrocker at nupedia.com wrote:
> ><wiki table, center, thin line>
> >|{light blue} ^ '''Mailing label''' ^|/
> >|Name:         |John Doe             |/
> >|Address:      |2000 Main Street     |/
> >| Postal Code: |123456               |/
> ></wiki table>
>
> I don't like it at all.  Tarquin still has the best idea so far--it
> just needs to be fleshed out a bit.
>

One of the tables I like in wikipedia is this one:
http://www.wikipedia.com/wiki/Beryllium

I think this is a very apropriate way to present the information,
some kind of fact sheet. tarquin's proposal needs to get some
kind of markup to mark the labels (which are then rastered with
background color according to selected skin).

[[Table:Factsheet]]
||
|== General ==
||
| [[List of elements by name|Name]], [[List of elements by symbol|Symbol]], [[List of elements by number|Number]]
| Beryllium, Br, 4
||
| [[periodic table series|Series]]
| [[alkali earth metal]]s
||
|== Atomic ==
||

If inside a table, headers would be rendered as table headers, spanning the
whole table, changing the style of the field containing them.

I see no easy way for the embedded table used to render the 6-column layout at the
bottom of the table. Does one need this?

Regards,

JeLuF


body:
> I think the problem with this markup is that you only have
> an "open"-tag and can't nest them.

You can, I just didn't show any examples of that.  What I want to
do is have {xx some text} produce a SPAN, and
{xx
Some text
}
Produce a DIV, either or both of which can be nested if
necessary (though it should almost never be).  The shortcut
syntax {xx} just means "apply the class or ID to whatever
the next thing you encounter is", which may be a single word
of text, or a table, or a cell, or a list, or a header....

> How would you combine it, for example, to have a small label
> below the floating-right image?

Put 'em in a DIV:

{right
[[image:baldeagle.jpg]]

Caption
}

We'll have to do something about
, and we also need a way
to specify table captions and headers (you could then put the
image in a table with a caption if you preferred).

>Make it look wiki, I think this is similar to
>the way Jan Hidders proposed:
>
>>> [[image:spottedowl.jpg|Spotted owl]] >>

Right now that sets the ALT text.


from_name: wiki pedista

subject: [Wikipedia-l] t-shirt

body:
Long time ago there was a discussion about making a
few wikipedia t-shirts. Apparently the discussion
died.
I recently found a site called cafepress.com, which is
in the bussiness of printing and selling merchandise
with logos for organizations and individuals. There
is no initial charge, they have a "base price" that
is the amount they keep for each article sold,
and if the selling price is over that, the rest is for
organization or individual owner of the desing.
Maybe the fact that it could bring some revenue could
infuriate some. Probably the one that most profits is
cafepress.com itself.

Just thought you could like to know.

P.S. If a similar message appears, is because I sent
it
before subscribing (i used just to read the archive),
so its awaiting "moderator approval".
I guess they had to do that given the number of
extraneous mail that was giving received by the list.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com


subject: [Wikipedia-l] Parsing TeX

in_reply_to: <200208021605.g72G5rj06884@ross.bomis.com>; from lcrocker@nupedia.com on Fri, Aug 02, 2002 at 09:05:53AM -0700

body:
On Fri, Aug 02, 2002 at 09:05:53AM -0700, lcrocker at nupedia.com wrote:
>
> Formulas should be seen as "inclusions", so I prefer the [[math:
> syntax overall.

I believe that if you would ask those that type a lot of mathematics (I have
typed some, but not very much) they would prefer the short markup.

> The software should look at the formula inside
> the brackets, and choose how to output it.  In particular, if it
> detects Mozilla it should output MATHML instead of calling TeX.

That would be really great because on my mozilla the set-up of planetmath is
rendered worse than Konquerer and IE.

-- Jan Hidders


from_name: Sean Barrett

subject: [Wikipedia-l] Non-standard Wiki markup language

body:
If Wiki markup is so much better than HTML, why doesn't '''USS ''Ohio''
(SSBN-726)''' do the right thing?  I can't be the only one who ever
wants to embed an italicized word in a bold phrase.

I guess I'll be sticking to '''USS Ohio (SSBN-726) for my
articles' first lines.

--
 Sean Barrett     | I don't mind being in touch with reality,
 sean at epoptic.com | as long as I don't have to stay.


from_name: Matthew Woodcraft

subject: [Wikipedia-l] Advanced free linking

in_reply_to: <3D4ACF05.6040407@stud.tue.nl>; from j.heijmans@stud.tue.nl on Fri, Aug 02, 2002 at 08:27:17PM +0200

body:
On Fri, Aug 02, 2002 at 08:27:17PM +0200, Jeroen Heijmans wrote:
> I propose:
>
> * [[English] language]] --> [[English language|English]]
> * [[George W. [Bush]] --> [[George W. Bush|Bush]]
>
> the [ and ] are just an idea, I don't really care if another character
> would be used."

If this feature is wanted, I think another character would be good. As
it is, it would make the bracket-matching facilities present in most
decent text editors less useful.

-M-


subject: [Wikipedia-l] "N"-mark on new articles on Recent Changes

body:
> Is this a Bug or intended behaviour?

Neither, really.  It's inevitable behavior based on the
database layout, and would require a lot of work to change.
Write it up as a feature request, but it won't be high
priority.


from_name: Jeroen Heijmans

subject: [Wikipedia-l] Advanced free linking

body:
With all the talk about extending the Wiki-syntax, I'd like to post this
extension I proposed earlier on SourceForge
(http://sourceforge.net/tracker/index.php?func=detail&aid=586885&group_id=34373&atid=411195)
:

"To avoid piping, maybe we could use some features like the [[plural]]s
thing, which is rendered as [[plural|plurals]].

I propose:

* [[English] language]] --> [[English language|English]]
* [[George W. [Bush]] --> [[George W. Bush|Bush]]

the [ and ] are just an idea, I don't really care if another character
would be used."

I got positive reactions from Brion Vibber and Toby Bartels, who
proposed the additional extension of [[George ]W. [Bush]] --> [[George
Bush]].

Jeroen Heijmans


body:
> Why doesn't '''USS ''Ohio'' (SSBN-726)''' do the right thing?
> I can't be the only one who ever wants to embed an italicized
> word in a bold phrase...

You are indeed the first person to make any mention of this bug,
despite my many pleas for testing while the software was being
written.  Here's the page I used to test that function:

http://www.piclab.com/newwiki/wiki.phtml?title=Quote_testing

As you'll see, it's pretty extensive, but it missed your case.
I'll add your case now.


from_name: tarquin

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work with
 current table layouts

body:
Daniel Mayer wrote:

>But here is the rub; any wiki syntax that is enacted
>will need to have nested tables, the ability to have
>embedded images, lists and heading color fill
>To manage your subscription to this list, please go here:
>http://www.nupedia.com/mailman/listinfo/wikipedia-l
>
>
>
That nested sub-table on Owl could be done with some clever CSS, I
should think, with row-group setting no borders and some colspan properties.
Nesting images would be a case of letting the parser read a link to the
image inside the markup -- it would be expected to read '' and ''' so
not much extra there.
Colours and fills: CSS again.
If the format of that species table is always going to be the same --
same number of rows and columns, the CSS can set all those things. The
wiki markup just needs a way of identifying the table type:
[[table:species]].

If the sub-table part might need a different number of lines, then some
sort of marker within the table would be needed.
However, it would be better to have abstract markers, ie [[row:Genera]],
leaving the specifics of *what* the colour is, etc, for the
[[table:species]] page to define.

The potential problem with CSS is browser support. :-(


from_name: Jan Hidders

subject: [Wikipedia-l] Advanced free linking

in_reply_to: <20020802200926.A26370@chiark.greenend.org.uk>; from mattheww@chiark.greenend.org.uk on Fri, Aug 02, 2002 at 08:09:26PM +0100

body:
On Fri, Aug 02, 2002 at 08:09:26PM +0100, Matthew Woodcraft wrote:
> On Fri, Aug 02, 2002 at 08:27:17PM +0200, Jeroen Heijmans wrote:
> > I propose:
> >
> > * [[English] language]] --> [[English language|English]]
> > * [[George W. [Bush]] --> [[George W. Bush|Bush]]
> >
> > the [ and ] are just an idea, I don't really care if another character
> > would be used."
>
> If this feature is wanted, I think another character would be good. As
> it is, it would make the bracket-matching facilities present in most
> decent text editors less useful.

Perhaps curly braces arount the parts you don't want in the link name?:

 * [[English {language}]] --> [[English language|English]]
 * [[{George W.} Bush]] --> [[George W. Bush|Bush]]

You could then even exclude multiple parts from the link name.

-- Jan Hidders


body:
On Fri, Aug 02, 2002 at 12:27:19PM -0700, Daniel Mayer wrote:
>
> In my view then, the goal of any wiki table mark-up
> should be to recreate the typical owl table in the
> most easy to learn and code wiki markup possible. The
> details on how to do this are not as important to me
> as the results.

Here goes:

[br=1,cs=0,al=r,cp=2||
[al=c,bc=pink|                         ''Owls'''                   |]
[|                 [[image:Northern_Spotted_Owl.USFWS-thumb.jpg]]  |]
[al=c|                         Northern spotted owl                |]
[al=c,bc=pink|           '''[[Scientific classification]]'''       |]
[|
[al=c||
[|      [[Kingdom (biology)|Kingdom]]:      ||  [[Animalia]]       |]
[|      [[Phylum]]:                         ||  [[Chordata]]       |]
[|      [[Class (biology)|Class]]:          ||  [[Aves]]           |]
[|      [[Order (biology)|Order]]:          ||  '''Strigiformes''' |]
||]
|]
[al=c,bc=pink|      '''[[family (biology)|Families]]'''            |]
[|
[||
[|         [[Barn owl|Tytonidae]] - Barn owls                      |]
[|         [[Typical owl|Strigidae]] - Typical owls                |]
||]
|]
||]

Basic principles:
- [%arg%|| ... ||] indicates a table (can be omitted if no arguments)
- [%arg%| ... |] indicates a row, arguments hold for first cell
- |%arg%| indicates beginning of next cell, arguments hold for this cell

Arguments:
- table:
    al=align, bc=background-color, br=border, wd=width,
    cp=cellpadding, cs=cellspacing
- cell:
    al=align, bc=background-color, cs=col-span, rs=rowspan,
    va=valign, wd=width
- table rule:
    - no arguments -

It's lay-out independent so it can also be written Tarquin's cell-per-row
format. It may look quite complicated but a simple table still looks like
this:

[| a simple table || with two columns |]
[| and two        || rows             |]

and even nested tables don't need to be difficult:

[| first a row with a single line    |]
[|
[| then a   || nested table          |]
[| with two || lines and two columns |]
|]
[| and finally again a single line   |]

Any questions?

-- Jan Hidders


subject: [Wikipedia-l] Parsing TeX

body:
On Fri, Aug 02, 2002 at 07:28:29PM +0200, Jan Hidders wrote:
> On Fri, Aug 02, 2002 at 09:05:53AM -0700, lcrocker at nupedia.com wrote:
> >
> > Formulas should be seen as "inclusions", so I prefer the [[math:
> > syntax overall.
>
> I believe that if you would ask those that type a lot of mathematics (I have
> typed some, but not very much) they would prefer the short markup.

I'm not sure which to prefer yet:

- $\sum_{i=1}$ and $$\sum_{i=1}$$ render to different images in TeX, for
  a good reason: keep lines with inline math as small as possible.
  [[math: ]]-Syntax currently renders everything in $$ ... $$ but displays
  it inline. So to get a display-formula you would have to do something like

  :[[math:\sum_{i=1}]]

  which is not realy a display formula, since the HTML generated is a
  <BLOCKQUOTE> and not a <CENTER> of the formula,

- The namespace "math" makes it easy for the casual reader of the source
  to recognize that the character garbage to follow has something to do
  with mathematical markup. This schema can easily be expanded to provide
  more than just math markup, e.g. something like

    [[barchart:(1999,37) (2000,45) (2001,60)]]

  which would fit perfectly into [[image:, [[media:, [[math: ...

- This misuse of namespaces does not look very 'wiki'.
  $ ... $ and $$ ... $$ look more similar to ''...'' and '''...'''.

> > The software should look at the formula inside
> > the brackets, and choose how to output it.  In particular, if it
> > detects Mozilla it should output MATHML instead of calling TeX.
>
> That would be really great because on my mozilla the set-up of planetmath is
> rendered worse than Konquerer and IE.

I just took a look at MathML. May I assume that we are not wanting to write
MathML to enter formulas instead of something TeXish?

For those not familiar with MathML:

To render the formula $ (a+b)^2 $ you may take two different approaches in
MathML. Either describing the layout:

     <msup>
       <mfenced>
         <mi>a</mi>
         <mo>+</mo>
         <mi>b</mi>
       </mfenced>
       <mn>2</mn>
     </msup>

or descriping the content:

    <apply>
      <power/>
      <apply>
        <plus/>
        <ci>a</ci>
        <ci>b</ci>
      </apply>
      <cn>2</cn>
    </apply>

Awfull, isn't it?

Is there some efficient way to render LaTeX-formulas into MathML? I just found
some XSLT to render MathML into LaTeX, but not vice versa.

Regards,

JeLuF


subject: [Wikipedia-l] Sysop status

body:
On Thu, Aug 01, 2002 at 11:22:58PM +0100, tarquin wrote:
> Brion VIBBER wrote:
>
> >tarquin wrote:
> >
> >>Before I too jump on the application bandwagon ;) -- what can sysops
> >>do that mortals can't?
> >
> Could I have sysop status please?
> I'd like to be able to copy wiki text from the policy pages. I might
> also need to rename pages on Meta.
>
> ...
> BTW, didn't someone mention a while ago that the incidents of crossed
> wires between the US admins of the 'pedia and the people on the European
> versions were due in part to differences in culture -- the Europeans
> perceiving the Americans as a little brash and pushy?
> I have a funny feeling we've just seen that in action again here: the
> above message I sent earlier is, in British English a fairly direct
> request ;-)

This doesn't seem to be an american vs. european problem. As a German, I
wouldn't read it as a request for sysop status, too. Seems like you
just wanting to know what you are missing - to judge whether you
need it, perhaps.

Suddenly the old "can you tell me the time?" - "yes" -joke comes
to my mind ...

regards,

jeluf


body:
On Friday 02 August 2002 06:31 pm, JeLuF wrote:
> I'd prefer the styles to be named for content markup, not for layout.
> They most probably will be skin-dependend. So in Cologne Blue the
> header of the table will be a greyish blue, in standard skin it
> will be pink and in StarTrek skin there will be a yellow background
> image with round corners.

Oh no! Pink was chosen to be the color for animals. Lightgreen is for plants,
lightblue for fungi, lightgrey for bacteria and khaki for protists. On top of
that there are slightly different tables for phylums/divisions, classes,
orders, families, genera and species is even more different (see:
http://www.wikipedia.com/wiki/Sainfoin). So any markup will have to be
flexible. (the different heading colors for the elements tables signify which
chemical series the element is in. I've also been kicking around the idea of
having different heading colors for the countries articles too with each
continent represented by a unique color. We could even have different heading
fill colors for each political party for the presidents tables also...).

I will work on making taxonomy tables for each taxon of Sainfoin for examples
of each slightly different tables.

--mav


body:
On Fri, Aug 02, 2002 at 04:56:01PM -0700, lcrocker at nupedia.com wrote:
>
> > Here goes:
> > [br=1,cs=0,al=r,cp=2||
> > [al=c,bc=pink|                         ''Owls'''
> |]
> > [al=c| Northern spotted owl |]
> > [al=c,bc=pink| '''[[Scientific classification]]''' |]
> > [|
> > [al=c||
> > [| [[Kingdom (biology)|Kingdom]]: || [[Animalia]] |]
> > [| [[Phylum]]: || [[Chordata]] |]
>
> ...
>
> > [| a simple table || with two columns |]
> > [| and two        || rows             |]
>
>
> The more I think about it, the more I'm convinced that CSS is the way
> to go.  It's not even a browser issue, really: browsers that can't
> handle CSS probably can't handle the things it's being used for
> anyway,
> and by definition they lose no content, only style, so I think that's
> fine.
> Your table syntax is nice if we really need nested tables, so adding
> my
> style syntax (which requires relaxing the "start of line" requirement
> a
> bit to skip over style tags that precede elements), we get:
>
> {species}
> {pink}[| '''Owls''' |]
> {cent}[| Northern spotted owl |]
> {pink}[| '''[[Scientific classification]]''' |]
> [|
> [| [[Kingdom (biology}|Kingdom]]:   ||  [[Animalia]]   |]
> [[ [[Phylum]]:                      ||  [[Chordata]]   |]
>
> ...
>
> |]
>

I'd prefer the styles to be named for content markup, not for layout.
They most probably will be skin-dependend. So in Cologne Blue the
header of the table will be a greyish blue, in standard skin it
will be pink and in StarTrek skin there will be a yellow background
image with round corners. (Only examples, of course). So I think it
should read:

{species}
{header}[| '''Owls''' |]
{subheader}[| Northern spotted owl |]
{header}[| '''[[Scientific classification]]''' |]
[|
[| [[Kingdom (biology}|Kingdom]]:   ||  [[Animalia]]   |]
[[ [[Phylum]]:                      ||  [[Chordata]]   |]

...

|]

> And hopefully, the stylesheet that defines {species}, {pink} and
> {cent}
> can be re-used by all the articles on different species, and different
> specialized stylesheets can be produced for things like elements if
> needed.  And exactly the same syntax is used for images, lists,
> headers,
> and everything else.
>
> {right}[[image:spottedowl.jpg]]
>
> {nobullets}* Item
> * Item
> * {red Item}
>
> {smaller}== Major heading ==
>
> {roman}# Item
> # Item
>
> {quote
> Long excerpt from book, indented and italicized...
> }

I think the problem with this markup is that you only have
an "open"-tag and can't nest them.

How would you combine it, for example, to have a small label below the
floating-right image?

== 1 ==
{right}[[image:spottedowl.jpg]] ''Spotted owl''

would most probably render "spotted owl" in one line to the
right of the image.

== 2 ==
{right}[[image:spottedowl.jpg]]
 {center} ''Spotted owl''

comes to mind. But this might create very long lines, which is not
very readable.

== 3 ==
OTOH, nesting tags fastly makes us reinvent XML with something like
{right [[image:spottedowl.jpg]]

  {center ''Spotted owl''}
}

(Hmm, looks Lisp'ish ...)

== 4 ==
Not sure whether it can be done with CSS only or whether it would
require help from PHP:

{labeledfloating}[[image:spottedowl.jpg]] Spotted owl

rendering to

    Spotted owl

That is, the first word would be taken as an image, the
following as label to be centered below the image.

== 5 ==
Make it look wiki, I think this is similar to
the way Jan Hidders proposed:

>> [[image:spottedowl.jpg|Spotted owl]] >>

My favourite is still number 5 for floating images and to have
{style} only for tables.

Regards,

JeLuF


from_name: Jimmy Wales

subject: [Wikipedia-l] t-shirt

in_reply_to: <20020803020545.5956.qmail@web14804.mail.yahoo.com>; from wikipedista@yahoo.com on Fri, Aug 02, 2002 at 07:05:45PM -0700

body:
I have a giant stack of Nupedia tshirts and coffee mugs laying around
my house.  Perhaps if there's interest, I could send them out to
people at the cost of shipping.

Not that anyone here cares about Nupedia, of course.  :-)


body:
Hello,

at 19:04 server time  206.148.76.193 created a new article
Arnold Schoenberg. On Recent Changes it was marked with
a bold N as a new article.

Since the article had no markup, I edited it and saved it.
(19:12 server time). On Recent Changes, there is no "N"
anymore in front of the 19:04 change. On special:New_Pages
Arnold Schoenberg is not listed any more as a new article.

Is this a Bug or intended behaviour?

Regards,

JeLuF


from_name: koyaanisqatsi at nupedia.com

body:
I don't know CSS *at all*, and all this talk is well over my head.  I know HTML enough to make a table when need be, but if we have to change from HTML I would very much prefer we change to something I (and other people, who *don't* know HTML) can read.  In other words, something we in my high school physics class used to call "intuitively obvious."

cheers,

kq

Jan wrote (in part):
>It just doesn't feel very democratic to me
>if you divide our contributers in those that know CSS and therefore can do
>formatting and understand what the styles do, and those that don't. I admit
>that the fact that I don't know CSS very well may play a part here, but it
>also shows how high the threshold for doing formatting would become.
>
>-- Jan Hidders


from_name: The Cunctator

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work
	with current table layouts

body:
On 8/3/02 8:00 AM, "koyaanisqatsi at nupedia.com" <koyaanisqatsi at nupedia.com>
wrote:

> I don't know CSS *at all*, and all this talk is well over my head.  I know
> HTML enough to make a table when need be, but if we have to change from HTML I
> would very much prefer we change to something I (and other people, who *don't*
> know HTML) can read.  In other words, something we in my high school physics
> class used to call "intuitively obvious."
>
CSS + simple wiki markup covers 90% of what we want.

The trick is to follow the Perl philosophy (cribbed from Alan Kay) of making
simple tasks easy and complex ones possible.

1a. So we should implement some straightforward variant of the MoinMoin
table syntax, as suggested by others

[ a | b | c]
[ 1 | 2 | 3]

or

[| a | b | c |]
[| 1 | 2 | 3 |]

For those of you who don't know CSS, don't worry. It's very straightforward
(at least for simple things).

E.g.

td { background-color: red }

will make table cells red.

Or you can define classes, as such:
.species {background-color: red }

then  and
 will give you red table
cells and paragraphs respectively.

1b. We should also allow HTML tables for cases in which the Wiki markup
isn't sufficient (such as embedding tables within tables/complicated
rowspan/colspans). Over time the markup can be tweaked such that we don't
need the HTML.

2. I'd also recommend considering using

[table:] syntax instead of [[table:]]. Why use the double brackets if not
necessary? And it almost makes more sense to extend the URL syntax (e.g.
[http:],[mailto:],[ftp:] etc.) than the Wiki space.

3. So you might do something like:

[style: .species {background-color: red}]

[table:{class=species}]
[ a | b | c ]
[ 1 | 2 | 3 ]


in_reply_to: <200208022356.g72Nu1p30513@ross.bomis.com>; from lcrocker@nupedia.com on Fri, Aug 02, 2002 at 04:56:01PM -0700

body:
I don't know CSS really that well, so this may be a stupid question. Is it
possible in a style to set the border value of a table? I know it is
possible to draw a border *around* a table, or around the contents of a
cell, but the border itself?

-- Jan Hidders


body:
Daniel Mayer wrote:

>Oh no! Pink was chosen to be the color for animals. Lightgreen is for plants,
>lightblue for fungi, lightgrey for bacteria and khaki for protists. On top of
>that there are slightly different tables for phylums/divisions, classes,
>orders, families, genera and species is even more different (see:
>http://www.wikipedia.com/wiki/Sainfoin). So any markup will have to be
>flexible.
>
so:
{species_animal} for the whole table
{species_animal_name}
{species_animal_name}
{species_animal_header}

Jan wrote:
 > is it posible in a style to set the border value of a table?

http://www.w3.org/TR/REC-CSS2/tables.html


from_name: Brion Vibber

subject: [Wikipedia-l] Parsing TeX to MathML

body:
Jens Frank wrote:

>I took a deeper look at MathML today. One thing seems to be a showstopper
>in the Moment: For Mozilla to render the MathML extensions the page must
>have Content-Type "text/xml" instead of "text/html". But in XML many of
>our pages are not valid, e.g. a line break has to be coded as
 in
>XML instead of
 in HTML. Mozilla's parser will stop and create an
>error message as soon as it finds an unmatched tag like
.
>
All the more reason to wipe out HTML...

In the particular case of, eg
, it would be elementary to transform
them to
 when we find them. Other cases could be similarly dealt
with, to a degree (there's already limited logic to try to keep paired
tags matched); but it's still pretty likely that as long as we allow
HTML it'll be hard to guarantee that we can produce a well-formed XHTML
document from it.

Since the "correct" response to a malformed XML document is a rude error
message rather than graceful failure, that may not be someplace we want
to delve just yet.

-- brion vibber (brion @ pobox.com)


from_name: Julie Hofmann Kemp

subject: [Wikipedia-l] Old hands, sysops, etc.

body:
Hey all -- I just noticed I'd lost ability to block IP's -- not that I'd
used it at all -- just in the last few days, I think, because they were
there after the move -- I can still move and delete pages, etc.  Is this
a buggy thing, or part of the changes everybody's been discussing?  I'd
certainly like to have the option, if it's still there for us. THx.

Jules

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikimedia.org/pipermail/wikipedia-l/attachments/20020803/7d4ab9c3/attachment.htm


body:
tarquin wrote:

> so:
> {species_animal} for the whole table
> {species_animal_name}
> {species_animal_name}
> {species_animal_header}
>
but it would be evern *smarter* if {species_animal} *knew* that
* the 1st row was a header, and therefore shaded
* the 3rd row was a subheader, and therefore shaded,
* rows 4-6 are should have no horizontal border between them them (thus
simulating the subtable)
etc


subject: [Wikipedia-l] t-shirt

body:
Jimmy Wales wrote:

>I have a giant stack of Nupedia tshirts and coffee mugs laying around
>my house.  Perhaps if there's interest, I could send them out to
>people at the cost of shipping.
>
>Not that anyone here cares about Nupedia, of course.  :-)
>
Heck, I'd love one. What do you have in an extra-large? (For the
T-shirt, that is; I assume the mugs are one-size-fits-all.)

-- brion vibber (brion @ pobox.com)


subject: [Wikipedia-l] Parsing TeX

body:
On Sat, Aug 03, 2002 at 01:17:19AM +0200, Jens Frank wrote:
>
> - This misuse of namespaces does not look very 'wiki'.
>   $ ... $ and $$ ... $$ look more similar to ''...'' and '''...'''.

Yes, but $ is already commonly used, so you need a more rare combination
like [$ ... $] and [$$ ... $$]. That also brings across more the
include-aspect of the thing.

> I just took a look at MathML. May I assume that we are not wanting to write
> MathML to enter formulas instead of something TeXish?

Last time this was discussed most people felt that MathML was too hard to
read and write. There are already some packages to translate TeX to MathML.
See:

  http://www.webeq.com/mathml/resources.html

However, I don't know to what extent these are really "production ready".

-- Jan Hidders


subject: [Wikipedia-l] A different tables approach

body:
On 8/3/02 10:03 AM, "Jens Frank" <JeLuF at gmx.de> wrote:

> Some of the markup-phobics have some very valid points
> against the implementation of new tags. So let's take
> a look at a different approach:
>
> Make tables separate from the article. Don't embedd them
> into the text but just refer to them like you do with
> images. Similar to "upload a new image" we would add
> a "create a new table". First it would ask you for a name
> of the table and for the number of fields. (You can change
> them afterwards, it's just easier to create enough of them
> in the beginning)

Tables should be within the article...


subject:
[Wikipedia-l] What a wiki table syntax needs to do to work
	withcurrent table layouts

body:
A wiki markup that's simple but able to handle reasonably fancy tables by
employing stylesheets.

The complicated Sainfoin table (http://www.wikipedia.com/wiki/Sainfoin)
would be written as:

[[table:plant
[{                            Sainfoin                             }]
[|                [image: OnobrychisViciifolia-thumb.jpg]          |]
[{                  [[Scientific classification]]                  }]
[|                      [[table:classification
    [| [[Kingdom (biology)|Kingdom]]:   | [[Plantae]]          |]
    [| [[Division (biology)|Division]]: | [[Magnoliophyta]]    |]
    [| [[Class (biology)|Class]]:       | [[Magnoliopsida]]    |]
    [| [[Order (biology)|Order]]:       | [[Fabales]]          |]
    [| [[Family (biology)|Family]]:     | [[Fabaceae]]         |]
    [| [[Genus]]:                       | '''''Onobrychis''''' |]
    [| '''[[Species]]:'''               | '''''vicifolia'''''  |]
                                   ]]
|]
[{            [[Binomial nomenclature|Binomial name]]             }]
[|                  ''Onobrychis vicifolia''                      |]
]]

{ } is for th, | | is for td.

To explain, I'll use the reduced :

[[table:plant
[{        Sainfoin          }]
[| ''Onobrychis vicifolia'' |]
]]

would be rendered as

Sainfoin

Onobrychis vicifolia

In theory, we could write
       [[table:plant]]
[{        Sainfoin          }]
[| ''Onobrychis vicifolia'' |]

instead, by using a blank-line rule to determine when tables end. That looks
nicer and probably would be simpler to parse. But would be a bit less
flexible. Do we need that flexibility? Not necessarily.


message_id: <3D490DB800024067@mail.epost.de> (added by postmaster@mail.epost.de)

from_name: Magnus Manske

subject: [Wikipedia-l] Table markup

body:
IMHO, we should either create a simple wiki-style table markup and leave the complex tables to HTML, or enable the wiki-markup to do both, inevitable resulting in a more complicated markup.

For that, we will need a way to include attributes in tables, rows and cells, no matter if we use stylesheets or "inline" attributes.

My (general) proposal:
{attr|text}
where *text* can span multiple lines (in the source!), and can include nested {attr|text} constructs. The *attr* part is always optional.

Now, should we use that for tables only, or for div and span as well. In the former case, we could say
{{{ means table
{{ means row
{ means cell
which could look like
{{ {President} {Instrument} }}
with *all* HTML options available if needed, for each element:
{colspan=2 bgcolor=blue|President}

Or, we only use {{}}, with {{table|text}}, {{row|text}}, {{div|text}}, and *cell* as default. Looks like
{{table|
{{row| {{President}} {{Instrument}} }}
}}
Not very pretty, but with all options available, even nested tables etc.

Optionally, we can limit HTML attributes by using our own style:
{{table species|
using "style:species" as stylesheet, or
{{table, blue background, thin red border,centered|

Sorry for typos and not answering to other suggestions, but I am on vacation, typing on a PalmPilot...

Magnus


in_reply_to: <3D4B9800.8020304@planetunreal.com>; from tarquin@planetunreal.com on Sat, Aug 03, 2002 at 09:44:48AM +0100

body:
On Sat, Aug 03, 2002 at 09:44:48AM +0100, tarquin wrote:
> Jan wrote:
>  > is it posible in a style to set the border value of a table?
>
> http://www.w3.org/TR/REC-CSS2/tables.html

Thanks. But that's CSS2 specific, isn't it? That would not work on some old
Netscape browsers.

-- Jan Hidders


in_reply_to: <3D4B9C3F.6070104@planetunreal.com>; from tarquin@planetunreal.com on Sat, Aug 03, 2002 at 10:02:55AM +0100

body:
On Sat, Aug 03, 2002 at 10:02:55AM +0100, tarquin wrote:
> tarquin wrote:
>
> > so:
> > {species_animal} for the whole table
> > {species_animal_name}
> > {species_animal_name}
> > {species_animal_header}
> >
> but it would be evern *smarter* if {species_animal} *knew* that
> * the 1st row was a header, and therefore shaded
> * the 3rd row was a subheader, and therefore shaded,
> * rows 4-6 are should have no horizontal border between them them (thus
> simulating the subtable)
> etc

Yes it would. But it would also mean you could not know what happens when
you add rows (or columns) to the table if you don't know what the CSS style
says.

Apoligies if I'm too negative about this idea. It's a very powerful idea and
my heart jumps with joy at the thought that we can used it to get rid of
HTML completely. However, it's just that for my feeling it makes formatting
so complicated and untransparent. It just doesn't feel very democratic to me
if you divide our contributers in those that know CSS and therefore can do
formatting and understand what the styles do, and those that don't. I admit
that the fact that I don't know CSS very well may play a part here, but it
also shows how high the threshold for doing formatting would become.

-- Jan Hidders


body:
On Sat, Aug 03, 2002 at 11:29:32AM +0200, Jan Hidders wrote:
> On Sat, Aug 03, 2002 at 10:02:55AM +0100, tarquin wrote:
> > tarquin wrote:
> >
> > > so:
> > > {species_animal} for the whole table
> > > {species_animal_name}
> > > {species_animal_name}
> > > {species_animal_header}
> > >
> > but it would be evern *smarter* if {species_animal} *knew* that
> > * the 1st row was a header, and therefore shaded
> > * the 3rd row was a subheader, and therefore shaded,
> > * rows 4-6 are should have no horizontal border between them them (thus
> > simulating the subtable)
> > etc
>
> Yes it would. But it would also mean you could not know what happens when
> you add rows (or columns) to the table if you don't know what the CSS style
> says.
>
> Apoligies if I'm too negative about this idea. It's a very powerful idea and
> my heart jumps with joy at the thought that we can used it to get rid of
> HTML completely. However, it's just that for my feeling it makes formatting
> so complicated and untransparent. It just doesn't feel very democratic to me
> if you divide our contributers in those that know CSS and therefore can do
> formatting and understand what the styles do, and those that don't. I admit
> that the fact that I don't know CSS very well may play a part here, but it
> also shows how high the threshold for doing formatting would become.

Wikipedia is an encyclopedia. In every printed encyclopedia there are people
writing content and others doing a consistent, efficient, easy to use
layout. The efforts spent in redesigning Cologne Blue show how difficult
layout is.

If we include markup to e.g. directly manipulate the colour of the
table background or the floating of images it would be hard for skin
authors to provide a consistent look and feel. A markup by content
is always to be preferred.

I can't count the students sitting in front of me after having
visited the professor who told them to swap chapters 3 and 5
and to make chapter 7 a section in chapter 6. They layouted by
hand: To make a new chapter they wrote "5 Influence on global politics",
marked the text, selected "bold" and "18 point" from the menubar.
References were made by hand. Swapping chapters or just making
section titles be underlined was a nightmare. With content markup
and a separate mapping content->layout all these things are trivial
tasks to do.

We already have mainly content markup in wikipedia. "== Header ==" is
content markup. Using your preferences you may control whether
headers are numbered or not. This can't be achieved if we would
have used

{bold, 14 point}Header

to create headers.

Therefor, layouting the taxonomy tables should not just count paragraphs
but label them by content in my opinion.

There should be a simple, default table layout for simple tasks, and
a consistent style sheet aproach to add markup to the most often
used types of tables. The simple table should already have optional
style-tags available to achieve commonly used effects like a
header line spanning the whole table, rendered with a pleasant
background and a bold font, centered.

A common use of tables will be some fact-sheet, having two columns,
some headers, floating right of the prosa, e.g. on the
Beryllium page. This could be used for cities in the same way:

+-------------------------------+
|          Demoscopic           |
+---------------+---------------+
| Inhabitants:	| 600.000       |
+---------------+---------------+
| Male          | 304.000       |
+---------------+---------------+
| Female        | 296.000       |
+---------------+---------------+
| Under 18 years| 127.000       |
+---------------+---------------+
|           History             |
+---------------+---------------+
| Founded       | 1230          |
+---------------+---------------+
| City rights   | 1487          |
+---------------+---------------+

I wouldn't want to always remember which background to use for
a factsheet header. Content markup is much easier:

{{table:factsheet}}
||
|{header} Demoscopic
||
|Inhabitants |600.000
||
|Male        |304.000
||
|Female      |296.000

....

(Not sure whether this is a good way of table/style mixup, just
some pseudo-code to show the principle).

Having three or four of these standard table styles will probably cover
80% of all needed tables.

Regards,

JeLuF


body:
On Sat, Aug 03, 2002 at 12:53:31PM +0200, Jens Frank wrote:
>
> If we include markup to e.g. directly manipulate the colour of the
> table background or the floating of images it would be hard for skin
> authors to provide a consistent look and feel. A markup by content
> is always to be preferred.

No, not in this case. I would agree with you if this was a normal
encyclopedia or any other big document with a fixed set of writers, but in
the case of Wikipedia I don't think markup by content is the right way. The
problem with that is that you require the users to know what types of
content are defined and how they should be used.

However, WikiWiki is based on the fact that there is a very limited set of
markup that is fixed and easy to learn. Trying to understand what the
abstractions are that the creators of the styles had in mind may not be easy
for everybody. Moreover, since the styles would be editable the markup would
in some sense become a moving target.  You cannot get much unWikier than
that.

Have you noticed that Lee's proposal is starting to look more
and more like LaTeX with command redefinitions? I am really a big fan of
LaTeX and write all of my scientific work in it, (there markup by content is
a must-have) but I don't think it is a good markup language for Wikipedia.

> +-------------------------------+
> |          Demoscopic           |
> +---------------+---------------+
> | Inhabitants:  | 600.000       |
> +---------------+---------------+
> | Male          | 304.000       |
> +---------------+---------------+
> | Female        | 296.000       |
> +---------------+---------------+
> | Under 18 years| 127.000       |
> +---------------+---------------+
> |           History             |
> +---------------+---------------+
> | Founded       | 1230          |
> +---------------+---------------+
> | City rights   | 1487          |
> +---------------+---------------+

Say, that's also not a bad table markup syntax. :-)

> I wouldn't want to always remember which background to use for
> a factsheet header. Content markup is much easier:

You'd still have to look up which style exactly you would have to use. The
most easy way to do that is to go to the pages that are similar to your page.
Doing some cut & paste is then probably not beyond your capabilities. :-)

> Having three or four of these standard table styles will probably cover
> 80% of all needed tables.

Sure, maybe now, but what will happen in the future as Wikpedia grows and
the group of contributers will become bigger and more diverse? And then I'm
not even thinking of what will happen if we replace the other HTML stuff.

-- Jan Hidders, who never knew that keeping things simple could be so hard


subject:
[Wikipedia-l] What a wiki table syntax needs to do to work with
  current table layouts

body:
Karen AKA Kajikit wrote:

>It doesn't matter WHAT the actual
>coding is if the user can write [[table:taxonomy]] or [[table:elements]]
>or [[table:other]] or whatever at the top of their data and have that
>particular formatting applied to their basic table data.
>

Exactly. Using something like [[table:elements]] means that:
* the default stylesheet can have Mav's colours -- they're nice :)
* a stylesheet aimed at blind users can skip the colours, and apply
voice emphasis, for example
* a stylesheet for the colour blind or partially sighted can skip the
colours too and use text-underline for example
* further stylesheets can do something else

And people who want to write articles don't need to worry about getting
the colours right.

Something like [[table:city_information]] is easy on the user. You need
to look it up, the same way you look up naming conventions sometimes.
But once you have that, it guarantees that all pages that use it will
have the same look. (content is the most important thing -- but if we're
going to have formatting, it may as well be consistent)

Much as [[image:foo]] either points to the image file, or to a wiki page
with information on the image, so could [[table:something]] either
format the table, or point to a page where that set of styles can be
edited. (though I must confess, I really don't understand how [[image:]]
and [[media:]] links work.)


from_name: Hr. Daniel Mikkelsen

body:
On Sat, 3 Aug 2002, Daniel Mayer wrote:

> Oh no! Pink was chosen to be the color for animals. Lightgreen is for plants,
> lightblue for fungi, lightgrey for bacteria and khaki for protists. On top of
> that there are slightly different tables for phylums/divisions, classes,
> orders, families, genera and species is even more different (see:
> http://www.wikipedia.com/wiki/Sainfoin). So any markup will have to be
> flexible.

Is this really what we want? To have articles decide layout and colors? I think
this is a very scary development - this is the same thing that happened to the
web in the early days, and look where we are now! Next thing, we have
[[flash:fun.swf]]!

The beauty of Wikipedia is its content, and that this content is separate from
the form. If we start using tables for anything else than structuring content
(that is layout, coloring, etc.) we risk seriously f#!$"ng up later chances for
presenting the content in a new way.

To blind people, or having your cellphone read it out aloud. Printing, XLM,
etc. Information will be lost here if tables become too powerful, and start
being used for non-content purposes.

But won't a colorless place look boring? Deal with it! Wikipedia already looks
boring! Let someone make a flash front end one day, instead.

Aren't anyone else worried about these things?

-- Daniel


subject: [Wikipedia-l] The meta-tree

body:
hi all.
What I had in mind is vaguely starting to take shape -- maybe you can
now all get an idea of what I've been rambling about ;)

After trying "presentation conventions" and "content conventions" I've
decided to call the whole kaboodle the "Meta-Tree". (it's short and more
descriptive than the previous two names)

I've copied across the details of chemical elements and the tree of life
and a few others for starters. I still haven't worked out exactly how to
present everything on individual pages.
I would very much appreciate comments & suggestions.
If you know of any "Basic topic"  pages, or pages that set out
presentation ideas (like the one on French Departements -- but got that
one :)  that are hidden somewhere on the 'pedia, please feel free to
copy the refactor the contents into the tree somewhere.

The main way in is currently:
http://meta.wikipedia.com/wiki.phtml?title=Presentation_Conventions

I anticipate that in the polished version the old [[Naming Conventions]]
will still exist, and point into pages on the tree that add further
naming guidelines.
A master page of Wiki Projects would do the same.

tarquin

BTW, is there an easy way to link to meta- from main? If not, I'll
suggest [[meta:pagename]] and [[metatalk:paename]] on sourceforge


from_name: Kurt Jansson

subject: [Wikipedia-l] t-shirt

body:
Jimbo wrote:

> I have a giant stack of Nupedia tshirts and coffee mugs laying around
> my house.  Perhaps if there's interest, I could send them out to
> people at the cost of shipping.

"Buy one Wikipedia t-shirt and get five Nupedia t-shirts and ten coffee
mugs for free!" :-)

Kurt


subject: [Wikipedia-l] What a wiki table syntax needs to do to work withcurrent table layouts

body:
I just wanted to say, that I'm all on the side of the "keep it simple"
fraction. Someone (Hawking?) said, that with every math formula in a
book you loose half of your readers, or something like that. I think
with every new wiki tag we will loose a big amount of new editors (not
readers)!

The fraction of people coming to Wikipedia and not knowing (and not
wanting to know) the concept of a markup language is growing every day.
Especially older people are frightened to damage something on our site.
And the more the text they see in the article differs from the one in
the EditBox, the likelier it gets that they just hit the "back" button.
That's at least my experience in convincing people to take part in our
project.

> But won't a colorless place look boring? Deal with it! Wikipedia
already looks
> boring! Let someone make a flash front end one day, instead.

All those CSS ideas are interesting and attractive, but wouldn't it be
better to keep these things for the staff which creates the stable,
"just for readers" set of articles in one or two years?

I say, better loose some readers then loose some editors. And I think
this is even more true for the international Wikipedias.

Kurt


body:
On Sat, Aug 03, 2002 at 03:39:01PM +0200, Kurt Jansson wrote:
> I just wanted to say, that I'm all on the side of the "keep it simple"
> fraction. Someone (Hawking?) said, that with every math formula in a
> book you loose half of your readers, or something like that. I think
> with every new wiki tag we will loose a big amount of new editors (not
> readers)!
>
> The fraction of people coming to Wikipedia and not knowing (and not
> wanting to know) the concept of a markup language is growing every day.
> Especially older people are frightened to damage something on our site.
> And the more the text they see in the article differs from the one in
> the EditBox, the likelier it gets that they just hit the "back" button.
> That's at least my experience in convincing people to take part in our
> project.

Hi Kurt,

I totally aggree, it should stay simple to contribute. But at the moment
wikipedia develops in a bad direction. Take a look at

	http://www.wikipedia.com/w/wiki.phtml?title=Duesseldorf&action=edit

for an example of markup that even scares me (and I'm HTML-literate for
nearly 9 years).

This is the markup to be stopped.

Regards,

JeLuF


body:
Some of the markup-phobics have some very valid points
against the implementation of new tags. So let's take
a look at a different approach:

Make tables separate from the article. Don't embedd them
into the text but just refer to them like you do with
images. Similar to "upload a new image" we would add
a "create a new table". First it would ask you for a name
of the table and for the number of fields. (You can change
them afterwards, it's just easier to create enough of them
in the beginning)

Then it will show you a mask with an array of textareas
to enter the values of the table. Each Field would have
a few buttons attached to make it merge with the cell
to the right, left, below and above. And a button
to make a coloured background.

Between each row and column there is a small button to
add a new row/column. And above each column and
in front of each row there's a button to remove the
column/row.

Each cell of the table will accept all kinds of wiki
markup of course, so you can add images, links, etc to
any cell.

A Preview button will show the rendered table.

Perhaps one wants to show the merge-buttons only upon
request for keeping the display simple.

I'm not sure whether this will become a PITA to edit
a large amount of tables, and perhaps one would add an
alternative text-markup entry page to create a table
"the old way" for us keyboard junkies and mouse haters.

Those two table entry modes would have to be equivalent
and tables created by the one have to be editable using
the other method, of course.

Regards,

JeLuF


subject: [Wikipedia-l] Parsing TeX to MathML

body:
On Sat, Aug 03, 2002 at 10:05:58AM +0200, Jan Hidders wrote:
> On Sat, Aug 03, 2002 at 01:17:19AM +0200, Jens Frank wrote:
> >
> > - This misuse of namespaces does not look very 'wiki'.
> >   $ ... $ and $$ ... $$ look more similar to ''...'' and '''...'''.
>
> Yes, but $ is already commonly used, so you need a more rare combination
> like [$ ... $] and [$$ ... $$]. That also brings across more the
> include-aspect of the thing.
>
> > I just took a look at MathML. May I assume that we are not wanting to write
> > MathML to enter formulas instead of something TeXish?
>
> Last time this was discussed most people felt that MathML was too hard to
> read and write. There are already some packages to translate TeX to MathML.
> See:
>
>   http://www.webeq.com/mathml/resources.html
>
> However, I don't know to what extent these are really "production ready".

I took a deeper look at MathML today. One thing seems to be a showstopper
in the Moment: For Mozilla to render the MathML extensions the page must
have Content-Type "text/xml" instead of "text/html". But in XML many of
our pages are not valid, e.g. a line break has to be coded as
 in
XML instead of
 in HTML. Mozilla's parser will stop and create an
error message as soon as it finds an unmatched tag like
.

Regards,

JeLuF


from_name: Brion VIBBER

subject: [Wikipedia-l] Jon's pic.bmp

body:
Pierre Abbat wrote:
> Someone who has shell access to the server, please delete this. The image
> page doesn't show anything because of mishandling of the apostrophe; but the
> picture exists and is a mere spattering of blue dots on a red background.

Killed it.

 > It is in BMP format, which has no business being on the Web.

Amen to that!

-- brion vibber (brion @ pobox.com)


from_name: Pierre Abbat

subject: [Wikipedia-l] Jon's pic.bmp

body:
Someone who has shell access to the server, please delete this. The image
page doesn't show anything because of mishandling of the apostrophe; but the
picture exists and is a mere spattering of blue dots on a red background. It
is in BMP format, which has no business being on the Web.

phma


from_name: Daniel Mayer

body:
On Saturday 03 August 2002 07:45 am, JeLuF wrote:
> Make tables separate from the article. Don't embedd them
> into the text but just refer to them like you do with
> images. Similar to "upload a new image" we would add
> a "create a new table". First it would ask you for a name
> of the table and for the number of fields. (You can change
> them afterwards, it's just easier to create enough of them
> in the beginning)

Sounds interesting to me. No matter what markup we use the elements tables
will still be long and ugly in edit mode (the others are similar, but not as
bad). Need we expose everyone to this when they just want to correct my
spelling or do some much needed copyediting of my English? And how often does
the heat of vaporization of lithium change or any other property that is in
that table? Does that information need to be edited as often as the body
text?

If I did make a mistake in one of the tables or if the source of that info
was incorrect then somebody could click a link somewhere on the table to
access the wiki code for that table in a table:namespace (these people would
be more technically inclined to notice the error in the first place so won't
be as prone to mark-up-phobia). Then it really doesn't matter as much if the
table syntax isn't too easy on the eyes and this frees the text area of an
article for, golly, words and not markup.

But then, I'm interested in results not specifics and just about anything
proposed here would be better than raw HTML -- in or outside of any
table:namespace.

-- mav


subject: [Wikipedia-l] GNU FDL pictures?

body:
If I upload a picture and do not specify that I'm releasing it into the public domain (and so release it implicitly under the GNU FDL instead), can that picture be used only in works that are also GNU FDL?  Or could it be reused in traditional, copyrighted works such as newspapers?

What does the GNU FDL say about this, if anything?  What constitutes the article?  The text?  The image?  The layout?  All of the above?  Some of the above?

Is there any way to release pictures for reuse only in GNU FDL or GPL works (and not in copyrighted works such as e.g. <i>The New York Times</i>)?  Yes, I'm serious about that.

thanks,

kq


subject: [Wikipedia-l] GNU FDL pictures?

body:
koyaanisqatsi at nupedia.com wrote:
> If I upload a picture and do not specify that I'm releasing it into the public domain (and so release it implicitly under the GNU FDL instead), can that picture be used only in works that are also GNU FDL?  Or could it be reused in traditional, copyrighted works such as newspapers?
>
> What does the GNU FDL say about this, if anything?  What constitutes the article?  The text?  The image?  The layout?  All of the above?  Some of the above?

This could theoretically fall under section 7:

(snippet from http://www.gnu.org/copyleft/fdl.html)
-------------------------------------------------------------------------
7. AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and
independent documents or works, in or on a volume of a storage or
distribution medium, does not as a whole count as a Modified Version of
the Document, provided no compilation copyright is claimed for the
compilation. Such a compilation is called an "aggregate", and this
License does not apply to the other self-contained works thus compiled
with the Document, on account of their being thus compiled, if they are
not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies
of the Document, then if the Document is less than one quarter of the
entire aggregate, the Document's Cover Texts may be placed on covers
that surround only the Document within the aggregate. Otherwise they
must appear on covers around the whole aggregate.
-------------------------------------------------------------------------

But, IANAIPL. Note that if they use it, they will have to include a GFDL
license notice and URL to a machine-readable version (see section 4).

 > Is there any way to release pictures for reuse only in GNU FDL or GPL
 > works (and not in copyrighted works such as e.g. <i>The New York
 > Times</i>)?  Yes, I'm serious about that.

Depends on how well the NYT can get away with claiming that your picture
or article is just one of many things in their collection of documents,
the rest of which happen to be under their copyright...

-- brion vibber (brion @ pobox.com)


from_name: Karen AKA Kajikit

body:
koyaanisqatsi at nupedia.com wrote:
>
> I don't know CSS *at all*, and all this talk is well over my head.  I know HTML enough to make a table when need be, but if we have to change from HTML I would very much prefer we change to something I (and other people, who *don't* know HTML) can read.  In other words, something we in my high school physics class used to call "intuitively obvious."
>
> cheers,
>
> kq
>
> Jan wrote (in part):
> >It just doesn't feel very democratic to me
> >if you divide our contributers in those that know CSS and therefore can do
> >formatting and understand what the styles do, and those that don't. I admit
> >that the fact that I don't know CSS very well may play a part here, but it
> >also shows how high the threshold for doing formatting would become.

I know nothing about tables or syntax, and this whole discussion is
flying so far above my head that I'm basically ignoring it. But as the
bottom-end non-technological user, the basic proposal that was made to
start all this seems like the most usable.

If you want to include fancy colours and styles, and you want the
average user to be able to use them in a standardised way, then you
really need to preset the tables (eg the taxonomy table that's being
added to each animal/plant entry). It doesn't matter WHAT the actual
coding is if the user can write [[table:taxonomy]] or [[table:elements]]
or [[table:other]] or whatever at the top of their data and have that
particular formatting applied to their basic table data.

I liked the idea of using the dashes to deliniate cells and lines - it
makes something that is a lot more readable on the edit screen than an
html table...

--

Karen AKA Kajikit

And on the seventh day, God said 'What my world needs is a creature that
will truly appreciate it in all its facets' -
and so He made the kitten.

Come and visit my part of the web:
Kajikit's Corner: http://Kajikit.netfirms.com/
Aussie Support Mailing List: http://groups.yahoo.com/group/AussieSupport
Allergyfree Eating Recipe Swap:
http://groups.yahoo.com/group/Allergyfree_Eating
Ample Aussies Mailing List: http://groups.yahoo.com/group/ampleaussies/

Love and huggles to all!


list: wikitech-l

from_name: Tomasz Wegrzanowski

subject: [Wikitech-l] Why there is no rsync yet ?

body:
It should be easy to add, but it still hasn't been added.
If it's just because Jimbo is too busy, could he give some other
person access to Wikipedia server so that rsync can be set up ?

The fact that tarball is generated only once per day is serious
problem for topological analysis that must be done in Polish
Wikipedia to make optimal start page.


subject: [Wikipedia-l] Image text.

body:
Hr. Daniel Mikkelsen wrote:
> On the topic of transferring Wikipedia content to other media - is there a way
> of giving pictures descriptions in the context of an article? Since a picture
> can be used in several articles, the descriptions have to be part of each
> article (since what it represents might vary from context to context).
>
> Ideally, I'm looking for both an "alt"-text (to represent the picture when it's
> not possible to display it, like "a map of Germany") as well as a subtext,
> "Fig. 2. This diagram plots the growth of Wikipedia."
>
> Is this possible to do with the [Image:] tag?

You can set the alt-text when you use the image the same way you specify
different text than the article title for a text link:

   [[Image:Filename.png|Useful description, hopefully]]

-- brion vibber (brion @ pobox.com)


message_id: <3D147B050032079B@mail.epost.de> (added by postmaster@mail.epost.de)

subject:
[Wikipedia-l] What a wiki table syntax needs to do to work withcurrent
  table layouts

body:
"Hr. Daniel Mikkelsen" <daniel at copyleft.no> wrote:
---
>Is this really what we want? To have articles decide layout and colors? I think
>this is a very scary development - this is the same thing that happened to the
>web in the early days, and look where we are now! Next thing, we have
>[[flash:fun.swf]]!

IMHO, it is a Good Thing to have all articles within the same encyclopedia that deal with similar content to use similar layout. It would also help to develop a reputation as a source of knowledge, compared to a "random dump of factoids".

Of course, an editor can still use it as the latter, but there should be an easy way to make wikipedia look a little more "organized" than the whole web. After all, we apply our own standards on content, why not on style and layout as well, where it makes sense?

Magnus


subject:
[Wikipedia-l] What a wiki table syntax needs to do to work withcurrent
   table layouts

body:
>
>
>Another thing I already find quite upsetting is the tendency to use right
>aligned "floating" tables. What is the use of this? It disociates the table
>from the page, making it much more difficult for an alternate rendering agent
>to determine where to put it (when to read it out aloud, for instance).
>
>Okay, I notice I'm getting myself worked up here, so I'll stop. But please,
>can't you all see that this is the road to disaster?
>
I second the comment on right-aligned tables.
They force content that flows to the left of the table to be far too
narrow to read -- unless one widens the entire window, and then the
full-width content is too wide to read comfortably.

Tables should be within the flow as a block in their own right, likewise
images.

I'm tempted to add "powerpoint slide" to the "what wikipedia is not"
page ... :-)


body:
On Sunday 04 August 2002 11:27 am,  tarquin wrote:
> I second the comment on right-aligned tables.
> They force content that flows to the left of the table to be far too
> narrow to read -- unless one widens the entire window, and then the
> full-width content is too wide to read comfortably.
>
> Tables should be within the flow as a block in their own right, likewise
> images.

This simply won't work for long tables such as the elements tables of even
with shorter ones like the country pages. All that is needed is diligence in
not making these tables too wide. Granted the elements tables are a bit fat
and are at the maximum of tolerance for low res screens but the taxonomy
tables are not in the vast majority of cases.

Table content is important too and not having right justification will make
for unnecessarily long articles with hordes of whitespace. The same is true
for image justification. The result will  be a more disjointed article with
that will not have /any/ readability benefits in or out of edit mode.

--mav


subject:
[Wikipedia-l] What a wiki table syntax needs to do to work withcurrent
 table layouts

body:
Lars Aronsson wrote:
> One thing I never liked about HTML tables is that I have to mark both
> the beginning and the end of each cell, row, and table.

Actually, that's not true in HTML; the <table> tag is the only one that
has to be closed. A lot of people close the others out of habit (I think
some old version of Netscape broke on _nested_ tables if you didn't
close your rows and cells as well), but it's not necessary.

(XHTML, however, being XML would require you to close cells and rows as
well.)

-- brion vibber (brion @ pobox.com)