UESPWiki:Archive/CP Table Formats

Table Formats

As part of the never-ending efforts to create a more uniform site appearance, I'd like to propose some changes to the CSS classes used to control format layouts.  We currently have two different classes that are widely used on the site, wikitable and greylapse.  (Technically, there are two more classes: prettytable is identical to wikitable, and graylapse is identical to greylapse).  Although there are slight differences between the classes, the names of the classes don't reflect what the differences really are, and more often than not one is chosen over the other based on individual editor's habits rather than based on actual differences between the table layouts.

What I think would be useful would be to first establish what really is preferred for a "standard" table layout on the site, and establish a single class to be used for that layout (perhaps wikitable, mainly just because that name is frequently used in the wikipedia documentation).  Then figure out what alternative types of table layouts are frequently needed and set up CSS code for those layouts, with layout names that make the layout's purpose a bit more obvious.

For those who can read CSS, the current definition of the tables can all be found at .  Or else some examples that all of us will find more intelligible:

;Wikitable

  This table shows the header colour for the original wikitable format that was in effect when this discussion was started.  The actual header colour has since been changed to match that used for the greylapse tables.

;Greylapse


The most apparent differences are:
The background color of the header boxes is different
Padding around the cells is somewhat larger in wikitable, as are the external margins around the table
Greylapse by default has valign=top set in every row
The headers are centered for wikitable, left-aligned for greylapse
For those wondering about the name, "grey" in greylapse I believe refers to the fact that the table borders are grey (a feature common to both table layouts), and "lapse" refers to the fact that borders collapse (again, common to both layouts).  So I don't think the "greylapse" name is particularly helpful in identifying what is useful or different about the layout.

I think it would be good to make an overall decision about what should be standard for some of the basic parameters.  Two such parameters that differ between these two layouts are the background color for header boxes and the amount of padding to use in tables.  I'd consider those to be parameters that should be fairly standard no matter how the table is being used, and therefore should be applied to all tables defined in the CSS files.  Personally, I think I prefer the header background colour from greylapse but the extra padding from wikitable, although I really don't have a strong opinion either way.

Other parameters, such as valign=top and alignment of headers probably depend more upon the purpose of the table.  In those cases, it seems like it would make sense to decide which alignments are desirable in the generic case.  And then figure out whether there are certain combinations that are frequently needed in other tables, and therefore should have CSS names.  Here I'd vote for the wikitable layout as the standard.  But I haven't looked into what other types of layouts we probably need (or are already using in various ways).

Any feedback?  Anyone who's willing to dig up examples of tables that need special treatment (ones that rely on one or the other of these layouts right now; or, ones that are using ugly amounts of manual overrides that could be achieved more elegantly using CSS; or, ones that look ugly right now and need to be reworked)? --Nephele  01:38, 14 November 2007 (EST)

:Personally, I would like to have the wikitable layout with greylapse color as standard. It's just a matter of personal taste, and I may prefer other formats on specific situations. One format that I think is quite common is to have all the table content centered. Also quite common is to center the whole table in the page. Another common style is to have the first column left-alinged and the rest centered. In any case, I think we should just create a few base formats from which other more complicated ones can be built upon, and not fall into the mistake of have a style for every different table we need. --DrPhoton 03:33, 14 November 2007 (EST)

::Yes, I agree that we don't want to try to come up with CSS tables to cover every single situation.  I was mainly thinking that I know there are cases where greylapse has been used instead of wikitable because of some of the formatting details (valign=top, for example), and wanted to provide better support for that.  Probably the options in the CSS tables should focus on some of the formatting aspects that are much easier to do in CSS... valign=top or other commands applied to every row being a good example.  But there are also some formatting options that can't be done more easily in CSS (first column left-aligned and the rest centered might be an example of that). --Nephele  13:46, 14 November 2007 (EST)

