[tables] Please implement COL, COLGROUP
OpenPublic

Description

See url.

  1. please do not filter COL and COLGROUP tags
  1. would be nice to implement its syntax, either the proposed one or else.

Version: 1.24rc
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Help_talk:Table#Needs_to_implement_COL.2C_COLGROUP

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz986.
grin created this task.Via LegacyDec 3 2004, 10:19 AM
bzimport added a comment.Via ConduitJan 6 2005, 8:01 AM

michael.favia wrote:

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.

attachment colgroupPatch.txt ignored as obsolete

bzimport added a comment.Via ConduitJan 6 2005, 8:50 AM

michael.favia wrote:

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.

bzimport added a comment.Via ConduitJan 21 2005, 7:16 AM

michael.favia wrote:

Is there any reason this patch isn't getting applied? Is not formatted correctly
or is it not a desired functionality?

bzimport added a comment.Via ConduitMar 30 2005, 10:37 AM

mediazilla wrote:

adds col functionality to wikitables via / syntax

this only adds <col /> functionality via a /

attachment patch for slash-syntax for col element in wiki tables.txt ignored as obsolete

bzimport added a comment.Via ConduitMar 30 2005, 10:39 AM

mediazilla wrote:

wikitable syntax functionality for slashes

(update to have the patch go the right way)

attachment patch for slash-syntax for col element in wiki tables.txt ignored as obsolete

bzimport added a comment.Via ConduitMay 16 2005, 4:31 AM

avarab wrote:

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.

bzimport added a comment.Via ConduitMay 16 2005, 1:45 PM

zigger wrote:

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. ..."

bzimport added a comment.Via ConduitMay 22 2005, 7:19 PM

Gabriel.de-Perthuis wrote:

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

brion added a comment.Via ConduitMay 22 2005, 11:27 PM
  • Bug 2221 has been marked as a duplicate of this bug. ***
brion added a comment.Via ConduitJul 10 2005, 11:05 PM

These patches probably out of date with current Sanitizer.php and Parser.php.

bzimport added a comment.Via ConduitAug 17 2005, 12:37 AM

zigger wrote:

(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

bzimport added a comment.Via ConduitApr 9 2006, 2:53 AM

ayg wrote:

(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.

mxn added a comment.Via ConduitApr 9 2006, 3:53 AM

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.

bzimport added a comment.Via ConduitApr 22 2006, 4:04 AM

michael wrote:

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.

bzimport added a comment.Via ConduitJul 16 2006, 9:29 PM

ayg wrote:

Updated patch

Patch up-to-date as of r15698.

attachment 986.patch ignored as obsolete

bzimport added a comment.Via ConduitAug 19 2006, 8:09 AM

denelson83 wrote:

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.

bzimport added a comment.Via ConduitNov 16 2006, 11:10 PM

ayg wrote:

*** Bug 7956 has been marked as a duplicate of this bug. ***

brion added a comment.Via ConduitJun 18 2007, 9:15 PM
  • Bug 10294 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitMay 23 2008, 4:47 PM

michael wrote:

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.).
bzimport added a comment.Via ConduitJul 7 2008, 10:45 AM

happy_melon wrote:

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...

bzimport added a comment.Via ConduitJul 7 2008, 1:20 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitJul 7 2008, 1:25 PM

happy_melon wrote:

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.

bzimport added a comment.Via ConduitJul 7 2008, 1:51 PM

ayg wrote:

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

bzimport added a comment.Via ConduitJul 7 2008, 1:55 PM

happy_melon wrote:

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.

bzimport added a comment.Via ConduitJul 7 2008, 2:05 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitJul 7 2008, 2:11 PM

happy_melon wrote:

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"???

bzimport added a comment.Via ConduitJul 7 2008, 2:15 PM

ayg wrote:

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.

bzimport added a comment.Via ConduitJul 18 2008, 8:58 AM

bugzilla.wikimedia wrote:

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.

Yann added a comment.Via ConduitAug 31 2008, 11:41 PM

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.

bzimport added a comment.Via ConduitAug 31 2008, 11:52 PM

ayg wrote:

(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.

bzimport added a comment.Via ConduitSep 1 2008, 7:59 PM

pogonyshev wrote:

(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.

bzimport added a comment.Via ConduitJul 24 2009, 11:55 AM

happy.melon.wiki wrote:

*** Bug 418 has been marked as a duplicate of this bug. ***

bzimport added a comment.Via ConduitNov 21 2011, 10:25 AM

sumanah wrote:

Comment on attachment 2114
Updated patch

Patch no longer cleanly applies.

bzimport added a comment.Via ConduitNov 21 2011, 10:26 AM

sumanah wrote:

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 .

He7d3r added a comment.Via ConduitJul 23 2012, 9:51 PM

Any news on this subject?

Dereckson added a comment.Via ConduitJan 17 2013, 4:07 PM
  • Bug 44064 has been marked as a duplicate of this bug. ***
Qgil added a comment.Via ConduitApr 29 2014, 5:22 AM

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?

mxn added a subscriber: mxn.Via WebNov 24 2014, 8:51 PM
GOIII added a subscriber: GOIII.Via WebJan 4 2015, 9:19 PM

Man, this brought back all sorts of ''memories'' of how much I hated the wiki-mark up /parser thingy - and mostly for the exact same lack of COL reason. So much so that I got off my azz today after stumbling over this earlier and did something about it.

It seems CSS3 has provided us a possible substitute. Its not perfect but it will do the basics of padding, background, content alignment, vertical alignment and similar. And it seems most browsers (moving forward that is) support it -- familiarize yourselves with nth-child, nth-last-child, last-child, first-child, only-child and few other recent pseudo-classes.

COL tag we will miss you
/*
 *      First column of target table
 */
table.colTest > tr > td:nth-child(0n+1), table.colTest > * > tr > td:nth-child(0n+1) {
	display: table-cell;
	padding-right: 0.75em;
	padding-left: 0.75em;
	text-align: right;
	background-color: yellow;
}
/*
 *      All 'Even' numbered columns of target table
 */
table.colTest > tr > td:nth-child(even), table.colTest > * > tr > td:nth-child(even) {
	display: table-cell;
	padding-right: 0.75em;
	padding-left: 0.75em;
	text-align: right;
}
/*
 *      All 'Odd' numbered columns of target table
 */
table.colTest > tr > td:nth-child(odd), table.colTest > * > tr > td:nth-child(odd) {
	display: table-cell;
	padding-right: 0.75em;
	padding-left: 0.75em;
	text-align: right;
}
/*
 *      Last column of target table
 */
table.colTest > tr > td:nth-last-child(-n+1), table.colTest > * > tr > td:nth-last-child(-n+1) {
	display: table-cell;
	padding-right: 0.75em;
	padding-left: 0.75em;
	text-align: right;
	background-color: lime;
}

Basically, that's all it took for -=Bam=- one single solitary input (or set of inputs truth be told) resulting in All the cells targeted within a single column of a multi-column table getting formatted according to said input -- sounds like <COL> to me.

The downside being the fact that it is CSS reliant - not something the typical wiki-visitor knows how to use never mind have any worthwhile access for applying it.

Still -- one less text-align:right is one more minute of added living in my book.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.