Last modified: 2014-09-24 00:45:49 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.
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.
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.
Is there any reason this patch isn't getting applied? Is not formatted correctly or is it not a desired functionality?
Created attachment 395 [details] adds col functionality to wikitables via / syntax this only adds <col /> functionality via a /
Created attachment 396 [details] wikitable syntax functionality for slashes (update to have the patch go the right way)
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.
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. ..."
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
*** Bug 2221 has been marked as a duplicate of this bug. ***
These patches probably out of date with current Sanitizer.php and Parser.php.
(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
(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.
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.
Created attachment 2114 [details] Updated patch Patch up-to-date as of r15698.
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.
*** Bug 7956 has been marked as a duplicate of this bug. ***
*** Bug 10294 has been marked as a duplicate of this bug. ***
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.).
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...
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.
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.
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
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.
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.
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"???
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.
(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.
(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.
*** Bug 418 has been marked as a duplicate of this bug. ***
Comment on attachment 2114 [details] Updated patch Patch no longer cleanly applies.
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 .
Any news on this subject?
*** Bug 44064 has been marked as a duplicate of this bug. ***
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?
