MediaWiki talk:Common.css/Archive 9

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

{{

Adding

*:not(.navbox) + table.navbox { margin-top: 1em; }

to the navbox section should solve the minor problem of reference lists and external link lists running into navboxes, while still allowing adjacent navboxes to stick together. Tested it out on different pages with different circumstances on Firefox 3 and it seems to work like a charm. To the right is the problem on the ironclad warship article, and fixed with this CSS. Obviously it does nothing on IE, and it should either work fine or do nothing on each of the other browsers. —Werson (talk) 04:51, 23 April 2009 (UTC)

What's up with the bullets in the right example? 「ダイノガイ千？！」^{(Dinoguy1000)} 05:27, 23 April 2009 (UTC)

Not sure what caused that. Fixed. —Werson (talk) 07:55, 23 April 2009 (UTC)

Do you think that's going to kill that JS script again because it's got ".navbox + " in it? I guess we can try it and see if anything breaks. I have absolutely no guilt over adding something we know won't work on IE; it's not the end of the world if this tweak isn't consistent (maybe it'll persuade even more people to switch to Firefox!). Happy‑melon 08:28, 23 April 2009 (UTC)

Hmm, this does seem like it might trigger that performance issue again. "Everything that is not .navbox", seems equally bad as "everything that is .navbox" to me. I guess we will have to test this in monobook.js. I would volunteer, but I never experienced the other case. I think it would be best if RockMFR tested, since he would know how the compare it to the previous time. --TheDJ (talk • contribs) 09:46, 23 April 2009 (UTC)

I do have a problem using code that does not work in all browsers, especially for such a trivial fix. There must be a better way of doing this. — Edokter • Talk • 12:03, 23 April 2009 (UTC)

I think the onus is on you to find the "better way", not to stall this solution because there hypothetically could be one. People who use crappy browsers can deal with minor issues, it's not the end of the world. —Werson (talk) 19:09, 23 April 2009 (UTC)

IE is used by a massive slice of our readership; probably over half. While I stand by what I said above, I don't think Edokter's position is invalid, especially since we have now identified other problems with the code. He's right, there probably is a better way. Happy‑melon 19:19, 23 April 2009 (UTC)

Actually, on looking at the existing code, we can just set margin:1em 0; in the existing navbox declaration; we already have a table.navbox + table.navbox override to make them stack. Happy‑melon 12:11, 23 April 2009 (UTC)

Wouldn't that create 1em of space between all navboxes then, that do not support the + selector though ? Seems a bit over the top again as well... --TheDJ (talk • contribs) 14:35, 23 April 2009 (UTC)

Werson: I moved the image at the top of this section down a bit, since it overlapped the code in my screen resolution. Sorry to edit your comment.

TheDJ: I know how to run that test, so I ran it. Graphically it worked well. But it did hang my Firefox 2.0 when viewing longer history lists, sorry. So I tried to change the code to this:

*:not(table.navbox) + table.navbox { margin-top: 1em; }

That didn't hang my Firefox when viewing longer history lists. But that didn't work graphically, I didn't get any extra top margin. So I guess Firefox doesn't understand that variant.

Wouldn't it be simpler if we forced the script users to stop removing double empty lines above the navboxes? Double lines is a MediaWiki feature, not a bug. But many editing scripts automatically remove any empty lines.

--David Göthberg (talk) 18:44, 23 April 2009 (UTC)

That's a shame, and slightly wierd that the table.navbox version isn't accepted.

Since the main issue here is the gap between navboxes and the bottom of external link lists, we could do something like this:

ul + table.navbox { margin-top:1em; }

How does that fare hanging-wise? Happy‑melon 18:58, 23 April 2009 (UTC)

Reference lists too, so

ul + table.navbox { margin-top: 1em; }
div.references + table.navbox { margin-top: 1em; }

which is why I just went with :not (since we're using selectors anyway). But I was unaware of any JS problem. —Werson (talk) 19:05, 23 April 2009 (UTC)

But + is a CSS2.1 selector, while :not is a CSS3 selector. Happy‑melon 19:09, 23 April 2009 (UTC)

ul + table.navbox,
div.references + table.navbox { margin-top: 1em; }

Seems like a good idea to me. It avoids FF selector slowness, and would deal with 95% of the cases I think. Perhaps something for stubs ? (...) ok, just found an interesting "next job" for us... "class=boilerplate metadata" id=stub". That doesn't sound too handy when you can have multiple stubs on one page..... --TheDJ (talk • contribs) 20:20, 23 April 2009 (UTC)

Heh, I had the very same thought today, DJ, when I looked at stubs. And only some stubs are using {{

Smbox}}) anyway, most of the gazillion there are have the 'class="boilerplate metadata" id="stub"' hardcoded. --Amalthea

20:33, 23 April 2009 (UTC)

Lol, how soon you forget about things at times. Stubs are supposed to go under navboxes officially anyways. So I guess we can just ignore that if we want. --TheDJ (talk • contribs) 20:37, 23 April 2009 (UTC)

The codes above work in my Firefox 2.0. I get extra top margin above the navbox, and it doesn't hang for long history lists.

Werson: I couldn't find any "div.references" on any page. If you know a place that uses it, can you point to it? But I did find "div.references-small" and "ol.references". And there also was the already suggested "ul" lists before navboxes. So I put together this code:

div.references-small + table.navbox,
ol.references + table.navbox,
ul + table.navbox { 
    margin-top: 1em; 
}

That worked fine. But since the plain "ul" works, I tried this:

table + table.navbox,
div + table.navbox,
ol + table.navbox,
ul + table.navbox { 
    margin-top: 1em; 
}

And that worked fine! Using plain elements like that will catch many more cases, so I say we should use that. That will also catch Werson's "div.references" case if it exists. And the "table + table.navbox" doesn't hurt, since the "table.navbox + table.navbox { margin-top: -1px; }" has higher specificity and thus wins. And browsers who doesn't understand "+" won't understand any of them anyway.

I am going to test this in more browsers, and I hope some of you guys will test it too. Just put that code in your personal /monobook.css, wait one minute, then

bypass

your browser cache. And take a look at how navboxes look on the pages.

If you have Firefox, go to any long history list, like for this page. Then select to view 250 revisions, if it fails then the browser will hang for some minutes after the page has been loaded. Don't try 500 revisions first time, since if it fails then it hangs for even longer, 10-15 minutes or so... (But no need to reboot, it will release automatically after some minutes.) Since the new codes seem to work: If you want to see it hang, try it with the first code suggested at the top of this section.

--David Göthberg (talk) 21:29, 23 April 2009 (UTC)

Good one. Makes cases like this: Fahri Korutürk work as well. --TheDJ (talk • contribs) 21:47, 23 April 2009 (UTC)

Yeah, that should've been "div.references-small", my mistake. Your code works perfectly. I viewed a history page of 3,000 edits on Firefox 3 with no abnormal behavior. —Werson (talk) 23:07, 23 April 2009 (UTC)

There is a lot of criticism about how {{

MetaPicstub}} when creating a new stub template which is why you see these classes. I recently added the plainlinks class to both templates. ---— Gadget850 (Ed) ^talk

23:33, 23 April 2009 (UTC)

TheDJ: I think that page didn't need any extra margin, but it didn't hurt either.

Werson: Thanks for confirming that it works in Firefox 3 too. I have now tested in my Opera 9.02 and it worked fine. And I have tested in my IE 5.5, which of course failed, but the styles did no harm. So I am in favour of deploying that code.

--David Göthberg (talk) 01:19, 24 April 2009 (UTC)

So, is this doable? —Werson (talk) 02:39, 26 April 2009 (UTC)

I don't see any problems with the code, and have had it in my personal monobook for 2 days now without trouble on Safari or FF. IE 5.5 seems covered as well, so let this be my first admin action !  Done --TheDJ (talk • contribs) 10:02, 26 April 2009 (UTC)

OK, so in which browsers does/doesn't it work? I might try something in javascript to add a margin to the first navbox in the article. — Edokter • Talk • 10:20, 26 April 2009 (UTC)

As far as I know only IE 5.5 and IE 6.0 http://www.quirksmode.org/css/contents.html --TheDJ (talk • contribs) 12:01, 26 April 2009 (UTC)

Would fit nicely in IE6Fixes.js then. Now I just need some code to find the first instance of a .navbox, find out what's in front of it and assign margin-top:1em; to it. — Edokter • Talk • 15:25, 26 April 2009 (UTC)

Margin amount

The CSS adds a margin of 1em. I think this is too much. Except for <ol>, <ul> and <div> (which are basiccally the only problematic elements), every other element has a default bottom margin of 0.5em. So I propose the margin be reduced to 0.5em. — Edokter • Talk • 20:37, 6 May 2009 (UTC)

On the other hand, Categories have 1em top margin, and headers have 0.6em bottom margin. (in 150% font-size, so that's about 1em as well). I don't really favor either one in particular. —TheDJ (talk • contribs) 12:45, 7 May 2009 (UTC)

The headers solve themselves then... If two margins overlap, it is the larger of the two that is applied. Many footer templates also use 0.5em; it seems to be the standard for any block element. 1em simply creates too much space between the text and other block elements. — Edokter • Talk • 12:58, 7 May 2009 (UTC)

Would it be more sensible to give <ol> and <ul> a 0.5em bottom margin? Applying it to all divs might be a bit extreme, but this would probably be more consistent (and scalable) than trying to tweak this specific scenario. Or would this be generally undesirable? Happy‑melon 13:36, 7 May 2009 (UTC)

That is actually a good idea; we basically wouldn't need any navbox hack in that case. — Edokter • Talk • 14:31, 7 May 2009 (UTC)

(←) The below code would make the 1em margin-top to the top navbox redundant, which would fix the navbox in 99.9% of all cases, across all browsers. I've never seen a navbox directly below a div, but if there are any, we could leave .div + .navbox. .dix references ususally contains a OL list, so that is covered as well. All other div boxes usually have a margin set. The #content is there so it doesn't touch anything outside the main content area, such as the left side menu. There would be no visible difference, as most, if not all block element such as P, DL and Hx headers already have a top margin ranging from 0.4 to 0.5em. — Edokter • Talk • 22:47, 7 May 2009 (UTC)

/* Margins for <ol> and <ul> */
#content ol, #content ul,
#mw_content ol, #mw_content ul {
  margin-bottom: 0.5em;
}

I've made this compatible with more skins. I haven't tested it yet btw. —TheDJ (talk • contribs) 14:58, 8 May 2009 (UTC)

Cheers. — Edokter • Talk • 15:09, 8 May 2009 (UTC)

Sounds good to me. Happy‑melon 15:32, 8 May 2009 (UTC)

 Done. — Edokter • Talk • 23:15, 8 May 2009 (UTC)

Discovered these :lang definitions we have aren't actually doing anything. See my comment at the talkpage of the one who added this. Questions that need answered:

• Is it IE specific ?
• If it is not, is it useful at all? should it be wholly removed?

Possible endings:

• Remove inherit lines from those definitions.
• Remove inherit and move the code to IEFixes.css
• Remove the code alltogether.

—TheDJ (talk • contribs) 18:05, 6 May 2009 (UTC)

I think I will remove it. It is not widely supported enough in browsers, so we might as well keep using the style definitions in the lang templates, combined with the CSS classes that are above it. (also used by these lang templates). —TheDJ (talk • contribs) 19:55, 6 May 2009 (UTC)

 Removed for now. Their usage is highly limited and duplicate with style definitions in the lang templates. Personally, I favor specific classes if we want to remove the style definitions from the templates. —TheDJ (talk • contribs) 12:44, 8 May 2009 (UTC)

Wow, that's a lot of bytes (over 7% of the new total). And it's useless, as you say. Well rid, I think. Happy‑melon 12:47, 8 May 2009 (UTC)

I'm proposing we load the following code MediaWiki:Common.css/IEFixes.css trough Javascript, like I have proposed earlier. Pros/Cons:

• Con: no "fixes" loaded if IE user has javascript disabled (who does that ?)
• Pro: simple, does not get loaded on non-IE, works for all versions of IE.

What do you guys think ? --TheDJ (talk • contribs) 22:47, 28 April 2009 (UTC)

I assume you mean "javascript disabled"?? :D Definitely prefer this to bloating CSS for all users with wierd hacks that don't even always work. That's a lot of bytes I'd rather not be sending to the large fraction of users who have no need of it. Happy‑melon 22:50, 28 April 2009 (UTC)

Too bad CSS does not have some inclusion mechanism (or is there?) I'm not thrilled with splitting up the code, as loading by javascript only slows it down. — Edokter • Talk • 23:54, 28 April 2009 (UTC)

It does, but it is not a conditional system. The only other way to do this is with IE conditional comments, but those don't work in .css or .js files (and we cannot edit the global HTML files of course.) --TheDJ (talk • contribs) 00:16, 29 April 2009 (UTC)

A better idea would be to have standard locations for IE fix files that can be edited on-wiki and have MediaWiki load them for us. This functionality would be useful for other wikis. --- RockMFR 02:54, 29 April 2009 (UTC)

With conditional comments you mean. I have asked the devs for this, and they basically said: "use JS" and "we want less, not more more stylesheets". --TheDJ (talk • contribs) 14:12, 29 April 2009 (UTC)

I still didn't feel 100% sure about this, so for now, I have added just the print CSS regarding line-height. This hopefully will at least stop the flood of reports of broken printing from the IE users. —TheDJ (talk • contribs) 00:23, 11 May 2009 (UTC)

OK, several things:

1. I'm working again on an mbox version for stubs {{asbox}}. The proposed style is on it's talk page.
2. I noticed some mbox types have class="mbox-empty-cell", {{ambox/core}}, but this is not in Common.css yet. Most others liks {{tmbox/core}} and {{ombox/core}}, don't use the class yet.

.mbox-empty-cell {
    border: none;
    padding: 0px;
    width: 1px;
}

—TheDJ (talk • contribs) 18:58, 4 May 2009 (UTC)

 Added mbox-empty-cell. Asbox changes still awaiting further comments. —TheDJ (talk • contribs) 13:38, 9 May 2009 (UTC)

In light of us setting ns-0 for many of the elements in print.css, I was just wondering.... For this to actually be useful on talkpages and template pages, wouldn't it be smart to "uncollapse" items when printing them ? so for MediaWiki:Print.css we might add:

table.collapsed tr {
  display: table-row !important;
}

This is pretty reasonably supported [1], just not in IE<8. Also since we should NOT be hiding content in general in article space, perhaps this should be applied to article space just as much as to any of the other namespaces? —TheDJ (talk • contribs) 12:03, 11 May 2009 (UTC)

Good idea, but I'd suggest

table.collapsed tr {
  display: block !important;
  display: table-row !important;
}

for even better compatibility. —Ms2ger (talk) 15:25, 11 May 2009 (UTC)

Perhaps even ?

body.mediawiki table.collapsed tr {
  display: block;
  display: table-row;
}

—TheDJ (talk • contribs) 16:15, 11 May 2009 (UTC)

Unfortunately, that wouldn't work. Only by using !important, we can override the inline styles used by the script.

Also, I just remembered that we'd need

div.NavPic, div.NavContent {
  display: block !important;
}

too. —Ms2ger (talk) 17:35, 11 May 2009 (UTC)

Good for print, no way in mainspace: we collapse navboxes for a reason! Good idea, DJ, but that won't quite work: IE will ignore the whole statement; they have to be separate:

table.collpased tr, div.NavPic, div.NavContent {
    display: block !important;
}
talbe.collapsed tr {
    display: table-row !important;
}

Should work. Happy‑melon 11:19, 12 May 2009 (UTC)

(unindent) I meant for print of mainspace. I initially thought it would be most useful for print of non-mainspace, and was not quite sure if it was desirable for print of mainspace. —TheDJ (talk • contribs) 11:53, 12 May 2009 (UTC) It has to be "collapsible" btw, because "collapsed" is an initial class, and says nothing about the "current" state (after using show/hide) of the collapsible tables. So:

/* Uncollapse collapsible tables/divs.
     The proper way to do this for tables is to use display:table-row,
     but this is not supported by all browsers, so use display:block as fallback.
*/
table.collapsible tr, div.NavPic, div.NavContent {
    display: block !important;
}
talbe.collapsible tr {
    display: table-row !important;
}

—TheDJ (talk • contribs) 12:03, 12 May 2009 (UTC)

 Added —TheDJ (talk • contribs) 19:01, 12 May 2009 (UTC)

Also hiding the toggles now for these items. —TheDJ (talk • contribs) 21:44, 12 May 2009 (UTC)

This looks mostly good. The poem in The Raven does not print across the page boundary. Any clue? ---— Gadget850 (Ed) ^talk 21:01, 12 May 2009 (UTC)

Well kinda depends on the browser of course... —TheDJ (talk • contribs) 21:26, 12 May 2009 (UTC)

Odd. I run FF 3.0.10 at home and work; at work it truncates at the page boundary, at home it expands and prints fully. ---— Gadget850 (Ed) ^talk 00:48, 13 May 2009 (UTC)

What about screen readers? ---— Gadget850 (Ed) ^talk 01:36, 13 May 2009 (UTC)

See the last comment I made at #Nospeak class. It does not seem that screenreaders abide any type of CSS targeted at them, accept in some cases speak:none. —TheDJ (talk • contribs) 01:47, 13 May 2009 (UTC)

I have proposed to disable multiple columns for references when printing, due to this issue. —TheDJ (talk • contribs) 12:42, 12 May 2009 (UTC)

The latest change made on this day breaks printing on Firefox 2. Perhaps it needs to be modified or rolled back? —Preceding unsigned comment added by 68.145.98.120 (talk) 20:07, 12 May 2009 (UTC)

Are you talking about this? How exactly is it breaking printing? 「

Dinoguy1000

) 20:22, 12 May 2009 (UTC)

