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
Daniel Mayer wrote (much snipped):
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.
PS - We've seem to have done fine during the past 2+ years with tolerating HTML where it makes sense (such as tables).
I want to put myself on the record as mostly supporting Mav's view on this. I say this as a person whose knowledge of HTML can politely be described as "limited" I have done a little work on some of the tables, and that was a learning experience. If I worked on nested tables I didn't realize that I was doing it. On the [[Fidel Castro]] article I tried to figure out how to centre the caption under the picture of him hugging the Chinese premier. I didn't succeed and by default it's still left justified, but that's OK; that's consistent with the principle of leaving something undone, and someone feeling inspired to make such a minor adjustment will do it. I don't feel bad about my lack of success.
I've always avoided style sheets. They give me the feeling of somebody trying to force me into his way of presenting things, even when I agree that the style in question might be appropriate. Others will embrace style sheets, and that's fine too -- for them!
To me dumbing down means depriving people of their own challenges in life, and doing things for them that they should be doing for themselves. Mothers do this all the time when they compulsively pick up their children's things; the result is children who never learn to pick for themselves - much to the irritation of their eventual spouses. The educational component of Wikipedia is not just about content and the process of making that content satisfy NPOV. The same process can also apply to article stucture and markup. Need the Wiki vs. HTML dynamic be any different than the one about American vs. British English.
Most of our edits must be and are with wiki-markup. That's good. It serves most contributors well. If there is an option of using Wiki-markup or HTML to accomplish the same thing then Wiki-markup should definitely be preferred If someone has used HTML in an article where I am working I'll make the change (if I understand it) but I'm not going to whine and complain about somebody else's markup choice. It worked. Having options for how we treat less frequent events gives more room for growth.
Eclecticology
(Ray Saintonge saintonge@telus.net):
To me dumbing down means depriving people of their own challenges in life, and doing things for them that they should be doing for themselves. Mothers do this all the time when they compulsively pick up their children's things; the result is children who never learn to pick for themselves - much to the irritation of their eventual spouses. The educational component of Wikipedia is not just about content and the process of making that content satisfy NPOV. The same process can also apply to article stucture and markup. Need the Wiki vs. HTML dynamic be any different than the one about American vs. British English.
That's a good point. We probably don't want to limit the content model so much that people can't learn and grow to think in terms of document structure and presentation as well as content. So if putting in those more advanced structural elements is a little difficult, that's not such a bad thing. But disabling them entirely in the name of simplicity probably is.
Here's my main concern: I don't expect a newbie encountering a complex table to be able to edit the table without taking some time to learn what might be a complex syntax. But I /do/ want a newbie who sees a table with a misspelled word or an out-of-date statistic in it to be able to click edit, find the text with reasonable ease, and fix the text.
That's why including the table from another namespace is a total non-starter for me. When the newbie who clicks edit opens the page, he may see something simpler, but he still won't see the word he wanted to change, and he won't know how to get there, so we haven't solved the problem at all.
Here's another proposal for how we might handle more complex markup like nested tables:
In my current vision, this:
{{xxx text.... * list... text... }}
already creates a DIV block-level element in order to apply the style "xxx" to it, and
{{xxx Inline text...}}
similarly creates a SPAN. Let's (1) allow omitting the style tag altogether, so we can just create an anonymous DIV or SPAN, (2) make the parser keep a stack of open DIVs and SPANs, and allow elements to nest inside them, and (3) make tables usable at phrase-level like images (which they are in HTML anyway).
That way, the nested table looks like this:
||| === Title === | head1 | head2 | head3 | {{ || ==== Inner table ==== | cell | cell }} | cell | cell | cell
This would also allow you do things like putting paragraphs within list items, as well as nasty things like putting a table inside a list item, which gives me pause. Anyway, it's just another possibility. It does have the benefits that (1) all the text is visible as text, with no alphabetic markup to obscure it (with the exception of any style tags that might be added), and (2) the blank line terminates the structure, and line breaks terminate rows, so if a user screws up the effects will be limited.
wikipedia-l@lists.wikimedia.org