User: Omegatron proposes that a new table editor should be written and that tables should be moved to their own Table: namespace, to keep the article wiki markup clean (you would type [[Table:World population|left]], like image markup, instead of putting the entire table inline).

This would make editing easier for the vast majority of people who don't understand code (either HTML or pipe syntax, which is really just a shortcut for HTML), in the spirit of the "easy to edit" wiki philosophy. If you like the idea, help flesh it out in the comments section, or code it, since I don't know how.

This would be beneficial because:

1. Large tables are annoying to work with while editing text. They clutter up the wiki markup. You have to scroll around them and it gets confusing and easy to get lost. They are definitely confusing for some newcomers. With taxoboxes they are often the first thing you see when editing an article! This is really ugly and bad for newcomers. This way you could link to them like images, with right and left floating tags, for instance, and edit them separately from the article. Also a single table could be used the same way as a template directly, instead of a table inside a template.
2. Editing tables is difficult in regular text editing mode. Especially large ones. A textarea-based table editing page could have non-wrapping text, for instance. It could have a list of the table elements displayed at the top for reference. Or even clickable like the special characters box at the bottom of the edit window.
3. Even better, it would allow an alternative paradigm of editing tables that is more in the spirit of easy-to-edit wikis. Less difficult to learn and hard to remember markup; more usability. The current table markup is harder to use than it needs to be. I am imagining a table of form cells that can each be edited individually, and the total number of cells chosen in another form box, a clickable box for spanning rows, etc. (See examples below) I just like the idea of each type of unit (image, table, template) having its own efficient editor functions and abilities. (Maybe this is related to some of the ideas that people had for m:SVG image support, of providing an edit window for each image that would allow people to change the XML directly and edit annotations and whatever.)
4. This could also have a simple parser to indicate when there is an error in the markup. There are often very bad errors in the table markup, which an HTML validator would find in a jiffy.

Tables, images, categories, and templates are all fundamentally different from articles, but only the latter three have their own namespaces. The others have their own specialized functionality, too, which I think the tables need.

Often it is very convenient to have "images" made up of a table of other images, for modularity and a consistent appearance. If Tables had their own namespace, these tables of images can be included in the article markup and framed like any regular image. This is useful for board game diagrams, sports team jerseys, any type of group of images that should appear together in one frame while still being separate images.

Some examples of modular images currently in use:

Air core	Iron core	Coil with tickler	Step down
Step up	Center tap (iron core)	Autotransformer

Transformers - Typical electrical configurations.
See standard symbols below.

More can be added to the image or the text can be changed without downloading and uploading a new image.

	a	b	c	d	e	f	g	h
8									8
7									7
6									6
5									5
4									4
3									3
2									2
1									1
	a	b	c	d	e	f	g	h

The chessboard is a perfect example of an image that is best generated by a table of other images.

Away colours

See also here, Template_talk:Float_begin

These are nonfunctional examples to show how the pages would be laid out, so you can "experience" it yourself.

The way it works currently, you see something like this:

• Normal article display

When you click "Edit this page", you get this:

• Normal article edit mode

This is not terribly newcomer-friendly, with lots of cryptic code and symbols. Even with pipe markup it is ugly and confusing.

With my proposal, you will see this (the only change is the "Edit this table" link, which will appear below every table):

• Article display with "Edit this table" link

If you then click "Edit this table", you will see the basic table editor, where you can change the wiki text in each cell (and in context!) without fear of screwing up the table markup (much easier for newcomers). (I think all we would need to implement this is to render the table normally, but replace everything inside <td></td> and <th></th> tags with a pre-filled input box. This seems very simple. Can you think of any situations that would break this?):

• Basic table editor

If you then click "Advanced mode", you will see the advanced table editor, which will allow you to configure any aspect of the table without entering invalid code and without being complicated to keep track of. (Note that this is rather half-baked compared to the basic editor):

• "Advanced" or "intermediate" table editor

(Preview mode of this might even include the above basic mode, or all three could be rolled into one page?)

If instead, you had clicked "Edit this page", you would end up at the standard article editor (though the textarea is not cluttered with table markup, just a simple [[Table:Bluejaytaxobox|right]]):

• Article edit page with proposed changes

And this page also has two links near the bottom to both the basic and advanced table editors for each table in the page.

The advanced table editor shown above is pretty unwieldy though and not very realistic (considering it would have to be configurable for every type of table markup possible, which I can't even think of how to do). Or we could limit wikipedia tables to a subset of the features of html tables. More likely and probably better, it would just be a standard article editor with some special table-editing features (no wrapping of text to allow cleaner code with whitespace and aligned tags, templates at the top to help get the markup correct with quotations around parameters, etc.) (in the example, the tags are html markup but i should have made them pipe markup. I forgot about that. Oh well; it's just a model.):

• Table markup or raw source editor

Right now I am leaning towards this instead of the above "advanced editor", which is complicated.

Note that the "Table markup editor" is an alternative to the "Advanced table editor". Which do you like better? Most seem to think both should be available.

• "Basic mode" example here.
• "Advanced mode" example here. It gets confusing fast, but with colors and more creative borders I think it could be made much more manageable than markup right in the article source. The checkboxes are for spanning cells, and could also be updated when you click the update button, refreshing the page with the affected cells merged into one. - Omegatron 19:13, Jan 21, 2005 (UTC)

This is intended to show a step-by-step process for implementation, with earlier parts not being dependent on later parts. This way we're not thrusting one single huge change on the developers and the users.

1. Create a Table: namespace with special properties (Step 1 has been entered as Feature request #2194. Note: A table namespace was created on the English Wikipedia in May 2007, without special properties. It was removed within a few days after objections.
   • What software changes, etc. would this require? Can we just start creating tables like Table:test?
   • Tables should be treated like images, with the same markup [[Table:test|right|framed|This is a test table]] and similar options:
     • Alignment floating left, floating right, top and bottom center, top and bottom left (none), or inline (no tag)
     • frame/framed option puts the same frame around the table, with the same gray line surrounding the entire table. This allows modular diagrams and the like. css will need to be updated a bit. (See Multiple images in one frame, Template talk:Float begin, Bugzilla #1729. Also see above for examples of table-based modular images in frames.)
     • alt/caption/title text should just go under the table like it would a regular image, which would be the necessary behavior for modular table-based images in frames. So you have the option of making a caption using the [[Table:test|caption here]] format or the <caption>caption here</caption> within the table itself, or both. Each has advantages for certain situations.
     • sizepx option makes no sense for tables
     • thumbnail option makes no sense for tables
   • All tables get an Edit this table or [ Edit ] link below them, equivalent to clicking on an image and going to the Image: page.
2. Implement the "Table markup editor"/"Raw source editor"
   • To implement this, we change the editor for articles in the Table: namespace:
     • Non-wrapping textarea
     • Templates at the top for commonly used table markup (similar to "Insert Á á É é" template at the bottom of normal edit windows)
3. Implement the "Basic table editor"
   • The basic editor simply renders the table normally, but replaces everything inside cell tags with an editable text box. This should not be too hard.
   • Both editor paradigms (basic rendered and raw markup) will link to each other, with changes updated in the process but without saving the page, like the preview button. So for instance, you can go to the raw markup editor, copy and paste a bunch of rows, and then go back to the basic editor to fill them in without getting lost in the markup or making mistakes.
   • After creating the basic editor, the Edit this table link will be changed to point to that instead.
4. Provide a button/link for a table markup checker? To check the table for errors before saving.
   • There are probably libraries available for this type of thing
5. Implement the "Advanced editor" or "Intermediate editor"
   • This needs a lot of fleshing-out and more thought before even thinking about implementing it.
   • Either ridiculously complicated and confusing with HTML or create a nice javascript editor that some people will hate because it's javascript

If you dislike some aspect of it, please suggest how you would like it better.

I (sort of :-) disagree with your suggestion of making a whole new namespace just for tables, but I do like the look of your tool: do you have a functional version yet or is it still at the design stage?. Maybe you might consider how to integrate it into the Mediawiki interface so that it could be called up for editing any page anywhere? --Phil | Talk 09:34, Jan 26, 2005 (UTC)

(Pertaining to "older examples".)

Well, images and templates and categories have their own namespaces, and each have their own specialized functionality. It makes sense to me that tables should have their own, too, since they are fundamentally different from articles. What concerns do you have about moving them to their own space?

How would this type of editor work with "any page anywhere"? It is only useful for tables, really, so you would have to code some kind of table editor into the regular editor... I don't really understand how that would work.

I don't know enough about html or php or whatever to code this. I will certainly help design it from a usability and visual standpoint, but I don't know how to program it. The example is just to show what I am imagining it would look like. - Omegatron 15:11, Jan 26, 2005 (UTC)

I don't really like the tool that much, but I like the idea of a namespace. Tables are a self-contained entity and should be treated as such. In books, tables are treated the same way as images. They should be treated similarly here. Of course, it's possible to get the same effect using a template, but that's really semantically incorrect for one-off tables. – flamurai^TM 15:23, Jan 26, 2005 (UTC)

What don't you like about the editor? I just think markup (pipe or html) is unnecessary, and should be circumvented for ease of use. - Omegatron 15:33, Jan 26, 2005 (UTC)

I also really like the idea of a namespace, with the table could be easily inserted by {{tablename)) -- not as intimidating for newbies, easier even for experienced editors who have to scroll past large tables to edit the rest of the text. I like the simple table editor a great deal -- the advanced could use some more work -- but that shouldn't be a stumbling block to the fundamental idea. Please continue to develop it and submit a feature request to bugzilla! Catherine\^talk 01:49, 28 Jan 2005 (UTC)

I was thinking [[Table:tablename|right]], as they are more like an image. What other options would it want, though? I guess nothing else about images is applicable. Maybe table size (width and height in px or percent) would be better indicated in the link than in the table markup itself? Maybe not.

Each table would need an Edit this table link at the bottom.

I will see what I can do with the advanced example... Anyone have ideas for making it powerful, yet easy to use? What features would it need? Maybe you could list some examples of tables currently in the wikipedia with weird/complicated markup to demonstrate the extremes that would challenge this idea? - Omegatron 04:01, Jan 28, 2005 (UTC)

I went through a lot of tables during the evolution of the MBTI article. The best solution is to make them a template and style them heavily with css. --Alterego 04:16, Jan 28, 2005 (UTC)

The best solution? Or just the best solution currently available? My proposal would make all tables behave as you suggested, but in their own namespace instead of as templates, with their own special functions like categories and images. - Omegatron 19:36, Jan 28, 2005 (UTC)

I really would love to have a table editor in Mediawiki. I am using the Mediawiki software for a variety of documentation applications. Many of these involve tables, and the unfortunately users mostly went back to shared Excel files for tables, due to the confusing markup of large Wiki tables.

Peter Franck Feb 11, 2005

That's a fantastic idea. -Grick 07:17, Feb 16, 2005 (UTC)

Agreed. I'd love to see this implemented. Tuf-Kat 02:41, Mar 2, 2005 (UTC)

I couldnt' figure out how to separate between these two in the advanced editor (sorry, I don't speak pipe):

<tr><td></td><td></td><td></td></tr>
<tr><td colspan="2"></td><td></td></tr>

and

<tr><td></td><td></td><td></td></tr>
<tr><td></td><td colspan="2"></td></tr>

Tables really are the most complex part of HTML. I wish luck to the attempt but it isn't an easy one. --EnSamulili 23:57, 17 Mar 2005 (UTC)

As I said, that bit is half-baked, but the spanning idea was to just click the checkboxes in between cells to indicate that the cells on either side of the checkbox were spanned.

See here

Clearly, if you can think of a more intuitive way, suggest it. Currently I'm just focusing on the simple editor with a slightly modified normal markup editor behind it (for "advanced mode", just a non-wrapping version with templates maybe), and the namespace. - Omegatron 06:09, Mar 18, 2005 (UTC)

How would a new namespace or using the editor affect some templates like this: Template:Taxobox ordo entry? (Better at questions than answers) --EnSamulili 16:32, 18 Mar 2005 (UTC)

*shrugs*  :-) The taxobox templates are an attempt to fix the same thing that this fixes. I don't know if one should overrule the other or if they should be combinable.. - Omegatron 16:59, Mar 21, 2005 (UTC)

I would like to see an option that allows people to edit the html/pipe syntax of the table directly. It sounds masochistic, but that's exactly what WordPerfect did. I'm sure editors would have their reasons to do so. Ingoolemo ^talk 2005 June 29 00:35 (UTC)

The current plan does include a raw source editor. I guess this page is getting so large it's confusing... :-\ - Omegatron June 29, 2005 18:09 (UTC)

If you like the idea, please vote for it on Mediazilla (but don't clutter up the comments) and tell others! Step 1 of the roadmap is Feature request #2194

Just to get an idea of how many like/dislike it. Please include reasons why you voted.

For those who think the wiki table markup itself should be changed, see m:Wiki markup tables for similar proposals that were made before the pipe markup was implemented. I agree that a change to the table markup might help streamline things, but I think my table editor solves a separate set of problems (ease of use to newcomers, ease of editing large tables, ...) Also the current pipe syntax was chosen for good reasons, and I think it's a pretty good solution. Most of the WYSIWYG proposals I have seen are not robust enough to handle spanning, large tables, markup within tables, and so on, which certainly have uses in the Wikipedia.

1. dustball - We badly need this
2. Omegatron - Of course. Reasons listed above.
3. AlbinoMonkey ^(Talk) - I think it's a very good idea
4. Tuf-Kat - This would be great.
5. Carrp - I'd like to see both of these ideas implemented.
6. Mgm|^(talk) Would rid the pedia of a lot of faulty coding.
7. Rmhermen 16:44, Mar 14, 2005 (UTC). And if not both at least the separate namespace, please.
8. r3m0t ^talk 09:17, Mar 17, 2005 (UTC) but please change the table editor to look reasonable. Javascript would be required here. Also, make all tables templates for taxoboxes.

   Make which table editor look reasonable?

   The "advanced" one? That one is not very fleshed out, as I said. Any suggestions on how to make it better? If it depended on javascript, we would still need to make some kind of alternative for people so that people who can't/won't use javascript can still modify the table at a fundamental level.

   What do you mean "make all tables templates for taxoboxes?" I am aware I was using a taxobox table for my example, and these are supposed to be replaced by templates, but even the long string of templates required kind of has the same problems. Hmmm... I guess the Table: namespace could have the templates as well? Not sure how this should be implemented... - Omegatron 19:30, Mar 17, 2005 (UTC)

   I meant... oh, never mind. It's already implemented. The ability to use any page as a template. As for the javascript, the none-javascript version would be the current table editor (i.e. wikisource), simple as that. r3m0t ^talk 19:02, Mar 19, 2005 (UTC)

   Yeah, that's a way. So:

Article page --*-> Edit text of article
               |             |
               |             V
               *-> Edit table with simple "fill in cells" editor
                                    |                    |
                                    V                    |
                   Javascript advanced editor            |(for javascript-haters)
                                |                        |
                                V                        V
                   Plain old wikisource editor except with non-wrapping and some templates maybe?

Or something. - Omegatron 22:21, Mar 19, 2005 (UTC)

1. Pekinensis 15:47, 17 Mar 2005 (UTC) Two good ideas.
2. --Davion 23:58, 17 Mar 2005 (UTC) That would be great !
3. Pro, Leopard 19:34, 22 Mar 2005 (UTC)
4. Looks good to me. Leonardo 04:14, 31 Mar 2005 (UTC)
5. Definately support this as per the diagram above, althought the "advanced" editor should be renamed "intermediate" and the wikiksource editor should be the "advanced" level. All levels should allow you to go directly to the other levels, automagically incorporating changes made in the level you're at (if possible). The Intermediate level needs better handling of spanning, e.g. how would you create the following table in it?

1. Thryduulf 14:15, 9 Apr 2005 (UTC)

   With the "intermediate" editor you click on the checkboxes to span cells, as I already explained to EnSamulili.  :-) I will rename sections as you said. I think the intermediate editor is the part that needs the most work, and for now we can work on the other bits and incorporate that after it's finished. - Omegatron 14:48, Apr 9, 2005 (UTC)