Probably due to this typo. Luckily I can share blame with Happy-Melon. He wrote the typo, I just copy pasted it :D —TheDJ (talk • contribs) 20:52, 12 May 2009 (UTC)

I have figured out how we can add a special CSS file that is only cached for say 4 hours, so we can deploy styles and "revert" mistakes much faster. And we admins can do this addition, the devs don't need to do anything. (But we should consult them on this first, so we don't do anything stupid.)

MediaWiki:Common.css and MediaWiki:Monobook.css etc. are set to cache for up to 31 days in the web browsers. This is annoying when we want to add or change styles, since we have to hard code them into our templates for 31 days. And not all kinds of CSS can be hardcoded. And it is a serious problem when we do a mistake in these CSS files, since even if we revert the mistake quickly, some users will have the damaged version for 31 days.

But we can make

We should only have one such "Common fast" file, to save server resources. We should not create fast versions for our skin files etc. Instead if we need to quickly add styles for some skin or for printing we can use CSS based skin detection and print media detection in our common fast file.

To deploy MediaWiki:Fast.css, all we have to do is to add this line of code to MediaWiki:Common.css. (It must be placed at the top, before any style declarations, otherwise most web browsers refuse to use it.):

/* Load the Fast.css file, that only caches for 4 hours. */
@import "/w/index.php?title=MediaWiki:Fast.css&action=raw&usemsgcache=yes&ctype=text/css&smaxage=14400&maxage=14400";

Then we of course have to wait 31 days before we can start using it.

That link has all the parameters that are needed to make it cache as nicely as possible, but only for 4 hours.

To add a style: Add it to both MediaWiki:Common.css and MediaWiki:Fast.css. After 4 hours all users can see the style. And after 31 days remove the style from MediaWiki:Fast.css, since it doesn't need to be there anymore. And we should of course keep that file short and clean.

To "revert" a mistake: Fix it in MediaWiki:Common.css. And place the same declaration in MediaWiki:Fast.css, but use higher specificity or the !important keyword so it overrides the old version that some users have cached. And after 31 days remove the style from MediaWiki:Fast.css.

--David Göthberg (talk) 01:22, 20 April 2009 (UTC)

4 hours? I think the devs would stab you. More better would be reducing general skin caches to a week or so. Or not making mistakes in skins... (haha, but seriously). --Splarka (rant) 08:00, 20 April 2009 (UTC)

That URL "/w/index.php?..." won't work on the secure server, it will need to be an absolute URL. As far as I can tell we already use non-secure images even on https://secure.wikimedia.org/wikipedia/en/wiki so I'm thinking it's acceptable? Amalthea 08:44, 20 April 2009 (UTC)

Do we really need this ? I think we did pretty reasonable and i don't see the point in adding options "just because we can". --TheDJ (talk • contribs) 08:57, 20 April 2009 (UTC)

While it is an ingenious idea, I think a method whereby it was only refetched when it had been changed would be infinitely superior. I'm not sure how useful this extra page will be. That said, if the devs don't kill us we should give it a try. No, the world isn't going to stop if we don't get this, but that's a falacious argument against. It

does no harm. Happy‑melon

09:30, 20 April 2009 (UTC)

Splarka: We could set it to 24 hours or 4 days if that makes people feel better about it. But really, it is one small file that will be loaded once per visitor. As far as I know many browsers anyway don't cache these files for 31 days, they reload them on every session. (Session as in once per time you have started your browser.) I think 4 days is a bit much, since that means when we do a mistake some users will see that for 4 days. 24 hours is perhaps okay (but would still cost us 24 hours of questions at the Village pumps each time we have a CSS bug). And yes, we have had some bad CSS bugs here. But most of you haven't noticed that, since your browsers reload the files on each session.

Amalthea: Ouch, I knew it was something more I should have tested. Thanks for noticing that. And yeah, loading the CSS file outside the https connection should probably be okay, since all that tells is that "the user is visiting Wikipedia" and that can be seen already from the https connection. I don't think that someone would have much use of playing man-in-the-middle and modifying the CSS file in transit. It is way worse that the images are loaded in an insecure manner since that means that an eavesdropper can see what images you see, and thus what articles you are reading.

TheDJ: Yes, each time we do a mistake and need to revert it quickly, then we really need this. And when deploying new or improved styles it would save a lot of work too. Since now we have to use hardcoded styles in the templates for 31 days. We get questions from users that want to style them, so we have to explain how to use the !important keyword, over and over again... And we even sometimes get edits where the users (or even admins when the templates are protected) try to add extra options to our templates so they can do other styling than the hardcoded ones. And sometimes they remove the hardcoded styles before the 31 days have passed with the comment: "Already in CSS". And I have noticed that even some of our more skilled coders have calculated wrong and removed the hardcoded styles after only 30 days. And when people copy our templates to other language editions of Wikipedia, they often get our early version with the hardcoded styles, and thus they get trouble later on. If we instead could deploy our actual final production version of our templates within a day or so that would avoid most of these problems. And remember, not all CSS styles can be hardcoded in templates, some have to be in the CSS files.

Happy-melon: If the devs build an automatic system it would cause refetches even when we just remove some old unused style or tweak some comment or do a non-urgent style change. And considering the rate we are editing MediaWiki:Common.css then it would cause refetches very often. And if such an automatic system would work the way I think, then it would cause all visitors to reload MediaWiki:Common.css when they visit the next article, even if in the middle of a session. Thus at least here on the English Wikipedia an automatic system would probably cost more resources than having MediaWiki:Fast.css. I hope that if they make an automatic system it will at least delay updates for an hour, so consecutive edits only cause one refetch. Of course, if we could manually tell the system when we want it to refetch and when not, then it would be another matter. But yeah, an automatic system would be convenient, and probably very good for other projects where they don't edit the CSS files as often.

--David Göthberg (talk) 11:01, 20 April 2009 (UTC)

Yes, if we had an automatic system, every time we changed Common.css, it would cause a wave of refetches. However, there would be a near-100% hitrate on the squid caches, so the requests would rarely make it through to the backend. The only instances when they would would be for users who have explicitly set "disable caching" in their preferences, and even then they would only get as far as the Apache msgcache, as the stylesheets are explicitly loaded with &usemsgcache=yes. So I don't think there would be any increase in load on the database servers: all hits would be served from cache.

I don't think this implementation is quite as useful as it could be, but it is useful, and kudos to David for coming up with it. I think four hours is an acceptable compromise between immediacy and server resources. Obviously if we get a sysadmin howling for our blood, we'll know we got the balance wrong. But unless that happens, we should do whatever helps us. If we can get the secure server issue sorted out, we should use this. Happy‑melon 13:44, 20 April 2009 (UTC)

BTW, WMF has been known to overwrite headers: Cache-Control: public, s-maxage=14400, max-age=14400, max-age=2592000. This can depend on php version, see bugzilla:14902. --Splarka (rant) 00:34, 21 April 2009 (UTC)

Splarka: Ouch, you are right. I tested to do the same kind of load for my user /monobook.css, and even to load some other non-css pages, but the servers added "max-age=2592000" then too. So we can't trick them by loading from other namespaces. So question is which of the two max-age parameters the web browsers honours? The first or the second? Guess I will have to spend some time testing that...

--David Göthberg (talk) 02:55, 21 April 2009 (UTC)

I added this to my personal /monobook.css and did some testing:

/* Load the Fast.css file, and only cache it for 10 minutes. */
@import "http://en.wikipedia.org/w/index.php?title=MediaWiki:Fast.css&usemsgcache=yes&action=raw&ctype=text/css&smaxage=600&maxage=600";

And then I used this test code:

<table class="bigbox">
<tr><td>Some content.
</table>

All three of my browsers could load the CSS file correctly, no matter if logged in normally or via the secure server. And all three of my browsers honoured the 10 minutes caching time. That is, within 10 minutes any changes I did to background colour in MediaWiki:Fast.css became visible, when just visiting/reloading my test page, without having to bypass my browser cache. I have a Firefox 2.0, Opera 9.02 and a very old Internet Explorer 5.5. So it seems it doesn't matter that the Wikipedia servers tag on the extra "max-age=2592000" parameter in the HTTP response header.

I would appreciate if someone with Safari and a recent version of Internet Explorer could test this too. You need to be an admin to edit MediaWiki:Fast.css, or you can use another CSS file in your own user space. The Wikipedia servers add the extra "max-age=2592000" parameter also for CSS files from user space.

--David Göthberg (talk) 19:34, 22 April 2009 (UTC)

This has completely died, were these extra tests ever run? Unless they were and failed, I'm inclined to run with this... Happy‑melon 09:09, 14 May 2009 (UTC)

I think it's too complicated a scheme; having to track two CSS files and how they interact. BTW, while the borwser cache is instructed to retain it's content 30 days, in practice this rarely happens. The 30 days are only honored if there are no changes, and 99% of all browsers are set to check for new versions "each session" anyway. So I think it adds little to no benefit. Also, with a new JS Core in the works, it should be trivial to incorporate CSS files in that mechanism. — Edokter • Talk • 12:02, 14 May 2009 (UTC)

Should topicons be hidden when printing? At least the protection and spoken icons are pretty much useless in this context. The featured icon however does provide some extra metadata context that might be "useful" in some cases.. —TheDJ (talk • contribs) 22:23, 12 May 2009 (UTC)

Keep the featured icon, but hide the others. ---— Gadget850 (Ed) ^talk 00:44, 13 May 2009 (UTC)

Hmm, I kind of agree, keep the "useful" stuff. Someone might argue that the protected icon is useful and that wikipedia is trying to hide the fact that not anyone could edit, but it seems a bit far fetched, i don't know, it doesn't bother me at least. :S
—Apis (talk) 14:57, 13 May 2009 (UTC)

Some icons should be printed, others should not. Those that shouldn't should have the noprint class added. No need for more CSS here. Happy‑melon 21:57, 21 May 2009 (UTC)

True. Probably need to discuss each at VPR. We don't need to add a noprint class to topicon.---— Gadget850 (Ed) ^talk 22:41, 21 May 2009 (UTC)

I agree, much smarter. —TheDJ (talk • contribs) 10:16, 22 May 2009 (UTC)

The span .PDFlink class has stopped displaying the PDFicon. Also, does anyone know if the slightly related class .geolink is even used anywhere? — Dispenser 22:13, 2 May 2009 (UTC)

Actually, I think that has been broken for quite some time. It seems as though the ".PDFlink a" declaration is overridden by main.css' "#bodyContent a.external" And though the classname "geolinks" is still used in some templates it seems, the actual CSS is not used anywhere as far as i remember: example of geolinks image —TheDJ (talk • contribs) 23:45, 2 May 2009 (UTC)

Well, should we fix the PDF link, or abandon it? It still works for internal links, but that's probably not the idea... I've never seen that globe icon before, seems completely useless. Happy‑melon 12:49, 8 May 2009 (UTC)

I have a fix for the PDF link issue:

#mw_content span.PDFlink a,
#bodyContent span.PDFlink a {
    background: 
        url("http://upload.wikimedia.org/wikipedia/commons/thumb/2/23/Icons-mini-file_acrobat.gif/15px-Icons-mini-file_acrobat.gif")
        center right no-repeat;
    padding-right: 17px;
}

Basically, this is the same level of specificity that the external link symbol has, and thus it works. For geolink, we need to first track down where that class is used at all. I'm quite sure i have seen this symbol on other projects, and I think it is part of the original implementation of the coordinates system on the german wikipedia. I'll ask around. —TheDJ (talk • contribs) 13:06, 8 May 2009 (UTC)

I have not been able to find any current use of geolink. As far as I've come to understand from the archives. class="geolink" was the old id="coordinates". It was basically deprecated after coord the {{geolinks-start}} and {{Mapit}}-* based templates were deprecated in favor of coor dms and later coord. I think we can safely remove it. —TheDJ (talk • contribs) 21:28, 8 May 2009 (UTC)

T20722 is relevant. I think we should fix the PDF link and remove the geolink. Happy‑melon 13:41, 9 May 2009 (UTC)

 Done Fixed and removed :D —TheDJ (talk • contribs) 13:48, 9 May 2009 (UTC)

bodyContent

BTW, i specifically chose to limit to bodyContent instead of content, because all our other definitions of these icons are also limited in the same way. We could change that everywhere of course, but I didn't feel that I should do that at this time. —TheDJ (talk • contribs) 13:50, 9 May 2009 (UTC)

The only extra things that are in #content but not #bodyContent are the first header (the page title), the sitenotice and an empty <a>...</a> element that serves as an anchor for the top of the page (no idea why a link is used...). #content is used across a much wider range of skins, as detailed in that bug. I think all instances of #bodyContent in Common.css (which is multi-skin) should be changed to use #content. Thoughts? Happy‑melon 14:44, 9 May 2009 (UTC)

I have no particular objections. It might be that some of those people using the other skins might not want link icons at all perhaps ? —TheDJ (talk • contribs) 12:45, 12 May 2009 (UTC)

We can select for skins using the .skin-monobook etc classes added to the <body> element, if we wanted to. Happy‑melon 12:59, 12 May 2009 (UTC)

 Done I've updated all the instances, and made sure that each declaration has both #content and #mw_content (for the modern skin). Happy‑melon 15:35, 23 May 2009 (UTC)

Right now. Users with equations set to using html for simple equations are seeing simple Tex equations being too small. The end result is that people like me are disabling this relatively nice feature by forcing these equations to use Tex mode (by adding a \, and other hackery that others not knowing why such strangeness is added to the equation then remove). The solution is fairly straight forward in css by adding font-size:XX to span.texhtml. I am not quite sure what the appropriate value should be without experimenting around using the possible configurations.

I don't know how the Tex pngs are served and whether they are different for different skins. If so (and I somewhat suspect that they are because span.texhtml sets the font-family in the skin files and not common.css) then the skin css should be altered instead. (If tex png files are served the same then, it seems to me that that css line should be moved to the commons instead. I would put the request there if I could find the place to do it. TStein (talk) 19:08, 21 May 2009 (UTC)

I have no objection to:

span.texhtml {
font-size:large;
}

Current: ${\displaystyle e^{i\pi }+1=0}$

Current PNG: ${\displaystyle e^{i\pi }+1=0\,}$

With font-size large: ${\displaystyle e^{i\pi }+1=0}$

With font-size x-large: ${\displaystyle e^{i\pi }+1=0}$

Even with font-size:large, this is still smaller than the PNGs for me. It however also makes it readable, compared to the original. :D —TheDJ (talk • contribs) 19:56, 21 May 2009 (UTC)

The png is a little smaller for me then the x-large (firefox 3.0) with a standard skin (I don't remember changing it at least). The extra-large is better for me since it catches the eye about the same as the png. The conversion process makes it look bold as well. The large might work for me if it was bolded as well.

My guess is that this will not be so simple as changing the common file because different browsers render stuff differently. I know enough css for my own webpage testing against a maximum of two browsers (firefox latest and IE latest) with at most one alternate stylesheet. TStein (talk) 02:27, 22 May 2009 (UTC)

I can tell you know, that it will be impossible to get it exactly the same on any browser esp, relative to the PNG. I think we just want to bring the PNG version and the textual version closer together. —TheDJ (talk • contribs) 10:33, 22 May 2009 (UTC)

Please don't use a fixed size—a percentage would be better. 150% looks about right for me. (${\displaystyle e^{i\pi }+1=0\,}$ vs. ${\displaystyle e^{i\pi }+1=0}$) —Ms2ger (talk) 12:03, 22 May 2009 (UTC)

Good point. 150% looks good to me as well. —TheDJ (talk • contribs) 12:43, 22 May 2009 (UTC)

span.texhtml {
font-size:150%;
}

Your example brings forth another interesting aspect btw.. vertical alignment of the TeX PNG image. Vertical-alignment is currently "middle", in all cases. It should either use different settings when the image has either sub OR super script. Alternatively, it should always render PNGs with equal space from the baseline to the top and bottom of the image. —TheDJ (talk • contribs) 12:43, 22 May 2009 (UTC)

150% is too big for me, but not horribly so. Happy‑melon 12:53, 22 May 2009 (UTC)

Is it bigger then the PNG? On my machine (IE6 with everything standard), 175% matches the text with the PNG, but it is indeed no guarantee it would match on all machines. .texhtml is defined as 'serif', so it could end up using any serif font on a user's machine. I do agree that without scaling, the text is too small. — Edokter • Talk • 13:51, 22 May 2009 (UTC)

Yes. For me the png matches the HTML at about 120%. It's not a significant problem, however. Happy‑melon 14:43, 22 May 2009 (UTC)

There is another way; since the PNG rendered output has a fixed font size, we could do the same to the HTML output. I found 16pt to most closely match the PNGs. This is the surest way of ensuring the most consistent fontsize across the board. And with regards the alignment, adding vertical-align: middle; to the text span ensures consistent aligning with the PNGs.
PNG: ${\displaystyle e^{i\pi }+1=0\,}$
Text: ${\displaystyle e^{i\pi }+1=0}$

span.texhtml {
font-size: 1.2em;
line-height: 20pt;
}

— Edokter • Talk • 22:04, 22 May 2009 (UTC)

I would not object to that either. Very close to the PNG. —TheDJ (talk • contribs) 23:19, 22 May 2009 (UTC)

Although i'm not sure we should start messing with HTML alignment simply because the PNG image does not know what a font baseline is.... Seems hacky. I've been looking at the code for the texcv (which does this stuff) and looking for a way to see if I can discover "sub OR sup" in the latex and then use different CSS classes based on that information for the image. —TheDJ (talk • contribs) 23:28, 22 May 2009 (UTC)

It's only intended to mimic current behaviour, not 'hacky' at all. If you want everything perfetly aligned, you would have to set the baseline in the PNG, and find a way to align the image to it's baseline, which is best done inline. You wouldn't even need CSS classes. Never mind, that is CSS2 only. OK, I'm rambling. I don't know TeX's capabilities, but I think it is impossible to perfectly allign the image to the surrounding text. — Edokter • Talk • 23:42, 22 May 2009 (UTC)

On second thought, the align:middle is not such a good idea. However, there is another problem. Having done some experimenting (

The 16pt HTML (${\displaystyle e^{i\pi }+1=0}$) is significantly larger than the surrounding text for me, to the point where it's actually detrimental. Happy‑melon 15:31, 23 May 2009 (UTC)

Of course... the point is to have the HTML render the same size as the PNGs. — Edokter • Talk • 16:47, 23 May 2009 (UTC)

It's about twice the size of the png. Happy‑melon 17:04, 23 May 2009 (UTC)

What is the default serif font in your browser? I'm interested in seeing a screenshot. — Edokter • Talk • 18:02, 23 May 2009 (UTC)

File:Texhtml sizes.png Happy‑melon 18:23, 23 May 2009 (UTC)

(←) Wow... you base font is huge. Still, 16pt should be a fixed size, unless Firefox scales that up as well (which is unfortunate). OK, let's try 21px:

PNG: ${\displaystyle e^{i\pi }+1=0\,}$

Text: ${\displaystyle e^{i\pi }+1=0}$.

If that doesn't look the same, I don't know what will force the same size. — Edokter • Talk • 22:00, 23 May 2009 (UTC)

Unfortunately, Firefox scales that up as well... — Edokter • Talk • 22:04, 23 May 2009 (UTC)

Does it need to be as big as the PNGs?

Default setting for TeX is "HTML if very simple or else PNG", which basically is limited to inline formulae. Main problem then is that Monobook and Modern use sans-serif, and TeX uses serif, the two of which are slighly incompatible regarding font-sizes. If HTML is primarely used inline, then a font-size of 125% (with a line-height of 1.5em) would be the most suitable: ${\displaystyle e^{i\pi }+1=0}$. That would match up nicely with the sans-serif in Monobook and Modern, while being slightly larger then the default serif fonts in the old skins. Of course, each skin can have it's own font-size. — Edokter • Talk • 22:25, 23 May 2009 (UTC)

Math mode is discouraged inline by the mathematics style guide for the very reason that it produces too large of text. (If needed anyway then it is recommended to use \scriptstyle to shrink it.) The real problem here is compatibility, though. The two modes (png and html) need to remain as close to the same as possible to avoid people editing equations to make it look good without realizing that it is making it worse for others. There are two problems here as it stands. The first is the person who has html mode for simple equations 'fixing' inline equations to be in mathmode instead of html. The person will do something like ${\displaystyle X^{m}}$ not realizing that to other people who use mathmode all of the time will see ${\displaystyle X^{m}\,}$. The second problem is the exact opposite with simple equations like

${\displaystyle R_{t}=R_{1}+R_{2}\,}$

that are not inline. People remove the \, hack not knowing what the heck it means and it

${\displaystyle R_{t}=R_{1}+R_{2}}$

becomes hard to distinguish from the rest of the article; this is particularly true when the rest of the article is long and includes a number of equations that are rendered as PNG. Personally I don't know why we have the simple mode for equations. A good bit of time is used to disable the feature anyway, with the \, hack, because of the size and appearance issue. (It does not look professional.) I can't imagine that it saves that much loading time. But if we are going to have it we might as well fix it so that it isn't wildly different then the png.TStein (talk) 03:59, 24 May 2009 (UTC)

The original idea was to make HTML look the same as the PNGs, but as discovered above, Firefox (and possibly other browsers) screw that up by not obeying static font sizes. What is agreed however is that the current HTML output is too small, even compared to regular text. So what would be the best compomise? — Edokter • Talk • 09:30, 24 May 2009 (UTC)

I have spent a lot of time this weekend looking into how all the math is converted. Basicly, it's a developer's hellhole. I think that you really want consistency for Math, and unfortunately, with all the broken fonts out there on the client side, that is simply not possible in HTML atm. The problem with PNGs is their alignment. Again, one heck of a problem. I figured i could somehow convince the converters to take into account lineheight or baseline, but it's just too hard. On the other hand, I don't see why we would use "html-mode", if almost all the formulas include \, to disable it... Basically, I'm at a loss what to do here. At the very least, the html mode needs to be "bigger" than it is now, because it's illegible at times these days. Perhaps we should also just consider disabling the HTML mode altogether, due to lack of usefulness. However. I have discovered something called jsMath. It produces very nice results, and uses images for unsupported characters where needed, and appropriate unicode or Math fonts if you have those installed. If this was the primary mode, with a <noscript> for the current PNGs, then that would be really cool I think. However, I'm not sure how much developer work that would be, and wether or not it would scale... —TheDJ (talk • contribs) 14:14, 24 May 2009 (UTC)

I think you're going to deep with this. PNG aligning needs no fixing. Having read

WP:MATH, complex formulae are not supposed to be shown inline anyway. The HTML rendering is, and the only problem is font-size. As I see it now, we should only increase the font size to 125% in all skins using sans-serif (Chick, Cologne Blue, Modern and Monobook) in order to make the inline HTML rendered formulae match in size with the surrounding font. They already match up in the other skins. — Edokter • Talk

• 09:30, 24 May 2009 (UTC)

Yes, I was going rather deep, because I think it should be better than it is now, and because I just wanted to know how it works. Conclusion, stay FAR FAR away from it :D —TheDJ (talk • contribs) 18:28, 25 May 2009 (UTC)

Monobook.css

I feel this is no longer a case for Common.css; it is skin-specific, as the skins using serif are not affected. I have opened up a thread at MediaWiki talk:Monobook.css#Math font-size. Comments are welcome. — Edokter • Talk • 21:46, 24 May 2009 (UTC)

In the absence of any comments/objections, I have added font-size: 125%; to Monobook.css for evaluation. — Edokter • Talk • 17:18, 25 May 2009 (UTC)

There is

There is no legitimate reason for a single project to do this. --- RockMFR 05:54, 16 April 2009 (UTC)

Personally I agree with them that the header colour they have chosen is nicer than the plain grey of the wikitable. If the tables were implemented through a template (and so could be centrally-controlled) then there wouldn't be an issue. Dumping hardcoded styles onto countless articles is a Bad Idea^TM and shouldn't be continued. If they plan to use this style consistently, we could probably support it here with just a few lines of code. Happy‑melon 10:04, 16 April 2009 (UTC)

Could someone point to a specific example? I tried finding one, but wasn't successful (and I doubt I'm the only one). 「ダイノガイ千？！」^{(Dinoguy1000)} 17:34, 16 April 2009 (UTC)

Maggie Gyllenhaal#Filmography, or any of their other FAs. Happy‑melon 17:58, 16 April 2009 (UTC)

Thanx for the example. I don't see the problem. But. this is unmaintainable in it's current form, they should use a template that expands the style options, at the very least. --TheDJ (talk • contribs) 18:19, 16 April 2009 (UTC)

Thanks you, HM05 (Flash)! It looks interesting, though personally, I prefer the more neutral colors of wikitable. If it's going to be used, though, might as well standardise it (via a template and/or CSS rules here). 「ダイノガイ千？！」^{(Dinoguy1000)} 19:31, 16 April 2009 (UTC)

IIRC there are some browser issues with that particular table styling. Personally I prefer the normal wikitable colours; I know I've butted heads over this issue in the past at an FLC review. PC78 (talk) 20:13, 16 April 2009 (UTC)

Visually there seems to be only two differences in their tables compared to a regular class="wikitable": They use smaller font, and blue background colour in the heading row. (Their cellpadding="4" is about equal to the "padding: 0.2em;" used in wikitables. And header cells are already centred here in Wikipedia.)

At the moment I think we should not add any code in MediaWiki:Common.css for this, since we can do this with a single template. Although the inner borders (cell borders) do look a bit different in different browsers. Anyway, here is how the template can be used:

{{filmography table head}}
! Year 
! Film 
! Role 
! Other notes
|-
| 1998
| ''[[Dil Se]]''
| Preeti Nair
| [[Filmfare Best Debut Award]].
|}

