[Wikipedia-l] A vision for wiki syntax, documented

[Lee Daniel Crocker]

>> Yeah, that nested table is a nuisance. I'll have to
>> think about that.
 
> There are two nested tables; the obvious one in the 
> isotopes section and the navigation nested table in 
> the first cell of the larger table (which in turn has 
> an image embedded in it). Both are necessary to the 
> functioning of the table and are not a "nuisance" at 
> all. 

No, I meant it's a nuisance to come up with a way to do
it simply; yes, it's certainly useful.

> Do you have /any/ idea about how much work would be 
> undone and have to be redone in a diminished format if
> the document as is were implemented? Thousands of 
> pages will be broken and many users, including me, may
> get fed-up with Wikipedia and leave. 

I don't plan to break hundreds of pages. Yes, that would
be a bad thing. But I'm trying to plan long-range here.
The fact is, regardless of how much work went into those
pages, they don't work. They don't serve Wikipedia's
goal. They have to change eventually, hopefully gradually,
and hopefully with automated processes that don't throw
away the work that has been done.

If we can come up with a way to do what those tables do
in a way that's editable, and in a way that can be created
automatically from the existing code, everybody wins. It
may not be possible to do that, so we may have to figure
out some way to compromise, or change gradually, or allow
special-case exceptions. But I'm not going to just say
it's too hard and give up. Something great /can/ be done
here to fix these monsters.

> A table is going to be dense and intimidating to 
> nontechnical users no matter what but tables are very 
> useful when it comes to effectively presenting tabular

I don't buy that tables /have/ to be anywhere near as
complex as they are now. 

> How the page functions for the reader is just as 
> important as how it functions for the writer.
> as different writers have different abilities to 
> contribute prose to an article, we have different 
> coders with different abilities to add markup
> to articles. 

I agree; I still think it's possible to come up with
a method by which coders can create the table and newbies
can still edit the textual content of the table. I
refuse to believe it can't be done until I try to do it.

> Why in the world is it necessary to break so many 
> things and therefore create so much added work? The 
> negative side-effects of the proposed WikiSyntax will 
> cause far more problems than it purports to solve, IMO. 

Who said anything was going to be broken? Please don't
argue against something I never had any intention of
doing. That's why I called this syntax a "vision"--that's
what it is, a vision of what might be. Now is the time
to think of what the obstacles are and what the path
might look like. I appreciate your feedback, and I take
it seriously. 

> Please replicate in WikiCode the HTML we currently 
> support (well, maybe not the obscure stuff that is 
> hardly ever used) and/or create a table:namespace.

One thing that might happen is to add the new table
syntax while allowing TABLE, TR, TD, and TH tags, with
no attributes, and discourage their use except in
those rare cases like nested tables. Then if we figure
out a way to get the nested tables in too (perhaps
transclusion or a new markup), then we can phase those
out as well. The functions of attributes can all be
done with styles (colors, boders, etc.)

> PS - We've seem to have done fine during the past 2+
> years with tolerating HTML where it makes sense (such
> as tables).

I agree it's not a big problem, but it is a problem,
and it will only get bigger as more time passes.

-- 
Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC