Last modified: 2014-09-24 00:45:49 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 986 - [tables] Please implement COL, COLGROUP
[tables] Please implement COL, COLGROUP
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.24rc
All All
: Lowest enhancement with 19 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/wiki/Help_t...
: accessibility
: 418 2221 7956 44064 (view as bug list)
Depends on:
Blocks: 10294 418 3156
  Show dependency treegraph
 
Reported: 2004-12-03 10:19 UTC by Peter Gervai (grin)
Modified: 2014-09-24 00:45 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Added the col and colgroup tags to allowable html for a start (342 bytes, patch)
2005-01-06 08:01 UTC, Michael Favia
Details
adds col functionality to wikitables via / syntax (826 bytes, patch)
2005-03-30 10:37 UTC, IlyaHaykinson
Details
wikitable syntax functionality for slashes (826 bytes, patch)
2005-03-30 10:39 UTC, IlyaHaykinson
Details
Updated patch (631 bytes, patch)
2006-07-16 21:29 UTC, Aryeh Gregor (not reading bugmail, please e-mail directly)
Details

Description Peter Gervai (grin) 2004-12-03 10:19:42 UTC
See url.

1) please do not filter COL and COLGROUP tags

2) would be nice to implement its syntax, either the proposed one or else.
Comment 1 Michael Favia 2005-01-06 08:01:32 UTC
Created attachment 199 [details]
Added the col and colgroup tags to allowable html for a start

this just adds col and colgroup tags to let them through the filter. their
attribute list is already allowed above. next ill add it to wikimarkup if i can
get a consensus on what tag to use.
Comment 2 Michael Favia 2005-01-06 08:50:34 UTC
Please commit patch 1 if no issues are found. If interest still remains ill add
the wikimarkup section but others mentioned that a WYSIWYG editor to make things
easier.
Comment 3 Michael Favia 2005-01-21 07:16:13 UTC
Is there any reason this patch isn't getting applied? Is not formatted correctly
or is it not a desired functionality?
Comment 4 IlyaHaykinson 2005-03-30 10:37:18 UTC
Created attachment 395 [details]
adds col functionality to wikitables via / syntax

this only adds <col /> functionality via a /
Comment 5 IlyaHaykinson 2005-03-30 10:39:45 UTC
Created attachment 396 [details]
wikitable syntax functionality for slashes

(update to have the patch go the right way)
Comment 6 Ævar Arnfjörð Bjarmason 2005-05-16 04:31:11 UTC
Perhaps if you'd show us some practical examples where this tag can be used for
improving the layout of tables people would be more interested in applying it.
Comment 7 Zigger 2005-05-16 13:45:34 UTC
As one example, columnar markup would allow columns of integers to be aligned right 
with one HTML attribute instead of having to repeat it for every numeric cell on 
every row.

"... We will control the horizontal.  We will control the vertical. ..."
Comment 8 Gabriel de Perthuis 2005-05-22 19:19:23 UTC
I've made an attempt to a chess layout here, which uses the col tag (as well as
tbody and tfooter):
http://fr.wikipedia.org/wiki/Utilisateur:Argav/Echecs&action=edit
http://fr.wikipedia.org/wiki/Utilisateur:Argav/ModèleEchecs&action=edit