Since I wanted to demonstrate this I had to do a template somewhere, so I made the actual {{filmography table head}} that you see in the example above. They can use it if they like it. If they want it, then I will document it properly.

Personally I find their text too small, I prefer normal text size in tables. But I made the template exactly according to their standard. I think the colour is okay, but perhaps a bit boring.

--David Göthberg (talk) 21:50, 16 April 2009 (UTC)

Yes, as I hinted at above, the cell borders look pretty horrible to me veiwing the table in IE (they're very hard to see). Is there a solution to this particular problem? PC78 (talk) 21:56, 16 April 2009 (UTC)

PC78: There are several ways to get the proper cell borders in all browsers:

• Manually add style="border: 1px #aaa solid;" to all cells in the table. But that is very messy.
• Use class="wikitable" in the table head and then use style="background: #f2f2f2;" in all of the blue header cells. But that is fairly messy.
• Add a "wikitable-blue" style in MediaWiki:Common.css. Then in the table head you would use class="wikitable wikitable-blue". But then other WikiProjects probably want their colours too. So then we would have to supply a whole set of such colour classes. Might actually be pretty nice, I like colours. But I dread the loooong and wild arguments there will be over which colours and nuances there should be. We have been through that with the mboxes for some years now...

So I think for now the Wikipedia:WikiProject Actors and Filmmakers should use the template. That template uses the same code they are already hard coding into their tables. So it means no change in looks, just a better way to handle it.

--David Göthberg (talk) 23:32, 16 April 2009 (UTC)

I think it's great that someone would address this particular point in a constructive way rather than a destructive one. The table style itself has been in use since almost the beginning of the project, only a few minor changes to that style were instituted in the interim. One was the color used in the table, another was the size of the font, although the original table also had smaller font. The only other change was in syntax (using "Nominated —" instead of "Nominated:"). Prior to this, the only input we got was "you can't do that", with no offers of assisting in developing a workable solution to the heading/style. With respect to the fact that a creator of a tool initiated this discussion, I had stopped using checklinks on actors and filmmakers article because during the course of the run, it automatically changed the style to the default wikitable style. I do believe any WikiProject should be able to determine style in the articles under its scope and the consensus of project members who participated pointedly approved of the color. (There are those who think the plain table is... plain.) There are uses of table styling used in various forms on many projects, although perhaps none has brought as much attention to them as in this discussion. I think the use of a template would offer a great boost to tabling filmographies and I would support the project to accept the change to templates. Having said that, I will be gone for a short time due to eye surgery and either may not be able to address this personally or respond to a discussion there. I'd offer anyone to link to this post to show my support of using the template. Wildhartlivie (talk) 02:56, 17 April 2009 (UTC)

I strongly disagree. Wikipedia is one encyclopedia, not a collection of separate WikiProjects. If WP:ACTOR decides all table headers should be blue, and WP:AMERICAN would want them red, what is to happen on an article about an American actor? Make it depend on what the table is about? Use red–blue striped backgrounds? Alternate the colors biweekly? —Ms2ger (talk) 17:43, 19 April 2009 (UTC)

A few questions that need answered:

1. Where did the WikiProject discuss this?
2. Why does the WikiProject not like the standard styling?
3. Does their reasoning apply to only articles in their project's scope, or could it apply globally?
4. Where was the standard .wikitable styling discussed?

--- RockMFR 21:07, 19 April 2009 (UTC)

The style was first used soon after

WP:ACTOR was formed and a few minor style changes were all that was made afterward. The project discussed this on the project talk page. The discussion covered the plainness and lack of style of the table and a general preference for the changes that had been made to the recommended table. Why doesn't it like it? Why do others prefer a plain and bland table? The reasoning only applies to articles under the project, no one has ever advocated it be taken more globally. The only reason this became an issue is because certain edit tools such as checklinks and reflinks overwrites the styling by default. That is why the template above was designed - to avoid such issues. Wildhartlivie (talk

) 21:37, 27 May 2009 (UTC)

Using inline colours is extremely bad for accessibility and should always be avoided, and there is no need for the default stylesheet to include separate style definitions for each WikiProject. The standard table is perfectly adequate. ed g2s • talk 17:21, 27 May 2009 (UTC)

That would be your opinion, one which you've steadily gone about applying based on your personal viewpoint.

WP:ACTOR agreed as a project that the color heading was a style preference that was endorsed and beyond the statement of "there is no need", there is also no policy against it, nor does it give anyone person the right to go about reverting this against consensus, ed g2s. "Perfectly adequate" would also be an opinion. This template was made in an effort to address issues that came up regarding updating from one point if style changes are needed or desired. Since when is it within the scope of one person to dictate style to a project? Wildhartlivie (talk

) 21:37, 27 May 2009 (UTC)

First of all, this style was used by the project long before I joined, it was adapted at the beginning of the project. Articles all across Wikipedia use styling in tables of various types, whether it be in using color, formatting or other aspects. The only difference between that and

WP:ACTOR also falls under the scope of other projects and always have. The most prevalent being WP:WikiProject Biography

