Last modified: 2014-04-29 05:10:33 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 10294 - shared attributes for wiki table syntax
shared attributes for wiki table syntax
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Low enhancement with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Norwich_...
:
Depends on: 986
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-17 11:32 UTC by Paul Pogonyshev
Modified: 2014-04-29 05:10 UTC (History)
5 users (show)

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


Attachments

Description Paul Pogonyshev 2007-06-17 11:32:44 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.)
Comment 1 Huji 2007-06-17 12:38:26 UTC
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.
Comment 2 Paul Pogonyshev 2007-06-17 12:45:40 UTC
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.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-17 19:41:52 UTC
Unless you use nth-child, but that's not really supported well enough yet and it mucks up with colspan, unfortunately.
Comment 4 Paul Pogonyshev 2007-06-17 21:10:08 UTC
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.
Comment 5 Huji 2007-06-17 22:10:05 UTC
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.
Comment 6 Paul Pogonyshev 2007-06-17 22:21:42 UTC
> "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.
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-18 00:34:48 UTC
(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.
Comment 8 Paul Pogonyshev 2007-06-18 20:59:42 UTC
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.)
Comment 9 Brion Vibber 2007-06-18 21:15:04 UTC

*** This bug has been marked as a duplicate of bug 986 ***
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-18 22:45:58 UTC
<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.
Comment 11 Helder 2012-07-23 21:52:04 UTC
Any progress on this?

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


Navigation
Links