Last modified: 2014-04-29 05:10:33 UTC
Create a possibility to specify shared attributes for all cells in a given table column. For instance, it is now common to write something like {| | 1. | align="center" | foo |- | 2. | align="center" | bar |- | 3. | align="center" | foobar |} which is difficult to read if your table is large. However, in most cases, attributes are meant to be applied to every or almost every cell in a column. For instance, I propose something like this: {| = == align="center" | 1. | foo |- | 2. | bar |- | 3. | foobar |} The first space after = sign is meant to specify "no attributes for the first column". Then there goes specfication of align="center" attribute for all cells in the second column. Alternatively, one could write it like this: {| = = align="center" ... The syntax can likely be improved. Default attributes should be ovveridable by per-cell attributes. For instance, one can write sth. like this: {| = class="shadow" | 12 |- | 15 |- | 9 |- | class="bright" | 12000 |} It is not clear how default attributes should interfere in case there are colspan="N" cells in a row. For a beginning, simplest solution is to never apply defaults to rows where there is at least one cell spanning several columns. Alternatively (more difficult), default attributes would not apply to such cells, but would apply to non-colspan cells, with column number properly adjusted if needed. Advantages: - much easier reading (hence editing) of tables; - much easier change of look-and-feel per-column (e.g. easy to right-align a whole column, attach a background color to a column, etc.); - a little easier creation of tables or new rows (not much, because you can copy existing rows anyway). Disadvantages: - need to synchronize default-attributes-rows and the data rows; - more complications in table syntax. However, I don't see the disadvantages as being really significant. (The link is to today's featured article in en-wiki, illustrating how attributes are attached currently.)
I think that is were stylesheets come in handy. If you give a class to your table like this: {| class="alignCenter" ... and define that class in the Common.css like this: TABLE.alignCenter TR TD { text-align:center; } You have the effect you need.
Not really. With my proposal I can, for instance, highlight the first column with different background, center-align columns 2, 3 and 4 and right-align the last column, all in one table. With stylesheets, I'd end up with all cells centered, regardless of column.
Unless you use nth-child, but that's not really supported well enough yet and it mucks up with colspan, unfortunately.
Hm, I don't quite understand the last comment. What is nth-child and in which language? I propose to do this at rendering time, so as you currently transfere normal cell attributes from wiki source to HTML, you would do the same with default attributes, if there are any. Colspans are tricky, yes, but for the first stab default attributes could be ignored for all rows that contain at least one colspan cell.
Well, may be I'm too pessimistic about it, but I think if this was a common case and an important problem, there was already support for it in current/next version of CSS.
> "if this was a common case and an important problem" You can judge about whether it is a common case by how often identical attributes are assigned to all cells in a given column in Wikipedia. From my point of view, they are often enough. I think it is not implemented in CSS because: - almost no one write tables by hands: they are usually generated by CMS or other server-side script machinery; - it only makes sense if you could attach a class to a column (and to all cells in it), which are not even objects in HTML/XHTML; otherwise, doing it by index, you wouldn't be able to account for 3-column table on one page and 10-column table on the next one; - it is difficult to do really generically (not least because of colspans). In our case point one is not valid currently, because, though tables are not written in HTML in Wikipedia, you cannot generically define columns. And I propose to add syntax for that.
(In reply to comment #4) > Hm, I don't quite understand the last comment. What is nth-child and in which > language? It's CSS. (In reply to comment #5) > Well, may be I'm too pessimistic about it, but I think if this was a common > case and an important problem, there was already support for it in current/next > version of CSS. See <http://ln.hixie.ch/?start=1070385285&count=1>. It's quite awkward to do in the framework of CSS. It's a highly requested feature nevertheless (c.f. <https://bugzilla.mozilla.org/show_bug.cgi?id=915>) and something that probably has most people reading the standard for the first time scratching their heads (I know I didn't understand the problem at all until I read that blog I just linked to). But that's beside the point. This is related to bug 986.
Well, it seems that at present there is no robust way of implementing this in CSS. And given CSS-friendlinness of IE, there will be no way for some next five years, I bet. Moreover, I guess that if it becomes widely supported, Mediawiki engine would need to invent some syntax for COLs. I guess the proposed syntax can be used to explicitely (at rendering time) copy the default attributes to the relevant cells, and, later, be switched to just output COLs with default attributes. I mean, there should be some way of attaching default attributes to columns --- whether CSS-frienly (class="...") or more old-school HTML (align="center" valign="top".) Whether this attribues are explicitely copied by wiki engine to cells, or just set on table COLs and left for the browser to be applied to relevant cells is not important to article authors. (As long as the latter does indeed work and at least in 95% of all browser.)
*** This bug has been marked as a duplicate of bug 986 ***
<col> does not permit as much flexibility as this suggestion. In fact, it permits almost nothing to be modified, not even width, in CSS 2.1 (and nobody's started on CSS3 tables last I checked). Everything that bug 986 would do could be accomplished by this bug, however, although the HTML output would be different (longer in some cases). As I said, they're related, but they're not the same.
Any progress on this?