. The difference is, those projects don't concern themselves with specific aspects of actors and filmmakers careers such as displaying film work and data concerning that, and are not likely to do so. If it happens, it will have to be addressed in regard to whatever issues arise out of it then. To date, I've not seen such an issue arise regarding conflicts in style in any project on which I work. In regard to accessibility, I'm not entirely clear, outside of the use of color, how this table would hinder accessibility. The color itself that is being used was checked with the color check tools and it did not have a adverse effect in regard to colorblindness of any type nor has anyone approached the actual project talk page to say that the color heading presents any accessibility issue in specific.

The issue that brought about the creation of the filmography heading template was the ability to make changes at one place that would carry throughout the articles using that style. The template was created and it had slowly begun to be used in that spirit. But essentially, if you are mandating a change to the template that was developed to address the point that changes can't be made across the board, then it is useless and won't be used, so the changes made to the template today are moot. Mostly what I see us being handed is a "we don't like it and you can't do it, there is no place for originality in projects here". If you don't like the styling of that heading, then by all means, come up with a way to use color in the heading for wikitables that doesn't require style formatting be inserted at the head of each individual column each time one is added. That can be done in the template itself, but that makes it is less adaptable because the column heading titles have to be included in the template and doesn't allow for additional columns if one is needed. It would be quite nice if you tried to work with us instead of dictating to us what you will and won't permit. The template was developed in that spirit. Wildhartlivie (talk) 02:38, 28 May 2009 (UTC)

arbitrary break for editing

Obviously, I disagree with your assertion that a project cannot make such choices, projects make style choices, write manuals of style for articles under their domain and proscribe other aspects of articles under them routinely.

You appear to misunderstand the role that WikiProjects typically play. The members of a WikiProject can help to ensure that the articles within its scope comply with the community's standards, which their familiarity with the subject matter enables them to interpret and apply in an appropriate manner. For example, the members of the music-related WikiProjects are best able to draft the criteria through which musicians are deemed notable. Their assessments aren't sacrosanct, but the Wikipedia community generally trusts their judgement and agrees with the guidelines that they lay out.

No WikiProject has the authority to substitute its consensus for that of the community. If the aforementioned music-related WikiProjects were to determine that every musician (without regard for notability) should have an article, or that only recording artists with platinum-selling albums qualified for articles, such a decision would not stand.

Likewise, the members of WikiProject Actors and Filmmakers undoubtedly are qualified to interpret and apply the community's standards to articles about actors and filmmakers. But that isn't what we're discussing. We're discussing the decision to overrule the community's standards for no valid reason. (A substantive difference between these articles and others could conceivably justify a stylistic deviation, but you're cited no rationale other than the belief that the Wikipedia community has selected a style that is "plain and bland," an opinion that is neither solely applicable to actor/filmmaker-related articles nor within your WikiProject's area of expertise.)

WikiProjects exist to help build a cohesive encyclopedia, not to claim ownership of portions thereof and style them to their personal liking.

I didn't answer Ms2ger's question because I didn't see it, but the fact is that every article that exists under

WP:ACTOR also falls under the scope of other projects and always have. The most prevalent being WP:WikiProject Biography

. The difference is, those projects don't concern themselves with specific aspects of actors and filmmakers careers such as displaying film work and data concerning that, and are not likely to do so.

That brings us to Ms2ger's question about "[making] it depend on what the table is about." Why should another table within the article use a different style? And again, what sets the filmography table apart from other tables that justifies a nonstandard style? Our articles are written for the benefit of their readers, not for the benefit of their authors. How do the readers benefit from this deviation? (If we assume that your preferred style is superior, it should be implemented as the new standard, not used in a seemingly random fashion reflecting the preferences of certain editors.)

If it happens, it will have to be addressed in regard to whatever issues arise out of it then.

Or we could just stick to the encyclopedia-wide standard.

In regard to accessibility, I'm not entirely clear, outside of the use of color, how this table would hinder accessibility. The color itself that is being used was checked with the color check tools and it did not have a adverse effect in regard to colorblindness of any type nor has anyone approached the actual project talk page to say that the color heading presents any accessibility issue in specific.

The issue doesn't pertain to the particular color in use (which I wouldn't mind seeing replace the standard grey). The problem (as I understand it) is that these tables exclude the "wikitable" class, thereby circumventing users' custom settings intended to restyle the tables to meet their needs. This concern also applies to the text size, which has been reduced.

Do you expect individuals to add the "filmography-table" class to their CSS files? If so, do you then expect them to add countless other classes as the myriad WikiProjects decide to introduce them for no other reason than to suit their arbitrary preferences (thereby constructing a patchwork encyclopedia)?

The issue that brought about the creation of the filmography heading template was the ability to make changes at one place that would carry throughout the articles using that style.

Right, and you just reverted two users when we attempted to make such a change.

The template was created and it had slowly begun to be used in that spirit. But essentially, if you are mandating a change to the template that was developed to address the point that changes can't be made across the board, then it is useless and won't be used, so the changes made to the template today are moot.

So...the template intended to enable across-the-board change is rendered useless when it's used to make an across-the-board change? Or does this only apply to changes that you dislike?

No one is "mandating" anything, aside from our stubborn insistence that your WikiProject provide a rationale for deviating from the community's standard styling beyond "we feel like it" (scare quotes).

Mostly what I see us being handed is a "we don't like it and you can't do it, there is no place for originality in projects here".

And what I see is the Wikipedia community being handed a "we don't like it, so we're going to ignore Wikipedia's standards and do what we please." And it troubles me greatly to see you continually refer to the articles in question as parts of your WikiProject (rather than the Wikipedia project).

If you don't like the styling of that heading...

This has nothing to do with which style is preferable. It's about standardization (on one style or another).

It would be quite nice if you tried to work with us instead of dictating to us what you will and won't permit.

Ditto. —

David Levy

04:22, 28 May 2009 (UTC)

David Gothberg was good enough to work up a template for us to use, the filmography-table class was included in that template, I don't know where that class came from. If it needs to be wikitable class, then again, help us develop the template to include the color. Ms2ger asked what happened if different projects under which an article falls want different things for the same content and my response was that it didn't normally happen because various projects concern themselves with different aspects of an article's content. Actually, his question was mostly concerned with color, and despite your rather snippy response to my answer, in the particular case of one project concerning actors/filmmakers in particular, WP:WikiProject Biography would not be addressing the specifics of tables for an actor's work, it would be addressing aspects of a biography as a whole. The two do not conflict. If other projects want to use the template, then fine, that's another good reason that the column headings not be incorporated into the template. In any case, then help us develop the template to use that allows the use of color without having to hard code into the individual columns. If the use of color is objectionable as a whole, then why is it available? Wildhartlivie (talk) 05:47, 28 May 2009 (UTC)

Before I say anything regarding the discussion at hand, let me say something about accessibility. Due to my own vision difficulties, the font color you've used in breaking down my post for your response is illegible to me without opening the page.

I apologize for that. I've switched from green to blue. If that doesn't help, please feel free to change the color again.

Note, however, that I did nothing to override a hypothetical custom CSS file properly coded to display all talk page text in a certain color. The template code in question, conversely, circumvents code intended to display all wikitables in a certain manner.

Once more, the table has been in use since the advent of the project, no one objected to its use until the color of the heading was changed.

Your point being?

I wasn't involved in the development of the project and I am not the only member of the project.

No one has stated anything to the contrary.

Any use of "you" in your lecture to me about misunderstanding the role of a project isn't to me personally, it is to the entire project,

No, I was addressing only you in that instance, as no one else (participating in this discussion) is claiming that WikiProjects are entitled to dictate articles' content by overruling community-wide consensus in favor of their own.

and your examples aren't nearly the same in comparison. No one at

WP:ACTOR

is trying to determine what qualifies as notability or exclude articles based on some arbitrary criteria, so I find your comparisons unconvincing.

I was making a general point, but okay. If you want to stick purely to aesthetics, a WikiProject's decision to present "its" articles in a custom typeface wouldn't stick either.

The other project I'm most involved in is

WP:FILM

and they most certainly have MOS guidelines that cover how something regarding films in specific is recommended for display. Those go beyond the existing MOS.

Right, they go beyond the general style guidelines (to address matters of greater specificity). They don't supersede them.

Note also that there are no private, WikiProject-controlled MoS entries. While much of the MoS is contributed by WikiProjects, all of it is subject to acceptance by the entire Wikipedia community. As I previously noted, however, the natural assumption is that the WikiProject members (guided by their knowledge of the specific subjects) generally will author reasonable additions reflecting commonsense implementations of the broader standards already in place.

I didn't create the original recommended table format, however, I did agree that the color of the heading was preferable.

I quite like it. Why not propose that it be adopted as the new standard? What, in your assessment, sets filmography tables apart (from a practical standpoint)?

There is no compelling reason why a project should not be able to that in regard to format for tools used in the project.

To which "project" are you referring? A WikiProject or the Wikipedia project? You appear to mean the former, which continues to be rather disconcerting; the articles in question are parts of the encyclopedia proper.

And let's be quite clear, we're talking primarily about a table to display filmwork that is in common to each article in the project in an organized manner. That in particular is all about consistency of those articles.

There is consensus within the English Wikipedia project to maintain standardized styles across all articles (not merely the ones of interest to a particular group of editors).

The heading color of the table was changed from what had been used for a few years now, the construction of the table is no different than any other table anywhere on Wikipedia. Projects determine the content and styling of their infoboxes all the time, and that too includes the use of color, which is contained in a template. Navboxes and templates incorporate the use of various color all the time and there is no objection to that, regardless of the color combinations used and whether they interfere with visual accessibility.

