LDC wrote:
There's no provision for nested tables. I don't think
there's a good enough case for their necessity. Cell backgrounds and borders can be done with styles.
Well I and many other very hard-working Wikipedians think there is a very real need for nested tables. They are used in each these converted articles; organisms (that nested table has a border=0), countries, heads of state, elements, and sub-national entities. And this list doesn't include the many other
non-project related nested tables.
So if http://www.wikipedia.org/wiki/Beryllium cannot be replicated pretty much as-is in wikicode then I for will have a fit (I'm sure many others will join me).
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.
An alternative solution is to only allow HTML syntax to be rendered if it is in a table:namespace
page.
As I said before, I want to eliminate the complexity,
not just move it around. I want newbies to have some chance of being to edit the table as well as the prose around it.
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.
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
data (something we have a lot of). Thus putting this complexity on a separate page seems to be a good compromise between preventing newbies from not being intimidated by hordes of markup and allowing more seasoned users the ability to present tabular data in a table.
How the page functions for the reader is just as important as how it functions for the writer. And just
as different writers have different abilities to contribute prose to an article, we have different coders with different abilities to add markup to articles.
We don't dumb down the prose of articles to reach the lowest common denominator reader/writer (except for intro paragraphs) and we should not similarly dumb down the markup just to make things a bit easier for the lowest common denominator coder. Just segregate the tables from the prose and both the markup- phobic and the markup gurus will be happy (that's not to say that I advocate for full HTML support; just move the HTML off of the regular article page and into
its own namespace).
I would still like to know if a conversion script would be run. If not, then disabling HTML would make Wikipedia look badly broken with the displayed text of
tens of thousands of instances of HTML markup. And all
that would have to be re-coded in the new syntax by hand. If it is run then the script is going to mangle any table that has markup in it that is no supported in the proposed wikicode. Either way we are talking about changing masses of content that somebody
is going to have to repair.
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.
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.
-- Daniel Mayer (aka mav)
PS - We've seem to have done fine during the past 2+ years with tolerating HTML where it makes sense (such as tables).
__________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com
On Thu, 2003-05-15 at 16:00, Daniel Mayer wrote: [snip]
I would still like to know if a conversion script would be run.
[snip]
Of course there would be, just as there was a conversion for the replacement of subpages with the talk namespace, and a conversion for the replacement of direct-URL images with the local upload space and [[image:]] links.
Limiting / stripping / segregating HTML now will be a huuuuge advantage in the future, when HTML is replaced by QLZML and nothing supports HTML anymore and we still want people to be able to read and edit the 10 million articles in Wikipedia. Much better to clean up our act now with a clean, well-understood syntax than when the burden will be much much greater.
I leave issues of particular table syntax to those who are interested in such.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote in part:
Limiting / stripping / segregating HTML now will be a huuuuge advantage in the future, when HTML is replaced by QLZML and nothing supports HTML anymore and we still want people to be able to read and edit the 10 million articles in Wikipedia.
No one even today wants the current QLZML (that is, HTML 4 or XHTML 1). We don't even want all of HTML 2. As QLZML increases the potential vocabulary, we can decide for ourselves what, if anything, we want to include, and how. But we can decide now to accept <tt> and <table> forever -- always parsing them into whatever output markup language is current (*not* leaving them unparsed as we do today).
-- Toby
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.
wikipedia-l@lists.wikimedia.org