2. Absolutely. I imagine it will be a technical and server nightmare, but the amount of tabling I did as a newbie would have totally turned of a lesser man. We could really use this. →Iñgōlemo← ^talk 05:35, 2005 May 17 (UTC)

   Have you looked at the Roadmap above? I think the first four changes are relatively easy. It's the "advanced" editor that will be the nightmare to design and implement... We can operate without it for now, though, and just start implementing the first four. - Omegatron 14:03, May 17, 2005 (UTC)

3. This is a wonderful idea. -℘yrop (talk) 03:41, May 19, 2005 (UTC)
4. I hate tables in wikipedia right now, I'm all for a table editing tool. Although I feel it might be wise to coordinate this project with the WYSIWYG editor project . Jacoplane 01:06, 14 Jun 2005 (UTC)
5. –M^T Brilliant proposal.
6. It'd be nice to have the Table: namespace and possibly a table editor. Quinobi 2 July 2005 05:49 (UTC)
7. I strongly agree with the new namespace idea. I also agree with the table editor although I may want to still use html/pipe syntax rather than the editor. Borb 5 July 2005 19:40 (UTC)

   You would still be able to access the raw markup. This is part of the plan. See step 2 of the roadmap, for instance. - Omegatron July 5, 2005 21:41 (UTC)

8. 213.160.22.50 15:28, 14 July 2005 (UTC) I'd like the table editor - but yet another feature request might be to have predefined value lists here, which may get their values from other tables of the same type.[reply]

   I'm not sure what you mean. Something like Wikidata? I think that's a great idea, but not completely the same problem as this. - Omegatron 16:51, July 14, 2005 (UTC)

9. Count me in, I've had a very hard time learning pipe... --Hymyly^TC 19:21, 29 August 2005 (UTC)[reply]
10. I can't believe that the proposal is over a year old and no work has been done on it!--Piotr Konieczny aka Prokonsul Piotrus ^Talk 17:00, 24 May 2006 (UTC)[reply]
11. I like it. --Cyde↔Weys 19:45, 13 June 2006 (UTC)[reply]
12. Such a tool, though probably ridiculously hard to enact without going to Java, would be a powerful addition. An intuitive interface for table editing will make table editing a whole lot easier, especially for users who are allergic to code. I fully support this measure (but don't expect me to be able to code it). And yes, as he with many names said above, this is long overdue. --Ourai 12:27, 13 August 2006 (UTC)[reply]

1. For now. For technical reasons. And for I love to disagree ;) --EnSamulili 23:59, 17 Mar 2005 (UTC)

   Hooray for disagreement! - Omegatron 06:11, Mar 18, 2005 (UTC)

2. I like the idea of the namespace, but I strongly disagree with the editor. Some day, I'd like to do all of my Wiki editing through a non-web interface. Even if the editor were optional, I think we should come up with a better markup for tables than something with clunky HTML forms. (moved proposal to meta:Wiki markup tables) --Sean κ. ⇔ 19:39, 12 Apr 2005 (UTC)

   See the talk page for basically the same proposal.  :-) Should move it here I guess. I still think a simple "fill in the blanks" editor would be useful in spite of whatever simplified markup we use, pipe syntax or otherwise. - Omegatron 20:28, Apr 12, 2005 (UTC)

   I guess the issue I have with the editor is whether it's solving the right problem. If the problem is that it's too difficult to make large tables, I would say it solves the problem. But I don't think that most good articles should have large tables, and I don't think that's the problem that needs to be addressed. I think the issue is, like you pointed out, simple tables like the taxonomy tables shouldn't have to use a sophisticated markup. If you took an inventory of Wikipedia, I'm guessing you would find that most tables don't really need to use column or row spans, and follow the format that I gave in my example. The point is that I don't feel the table editor solves that problem: I think it's too clunky for the basic tables we see in most articles. Sean κ. ⇔ 03:58, 13 Apr 2005 (UTC)

   1. I think the table editor addresses a different set of problems
   2. I think there are plenty of good reasons to keep a table formatting concept, as opposed to reducing it to logical structure, but maybe the logical structure mindset has its place too?
   3. Perhaps a simpler WYSIWYG markup could be implemented alongside the pipe markup for the simple tables? That is a discussion for another page, though. - Omegatron 14:27, Apr 13, 2005 (UTC)