:Myself, I generally default to wikitable, but there are cases where I've switched to greylapse for a few specific reasons.  First, having the text top-aligned can be an advantage if you're going to be using Linkable Entries in the the table.  An example would be the  page.  When I had it as wikitable before, a link would bring you to a list, but half the list would be scrolled off the top of the page and you'd have to scroll it back down to see it all.  By having the titles with the linkable entries top-aligned, you now see the whole list when you link to an item on this page.  The other place I've been using greylapse is on Quest Stages sections on the Morrowind quest pages.  My main reason for this was that it conserves space, allowing you to see the whole table at once except in the most extreme cases.  When space isn't a premium, I generally go for wikitable instead.  I wouldn't mind changing them to be more similar (there's no reason for the header colors to be different, I think).  But eliminating one in favor of the other seems to be a bit hasty to me.
:Alternatively, we could change them so that they're even more different, in order to make them less redundant.  Maybe make greylapse have slightly smaller text or even thinner margins/padding, to further give it the advantage of fitting in tighter spaces (since that's what it's generally used for).  Maybe make wikitable entries all centered by default instead of just the headers?  (maybe not).  Maybe a third class that's right-aligned by default would be useful for things like item-pages where you want the weight, damage, defense, etc. values to all be on the right side so the digits line up.  Now a lot of this alignment stuff was made much easier by my  template, but I can still see an advantage to having classes that do this by default.  A name-change for the classes to make them more accurately descriptive isn't out of the question either.  (Keep the old names as duplicates, just so we don't have to change every table on the site, of course.)  --TheRealLurlock   15:25, 14 November 2007 (EST)