I've seen many templates that are color-coded for differentiation from other templates with which they're frequently stacked (thereby providing a useful navigational aid). What distinction[s], other than "these are our pretty tables," is your WikiProject drawing (and how does this benefit the articles' readers)?

I stated quite clearly if you can suggest a way to use the color heading in the wikitable without having to add separate style coding for each column each time it is used, then by all means, share that.

And I stated quite clearly that I oppose the use of a nonstandard color heading. (However, I don't object to the idea of making your preferred color the new standard.)

You didn't respond at all to any of those comments I made above, so am I to assume you don't have suggestions to fix that?

Why are you asking me to supply a means of accomplishing something that I oppose?

The whole purpose of creating the template was to help address concerns about style, so fine, the use of a template to do that shouldn't be an issue. Help us develop one to use color in the heading that doesn't require having to insert separate coding each time. That makes it difficult to construct for newer editors.

Please see above. (And for the record, I'm far from a coding expert.)

It's important that the color be included in the template so that we have the flexibility to add additional columns occasionally for whatever reason.

You've yet to explain why it's important that your WikiProject use nonstandard styling for the tables that it places in the encyclopedia.

David Gothberg was good enough to work up a template for us to use, the filmography-table class was included in that template, I don't know where that class came from.

I assume that David invented it for the template. While this is better than including no class, it only benefits users with custom CSS code for that specific template.

If it needs to be wikitable class, then again, help us develop the template to include the color.

Again, I oppose the inclusion of nonstandard coloring, for which I've read no rationale other than your WikiProject's opinion that the standard coloring is "plain and bland." Regardless, I truly don't know how to accomplish what you're asking.

Ms2ger asked what happened if different projects under which an article falls want different things for the same content and my response was that it didn't normally happen because various projects concern themselves with different aspects of an article's content.

And again, that brings us to Ms2ger's question about "[making] it depend on what the table is about." Why should another table within the article use a different style? And what sets the filmography table apart from other tables that justifies a nonstandard style?

If the use of color is objectionable as a whole, then why is it available?

Are you suggesting that the option's technical availability reflects its appropriateness? It's possible to render articles in

David Levy

07:29, 28 May 2009 (UTC)

• Note: After reverting twice, Wildhartlivie has responded to the template's standardization by a third editor by manually replacing it with the nonstandard styling in numerous articles (without edit summaries). —
  David Levy
  07:47, 28 May 2009 (UTC)

• Note: The template's standardization... what a novel way to put it. The template's change, a new and little used tool, was essentially forced by a couple adminstrators. The template has only existed for perhaps 5 weeks, it was only in use on approximately 120 or so articles and has only added sporadically. Of those 120 or so articles, I created the filmography table from either a bare list, or in some cases, added the entire filmography where there was none, on somewhere around half of those in the last month. There obviously is no standard that requires that the template be used, the template was put on those articles by myself or another editor. Wildhartlivie replaced the template on some 15 or so articles where it had only been used on a very limited number of articles. Please do not misrepresent what I was doing. It's quite obvious that any comments I post here will be broken down into sentences, snippy comments or hyperbole such as the "giant, yellow Comic Sans" example be posted after each, and in the end, what it all says is that the tool developed to save some work isn't going to be acceptable except in a form that accomplishes nothing, so the use of it is moot. At the moment, I see no point in trying to discuss or try to explain anything, because every statement I have made brings the same type of response. Meanwhile,
  WP:ACTOR have a large quantity of content displayed in tables, which is the manner in which the project decided would be the best way to display it in a meaningful way. That was a good decision because it's difficult to include large lists of films, the roles played, other notes regarding it and the awards earned in the process in a way that organizes it concisely for easy viewing and at a glance comprehension. Other articles that have large amounts of content can break up the monotony of it with images, but we can't use those in the filmography. That is why color is used in so many table headings. It breaks up the monotony. Featured list criteria even suggests the use of color where possible. There's a lot more inconsistency on Wikipedia than in the relatively small number of articles that have filmographies. It doesn't necessarily benefit the reader, but it also does not present a detriment. Personally, I don't see how the color in table headings is that great an issue or why color is such a deviation from what otherwise is standard use of tables. The difference between what the actor project is doing that differs from other projects that use tables is that we tried to make it consistent for the filmography/filmography and awards tables that we use. I don't see how that differs from the styling used with color in infoboxes, various footer templates, succession boxes and navboxes. Some even change colors depending on whether a person is dead or living. Yet the infoboxes are also standard within in a project and differ from project to project, yet there is no outcry that it deviates from some community wide standard. Each overrides use preference settings. In any case, there isn't a snowball's chance that anything I say in response will suffice. Wildhartlivie (talk
  ) 09:26, 28 May 2009 (UTC)

The template's standardization... what a novel way to put it.

How so? Do you deny that their code was switched to the Wikipedia standard?

The template's change, a new and little used tool, was essentially forced by a couple adminstrators.

Two of the three editors to standardize the template (including me) are administrators, but no administrative tools were used, nor was the fact that we're administrators even mentioned (except by you). A far less misleading statement is that the template was standardized by three different users, the first two of whom you reverted. When a third reverted back, you began removing the template from articles.

The template has only existed for perhaps 5 weeks, it was only in use on approximately 120 or so articles and has only added sporadically.

Your point being? You obviously thought that the ability to edit the style in one location was a good idea...until this was done in a manner not to your liking, at which point you declared that the template would not be used and should be deleted and began replacing it in articles (with hard code lacking even a class enabling custom tweaks) without the use of edit summaries (a process that appears to be ongoing).

Of those 120 or so articles, I created the filmography table from either a bare list, or in some cases, added the entire filmography where there was none, on somewhere around half of those in the last month.

Meaning that you therefore

possess special authority to control

these tables?

There obviously is no standard that requires that the template be used, the template was put on those articles by myself or another editor.

...and removed by you when other editors had the audacity to edit the template in a manner not to your liking.

Wildhartlivie replaced the template on some 15 or so articles where it had only been used on a very limited number of articles.

Seventeen replacements (so far) with zero edit summaries. Why are you referring to yourself in the third person?

Please do not misrepresent what I was doing.

How have I done so? What false or misleading statements have I made?

It's quite obvious that any comments I post here will be broken down into sentences,

Yes, I often take the time to quote people's statements/questions and address them on an individual basis. Why does this offend you?

snippy comments or hyperbole such as the "giant, yellow Comic Sans" example be posted after each,

In case you thought otherwise, I wasn't suggesting that the situation at hand is comparable. You appeared to imply that custom style code must be appropriate or its use wouldn't be possible, and I responded by pointing out that no such styling (no matter how ridiculous) has been barred at the technical level. And believe it or not, I actually have seen editors attempt to use Comic Sans and various other typefaces in arbitrary articles.

and in the end, what it all says is that the tool developed to save some work isn't going to be acceptable except in a form that accomplishes nothing, so the use of it is moot.

It enabled users (particularly those with accessibility issues) to customize the tables' display. (This was more difficult in the pre-standardized version, but at least it was possible with some effort). Now you're stripping away that capability (with no rationale other than a WikiProject's desire to use tables that it subjectively regards as prettier).

Meanwhile,

WP:ACTOR

has used a table format that only differs from a myriad of other tables by a bit of coding difference,'

...causing the inability of users with special needs to customize the tables for improved accessibility.

yet there are featured articles, featured lists, good articles and the like all across Wikipedia that incorporate the use of color in many places.

No one has opined that color should never be used. The point is that it should represent something meaningful (not merely a WikiProject's determination that the standard style is "plain and bland") and not be implemented in a manner that harms accessibility.

The articles at

WP:ACTOR

have a large quantity of content displayed in tables, which is the manner in which the project decided would be the best way to display it in a meaningful way.

And I endorse that decision. But you've yet to cite a valid reason to deviate from the standard table style (let alone to do so in a manner that renders content less accessible).

That was a good decision because it's difficult to include large lists of films, the roles played, other notes regarding it and the awards earned in the process in a way that organizes it concisely for easy viewing and at a glance comprehension.

Agreed. Now please explain how the use of standard tables fails to accomplish this.

Other articles that have large amounts of content can break up the monotony of it with images, but we can't use those in the filmography. That is why color is used in so many table headings. It breaks up the monotony.

I'm not sure that I agree, but let's assume that this is the case. What sets filmography tables apart from other tables? In other words, why shouldn't the "monotony" be broken in all articles containing tables?

Featured list criteria even suggests the use of color where possible.

The "suitable" use of color is recommended. Random use it not. As I've already noted, content can be color-coded in a meaningful fashion that enhances labeling and navigation. That isn't what we're discussing here. We're discussing a decision to use nonstandard styling because of the opinion that the standard style is "plain and bland" (your words).

Again, why don't you propose that your preferred style become the new standard? Does this stem from a desire that your WikiProject's tables be special?

It doesn't necessarily benefit the reader, but it also does not present a detriment.

I've repeatedly explained that it does present the detriment of reduced accessibility. You acknowledge that the reader doesn't benefit, so what is the justification?

Personally, I don't see how the color in table headings is that great an issue or why color is such a deviation from what otherwise is standard use of tables.

The standard use of tables enables readers to address their accessibility needs via the use of custom CSS code.

The difference between what the actor project is doing that differs from other projects that use tables is that we tried to make it consistent for the filmography/filmography and awards tables that we use.

Using the standard style would make these tables consistent with each other and the other tables used throughout the encyclopedia. The deviation in question has reduced consistency.

I don't see how that differs from the styling used with color in infoboxes, various footer templates, succession boxes and navboxes.

I've repeatedly explained the differences.

Some even change colors depending on whether a person is dead or living.

Yes, and that's a meaningful difference; it actually conveys information to the reader. Using a subjectively prettier style for arbitrary tables does not. —

David Levy

18:24, 28 May 2009 (UTC)

As you are aware from your post on my talk page, I do have issue with my comments being broken down for the convenience of making points off each sentence. It has the feel of attack, whether that is your intent or not, because in doing that, you tend to make statements that are more effectively simply scoring points ("Why are you referring to yourself in the third person?" - because I originally started my response in a repetitive manner to the note you made and then changed my mind) and probably do not normally occur in a unhacked response. That's why it offends me. I have repeatedly said I didn't do anything that wasn't already in place as a recommended table and that already existed and was in use on multiple articles. I personally didn't go about on a crusade to strip away anything. And my reference to "the tool" was the template itself.

Since I was primarily the one who was inserting the template, and I won't be using it anymore, the statement on the template talk page is fact. Its existence is moot to me. It's not clear whether your comment of "a process that appears to be ongoing" is in regard to replacing the template. If so, it is factually untrue. I have not replaced the template since I posted the response above. If it is in regard to edit summaries, no, I don't always make an edit summary. Then again, I don't always not leave an edit summary. Using that to make some point isn't valid, implies meaning that isn't there and seems to reflect some erroneous judgment on your part about intent. No, my statement regarding the work I've put into building, adding and expanding filmographies wasn't to imply ownership, but that's a fairly disengenuous WP admin response when anyone mentions the work they've done. Just as the color changes in the actor infobox changes to reflect whether an actor is living or dead, the color in the heading reflects that the content is a filmography. Neither is particularly necessary, not in the infobox, not in the table heading color, but it does have meaning, which is not particularly true of the colors used in various other tables in which there is no consistency or meaning whatsoever. (Ref. the remark by

Katharine Hepburn filmography). The monotony should be broken on other tables, I have no issue with that. If the music people want to use some given color to indicate discographies, there should be no valid reason not to chose a representative color, just as different color headings in infoboxes have a meaning - it reflects what category it is in. That would reflect consistency as well. In the past, at least some filmographies used images, but that fell into disfavor because of non-free image use rationale, so no, it's basically not possible to break the monotony with images therein. I cannot construct an argument that would suit you regarding color headings in tables because you have a blanket view that none should be used. No rationale would seem to change that, despite the fact that if a certain category of tables used to display one certain category of information uses one specific color in the heading, then it does have meaning. And wikitables can be coded to use color, it's just a pain in the rear to use, but it is used all the time. If that is truly a detriment to accessibility, then there needs to be a blanket policy prohibiting its use. No, random use of color is simply that, random. That's why the project chose a color, other than the one that had been in use for several years. Wildhartlivie (talk

) 22:04, 28 May 2009 (UTC)

No, I don't care to explain why I sometimes make edit summaries and sometimes I don't.

Okay, but neglecting to do so inconveniences other users.

I don't particularly have a reason, if I have something relevant to say regarding whatever edit I've made, I make an edit summary, if not, I don't.

The summary "replaced filmography table template with raw code" (or something similar) would have been relevant.

I leave them more often than I don't.

That's good, but it would be more helpful to leave them most of the time.

I also don't feel the need to make a statement regarding ownership, nor will I do so.

That's your prerogative, but you already have made several comments that appear to convey the belief that you possess special authority to dictate articles' content. I don't know how else to interpret your statement that the template should be deleted because you have decided not to use it.

Three years worth of work over tens of thousands of edits on thousands of articles and my working relationship with various editors makes its own statement.

Indeed, it does, and no one has asserted that you aren't a good editor.

I don't propose a new standard color for table headings because 1) I have no idea how one would go about doing so,

Wikipedia:Village pump (proposals)

2) it is far beyond the scope of what I think any one person can do

Every proposal has to begin with someone (or nothing would ever be proposed). Of course, you would have my backing (and presumably that of the WikiProject's members).

and 3) what forays I have experienced in matters of Wiki-policy is far too stressful for my health to stand it.

This is not a matter of policy.

This conversation is skirting on that and I try to reserve my attention focus on keeping people from arbitrarily adding that some person or another is a pedophile, an anti-Semite or a homosexual - all

WP:BLP

issues I've dealt with lately.

And you are to be commended for that. I mean this sincerely.

I would be interested, however, in seeing the precise community wide discussion in which it was determined that tables would not use color for its headings and where it is written that color cannot be implemented in them.

That would be the same page on which it is stated that articles are not to be written in giant, yellow Comic Sans.

In other words, that isn't how Wikipedia works. When consensus dictates, we create site-wide standards, and the onus is then on others to demonstrate consensus for changes/exceptions (and a WikiProject's consensus does not equal or supersede Wikipedia consensus).

It's not wikilawyering,

It really is, even if unintentional. How can you expect there to be a written rule for everything that should not be done? No offense, but I'm reminded of a user who continually performed edits such as this to her favorite articles and demanded that others cite specific policies against the precise changes that she made.

You appear to have stopped addressing the accessibility issue, which remains the more important concern (IMHO). —

David Levy

04:41, 29 May 2009 (UTC)

Table Modifications are allowed

Since there are instructions on how to modify tables, located at Help:Table, one must infer that table modifications are allowed. Therefore, a Template of the most common and frequent table modification would seem efficient. —Preceding unsigned comment added by 98.71.213.107 (talk • contribs)

No one is claiming that modifications of table appearances are 'not allowed'. Tables can and should be modified in style when there is a valid semantic reason to do so. "It looks nice[r]" is not a valid reason. Happy‑melon 20:39, 31 May 2009 (UTC)

The documentation on wikibooks:Editing Wikitext/Class and Style Notes is wrong. It seems to suggest that the purple heading is original, and to make the heading the same color as the cells more code must be added. Is there anywhere else that correctly documents the wikitable class?74.178.246.115 (talk) 03:28, 1 June 2009 (UTC)edited74.178.246.115 (talk) 03:30, 1 June 2009 (UTC)

The Wikibooks implementation of .wikitable is different to our implementation; notably it uses a different colour for the table header. As David has said several times above, there is no reason why the standard wikitable style can't be updated if a superior style is available; only that deliberately declining to use the standard features purely because "it looks nicer" is not a valid justification. Happy‑melon 08:31, 1 June 2009 (UTC)

Oh, let's be perfectly clear. There was more than just a little more rationale given and discussion attempted above than "it looks nicer". That is how everything I said was dismissed, but it isn't a valid summary of it. It's the comment that was paraphrased and used to characterize a number of points I made, and it's really misleading to represent it as such. The wikitable can be coded for color although it is a lot more trouble. It seems perfectly ridiculous to me that so much is made of an effort to use a table head color for a specific purpose when a wikitable is used to produce tables such as on Rafael Nadal career statistics. Somehow I doubt that anyone bothered to check whether those interfere with viewing by someone who is colorblind. I don't accept the dismissal of color table headings used to indicate filmographies vs. a discography, for example, yet approval indicated for color used in infoboxes and templates to convey a meaning. That's a little too convenient a distinction to make and I don't find it valid. I also don't expect anything I say to change that viewpoint, but geez, let's don't trivialize me quite to death. Wildhartlivie (talk) 09:45, 1 June 2009 (UTC)

Yuck. If anything, that article is a fantastic justification of why gratuitous use of nonstandard colours should not be condoned. Some use of colour is appropriate: green and red for winning and losing, gold/silver/bronze for medals, etc. Much of the colour used on that page is, as far as I can tell, completely gratuitous and should be removed. To argue that the fact that such an article exists is justification for similar misuse of styles is the basis of

WP:OTHERSTUFFEXISTS

: rather, that article is equally wrong and equally in need of fixing.

There's certainly a lot of material in the discussions above, so it's perfectly possible that I've missed your other reasons, but I have to say I'm not seeing them. My apologies if I have not given a representative summary, but would you care to provide such? I don't particularly care about the template vs hardcoded styles, about how the styles are being implemented or for how long and by whom. Why does WPActors consider it productive to implement nonstandard styles on filmography tables? Happy‑melon 10:04, 1 June 2009 (UTC)

An Athlete's page in this discussion is unproductive. The situation where an Actor is also: Producer, Director, Writer, or some other Crew Member on a film leaves the editor with the need to vary the table. The Jackie Chan filmography vaguely and imprecisely uses the word "Role" to discribe EVERYTHING, but uses the standard table. The Woody Allen filmography decides to use colors to mark his film contributions. Mel Gibson's page includes his filmography as it is not a long as Jackie Chan's, but separates his contributions in different tables. Is a template modifying the wikitable needed under these conditions? If so, what format should be used for Wikipedia:WikiProject Actors and Filmmakers?74.178.203.43 (talk) 16:43, 1 June 2009 (UTC)

All of these are legitimate ways to create semantic clarity in articles. None of these are examples of the issue at hand. The tables in Mel Gibson would not suddenly become incomprehensible if they used the wikitable style; there would be a trivial change in the colour of the header. Why is it necessary for the colours of the table headers in Mel Gibson to be different to the colour of the table headers in Demographics of France, to pick a random example? Or different to the table headers in List of highest-grossing films?? Happy‑melon 16:59, 1 June 2009 (UTC)

If you would, I need to postpone further discussing this until I have had the eye surgery that is scheduled for tomorrow. I have a lot of difficulty tracking through longer discussions and expect that to be quite improved after I recuperate from the surgery. I do want to say that an athlete's page in this discussion was productive as it was a glaring example of indiscriminate use of color within table text that has no apparent meaning. You don't find tables on actors & others pages doing something that extreme. If one comes down to why is it necessary, nothing at all anywhere is particularly necessary, be it colors in a table heading, use of images, colors in infobox headings, or any other application. We would still have an encyclopedia full of text, but nothing else. I've said too many times now that wikitable can be used, modifications are possible in them for anything, even when it borders on the ridiculous, which again is why the Rafael Nadal page was mentioned. I'd truly like to postpone this until later in the week sometime until after my surgery when I am better able to sort through any lengthy discussions, etc. without developing migraines! Wildhartlivie (talk) 21:06, 1 June 2009 (UTC)