3. I'm neutral about a new namespace but what I'm really against is an adavanced table editor. One of the reasons that I started to edit Wikiedpia was that it was not WYSIWYG, otherwise I don't think that I ever would have. While it might sound ok with an option to edit the raw code I don't think that the combination of manual editing and a GUI ever has worked well (not that I have seen at least). WYSIWIG generates crappy code and manual editors add things that the WYSIWYG editor doesn't understand. I'm not against changing the current syntax. It isn't terribly good or userfriendly but I don't think it is that easy to make somehting better. Jeltz talk 19:57, 25 May 2006 (UTC)[reply]

   In the future, the entire site will be WYSIWYG. See m:WYSIWYM editor. I don't see any reason why this shouldn't happen. This is a wiki; not a hacker convention. — Omegatron 02:52, 14 June 2006 (UTC)[reply]

1. grendel|khan - This doesn't justify introducing yet another namespace. 16:39, 2005 Mar 22 (UTC)

   What's wrong with another namespace? - Omegatron 17:31, Mar 22, 2005 (UTC)

1. (Diatribe bubbling on back burner.) This is a step in the right direction, but the UI needs an overhaul of greater scope. I would not try to work this into the engine now, but fold this Good Idea into the larger UI overhaul. — Xiong (talk) 13:44, 2005 Mar 23 (UTC)

   I'm in favor of realism.  :-) Let's focus on small changes at a time to get towards your ultimate goal. - Omegatron 19:07, Apr 7, 2005 (UTC)

I've been editing tables for a month since my last comment, and I agree that this is a burning issue. I'm still not sure it should be resolved alone. The engine is a terrible mess right now; many issues need to be overhauled in a similar way. The goal cannot be achieved by piecemeal stepwise refinement.

The quick-and-dirty fix for the problem is to create new tables on subpages, and transclude them into the main page. This helps not at all with editing tables, but at least keeps them out of the way of the novice who is editing the article proper. This also requires no development and can be implemented case-by-case by any user, now.

I appreciate the effort that has gone into this proposal and I think it is not wasted. It just needs to be joined up with similar overhauls and presented to the developer team with a large injection of Cash Money. — Xiong熊talk 16:27, 2005 Apr 24 (UTC)

I'm sorry, but I disagree. Please do not start unilaterally transcluding tables and giving my idea a bad name. The last thing I need is for this idea to get bound up and drowned in tranclusion politics.

There are instances where large tables have been moved to templates with no disagreement, like MBTI and... I can't find any other examples, though I'm sure a few exist. Regardless, we are not going to get this idea implemented or get any kind of consensus support by disrupting the status quo. I'm going to try to get in touch with the developers (how do I do that, anyway?) and write up some feature requests for the first things on the roadmap above. - Omegatron 13:59, May 17, 2005 (UTC)

Whatever is done, it should, if possible, address the rampant use of tables for layout (in infoboxes, etc.) by treating tables as semantic structures. Vagary 08:59, 24 May 2007 (UTC)[reply]

I agree, and have worked on this in the past, but I'm not sure what that has to do with this proposal. — Omegatron 13:54, 24 May 2007 (UTC)[reply]

• m:Wikidata - A proposal to create a database structure within wikipedia for storing tables of data
• m:Wiki markup tables - The original proposal for pipe markup, with alternatives

• HTML tables generator