OK, I've started to experiment with how to implement things.  I'll give things a couple more days before starting to make global changes to how the existing tables work.  But here's what I'd suggest:
Change all tables on the site to class=wikitable (doesn't have to be done overnight, but that would be the long-term goal)
For tables that need other formatting options, add extra class options.  So to get a table similar to the existing greylapse, you could use class="wikitable compress vtop".  This allows editors to mix and match the options instead of forcing various options to always be combined.  The options I've created so far:
compress: reduces the padding in the table
vtop: sets valign=top for all rows and cells
firstleft: the first column of the table is left-aligned, the rest are centered.  (Note: this one uses a somewhat obscure CSS pseudoclass known as "first-child".  According to my CSS book, this feature is not recognized by IE6, so IE6 users will just see a center-aligned table.  I've confirmed however that it does work in firefox and IE7.  Also, this feature can only be used to make the first-column different from the others; no way to make column #4 special, for example).
Other options that have been suggested above can IMO be just as easily implemented as individual cases without the need to add hard-wired CSS code
To center the whole table, use align=center
To change overall text-alignment, use "style=text-align:center" or "style=text-align:left" (or use the Al template)

If nobody speaks up in a couple days I'll change the default header background on wikitables to be the #efefef colour currently used by greylapse tables.  Other than that, I'd say it's just a question of finding some willing volunteers to gradually go through the site and start phasing out all the old table classes (hint: do a search on "greylapse" or "graylapse" to find them).  --Nephele  13:15, 19 November 2007 (EST)

:I believe that the Greylapse COLOURS are much better, as they the wiki a more unique feel. However, I believe that the padding and centereed heading on the Wkitables should be implemented on the Greylapse tables. If I knew how to work table scripting, I would change them myself! (HMSVictory 12:06, 20 November 2007 (EST))

::Eh...Wouldn't it be easier to just change the colour of the wikitable header rather than the wikitable options on the greylapse? I've already started on making greylapse tables to wikitable ones. (Can't say I'm sure I have done it right, though.) Vesna 23:44, 20 November 2007 (EST)

:A few reactions so far - The new tables do work for the most part.  Some things I'd like to see changed though on the compressed tables.  (In descending order of how important the are to me.)
:*The captions are too high.  Greylapse captions are very close to the table, but wikitable compressed are much higher.  This spoils the association with the chart when several tables are used at once (as is the case with the Quest Stages on several pages).
:*Header text is center-aligned by default, while Greylapse was left-aligned.  Maybe I'm just not used to it, but I think the effect it has on Quest Stages tables is not a good one.  See: , compared to any quest page that hasn't been changed over yet.  When the table is just two columns, and the first is very narrow, it helps to have both column titles next to eachother, which you get from a left-align, but not from centered.
:*The header could stand to be a bit less compressed.  Right now it's about the same height as a regular row, while in Greylapse it was a bit taller.  I do get that the point is to be more compressed, but these look a little TOO compressed, maybe.
:*Now that I look at it, I agree with HMSVictory about the title colors from Greylapse.  Call me resistant to change, but I prefered the old color scheme to the wikitable one in some cases.
:I'm also not thrilled about the names for the new classes - they're longer, and have spaces in them, which requires you to use quotes, something that was previously only needed for sortable tables.  Not sure what to do about that, especially since people have already started changing these en masse - a step which I feel may have been a bit premature before getting community approval of the new classes.  (Also a job which presumably could be handled by a bot later on, but whatever.)  Anyhow, I'll stop being a curmudgeon for now and see what other people have to say about this.  --TheRealLurlock   00:29, 21 November 2007 (EST)

::Replying to Lurlock's points:
::*Captions look the same to me (I'm using IE7). See:  and . If you were referring to the tables above, those have no captions, and the spacing you see is the margin of each of the tables.
::*I personally prefer centered headings, but if left-aligned headers are necessary, that can be done with "style=text-align:left". Maybe, the class definitions can be tweaked such that it's not necessary to include it on every cell, but just on the row.
::*I agree that headers can be a bit higher.
::*Greylapse color is in general better for me, but in some cases it can be a bit too dark, especially when you have several title cells together. I would also provide a boackground color between that of the Greylapse and the page background (wikitable has too much pink for me).
::*Regarding the names, I don't think there's much we can do about the spaces, as the styles are built upon different classes, that are put together in that way. Having a different class for each combination would not be flexible/practical.
::I would also sugggest, as Lurlock, to stop any mass changeover until the classes and the way forward have been settled. --DrPhoton 03:45, 21 November 2007 (EST)

:::General clarification: my plan since the early stages of this discussion has been to change the wikitable background header colours over over to the graylapse colours.  This was based on the discussion here, and that's what I stated two days ago in my last update to this discussion.  The only reason I had held off on making that change was because I wanted to give everyone a couple more days to chime in with feedback on the decision.  However, based on the feedback that came in over the last couple days it seemed to me that (a) everyone wanted the darker (greylapse) colours for the headers (b) not making the change was leading to general confusion with everyone seeming to think that the wikitable header colours were being kept.  Therefore, I just went ahead and changed the wikitable header colours.  Sorry, DrPhoton, but I was working on this change as you made your last comment, and therefore I'd already made it before seeing your request for a moratorium on further changes.
:::Overall with the changes, my impression was that everyone was in agreement with making changes to the table formats, which is why I started implementing the changes.  And it still seems to me that everyone is in agreement with basic idea here, which is to standardize to a more uniform general table appearance and then have some variants for special cases.  There are specific details with the CSS settings needing to be tweaked and I'm sure more tweaks will continue to be needed.  However, the advantage of doing this with CSS is that it just needs to be done once in the CSS file and will apply everywhere, so I don't see why concerns about further tweaks mean that the entire project needs to be put on hold.
:::The only larger scale issue that appears to have been brought up is the names being used for the new classes.  I apologize for making a unilateral decision about the CSS names.  I thought that the most important issue here was the ultimate appearance of the pages to readers, and that there wouldn't be any reason for preferences in terms of whether the classes happened to be named "compress" or "compact" or whatever other class name someone might come up with.  Therefore I didn't realize that it would be necessary to go through a step of proposing the exact names to be used for the tables and waiting for community consensus on what, to me, seemed like a minor coding detail.  And I did not choose class names that contain spaces.  Rather, I chose to set up several different classes that can be combined in whatever way editors feel appropriate to obtain the desired format.  There is no class named "wikitable compress".  Rather there is a "wikitable" class and a "compress" class.  "compress" can be used by itself if someone wants, or it could be combined with any other class ("hiddentable compress", "prettytable compress", "greylapse compress", etc.); it exists independently of the wikitable class.  In my opinion, setting up the classes this way provides the most flexibility for editors.

:::As for specific formatting issues:
:::* Header spacing.  I made a mistake in the original vertical spacing for the compress class; I meant to make the vertical spacing identical to greylapse but determining what that spacing is in greylapse is far from trivial.  The vertical spacing has now been fixed.  DrPhoton: it's likely that by the time you looked at the examples, the spacing had already been fixed.
:::* Caption margins: I have adjusted the caption margins, both on wikitable and on compress.  While I was there, I also changed the captions to be bold-face by default.  Overall, I would like to find ways to make table captions look more "caption-like".  Right now I never use them because I think they look, frankly, ugly (they just look like out-of-place standard text, and do not in any way stand out as being a "title").
:::* Header alignment.  Changing one header to be left-aligned instead of center-aligned is something that I think is more appropriately done on individual tables as needed.  Unless you want to have a "queststage" table format, for example, that is set up to do all the formatting tweaks that apply to all quest stage tables.  But I don't think that left-aligned headers are something that should be packaged in with other formatting options, such as "compress" or "vtop" because it doesn't seem like there's any reason in general why those options should always go together.

:::I'm willing to delay any further changes to the tables.  Again, sorry DrPhoton for making more changes this evening, but I made them before seeing your request.  And given that some of the changes I made were to fix mistakes and others to fix obvious widespread confusion, I'm reluctant to just revert them all now.  But it would be helpful for me to get a bit more guidance on what exactly I've done that was not in agreement with the community consensus.  Also, I'm not clear how exactly people would like to proceed if tinkering with the layout is not acceptable: I doubt that we can come to a consensus without actually seeing the changes in action (and I'll be the first to admit that I am very likely to make mistakes when implementing any suggestions, so it's not too realistic to expect that the changes can be made all at once and never be tweaked again).  --Nephele  04:39, 21 November 2007 (EST)
::::I wasn't referring to your changes to the stylesheet (those can be undone with just one edit if need be), but to changes that have already been done to article pages, where "greylapse" has been changed over to "wikitable compress". In my opinion, we should refrrain ourselves from such changes until this discussion is sttled, or otherwise we may have to undo/redo a lot of edits to several different pages. --DrPhoton 08:33, 21 November 2007 (EST)
:::::Ouch. As one of the two or so people that's aimed at, I honestly thought there was a consensus. Until a few hours ago there wasn't a dissenting voice on this page. Anyway, in the light of more recent discussions I've stopped. I'm going to post in more detail on this later on, but for now I've already spent enough company time on the site today! --Rpeh  08:51, 21 November 2007 (EST)
::::::In Vensa's defense, I'd just like to say that she started changing articles because I asked her to.  And if I'd had any suspicion that were wasn't consensus, I never would have asked Vesna to start making the edits.  I sincerely thought that starting to change pages over to use the wikitable format was the least controversial part of any of this.
::::::And I'm still somewhat confused as to what still needs to be decided about changing the articles.  Yes, we all seem to want a standard format with wikitable as the basic standard format.  Yes, we all think that variants are needed in some cases.  I don't really see it as realistic to put up a list of every table on the site here on the community portal and vote on the desired format of each individual table.  So it's going to come down to an editor or two going through and making judgment calls on a page by page basis and deciding which parameters to used for each table.  Sorry for being somewhat obtuse here, but I'm still having a hard time understanding what needs to happen next. --Nephele  13:04, 21 November 2007 (EST)

(outdent) Okay, having thought about this for a while I'm not accepting that anybody has violated consensus. Nephele's post of 19 November clearly stated her intention to update the tables "if nobody speaks up in a couple of days" and also called for volunteers to start making the changes. Both things have happened since. Suddenly the implication is that consensus has been ignored and that the whole project should be shelved.

I think the project is long overdue and should go ahead at once. The site is a mish-mash of styles; not only are there the two main table styles but very often people have added their own improvements with non-standard cell padding, spacing and so on. That's not aimed at anybody incidentally - I've been at least as guilty as anybody else. Switching to a few, standard table forms will make the site look much more consistent; even professional!

As for the specific criticisms there have been on here, I'd say the names of the classes are ideal. It is much better to have
descriptive names where possible; only people who looked at the CSS file
will have been aware what "greylapse" meant but "compress" and "vtop"
are a lot clearer. Yes, quotes are required except when using the base
"wikitable" class, but then for 100% correct HTML they should be used
anyway. I really don't want to see a lot of obscure codes like "wc" or
"wv" for class names - we're not trying to win an obfuscation contest
here.

Changes like this can only be tested by going and doing them. It's
possible to edit your own copies of the style files but then only you
get to see the changes. There's such a wide range of pages using tables
that making the changes for real is the only way for everybody to see how everything
will be affected. And to be honest, given all the browser variations out
there, if we look at variant after variant until we all agree on the
exact number of pixels that should pad out a table header, we'll die of
old age before everybody is 100% happy

I don't see that there's anything wrong that a few tweaks can't fix. Let's get Nephele to do those and then get on with harmonizing the site. --Rpeh  14:42, 21 November 2007 (EST)

:Before we get over our heads, I'd like to clarify a few things that may not have been clear. I only asked to call off the changeover of the tables because I felt that there were a few issues raised by Lurlock that needed to be addressed before a massive overhaul. I never accused anybody of breaching consensus and I don't believe anybody have done so. I also don't think this project should be scrapped, as it is quite necessary.
:To go forward with the table changes let's all agree on the current table classes: wikitable, compress, vtop, and firstleft. I understand Nephele and Rpeh agree with these. I also agree. If Lurlock is also happy with them, then let's go on changing the tables. The classes can be fine tuned later on the style sheet, or we can even add new classes if we need. --DrPhoton 03:56, 22 November 2007 (EST)
::Well, (after over a week) I'm okay for the most part - one other change I might suggest though - it seems to me that vtop is an option that will be used more often than not, especially if there are Linkable Entries in the first column, as a large percentage of tables have.  I'd say that should be the default, and maybe have a vmid for any others.  Or maybe just make the first column default to top align, and have a firstmid to center them?  Not sure, just I know that there's far more reason to justify top-aligned text (due to linkable entries) than there is to justify center-aligned.  --TheRealLurlock   17:03, 3 December 2007 (EST)

:::I'll assume the lack of response to Lurlock's vtop suggestion means nobody has any objections ;)
:::To really be useful, I'm inclined to say that the default vertical alignment for all tables, not just wikitable-class tables, should be vtop.  There are many places where invisible tables (no borders) are being used to layout information.  For example, all the tables at  are embedded in an additional set of tables that position everything on the page.  In all of those cases, we really want vtop-type alignment, and I know I've had to go in and add vtop (or previously valign=top) tags to countless tables to fix the alignment.  Changing the default vertical alignment for every table on the site is a fairly substantial change, and it's hard to be sure whether there are tables that will be affected for the worse.  But trying to scan through pages and survey what's being done so far, I think the vtop option will probably have no effect in many places (i.e., tables where the rows are only one line high will not be altered by a change in the vertical alignment), and will probably be an improvement in more than a few places.  If we're going to make such a change it's probably best to do it sooner rather than later, and in particular so that any problem cases can be fixed as editors go through and fix up the table formats based on these updates.
:::So I'm going to go ahead and change the default alignment to be vtop.  I'll add a vmid option, but I'll also leave the vtop option in the css files just in case.  I'm not sure about the firstmid idea though (and wouldn't it be firsttop anyway?): I tend to find having different vertical alignment as you scan across a row of cells confusing, and I can't think of any examples right now where we would want to use it.  But if as we proceed someone finds cases where that would be a useful option, it can always be added at that point. --Nephele  16:14, 21 December 2007 (EST)