See url.
Version: 1.24rc
Severity: enhancement
URL: http://meta.wikimedia.org/wiki/Help_talk:Table#Needs_to_implement_COL.2C_COLGROUP
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T12294 shared attributes for wiki table syntax | |||
| Open | Feature | None | T2418 Easier and better alignment within Wiki Tables | ||
| Open | None | T25932 Allow use of semantic HTML5 elements in wikitext | |||
| Open | Feature | None | T2986 [tables] Please implement COL, COLGROUP |
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
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.
michael.favia wrote:
Is there any reason this patch isn't getting applied? Is not formatted correctly
or is it not a desired functionality?
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
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
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.
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. ..."
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
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
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.
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§ion=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.
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.
ayg wrote:
Updated patch
Patch up-to-date as of r15698.
attachment 986.patch ignored as obsolete
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.
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:
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...
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.
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.
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:
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.
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:
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.
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"???
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.
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.
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.
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.
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.
sumanah wrote:
Comment on attachment 2114
Updated patch
Patch no longer cleanly applies.
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 .
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?
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.
/* * 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.
I apologyze for a banal question - is there any drawback to use Lua as a table generator (i.e. generating plain html)? Simply removing the filter for colgroup and col tags, any interested user could test this syntax - even if wiki markup can't output it.
a few predefined classes + whitelisted col/colgroup sounds like the right approach to me.
Ultimately might require the "Per template stylesheet" stuff (T483) that we have talked about for so long in order to truly make it manageable however.
@TheDJ I don't understand the significance of whitelisting components, but that would stem from my lack of understanding of why this hasn't progressed in time. I had presume complexity, or through history a lack of browser standardised response, though your response indicates other issues.
The Wikisources would truly benefit from the addition of the functionality,, especially to be able remove formatting bloat, and to improve the ease of table coding and formatting.
As the Wikisources try to apply similar style to their reproduced works, and has most of the larger works that we reproduce has tables of content, there are about ten major styles of ToC that we mimic. In 19thC works the ToC can progress for 5 or six pages, and needed to add padding, aligning to the right, or centring of text for each row is prone to error, and adds complexity to the coding.
Similarly we replicate published, complex tables, and with having to code by cell is entirely painful,. Happy to demonstrate with examples if that is helpful.
To have the ability to define table columns to have an text-alignment, border, padding, spacing would be my priorities.
In original task I opened (then merged into this one) I added only a project - wikisource - since wikisource is really, deeply different from any other wiki project dealing with formatting issues.
The other projects build a formatting standard for their pages, and the best solution is to write and apply a good shared css; wikisource is different, since its goal is to digitalize both the text and the formatting style of original editions, so it's impossible to avoid an heavy inline styling. So, I presume that wikisource feels a particular, high interest about colgroup and col tags, and IMHO the first, simple step could be to remove the filter for these two html tags - I imagine that this can be done easily; any change into wiki table markup could be deferred. So, my request is to split the task into two parts: the first one, with high priority, to remove the filter; the second one, with a lower priority, to edit wiki markup for tables.
Any idea if that will also make the display: attribute(s) table-column & table-column-group "valid & working" for 'faux tables' based on div tags under wiki mark-up?
I'd rather be able just to reproduce their expected behavior when using divs if "activating" COL & COLGROUP winds up being unfeasible or something here.
I'm pretty sure the lack of universal browser support for the more "exotic" table elements was the initial reason not to pursue this but I can see how coming up with a sane set of hash, slash &/or dash symbols to use under wiki mark-up also poses problems.
The Wikisources would truly benefit from the addition of the functionality,, especially to be able remove formatting bloat, and to improve the ease of table coding and formatting.
AGREED!
As the Wikisources try to apply similar style to their reproduced works, and as most of the larger works that we reproduce have tables of content, there are about ten major styles of ToC that we mimic. In 19thC works the ToC can progress for 5 or six pages, and needed to add padding, aligning to the right, or centring of text for each row is prone to error, and adds complexity to the coding.
This is where we part ways. It seems like once a year I try to get the point across that the table in table of contents is not to be taken literally (.e.g not an html table) -- most ToCs are just modified list-items (LI tags) with the item-marker at the end (to the right; typically the page number) rather than to the left of the item text itself as found with "normal" ordered or bulleted lists.
Since developing that kind of flexible list-item never took off - we've been doing the html table dance for ToCs ever since.
Similarly we replicate published, complex tables, and with having to code by cell is entirely painful,. Happy to demonstrate with examples if that is helpful.
100% agree
To have the ability to define table columns to have an text-alignment, border, padding, spacing would be my priorities.
Also agree - though this could have been much farther along by now through consensus driven .css class definitions and standardized template-ization practices.
I found into en.wikisource.org MediaWiki:Coltest.css a try to simulate COL tag by css. From the comment, the css trick is: "Format 1 cell and you've formatted the entire column". Nevertheless, I found that in many cases cell 1 has a different format from the other cells so that this css doesn't avoid the "old school COL tag". HTML5 uses a COL tag - simply deprecates the uses of old-school attributes and incourages css styling.
You found the test .css for a specific example used for testing purposes. It insured each column was formatted the same across several rows. See it at Wikisource:Style guide/Tables/Testbed. Please look at that example-table in edit mode to see that absolutely no table-row or table-cell inline styling was applied to achieve the desired uniform formatting per table-column; everything comes from the definitions found in en.wikisource.org's MediaWiki:Coltest.css
So you misunderstood the purpose -- It was originally created only to determine the lowest browser & version where all the formatting applied was being rendered properly (See HERE.
Bottom line is that you can use a combination of Css3 pseudo elements nth-child(an+b) and/or nth-of-type(an+b) to "mimic" any "traditional" COL & COLGROUP behavior through a well-defined group of .css definitions.
@brion, @TheDJ: Could someone quickly summarize why support for col and colgroup has never been implemented (despite it being requested for 11 years)? Is it lack of interest from developers? Browser support issues? High difficulty/complexity to implement? I tried to read though most of the discussion above, but most of it isn't directly related to the bug.
@kaldari 1) inertia 2) low desire to add more HTML tags ... I suspect this can be overcome if there's interest in Just Fixing It
Well that, and i think there was some doubts at some point about adding support for a single html table tag that would then be the only one that didn't have a corresponding wiki syntax equivalent.
Biggest problem i see, is that you need stylesheet definitions in order to do anything useful with these tags. You will need classes defined in Common.css if you want to be able to use it and have it actually do something useful. That's why i said that it probably requires T483 at some point to keep it manageable AND useful.
While full effectiveness may come from a new tag, the WSes do and can edit
their common.css files. As this is predominantly part of reproducing
published works, there may be scope for using the components within
proofread page extension and implementation, or even a centralised style
file at mulWS (or somewhere) which can be built under the auspices of the
community, and much of what we need will be usable xwiki. Doing this in
steps, would be acceptable, as two or three basic classes can have the
concept proved and start the declutter the inline formatting.
Dealing with complex tables formatting, most troubles come from borders, text-align and vertical-align, I see from col tag specifications that col tag can't assign the last two properties to cells.... so, col tag would not avoid the need of a cell-by-cell styling, faux tables having the same limitation. I didn't know this severe limitation when asking for col tag activation; by now, my interest much decreased. My apologies for your wasted time.
@Danny_B, is there a chance to have this with html5 convertion, or somewhen in the future? Thank you
Change 948593 had a related patch set uploaded (by Winston Sung; author: Winston Sung):
[mediawiki/core@master] Sanitizer: Update to HTML 5 and allow some elements