Comment 9 Brion Vibber 2005-05-22 23:27:15 UTC
*** Bug 2221 has been marked as a duplicate of this bug. ***
Comment 10 Brion Vibber 2005-07-10 23:05:23 UTC
These patches probably out of date with current Sanitizer.php and Parser.php.
Comment 11 Zigger 2005-08-17 00:37:08 UTC
(In reply to comment #7)
> As one example, columnar markup would allow columns of integers to be aligned
right 
> with one HTML attribute instead of having to repeat it for every numeric cell on 
> every row.

Unfortunately various browsers have some columnar layout limitations:

https://bugzilla.mozilla.org/show_bug.cgi?id=915
https://bugzilla.mozilla.org/show_bug.cgi?id=2212
Comment 12 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-04-09 02:53:10 UTC
(In reply to comment #6)
> Perhaps if you'd show us some practical examples where this tag can be used for
> improving the layout of tables people would be more interested in applying it.

I wish I could remember the specific instance, but I do distinctly recall once
trying to format something and thinking "damn, why doesn't <col> work?"  There
may have been some other way to do that, of course, whatever it was, since my
HTML skills are fairly modest.  But my understanding is that <col> is the only
way to format an entire column all at once, isn't it?  Otherwise you have to do
it cell-by-cell.
Comment 13 Minh Nguyễn 2006-04-09 03:53:47 UTC
For examples, just take a look most any table that contains columns of numbers;
this table at the [[Ohio]] article is one:

http://en.wikipedia.org/w/index.php?title=Ohio&action=edit&section=5

There's a lot of code there that needs to be copy-pasted for every single row,
and it's a bit daunting for the casual editor who just wants to edit the text
that comes after it. And there are *much* more convoluted tables around. I
suppose that's one of the reasons we have templates at Wikipedia, but sometimes
a template is overkill for a table that just needs all the numbers in one row
right-aligned.
Comment 14 Michael Zajac 2006-04-22 04:04:12 UTC
Any table which mixes columns of left-aligned headers or text, and columns of right-aligned numbers would benefit from 
this in greatly reducing the necessary mark-up, for starters. 
Comment 15 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-07-16 21:29:32 UTC
Created attachment 2114 [details]
Updated patch

Patch up-to-date as of r15698.
Comment 16 denelson83 2006-08-19 08:09:50 UTC
Implementing <colgroup> in table markup would be really handy for the Canadian
postal code lists, because it would allow me to compress the wiki markup in each
of those lists.
Comment 17 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-11-16 23:10:18 UTC
*** Bug 7956 has been marked as a duplicate of this bug. ***
Comment 18 Brion Vibber 2007-06-18 21:15:04 UTC
*** Bug 10294 has been marked as a duplicate of this bug. ***
Comment 19 Michael Zajac 2008-05-23 16:47:16 UTC
This is useful not only for formatting, but also to apply other attributes to table columns.  One application is to use a title to improve readability and accessibility for all readers, whether they use a visual browser, audible screen reader, text-only browser, etc., by .  

For example, in the very tall table at [[w:List of Cyrillic letters]], adding <col title="Russian alphabet">, etc,  would provide two benefits: 

* When scrolled down so that the column headers are invisible, would allow the reader to hover over any column to determine what it is.
* Even with headers visible, would give a larger hover target to expand the abbreviations (e.g. ru=Russian alphabet, be=Belarusian alphabet, etc.).
Comment 20 Happy-melon 2008-07-07 10:45:22 UTC
The discussion at http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=224097375#Tables:_How_to_define_alignment_for_an_entire_column.3F has an interesting idea for this bug. For as long as the <col> tag continues to have problems on major browsers, could we add something to the parser that interprets col tags as "copy the attributes manually to every cell in the column"? That would cause it to display correctly in all browsers, and allow wikicode simplification. Then, when the display issues with the raw tag are resolved satisfactorily, the alteration to the parser can be removed and the tag whitelisted; the syntax will then function fully and require no modification to in-situ wikitext.  I realise it's something of a hack, but it would provide useful functionality and be of a temporary nature. Just a thought... 
Comment 21 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-07 13:20:10 UTC
If that's done, we should definitely not use the names <col> and <colgroup>, because those would be expected to work like the HTML tags of the same name.  The current situation with <pre> is bad enough.
Comment 22 Happy-melon 2008-07-07 13:25:50 UTC
The point of the change (or 'hack' if you must :-D) *IS* to mimic the functionality of the <col> and <colgroup> tags, but in such a way as to not result in display issues on common browsers.  That way when said issues are resolved, we can enable the tags 'live' without anyone noticing that they are now being handled by the browser rather than the MediaWiki parser. 
Comment 23 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-07 13:51:37 UTC
The proposal would behave quite differently from actually outputting the <col> and <colgroup> tags.  CSS properties like color do *not* propagate from columns to table cells.  The only properties that apply to columns in CSS are border, background, width, and visibility:

http://www.w3.org/TR/CSS21/tables.html#columns
Comment 24 Happy-melon 2008-07-07 13:55:43 UTC
Then that's how the parser should behave - I quite agree that redefining the tags within a MediaWiki environment is a very Bad Idea. But even having that limited functionality work reliably within MediaWiki without having to wait for certain browsers to get their act together would be a positive development.
Comment 25 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-07 14:05:07 UTC
It's not possible to replicate the behavior of all those properties by propagating them to descendants.  They aren't actually inherited; they have an effect on the column, not the cells in the column.  For instance, just copying background properties from the column to the cells is incorrect, because column backgrounds are drawn under row backgrounds, while cell backgrounds are drawn over them.  It's not possible for MediaWiki to know whether there's a background on the row, since it could in the worst case be added dynamically after the page is served.

A slightly more practical solution would be to output the <col> and <colgroup> elements, but copy any align/valign attributes to table cells in the column (except if they already have align/valign manually specified).  This would behave as the HTML spec says in every way I can think of off-hand.  However, it would have practical problems: 

* We'd have to significantly improve table parsing.  Currently the parser doesn't keep track of columns; it has no reason to.  In fact it doesn't treat tables very differently from any other HTML.  It would have to be able to recognize and remember col and colgroup elements, keep track of when it's in the same table, identify colspan and other significant attributes, and so on, for HTML tables, wikitables, or any mix of them, all in accordance with the HTML spec.
* It would produce inconsistent behavior if table cells are altered after the page load with JavaScript or through other means.  This would make the behavior unreliable: it would fail for dynamically-adjusted tables, in certain browsers only.

There may be other problems as well.  I don't think it's practical.  Allowing <col> and <colgroup> for the purpose of border, background, width, and visibility might be moderately useful, but they aren't good for much else that I know of.
Comment 26 Happy-melon 2008-07-07 14:11:34 UTC
I see - probably too much of a pain to implement then for such a small gain. So I guess we'll just have to wait for browsers to improve the handling of the tags... see you in ten years time then :D

Mark as "LATER"???
Comment 27 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-07-07 14:15:31 UTC
As I said, it might be reasonable to permit them for the sake of the CSS properties that apply to them.  I don't see any remarkably good reason *not* to permit them.  Complexity of markup isn't much of a reason when we allow stuff like arbitrary inline styles.
Comment 28 Purodha Blissenbach 2008-07-18 08:58:43 UTC
Allowing table cell attribute to be set in on place rather than being repeated would bring tables back to work like the one in [[ksh:Wikipedia:Babel]] which were broken by the inclusion byte limit.
Comment 29 Yann Forget 2008-08-31 23:41:07 UTC
Here is a table where it would be useful: http://en.wikisource.org/w/index.php?title=Page:Rolland_Life_of_Tolstoy.djvu/13&oldid=756830
Please implement a solution for this.
Comment 30 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-08-31 23:52:35 UTC
(In reply to comment #29)
> Here is a table where it would be useful:
> http://en.wikisource.org/w/index.php?title=Page:Rolland_Life_of_Tolstoy.djvu/13&oldid=756830
> Please implement a solution for this.

What would you use it for there?  Remember that *align does not work for columns* on Firefox.
Comment 31 Paul Pogonyshev 2008-09-01 19:59:44 UTC
(In reply to comment #30)
> What would you use it for there?  Remember that *align does not work for
> columns* on Firefox.

Please have a look at bug 10294.  I believe that MediaWiki shouldn't be limited by limitations in HTML itself.  The point is, if something is not supported for columns, just have the HTML generator apply it to each cell automatically, instead of having users to copy it to each cell manually.
Comment 32 Happy-melon 2009-07-24 11:55:14 UTC
*** Bug 418 has been marked as a duplicate of this bug. ***
Comment 33 Sumana Harihareswara 2011-11-21 10:25:01 UTC
Comment on attachment 2114 [details]
Updated patch

Patch no longer cleanly applies.
Comment 34 Sumana Harihareswara 2011-11-21 10:26:00 UTC
Removing patch & need-review tags; most recent patch no longer applies to trunk, per http://lists.wikimedia.org/pipermail/wikitech-l/2011-November/056340.html .
Comment 35 Helder 2012-07-23 21:51:53 UTC
Any news on this subject?
Comment 36 Dereckson 2013-01-17 16:07:46 UTC
*** Bug 44064 has been marked as a duplicate of this bug. ***
Comment 37 Quim Gil 2014-04-29 05:22:28 UTC
Changing priority to Lowest because nobody is working or planning to work on this.

Browser support is still a red question mark for most <col> and <colgroup> theoretical features, according to 

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/col
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/colgroup

Seeing the deprecation tags and the lack of support, it doesn't look like you would want to make a long term bet on these tags, if they happen to solve any practical problem now. Anyway, just an opinion.

Wontfix?

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links