Template talk:Episode list/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

Formatting problem

I'm not sure if this is a problem with the template or just a stupid formatting error at the page, but it appears that List of Burn Notice episodes didn't get hit with the recent unbolding of the title column. None of the articles related to it have been edited in the past several days (apart from a few minor changes that shouldn't affect the charts), so I'm not really sure what the problem is. It also looks like there is a problem with fields that have not yet been filled, as they are showing three apostrophes followed by a bolded quotation mark. List of Monk episodes, List of Psych episodes, List of The Office (U.S. TV series) episodes, and many others are doing the same things, it appears. I've narrowed it down to possibly being a problem at Template:Episode list/sublist, as the majority of these articles use it rather than the main template. I'd go ahead and fix it myself, but I don't feel confident doing that since it's used on so many pages. Would someone mind taking a look at this? Thanks. Kevinbrogers (talk) 22:29, 9 May 2012 (UTC)

Yes, it seems that someone has decided they would bypass the decision made here, and apply bolding to the subtemplate. It should be fully protected like this one. 117Avenue (talk) 01:57, 10 May 2012 (UTC)

Thanks. That seems to have fixed it. Kevinbrogers (talk) 02:01, 10 May 2012 (UTC)

TopColor broken

Since the recent template changes, episode tables using "TopColor" now have the Title cell with a white (or at least pale grey) background, while the rest of the episode header row follows the colour specifed by TopColor.

Or is this just a sign that TopColor is the next formatting to be expunged? There is nothing at Template:Episode list to say this parameter is deprecated.

Example:

No.	Title	Director	Original air date
1	"New Blood"	Tim Haines & Jasper James	16 April 1999 (1999-04-16)
The episode followed ...
2	"Time of the Titans"	Tim Haines & Jasper James	23 April 1999 (1999-04-23)
This episode followed the life of a young female ....

Barsoomian (talk) 01:04, 18 May 2012 (UTC)

Hi Barsoomian. Yes, one of the "issues", if you like, is that |scope="row" overrides any specified shading for the cell. We're already aware of it from test case 3. Surely you like it though? Does it not allow you to find the episode title quickly, almost as if it highlights it now that bold face is gone. :) Matthewedwards (talk · contribs) 04:28, 18 May 2012 (UTC)

Oh yes, it's really beautiful. How rude of me not to be grateful for this wonderful enhancement. So does "aware of it" mean it's going to be fixed, or are you just going to remove the TopColor functionality entirely so we won't be tempted to use sinful formatting? Barsoomian (talk) 05:28, 18 May 2012 (UTC)

If you can dispense with the histrionics, I'll be happy to reply. But it's 20 past midnight, so it won't be until tomorrow. Matthewedwards (talk · contribs) 07:19, 18 May 2012 (UTC)

"Histrionics"? You're beginning to sound like my stalker friend. I didn't give you a deadline or make any demands, I know how pointless that would be, just reported it. Barsoomian (talk) 07:48, 18 May 2012 (UTC)

The column headers would benefit from having a column scope set. This is how the default table looks:

No.	Title	Director	Original air date
1	"New Blood"	Tim Haines & Jasper James	16 April 1999 (1999-04-16)
The episode followed ...
2	"Time of the Titans"	Tim Haines & Jasper James	23 April 1999 (1999-04-23)
This episode followed the life of a young female ....

Is the table below what you want it to look like? It seems you need an #if to test whether {{{TopColor}}} exists and if so, to set that background-color on the TH tag in the row. Shouldn't be too hard.

No.	Title	Director	Original air date
1	"New Blood"	Tim Haines & Jasper James	16 April 1999 (1999-04-16)
The episode followed ...
2	"Time of the Titans"	Tim Haines & Jasper James	23 April 1999 (1999-04-23)
This episode followed the life of a young female ....

I'm not sure what purpose the other inline coded styles serve. Perhaps if someone could explain what they do, others might be able to see how to achieve what you want. --RexxS (talk) 00:18, 19 May 2012 (UTC)

What "inline coded styles" are you talking about? If the thick lines, and colour, the particular article this was excerpted from has a very long "ShortSummary", with several subsections, and a list or two. It isn't just a paragraph of plain text. So it needed more structure and the coloured headers and lines made the divisions between episodes clearer. It wouldn't be necessary if it really was as short as the example above. In context, the layout is appropriate. Barsoomian (talk) 12:45, 19 May 2012 (UTC)

Have a look at the code you used for your example and then compare it with the code I used for the default. The difference is the "inline coded styles" that I referred to. Are you saying that if the "ShortSummary" wasn't actually short, then viewers would need coloured rows and borders to be able to see which episode was which? --RexxS (talk) 15:45, 19 May 2012 (UTC)

The code is different, obviously. Mostly in your use of "scopes", which I'm not familiar with. But I still don't know which elements you are referring to as "inline coded styles", or why it's important. I can read HTML. Wiki markup is another matter. I mostly cut and paste and use trial and error, if it works, it works and I leave it alone. Otherwise, I'm not saying readers "need" anything. All they "need" is text on the page. I do believe that it is not a bad design choice, given the amount and complexity of text. But I didn't use this example to ask for opinions on a particular article, let alone have to defend my design in a review. It doesn't matter if it's well designed or not. It used legal wiki code, and was broken by the recent changes. That's the only thing that's relevant here. Barsoomian (talk) 16:34, 19 May 2012 (UTC)

That's neat. I wonder how it works in transclusions. Matthewedwards (talk · contribs) 01:25, 19 May 2012 (UTC)

Not well, it seems. At Walking with Dinosaurs it's not a problem but on articles that transclude there's no {{episode list}} so it just transcludes the entire table, including captions and thick lines. Is there any way at all to make it do this with the template? Matthewedwards (talk · contribs) 01:40, 19 May 2012 (UTC)

Well, if this was transcluded then it would be the responsibility of the person doing that to make adjustments as necessary. Since this series had one season of 6 episodes in 1999, that seems a very hypothetical problem. Barsoomian (talk) 12:45, 19 May 2012 (UTC)

I'm sorry I wasn't clear. The last table I wrote was simply a wikitable, and I was asking if it resembled the output Barsoomian wanted. It is only a demonstration that the output is feasible, but it would need to be coded into the {{episode list}} template if there were consensus on what was wanted. I was not suggesting using wikitables as an alternative to the template that project editors are familiar with. I'm just trying to get the folks here to agree on what is wanted so that the fixing gets done once. --RexxS (talk) 15:45, 19 May 2012 (UTC)

Yes, thanks, it does look almost like the original format, (well, except missing bold titles). Barsoomian (talk) 16:34, 19 May 2012 (UTC)

this will fix TopColor. Reused a switch that we were already using in the template itself to make this work. It also changes the title cell from TH to TD when there is no summary and it's a straight up list, so it wouldn't be of any help to screen readers in that case (might actually make navigation worse there). Tested against several examples. -- Ned Scott 21:06, 20 May 2012 (UTC)

Err, Why would we want it to remove TH? Matthewedwards (talk · contribs) 00:07, 21 May 2012 (UTC)

In only one case would it be removed, and that is if there is no summary. It wouldn't make any sense for a screen reader in that plain-table format. -- Ned Scott 07:17, 22 May 2012 (UTC)

Okay, for the sake of getting the fix in so the template doesn't look so awful on season pages:
this has the fix applied, but minus the TH/TD switch. -- Ned Scott 07:25, 22 May 2012 (UTC)

oops, didn't see the edit request below. -- Ned Scott 07:27, 22 May 2012 (UTC)

Reimplemented

In response to the above I had a dig through this codebase and it's... not pretty. I've gone through it and reimplemented it in mostly-wikicode, with a sane way of checking empty parameters (just check if they're supplied, rather than comparing them to some random Unicode character...) and judicious use of line breaks. Can someone have a look at the sandbox and test cases and kick the tyres to ensure everything's working okay (including the colour fix from the section above)? If so I'll sync. At this time I haven't included Ned Scott's proposed change to the header if no summary is provided, pending further discussion. Chris Cunningham (user:thumperward) (talk) 12:54, 21 May 2012 (UTC)

Remember, the reason for the odd parameter checks is so that a cell will force open simply by having a parameter listed, but not filled out. -- Ned Scott 07:14, 22 May 2012 (UTC)

Yeah, just looked at your version and no way that would work. Trust me, we weren't crazy when we came up with the current system and if that was all we had to do then we would have avoided a lot of challenges :)

I do have a pure wiki-code version that I made for a 3rd party wiki somewhere that I could probably update to be back in sync with this copy. I never bothered proposing that version here since Wikipedia is able to mix HTML and wiki code in more ways than most MediaWiki installations, and the HTML-mixed version is easier to edit. -- Ned Scott 07:21, 22 May 2012 (UTC)

The way MediaWiki handles conditionals has changed considerably since this code was created. An empty conditional will evaluate as false if tested by itself, which is what we do here. There should no need for obscure hacks any more. I will, of course, confirm this before pushing any changes. Chris Cunningham (user:thumperward) (talk) 09:18, 22 May 2012 (UTC)

I might not have edited Wikipedia extensively in years, but I do extensively edit on other MediaWiki installations that are up-to-date with the software. What I am talking about has not changed, and your version will not work. See the discussion below for my example sandbox. -- Ned Scott 22:58, 22 May 2012 (UTC)

Reference order

Now with a greater forum, I hope to pass a proposal I made in February 2011. This template causes references to appear in the incorrect order. For example see test case 4. I propose a null if statement at the beginning of this template, with all parameters, in the correct sequence, to be added. Referencing is an important part of Wikipedia, and in making a good article, I hope this issue no longer gets overlooked. 117Avenue (talk) 03:33, 18 May 2012 (UTC)

I saw the original discussion about this but it had already died down. I think it's a good thing to do this. It's not even about just citing future stuff. If people want to cite directors, writers and airdates for old episodes to book pages or web pages they should be allowed, instead of being told "don't, the episode cites itself". References in prose appear in numerical order, and when we use multiple references to cite a single sentence we're told to order them numerically. I don't see why we shouldn't have references ordered numerically as we read left to right and down through the episode lists. This is a simple fix and I don't think there's a reason not to do it. Matthewedwards (talk · contribs) 04:00, 18 May 2012 (UTC)

List of Winx Club episodes

http://en.wiki.x.io/w/index.php?title=List_of_Winx_Club_episodes&oldid=493272346 this one is delbriate adding bolding overriding the template can someone remove it--Andrewcrawford (talk - contrib) 08:29, 19 May 2012 (UTC)

 Done. I'll watchlist it. Matthewedwards (talk · contribs) 16:27, 20 May 2012 (UTC)

Transclusion Overload

As matthew found when converting time team from teh show hack i made to sublist it causes transclusion overload due to amount of templates it is transclusion which is caused by that article using coordinates. Not sure if it is possible but could we create a |removefield= which in time team case would have |removefield==Aux3 and in trasncusion it automatically removes that field meaning time team could use sublist so removing another show hack--Andrewcrawford (talk - contrib) 08:41, 19 May 2012 (UTC)

I suspect this would be done liek this pseudo code not wiki code, if removefield is present, for list of x removefield from list of x probally quite hard code but would allow th time team show hack to be deleted--Andrewcrawford (talk - contrib) 14:04, 19 May 2012 (UTC)

It's not really feasable to remove alt3= (or any other fields, for that matter) from tanscluding just for one article. If we did, all the other articles that use the field would also have it removed. Maybe it's better not to transclude in this case, and to use normal wikitable markup. Or just retain the show-specific hack. Matthewedwards (talk · contribs) 03:32, 20 May 2012 (UTC)

Unfortnally befor ei had split it out it was over 180kb it breaks teh size limit so has to be split, we could jsut get rid of the list but it defies the point ofa ;list which is to have jsut the episod einformation wihtout summaires, maybe this might be one thata show hack cant be removed. i dnt know wiki programming code that well but wha ti have seen it owuld be possible to remove a field from and particular list just require very complex code to do it, if i can understand the wiki code i can probally design it--Andrewcrawford (talk - contrib) 14:42, 20 May 2012 (UTC)

If you're talking about List of Time Team episodes, it was only 107kb at the time you split it.[1] However, that was the file size and WP:ARTICLESIZE refers to the amount of readable prose, not the file size. At the time you split it, there was only (using a very loose definition of readable prose), less than 1kb of readable prose. --AussieLegend (talk) 15:34, 20 May 2012 (UTC)

That diff just had directors and coordinates removed. The diffs for switching to transclusions of individual season pages is [2] which removed 28676 bytes of data, most of which -- table code and template parameters -- does not count towards page size like you said.

The season pages are too small and too void of detail to really justify them as stand alone articles, it's obvious they were created to circumvent the transclusion limits. The problem still remains, though, that if we merged all the tables back in to the main list, 268 (and counting) instances of {{episode list}} and {{coords}} are going hit the transclusion limit and break the page. Matthewedwards (talk · contribs) 16:24, 20 May 2012 (UTC)

I never tried to cirventset teh transclusion limits, i really thought the page exceeed the 100kb limit i wasnt aware because of hwo i read the guideline due to my dsylexica i misunderstood it, the question is how to achive the goal oh i have seen otehr people split article for far less size or information but that is no excuss--Andrewcrawford (talk - contrib) 17:02, 20 May 2012 (UTC)

I must admit that I haven't delved too deeply into it but this seems to work fine. --AussieLegend (talk) 17:32, 20 May 2012 (UTC)

it does seem fine the question is why, but that is not using transclusion but hte page is really long and sort of unreable due to length the summaries really shouldnt be there but i if it working i have no objections to it being there but im baffled why it working and it didnt for me or matthew--Andrewcrawford (talk - contrib) 19:59, 20 May 2012 (UTC)

It wasn't working for me because I was still transcluding from the season pages. This does away with season pages, so there is far less to transclude. Matthewedwards (talk · contribs) 23:50, 20 May 2012 (UTC)

List of Degrassi: The Next Generation episodes

i aint sure why this has a show hack it is the same as teh sublist this should be converted also will need bolding removed from part epsiodes as it manually done in the list, ive removied bolding of the titels from teh template--Andrewcrawford (talk - contrib) 13:57, 19 May 2012 (UTC)

The subtemplate has a hack that reverses the director and writer columns (although the fields aren't currently in use). The other hack places references in numerical order (see #Reference order above. When the reference order numbering issue is addressed, this template will be deleted. Matthewedwards (talk · contribs) 03:50, 20 May 2012 (UTC)

the director and the writer are easily fixed, show hack isnt needed, basically all we do is where director field is jus tnow we make it writor paratmer, and wher ethe writer field is make it director parameter, what is seen will be no different but a hidden note will have to be placed on the page to say the director parameter is teh writer coloum and via versa, once the reference order is fixed which i think it should be as simple as copying the code on this hack to the main template then this show hack could go, in case your wondering i am trying to get it wher ethere no show hacks if possible ;)--Andrewcrawford (talk - contrib) 16:58, 20 May 2012 (UTC)

List of Iron Man: Armored Adventures episodes

This show hack isnt required it just be done to have 3 coloums for the different english air dates for america, canada and australia this can be achived using USA Airdate
Candian Airdate
Austrlain Airdate, it will require manul conversion then the show hack can be delted--Andrewcrawford (talk - contrib) 14:00, 19 May 2012 (UTC)

The pages could use "OriginalAirDate" for US, "AltDate" for AUS, and "Aux4" for CAN. The problem is that the template displays Aux4 after the production code. It seems rather convoluted, but we could add Aux5 to the template and put it after Aux4, then use AWB to change all articles that use Aux4 to Aux5. When that's done, move Aux4 in the template to before the production code, and it's fixed. Like I said, it's rather complicated and silly, and I don't think we need a fifth auxiliary parameter, so perhaps someone else has a better idea. Matthewedwards (talk · contribs) 03:50, 20 May 2012 (UTC)

And I suspect the "101", "102" etc production codes are made up. If they are we could remove that column and stick with aux4. Matthewedwards (talk · contribs) 03:56, 20 May 2012 (UTC)

Actually, the subtemplate is unnecessary and can be TfD'ed. It isn't even used in the article. Matthewedwards (talk · contribs) 16:50, 20 May 2012 (UTC)

DoneAndrewcrawford (talk - contrib) 16:55, 20 May 2012 (UTC)

Request edit to protected template

Please copy over exactly the code from this revision to the template.

Following the discussions and developments that have occurred over the last few days, I believe I've now incorporated everybody's wishes into a fully working template:

• At #way forward discussions were leading towards removing the rowscopes from the title cells and putting them in the episode number row, and this seems favorable oustide of this venue too. It's less intrusive all round as it removes the cell background shading from cells in the middle of the table and puts it in the left-most column, resulting in a more normal-looking table as exampled at Help:Tables; it makes the row header the first cell of the row; and according to AussieLegend who has access to a screenreader and has tested at the NCIS list, allows screenreaders to read the row correctly, whereas it currently does not.
• It incorporates 117Avenue's uncontroversial and sensible suggestion at #Reference order to place references in numerical order in the table, working left to right on the top row, and then any in the summary, as opposed to current practice which is to order references in the summary first then the top rop.
• It incorporates Ned's #TopColor broken fix, except it's been applied to the episode number cell instead of the title cell.
• It includes a new optional parameter, "|Viewers=", that I mentioned a couple of weeks ago and is uncontroversial. Editors will be able to use it to show the viewing figures for episodes. A great number of articles do this already, and it's becoming more widespread and popular but editors have to use an auxiliary parameter (usually "|aux4=") to achieve this. Benefits include freeing up "Aux4=" and that editors will feel encouraged to add viewing figures to lists that don't have them because there's a parameter to do so. A bot or AWB can also easily change all instances of "|Aux4=" to "|Viewers=" at any time with no damage to the tables because the new parameter is placed so that it immediately preceeds the Aux.

Examples in multiple uses and situation can be found at Template:Episode list/testcases, which show current template outputs vs sandbox outputs.

At the same time, please edit Template:Episode list/sublist with this (the talkpage for the sublist redirects here). This will correct an error in transclusion striping for irregular episode numbers, as seen at Template:Episode list/testcases#Sublist, and add the Viewers parameter.

One other thing, Taking into account the phrase "If it ain't broke, don't fix it", it doesn't incorporate Thumperward's recent tests to the sandbox that seemed to produced some errors, but that's not to say we can't experiment after this working version has been implemented. Matthewedwards (talk · contribs) 01:37, 22 May 2012 (UTC)

How about #"Hidden" episode summary? Where we can leave the ShortSummary parameter empty, and the summary row won't appear. 117Avenue (talk) 03:29, 22 May 2012 (UTC)

Didn't that go wrong last time? The diffs code the template in an entirely different way than current, more like Thumperward's edits. It will be easier to test if this template gets updated to the current sandbox so we can compare results. Matthewedwards (talk · contribs) 04:32, 22 May 2012 (UTC)

It's a simple change to the #if statements, diff, of course the sublist would have to be changed at the same time, diff. 117Avenue (talk) 04:58, 22 May 2012 (UTC)

I thought it would be more complex than that. And it works, tested at Template:Episode list/testcases#Short summary parameter defined. Matthewedwards (talk · contribs) 05:24, 22 May 2012 (UTC)

What you guys currently have looks great to me. Great job! -- Ned Scott 07:31, 22 May 2012 (UTC)

The codebase is broken. It's completely unmaintainable, fully of obscure hacks to work around no-longer-extant bugs in MediaWiki's conditional handling. As requested on my talk page yesterday, I've updated the sandbox with code which should provide the majority of the above requests (as it's based on the code you've modified) but with significant simplications to the syntax which should result in much easier maintenance in future. If there are still pending requests from above I am more than happy to incorporate them into the new codebase myself. Chris Cunningham (user:thumperward) (talk) 09:26, 22 May 2012 (UTC)

 Done The Helpful One 16:54, 22 May 2012 (UTC)

Thanks. Chris, I've noticed that your sandbox version still needs the row headers moving to the episode list and references ordering correctly. Matthewedwards (talk · contribs) 17:03, 22 May 2012 (UTC)

Hmm, they were both buggy.. I'm reverting. Matthewedwards (talk · contribs) 17:10, 22 May 2012 (UTC)

Something went wrong in the transclusions. It produced extra table columns and a backwards-facing "R" to appear in the summary row. Perhaps we should implement each change in separate edits. It's odd that they worked in the testcases though. Matthewedwards (talk · contribs) 17:20, 22 May 2012 (UTC)

Did you try purging the pages? What article did you notice an error on? It should have worked. 117Avenue (talk) 02:05, 23 May 2012 (UTC)

I forgot to remove the "sandbox" from the first line of this diff to the edit of the Sublist template. Matthewedwards (talk · contribs) 04:21, 23 May 2012 (UTC)

Ah, I didn't catch that. 117Avenue (talk) 05:10, 23 May 2012 (UTC)

(ec) (copied from my talk page)

Hi,

Why did you make this change while there was ongoing discussion? Chris Cunningham (user:thumperward) (talk) 16:58, 22 May 2012 (UTC)

Hi Chris, I made the change because the original edit protected request was for Matthewedwards's changes which had been discussed whilst your edits hadn't yet been discussed. However, there appears to be some problems with the new versions as well that weren't appearing in the test case, so I've gone ahead and undone the edit, time for some more testing I think! The Helpful One 17:12, 22 May 2012 (UTC)

When do you think you'll be done, Chris? We want to push forward with this. Matthewedwards (talk · contribs) 18:12, 22 May 2012 (UTC)

I think the last revision of my sandbox should be fine. That's why I requested it be checked. I'm aware that it may not contain all of the new features requested, but I'd rather this moved forward incrementally. Hopefully those features it doesn't include will be easy enough to graft on once it's been tested, deployed and checked in the wild. Chris Cunningham (user:thumperward) (talk) 19:52, 22 May 2012 (UTC)

Like I said before, it doesn't work. See User:Ned Scott/sandbox. Parameters listed, but not filled out, do not expend the table cells. That is a missing fundamental feature of this template and cannot be removed. -- Ned Scott 22:51, 22 May 2012 (UTC)

It can, and it should. If the missing attributes are skipped from all rows, the table works fine. It is only in the case that some rows are skipped that there are problems. This should be highlighted to readers so that they can fix it, rather than hidden behind an incomprehensible wall of conditionals. Failing gracefully has its limits. Better that people be able to identify what has gone wrong immediately and be able to fix it than to have to slavishly copy old work cargo-cult style in the hope of not having nonsense like upside-down Rs show up in articles because that was how things worked when this one guy maintained all of our TV articles 6+ years ago. Chris Cunningham (user:thumperward) (talk) 23:19, 22 May 2012 (UTC)

This system has been in place, has been maintained, and has worked for years before you and you alone decided that it was "the wrong way". There is nothing wrong with the way the template currently works.

It is designed to be extremely flexible and easy to use, with just about everything being optional. Users only need to list the parameters they wish to include, and do so in a way that works for in-progress/incomplete lists. Cells pop open so that a reader, without ever seeing the wiki code, knows that there is information missing and needs to be filled out. It's been this kind of ease-of-use that allowed the template's usage to explode into thousands of pages.

Several editors, administrators, and template experts (for a lack of a better term) have looked at this template, improved it, and commented on it. I mean no disrespect, but your objection alone should not undermine all those other editors.

It is not uncommon for template hacks of this nature to be used. It has yet to be an issue for this template. It is an accepted reality that, until MediaWiki has some better template code/system, we have to use "crazy-ass" template hacks to get certain functionality.

You are proposing a major change to how this template has functioned for almost six years.

I am not opposed to getting ride of crazy hacks, but not at the expense of functionality. Thankfully, there are planned changes to the template system in store for MediaWiki (and Wikipedia specifically) that will allow for a kind of programming language (See mw:Lua scripting), so that we don't have to use such strange (and often limiting) wiki code. Until that happens, we still need the strange checks and hacks that this template uses.

Oh, and "that one guy" was me, by the way. -- Ned Scott 23:39, 22 May 2012 (UTC)

I wouldn't have called them "hacks", that is simply how templates work, how an empty parameter is detected. Thumperward, your versions will simply not work. 117Avenue (talk) 02:05, 23 May 2012 (UTC)

Just one non-breaking non-controversal edit request

Right now the template is currently broken in regards to the title cell shading. See List of The Mentalist episodes for an example.

this version of the template changes one thing and one thing only, it fixes that title cell shading. It doesn't break anything, everyone wants the shading to work again, and even if that exact code will change with the other changes, it's not a big deal to fix this one thing now while we hammer out everything else. Unlike the other changes, this one is fixing an eyesore of a problem in the here and now. -- Ned Scott 22:56, 22 May 2012 (UTC)

 Done -- I know I'm an active participant here, but it's ridiculous that we have to wait 3 days for a different admin because there's a backlog of edit protection request. But if anybody does find it horrendous, I'll revert myself. Matthewedwards (talk · contribs) 03:23, 23 May 2012 (UTC)

All changes now live

Working through the sandbox for the last hour or so, figuring out what went wrong this morning (we forgot to remove "/sandbox" from the first line of Template:Episode list/sublist, all changes discussed over the last 10+ days have gone live. Hopefully nobody sees this as too much Conflict of Interest since I was involved heavily in the discussions, I only edited it based on the discussion outcomes. These changes have been ready to go for days, but there's a backlog of requests to protected pages and we've all wanted this to get pushed through ASAP. As I already said, if anybody does find it horrendous that I did this, I'll revert myself, but it seems kind of silly because we're just going to need it done again.

Chris has been editing the sandbox to recode the template but those changes are still not completed and don't yet give the results we're after, whereas these do. They haven't really been discussed yet, either, so it's unwise to move them to the template as this stage. If when completed it turns out that they work then we can always discuss implementing them, but there was no need to hold back on updating the template until that happens.

To recap, new changes are:

1. Removing the row headers / row scopes from the Title cells, and moving them to the EpisodeNumber= field, resulting in a more standard looking table (this is actually only visibly noticeable at transcluded tables from seasons to main episode lists or lists without summaries)
2. Changing the TopColor so that if there is a TopColor specified, it changes the colour of the Episode Number cell rather than it remaining grey because it is a row header
3. Fixing the striping on transcluded tables where the Episode numbers aren't regular numbers (like when an episode is double-length and entered into the Episode number parameter as "11–12") so the striping isn't broken or repeated twice in a row
4. Addressing the necessity to remove the "ShortSummary=" field when left empty and a summary is not actually given. Previously the template created an empty bottom row that would contain the summary, now it doesn't produce the bottom row at all
5. Adding the new "Viewers=" parameter between "ProdCode" and "Aux4", which will hopefully encourage editors to add viewing figures when they were previously not entered, and freeing up the "Aux4=" parameter when they were. Matthewedwards (talk · contribs) 05:01, 23 May 2012 (UTC)

Looks good. And if Chris is able to improve/simplify the template code, then all the better, but until then this is the next best version. -- Ned Scott 20:33, 23 May 2012 (UTC)

Title option

The template currently requires an episode title to be provided, using either "Title=" or "RTitle=". For television shows that do not name episodes, editors are forced to make up a title, which usually results in "Episode 1". That shouldn't happen. If there is no title, we shouldn't be presenting readers with incorrect information. It's also superfluous to state "Episode 1" when the EpisodeNumber has just told the reader that it's the first episode.

A large number of British shows don't name episodes, especially Comedy Quizzes, Gameshows, and a few dramas, as I found out when I removed the "Title=" parameter and entries at Monarch of the Glen, which completely broke the table formatting [3].

I thought this sandbox edit might fix it, but the output at Template:Episode list/testcases#7 proves otherwise (for cases when "RTitle" is used instead of "Title=", like for a television movie that doesn't require the quotemarks that "Title=" provides).

Does anyone else have any thoughts on this? Can anyone make the correct edit to the sandbox? Matthewedwards (talk · contribs) 05:02, 23 May 2012 (UTC)

This is what it would look like if the title parameters were made optional, and if the th were always on the first column. 117Avenue (talk) 08:11, 23 May 2012 (UTC)

I don't think |Title= shouldn't be mandatory, and making it optional would solve The Colbert Report list etc. but I do not like that the Title is now aligned in the center instead of left as it used to be. So I'd like to request that that is changed back. _Xeworlebi ^(talk) 15:05, 23 May 2012 (UTC)

@Xeworlebi The title is no longer centered. I think it was just being edited. Hmm, usually when you remove let's say production code form the header then the "ProdCode=" it keeps everything aligned. Maybe perhaps there's something in the coding that's causing it to do that and there has to be that there. I even tried to "hide" both the header and the "Title=" but it still did the same thing. What you Suggested Matthew will probably be the best approach (unless someone else has something different to weigh-in). I'm all for it and I agree we don't want to supply false information with "Episode 1" when we can just point that out with the episode number. - Alec (talk) 18:08, 24 May 2012 (UTC)

It gets tricky when everything becomes optional, but there should be a way to do it. Originally it was just a way to make the code easier to handle (especially with more than one parameter for title), but making it optional was inevitable. -- Ned Scott 01:12, 25 May 2012 (UTC)

"Hidden" episode summary?

I have a suggestion/request regarding the "ShortSummary =" parameter of the template. Would it be possible to make this row invisible or "hidden" when no summary is provided (the same way parameters automatically become "invisible" in infoboxes when not in use)? I'm asking because I've recently used the "episode list" template for a television series in which no episode synopsis is, as yet, available. I don't want to simply remove the parameter from the table, since future editors may be able to expand with episode summaries, and many, most likely, will not be familiar enough with the table and it's parameters to re-add the "ShortSummary" section themselves. As it is now, an empty "ShortSummary" parameter creates a blank row and making it "hidden" (when not in use) would help keep the table tidy, instead of unnecessarily stretching the table to twice the length. --- Crakkerjakk (talk) 15:01, 5 April 2012 (UTC)

I did a full recode of the template in the sandbox and added a couple testcases. Besides the "ShortSummary" problem, it also fixes any time more parameters are left blank in the template. So now you can actually leave "DirectedBy" and "WrittenBy" in the template for instance, if you know they will be filled in someday, and it won't mess up the table. — Bility (talk) 18:43, 5 April 2012 (UTC)

Thanks for doing that. Yes, that's pretty much exactly what I had in mind. Now we just need someone to implement the changes to the template. Are you authorized to make the changes? Or do we need to wait for however many months/years it takes for others to notice this proposal in order to reach a "consensus"? It doesn't seem like something that would be a highly controversial change, but I guess I could be wrong. The only slight change I might suggest to your sandbox tests would be to ask if we could keep the thin "color bar" line below each episode row when the "ShortSummary" is invisible? Just for continuity and aesthetics, some people might want to keep that in order to make a clear delineation between each episode - particularly in cases where a page is "in development", where some episodes may have a summary and others don't - it would probably help make it clear "at-a-glance" where one episode ends and the next episode begins. --- Crakkerjakk (talk) 07:27, 7 April 2012 (UTC)

Haha, months/years? Eventually an admin will review the edit requests (slight backlog right now) and if there is some opposition to this change or they see something wrong with the code, then discussion will ensue, otherwise these protected edit requests are sometimes pretty straightforward. They might tell you to go get consensus at whichever WikiProject is in charge of this template though. I'll add the line in the meantime and see how that looks. :D — Bility (talk) 14:01, 7 April 2012 (UTC)

Thanks for adding the color bar when the summary parameter is in "invisible" mode. It looks good to me. :) --- Crakkerjakk (talk) 22:32, 7 April 2012 (UTC)

No prob. — Bility (talk) 04:20, 8 April 2012 (UTC)

DONE I copied the sandbox code to the template page. Some episode lists may still require a WP:PURGE to make them look right (this will straighten out by itself eventually). – sgeureka ^t•c 09:12, 8 April 2012 (UTC)

Am I missing something here? You can simply comment out |ShortSummary= (<!-- |ShortSummary -->) to stop it displaying an empty line. (See List of That Girl episodes) As for |DirectedBy= and |WrittenBy=, leaving them empty has never caused a problem.

No. in series	No. in season	Title	Aux1	Directed by	Written by	Aux2	Aux3	Original air date	AltDate	ProdCode	Aux4
1	TBA	TBA	TBA	TBA	TBA	TBA	TBA	TBA	TBA	TBA	TBA

If this is what is meant in regard to DirectedBy and WrittenBy, then the changes are unnecessary because the problem is in not providing the correct number of column headings for the fields used. If you include fields then you should include appropriate column headings. We shouldn't be changing the template to compensate for poor editing practices. --AussieLegend (talk) 10:49, 9 April 2012 (UTC)

HTML comments is good editing practice? :P There are actually three changes to the template: 1) blank ShortSummary parameter, 2) can leave other blank parameters in the template and 3) adds the colored line at the bottom when there is no short summary. I think the first and third ones are worth changing the template for. — Bility (talk) 16:11, 9 April 2012 (UTC)

I didn't make an itemized list of every possible scenario, but I thought I was pretty clear. The casual editors that may come to a page down the line most likely will not know all of the intricate "template" details (such as that they would need to remove the <!--- and ---> parameters before a ShortSummary they add will show up), so that "solution" basically creates the same problems as simply removing the "ShortSummary" parameter altogether. There are dozens of "hidden" parameters in every infobox template I've ever seen, so I didn't see any reason why the same format shouldn't be applied to the Episode list template. I can't speak for others here, but I don't intend to monitor pages on a daily basis after I write them. The idea was to make things easier for casual editors to be able to expand pages after we leave. I don't consider it "poor editing practices" simply because casual editors may not be familiar with all of the intricacies of Wikipedia templates. I'm assuming everyone here is relatively familiar with the basic templates on Wikipedia - but let's keep in mind that there are hundreds and thousands of editors who aren't. I don't think that's any reason to look down our noses at them or refuse to make minor changes which will help to simplify the editing process for them. --- Crakkerjakk (talk) 19:38, 9 April 2012 (UTC)

There's nothing wrong with commenting out presently unused fields. We use commented out content everywhere and it isn't bad practice. Optional, unused fields shouldn't be left in articles. If |ProdCode= (for example) isn't going to be used, it shouldn't be there. If it is going to be used, there should be a column heading for it. Arguments about casual editors not knowing something don't really fly because this happens with everything in every article. Most of what I do on Wikipedia is fixing errors made by casual editors as well as editors who should know better. Errors occur, but an experienced editor almost always comes along to fix problems. The coloured line is used to delineate between episode entries when an episode summary is included. When episode articles are transcluded, we don't include the coloured line because we don't need to delineate between single rows in tables, either in episode lists or generally. --AussieLegend (talk) 03:01, 10 April 2012 (UTC)

Again - As previously stated above, I thought the colored line below each episode would be useful in pages that are in development (for example: an episode list where some episodes do have an episode summary while others don't (and I personally don't think a 2px colored line between episodes on transcluded pages would throw everything into upheaval - but that's a separate issue). As far as I can tell - you haven't really presented any reason why any of these changes would present any problems - just that you don't think we should "need" to do it. The case that the template has been working perfectly without these changes thus far fails to take into account the improvements that were never made because a casual editor tried to add to a table - got confused and/or frustrated, and ended up leaving without making the improvements. I don't claim to be an expert with templates, but I think I'm at least familiar with the basics of how they work and even I will still occasionally accidentally remove a semi-colon or make some other little mistake which throws a template off and I end up spending 10 or 20 (or more) minutes retracing my steps to find my mistake. The rationale that there are already far more complicated ways around the problems doesn't really gel with the mission of Wikipedia being welcoming/inviting place for new editors to edit. The assertion that new editors make mistakes with "everything" in "every" article doesn't really fly either - I would maintain that knowing Wikipedia's policies regarding citing reliable sources is far more remedial than the syntaxt codes for templates, which is far more advanced than simply citing a reference at the end of a sentence (I find people often slap a simple link to a source into an article and I convert them into reflinks all the time). That's like comparing third grade mathematics to advanced trigonometry. --- Crakkerjakk (talk) 03:36, 10 April 2012 (UTC)

The template is already designed to handle the issue, and the documentation provides adequate explanation. It very specifically says only to include parameters that are being used. The template puts in empty spaces when the parameter is called so the table would be designed correctly even if information is not yet known. For instance, we only know writers and directors for episodes already broadcast, but we know titles and airdates for upcoming episodes. Jay32183 (talk) 05:52, 10 April 2012 (UTC)

With all due respect, the template does not "handle the issues" I've (now repeatedly) outlined above. Those of us on this page are obviously familiar with the documentation of templates, but the majority of editors are not. I understand what you're saying about current shows, but keep in mind, mainstream television existed some 50+ years prior to Wikipedia becoming mainstream, and many old shows are "brought back", either in reruns on one of the 500+ cable channels, through DVD releases, on itunes or hulu, etc. Details on an old show from 30 or 40 or 50+ years ago may not be readily available today, but old details often become available with renewed interest in a series after a template has been created. As far as what you're saying about tables for current shows - Maybe I'm a little confused, but I thought the vertical parameters would only become invisible if there was no information for that column in any of the episodes. For example: If there was no information available about the directors of an old show, then that column would automatically become hidden, but as soon as someone added the name of the director for the pilot episode then that parameter would automatically become visible all the way down the length of the entire table (I could be wrong, but that was my assumption). The "ShortSummary" section is a somewhat different case since it's a horizontal parameter, so I don't believe having summary parameters appear for some episodes and not others would confuse the table. Again - So far, the only rationale I can discern for denying the changes is that the Wikipedia "good fairies" who spend their time magically appearing and fixing complicated tables will no longer have anything to do. Granted, my original request was for the "ShortSummary" parameter, but I still haven't seen anyone outline any downside whatsoever for including the "hidden" option for other columns as well. If your "solution" is to simply remove parameters so that only an elite few of us can expand a template as more information becomes available later on down the line, then no thanks - I'd rather just leave the blank "ShortSummary" paramaters that double the length of the table (and the page), than create a table that's prohibitive of others being able to easily add information later on if/when it becomes available. I would have thought if "hidden" parameters were so objectionable then they wouldn't be included on just about every infobox template I've ever seen on Wikipedia.--- Crakkerjakk (talk) 06:57, 10 April 2012 (UTC)

P.S. - In response to your edit summary - the previous edit did not "break the table" - it created an unanticipated problem on tables that were transcluded from other pages and has been fixed. --- Crakkerjakk (talk) 07:23, 10 April 2012 (UTC)

I'm not going to bother reading your full post because your first sentenced pissed me off. If editors are unfamiliar with the documentation it is their responsibility to familiarize themselves with it. We shouldn't dumb down a functional template because some people can't be bothered to read the directions. There is no reason to change the template. Another reason it's written the way it was was to keep its size smaller because there are template limits on pages. If templates get too big, they stop showing up on pages. Jay32183 (talk) 03:34, 11 April 2012 (UTC)

"Dumbing down a template" WTF are you talking about? You're the one who is determined to remove functionality from a template in the service of a pettifogging misapplication of a rule defined for a different context.Barsoomian (talk) 12:56, 2 May 2012 (UTC)

I too would like to not have to hide the ShortSummary parameter in order to hide the summary row. The summary row should not be shown when the parameter is left blank. 117Avenue (talk) 02:56, 3 May 2012 (UTC)

I know this is probably a bit late to this discussion, but just wanted to point out that making a blank cell for ShortSummary was specifically intended. The idea of having the cells open when listed, but not filled out, wasn't just to preserve formatting, but was also to encourage editors to fill out information. -- Ned Scott 01:16, 25 May 2012 (UTC)

That's great for the other fields, because all it makes is an empty cell. But it is quite pointless to have an empty row. 117Avenue (talk) 03:43, 25 May 2012 (UTC)

I completely disagree. It's still a cell, a portion of data that is blank that should be shown as "needing to be filled out". Hiding ShortSummary is also how the template switches between having a colored line or not and not having shading on the semi-headers. Basically, having ShortSummary or not is a trigger for two different uses/appearances.

It also just looks silly to me that one episode entry would not have a summary box while others do. It looks distracting and odd. -- Ned Scott 18:11, 30 May 2012 (UTC)

My reply to this, is the same as to Viewers below. I don't think that an empty cell should scream fill me! It encourages vandals, and original research. It is alright to not have unavailable information. Also, why can't a darker grey act as a sort of "header", for the ShortSummary below? Am I correct in assuming it is cases like Degrassi (season 12) where you disagree with the formatting? I think adding a blank row in between all of the existing ones would look worse, and is probably against the common sense of table use. 117Avenue (talk) 03:12, 31 May 2012 (UTC)

You can't really compare Viewers and ShortSummary, because the first is a cell that has to be in the table if viewer figures exist anywhere in the column, while the second is a multiple column spanning cell in a row that can be excluded. --AussieLegend (talk) 03:21, 31 May 2012 (UTC)

Row scopes redux

Well I've spend the last few days editing each and every page that transcludes Template:Episode list, adding class="plainrowheaders" to the tables. Per the discussion at #So far/What now?, specifically RexxS's comments, can an uninvolved admin please change the following line:

• <td scope="row" class="summary" style="text-align: left;">{{#if:{{{Title|}}}|"{{{Title}}}"}}{{{RTitle|}}} {{#if:{{{AltTitle|}}}|<br />"{{{AltTitle}}}"}}{{{RAltTitle|}}}</td>{{

to

• <th scope="row" class="summary" style="text-align: left;">{{#if:{{{Title|}}}|"{{{Title}}}"}}{{{RTitle|}}} {{#if:{{{AltTitle|}}}|<br />"{{{AltTitle}}}"}}{{{RAltTitle|}}}</th>{{

ie change "td" to "th".

I've tested in the sandbox, and there's been no damage to the test cases, so it should be safe to put live on the main template.

Thanks, Matthewedwards (talk · contribs) 07:08, 16 May 2012 (UTC)

Just a note to everyone (especially those who still want the titles to be bolded), the cells in the title column will become shaded a slightly darker colour because it is acting as a table header. Matthewedwards (talk · contribs) 03:27, 17 May 2012 (UTC)

 Done --Rschen7754 06:12, 17 May 2012 (UTC)

Thank you! :)

After a quick check everything is okay now and overall the template seems to be working fine. Bolding is gone, but the cells with the titles are now hard-formatted with a darker shade of #F2F2F2 rather than the standard wikitable cell shading of #F9F9F9, which should appease the people who wanted boldface or want it back. The shading doesn't appear to be a problem in most cases because the row with the title, episode numbers, writers, directors, etc is also usually shaded #F2F2F2. It does become slightly more noticable at pages where tables are transcluded though, like List of Bones episodes, where rows are zig-zagged or zebra'd between the darker #E9E9E9 and the standard #F9F9F9, and the title cells are shaded #F2F2F2.

I have a couple of ideas/proposals for the template that I plan on bringing up probably next week, depending on the reaction to the changes by people who aren't aware of these discussions. Matthewedwards (talk · contribs) 06:34, 17 May 2012 (UTC)

Hard formatting the third column looks quite ridiculous. If we are to hard format one column,we should be doing it to the first, which coincides with "|EpisodeNumber=", the field that is anchored. --AussieLegend (talk) 15:01, 18 May 2012 (UTC)

"titles are now hard-formatted ... which should appease the people who wanted boldface or want it back." What??? You did this deliberately, and say this is somehow supposed to substitute for "bold"? I thought it was an unforeseen side effect of the debolding. This is the first time anyone has tried to "appease" me here, (usually they tell me to run along and not bother them) and I'm afraid it is having the opposite effect. As I noted earlier, this royally screws up any table using TopColor. I've got an idea -- why not emphasise the title in another way -- say by using a thicker, more prominent font? I've seen even some headings in Wikipedia use that. Anyway some MOS guy will probably come along and ban this grey on grey "highlight" too once they notice it. Please do not hard format the colours of any single cells. It's barely noticeable in default colours, and looks awful on any customised ones. Barsoomian (talk) 16:02, 18 May 2012 (UTC)

"Anyway some MOS guy will probably come along and ban this grey on grey "highlight" too once they notice it" – more hyperbolic cadaver nudging? Every time you make a point, you entirely undermine it. Which is a shame, I'm sure you'll agree. The Rambling Man (talk) 16:38, 18 May 2012 (UTC)

Every time I make a point, you come along and attack an aside or joke I made and completely ignore the main point. Have you nothing better to do with your time than harass and stalk me here and on articles I edit? Are you really so petty and vindictive? Barsoomian (talk) 17:23, 18 May 2012 (UTC)

Well, according to you, I edit "your" articles. Perhaps that needs to be addressed. I have 6,107 articles on my watch list. So what. I don't moan about it and screech about "stalking". It happens. You're not making jokes, you're just being hyperbolic and undermining your own viewpoint. The Rambling Man (talk) 17:30, 18 May 2012 (UTC)

Your last two posts here have addressed nothing about the subject (coloured cells in tables), just attacked me. And if I'm "undermining my own viewpoint", why not just stand back and let me do it? Instead of leaping in to make the same tedious characterisations, with the same tedious links defining completely obvious terms. Barsoomian (talk) 17:58, 18 May 2012 (UTC)

Indeed, tedious in extremis! ;) The Rambling Man (talk) 18:02, 18 May 2012 (UTC)

UNIDENT

Can you please both get back onto the subject matter and not bicker :) playing tit for tat wont achive anything for either of you--Andrewcrawford (talk - contrib) 17:29, 18 May 2012 (UTC)

I've made my point, so I'll leave you to it. Rambler will take a few more swipes at me after I go, sorry about that. Barsoomian (talk) 17:58, 18 May 2012 (UTC)

Nope, will just reiterate what Matthew said, you get your episode title "featured" (why that's necessary is entirely unclear) in all of "your" articles. The Rambling Man (talk) 18:02, 18 May 2012 (UTC)

way forward

Barsoomian, it's not as simple as that when we added |scope="row" we also deliberately forced the shading, it's just that to make it comply with WP:ACCESS, we must use row headers, and Wikimedia's .css makes the headers a darker shade of grey. It's not an unforseen side effect of unbolding. Headers have nothing to do with bold face and they are two completely separate and unconnected issues, except that both are required by the Manual of Style. No MOS guy will come along and ban it or require the removal of the shading, because it's doing exactly what the MOS wants.

Like I said, the deal with the darker shaded cells is that |scope="row" identifies the episode title cell as a table header, but instead of being a column header, which is what we're used to seeing on Wikipeida, it's a row header. In this respect, it's unfortunate that the episode titles are placed in the middle of the table. The shading actually is not noticeable in the majority of cases where there is an episode summary because the template is coded so that when there is a summary the entire "top row" containing the episode numbers, title, airdates, writers, director, etc is changed to being shaded #F2F2F2. See test cases 1, 2 and 4. The problem is only noticable in three situations:

1. When there are no summaries (see the No short summary test case)
2. When the |topcolor= parameter is called upon (as Barsoomian mentioned -- see test cases 3)
3. When the table is transcluded from a season page to a main list of episodes (see List of Bones episodes).

In the first case, the template allows the data (not the title row header) in the "top row" only to be shown, and leaves it the default shade of #F9F9F9. In the second case, the "top row" data is shaded whatever colour specified, leaving the title header grey, and in the third case the transcluded template is zebra-striped between an off-white and grey.

Normal or default wikitable markup shading is #F2F2F2 for table headers, and #F9F9F9 for data. Template:Episode list overrides this at every possible step but really it shouldn't. We have to be careful not to ignore the WP:DEVIATIONS part of the Manual of Style, which says "styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes."

The template forces the data row containing episode numbers, title, writers, director, production codes to #F2F2F2 when it should be #F9F9F9, but that can be overridden using the |topcolor= parameter. But remember, because the title is a header, it can't be overridden. And for what it's worth, out of the 5132 pages (including various talk pages, user pages and Wikipedia: pages) that transclude the template, just 100 use the |topcolor= parameter, and only 81 of those 100 are in article space. The other 19 are in talk/user/user talk/Wikipedia space. That means that just 1.57% of all the articles that use the template specify a different colour, and some of those colours specified are actually #F9F9F9 or #FFFFFF to try and remove the header shading from data cells that aren't headers. So I know you won't like it, Barsoomian, but perhaps we should look at whether we want to remove that parameter from the template. It's barely used, when it is used it's sometimes used to correct the template's poor formatting, and the other times it's to add non-standard colours to Wikitables, resulting in what is often called "Skittlepedia".

For the zebra stripes when transcluding, the template forces an entirely new set of shading. If you take a look at an episode list where the tables are transcluded from season pages, you'll see that they are zigzagged between two different shades of grey. Odd-numbered episodes are shaded #E9E9E9, an off-white colour, even-numbered episodes are #F2F2F2. Remember, #F9F9F9 is the standard color for data cells, not #E9E9E9, and that #F2F2F2 is used for headers. Other problems arise when, for example, there is a double-episode and the zebra effect is broken. (See List of Friends episodes. In season 1, episodes 16 and 17 were originally broadcast as one hour-long episode, but look what happens with the stripes.) Episode tables are the only ones that mess with cell shading as much as this. No other group of tables stripe the rows, no others force them to go against the standard markup. In this respect, the template is a disaster.

So what can be done to fix both the template and the row header shading? Well fixing the template is complex and other decisions need to be made first. We can:

(A) Just live with it and allow the title cells to retain the forced #F2F2F2 on every possible example of table. Editors of other tables that have implemented rowscopes don't seemed to be put off by this (but then most other tables don't tolerate the use of a bunch of other colours like we do)

(B) Remove |topcolor= from the template. Since it's underused anyway (1.57%) and shading rows all different colours is not normal practice in most other "standard" wikitables and goes against WP:DEVIATIONS, and test case 3 and Barsoomian's example in the thread below are (IMO) by far the ugliest tables we produce, it might be time to do this anyway

(C) Do (B) AND stop the zebra effect when transcluding AND give the rest of the cells in the transcluded tables the regular #F9F9F9 shading. I, for one, don't understand why we do the zebra thing anyway. It can't be for ease of reading which is the usual reason that gets bandied around, because I haven't come across any other standard wikitables that do this.

(D) Stop the template from changing the top row colour to F2F2F2 when there is a summary. The template automatically adds a 3px light-blue line between the two rows of information for each episode when there is a summary (the colour can also be specified/changed within the template), so would readers find it difficult to stay within those lines when reading the table? If necessary we could change the default colour of that line to something darker. See test case 4 for examples of the coloured line in use.

That still leaves the shading of the episode title row headers, and that's easier to address:

(1) Use the episode number column as the header so that the row header is at the far left of the table like in AussieLegend's calendar tables or the example at WP:DTT#Overview of basics

(2) Move the episode title to the far left of the table

(3) We can force the template to shade the header one other specified colour. I haven't mentioned this yet, but we can add a piece of coding to the <th> code, but it's still going to be transcluded throughout all the tables, so unless we remove all other custom color formatting from the template and change it to #F9F9F9, it's not going to make a difference and will still look weird, whatever colour we pick. Matthewedwards (talk · contribs) 23:52, 18 May 2012 (UTC)

• B, or at least revert the 06:11, 17 May 2012 (UTC) edit. topcolor is a WP:DEVIATIONS violation, and a darker shading should be used to differentiate it from the summary, F2F2F2 does this. When there is no summary, it is a standard table, and should follow standard table MOS, ie. F9F9F9. When transcluded, I see no problem with zebra stripping, Template:Navbox uses it. 117Avenue (talk) 02:05, 19 May 2012 (UTC)

• "I, for one, don't understand why we do the zebra thing anyway. It can't be for ease of reading which is the usual reason that gets bandied around, because I haven't come across any other standard wikitables that do this." - Wikitables aren't the only types of tables in use in the world and ease of reading is exactly why the rows are alternately shaded. When working with tables it's always easier to read across the rows if they're alternately shaded. In the old days of fan-fold paper, shaded paper was commonly available for this purpose. (I only threw out my last box a few months ago.) It was pretty much essential in large format (up to A0 - 1,189 mm (46.8 in) wide) printouts. With the first 1970s computer monitors being 12" diagonal and 64 characters across, (home users often used 12" portable TVs) on-screen shading wasn't possible. However, printouts still used it through use of the shaded paper. Again, it was essential for some formats, such as Assembly language printouts like this. In more modern times, with horizontal resolutions expanding from 640px to 1980px or more, and screen sizes having increased from 12" to 50" (some design places use two 42" monitors), shading is becoming more popular. Even in Wikipedia, with home users typically using 19", 1440x900 monitors, alternate line shading can still be of benefit. It's just that most people aren't used to it, so they don't see a need for it.
  Enough of the history lesson, of the options presented by Matthewedwards, (B) seems the best way forward. I've edited a lot of episode lists and have never seen the need for TopColor at all, as it serves no real purpose and often results in a rather garish appearance. Any colouring should be subtle. LineColor provides an obvious differentiation between episodes where an episode summary is included and that's all we need. There's no need for colouring in the other fields, any more than bolding of the episode title is required. Naturally, I also have to support (1), as it makes far more sense to shade (if we have to have shading) the left-most field, rather than a field in the middle of the table. As I've earlier indicated, the template provides an anchor to EpisodeNumber. If we link to episodes it's in the form "[[List of Foo episodes#ep<EpisodeNumber>|<Title>]]", not to "[[List of Foo episodes#ep<Title>|<Title>]]". The contents of "|EpisodeNumber=" is generally more stable than "|Title=". Episode numbers are usually left alone, while episode titles are often changed, or people include references with the title, rather than separately in the RTitle field. As I've also already indicated, some shows don't have episode titles so there are no good reaasons to anchor to Title. As the anchored field, EpisodeNumber is the primary field and therefore it should be the first (i.e. left-most) field, and that's the one that should be shaded. Of course, if we were to retain TopColor, shading the left most field also results in the least amount of "disruption" to the colouring, since EpisodeNumber is generally a very narrow field compared to the rest. --AussieLegend (talk) 05:23, 19 May 2012 (UTC)

I would go with option B as top colour really is daft, but i would also say add a parameter |nozebreaeffect= and when it equals yes it removes teh zebra effect as lists like frined and time team are affect by it and look weird, i would also support 1as i dnt think epsiode titel should be the first field the logical first field is episode number.--Andrewcrawford (talk - contrib) 08:38, 19 May 2012 (UTC)

This idea of colouring one cell in a row a slightly different shade is silly. It's barely discernible from the default background. So it's either unnoticeable or awful (when TopColor has been used). Just forget it. It's bad enough what has already been done in the last weeks. Leave it at that and don't mess with the colors as well as the text styles. If these arbitrary removals of features continues I think I should just give up on the template entirely and do my tables in monospace text. Barsoomian (talk) 09:47, 19 May 2012 (UTC)

In which case your delbrite bypassing the template cause you dfnt like it to make a page you want your way which goes against wikipedia ownership, you do not own teh page, the template is out of date and doesnt comply with accessabilty or mos it now much closer to that, instad of trying to keep it the way you want it why not contructsive put a way forward to try get it better and comply to mos and accessabilty? ive agreed with you in prinipcle with some thing but now your crossing the line into be disruptive in my opinion if oyu just by pass the template and creata table the way you want it--Andrewcrawford (talk - contrib) 10:05, 19 May 2012 (UTC)

No, I'm not seriously proposing to use Courier. That was a hypothetical statement. Barsoomian (talk) 11:50, 19 May 2012 (UTC)

"If these arbitrary removals of features continues I think I should just give up on the template entirely and do my tables in monospace text." That suggests to me you will make tables up on epsiode list pages to make them do what you want if the template changes anymore, you do not own them the pages i mean, you have the right to say i dnt think this is right this is the way forward and try reach a consesus within th MOS guidelines but to just bypass it would be disprutive--Andrewcrawford (talk - contrib) 12:01, 19 May 2012 (UTC)

You're being over literal. So I'll try to be more clear: I meant that it's very disheartening to work hard to make attractive tables in an article, only to see them all turn to crap overnight when a the template definition was arbitrarily changed. Also, despite "MOS guidelines" being invoked at every turn, I have asked (I opened a topic at MOS) exactly what in MOS requires all these changes and never received a clear response. People claimed they were acting in compliance, never cited the text to back it up. Just looking at the result, I find it absurd to say that the tables are more accessible to anyone. They're less legible, harder to navigate and much more ugly. Barsoomian (talk) 12:32, 19 May 2012 (UTC)

No unfortnally i am being dsylexic since i am, apogolise for not getting what you mean, ive never said the way it s , is fine it just MOS complaint to which i always try to comply to, if MOS is being daft that something you have to do RFC for to get qider guieance and possible MOS changing. I suggest this way forward for you, instead of the way yoru doign it now--Andrewcrawford (talk - contrib) 13:38, 19 May 2012 (UTC)

Barsoomian, it would probably help if you read HTML Tables with JAWS and MAGic which explains how the JAWS screenreader can use cells marked up as column and row headers to allow the user to navigate around tables in a non-linear way. We know that different screen readers identify headers in different ways, so we recommend using '!' (to make a TH cell) and 'scope='col'"/'scope="row"' (to explicitly define the scope of the header). That way we ensure as many non-visual agents as possible can correctly identify the headers we want. It's also an advantage to place the column headers in the first row and the row headers in the first column, for the same reason, but that is less important than proper markup. So that's why we wanted to change {{episode list}} to use '! scope="row"'. As you know, the effect of '!' by default is to change the background colour to grey, to bold the text, and to centre it. A lot of projects did not want the centred, bold text and so a new class was created, "plainrowheaders". This class restores normal weight and left-alignment to text in a row header. If you finally agree among yourselves that you want bold text for the row header, then just remove the "plainrowheaders" from the first line of the table. Try it in a preview and see. --RexxS (talk) 16:16, 19 May 2012 (UTC)

Matthew: I draw your attention to two statements you made:

The actual episode title isn't a header, just like the entries "53", "Steve Zuckerman", "Shana Goldberg-Meehan & Scott Silveri", "January 1, 2012" are not headers or subheaders. That's why they're not bolded Matthewedwards : Chat 02:48, 2 May 2012 (UTC)

the deal with the darker shaded cells is that |scope="row" identifies the episode title cell as a table header Matthewedwards (talk · contribs) 23:52, 18 May 2012 (UTC)

To summarise: (2 May) Titles must not be bold because they're not headers. (18 May) Now Titles are headers so they must have a darker background. Tell me why, now that Titles are headers, that they can't be bold and we can both satisfy the arcane accessibility rules and also have an attractive and clear table for everyone else. Barsoomian (talk)

I cant speak for matthew but ill try guess why i think it done, using th is partially because of html5, html5 at the moment means td cant havea scope but th can, so for template to be html5 complaint as well hey changed epiosd etitels from td to th i cant say why the shading but i knwo that why th is being used instead of td--Andrewcrawford (talk - contrib) 13:38, 19 May 2012 (UTC)

I'm not asking why it's now a header. My point is, since it IS now a header, that the objection to the Titles being bold is moot. Barsoomian (talk) 15:03, 19 May 2012 (UTC)

It's not moot, as the shading is causing some obvious problems and discussion is underway about that. The decision to make Title a header field was fairly abitrary, and one of the options being discussed is to make EpisodeNumber the row header, which makes a lot more sense. --AussieLegend (talk) 15:19, 19 May 2012 (UTC)

The shading can be sorted out by testing for the existence of {{{TopColor}}} in the template and applying it to the row header. Naturally, I'd encourage you all to make a decision on whether you want episode number or episode title as the row header. That will determine whether a blind visitor hears something like:

• "1", "Original air date", "16 April 1999"; "2", "Original air date", "23 April 1999";

or

• "New Blood", "Original air date", "16 April 1999"; "Time of the Titans", "Original air date", "23 April 1999";

That will determine which is to be the row header - after all, this debate only started because we have been seeking to improve these tables for the visually impaired. Once you have consensus on that, then please try to agree on whether you want to emphasise the row header as a header or as just another piece of data. If the former, then bold would be appropriate, otherwise not. Finally, reach consensus on whether there is real value in having background, text, and border colours freely definable. One of the purposes of WP:DEVIATIONS is to ensure that colour combinations remain accessible even for colour-blind visitors and the elderly (which the defaults have been tested to ensure). Once all of that is settled, I assure you that you'll be able to find an implementation of {{episode list}} to meet your needs. --RexxS (talk) 16:16, 19 May 2012 (UTC)

• My question stands. Titles are now headers. So why can't they be bold? That they weren't "headers" was made a big deal of and I was told over and over that that meant they must not be bold. Well, that is no longer true. Barsoomian (talk) 16:42, 19 May 2012 (UTC)

episode titles are data cells. Making them headers is for the benefit of screenreaders so that they read the title first before any other information. It doesn't make them headers, even though we're using code to make them act like headers. Matthewedwards (talk · contribs) 23:20, 19 May 2012 (UTC)

There not TABLE HEADERS they are using th because of screen readers!!!!! it to do with html and how it works as rex said i suggest you read up on htmlAndrewcrawford (talk - contrib) 17:11, 19 May 2012 (UTC)

"th" = "table header". I've been making HTML tables for 20 years. So don't patronise me, please.Barsoomian (talk) 17:25, 19 May 2012 (UTC)

TH is just a tag name. The TH cell may contain a header or a piece of data that can be treated as a header. What you need to do is try to find whether editors want to emphasise the key nature of a particular cell (and so mark it bold because it's a header) or de-emphasise that role (and leave it unbolded because it's just data). MOS does not insist on row headers being bold (which is why plainrowheaders exists), so you (and the other regulars here) should reach an agreement on which way you want these tables to look. Anybody who sees the relevant item as just another piece of data will prefer non-bold; I assume you prefer bold because you want that item (either episode number or title) to be demarcated from the other data in the row. Can we encourage other regulars to try to firm up their views one way or the other? --RexxS (talk) 18:44, 19 May 2012 (UTC)

Rexx, in your examples of what a blind user will hear from their reader, where would the episode title be read in the first example, and where is the episode number read in the second? Also, is it possible to create something that would remove the shading from headers, just as plainrowheaders removed formatting? Matthewedwards (talk · contribs) 23:20, 19 May 2012 (UTC)

To answer your last comment, it is my preference to leave the episode title as the row header so that screen readers say the title first. In other articles on Wikipedia, as well as work off site, it's the episode titles that are referred to, not episode numbers. The title is still data, we just want blind readers to know what all the other data relates to. Sighted readers can do that anyway so it doesn't matter to them what the row header is. If we can get rid of the shading in that cell, I think that would be preferential to all because it is a bit odd to have that occur in a middle column. If that can't be done we should make the episode number the shaded column or put the titles as the first column. The latter is a lot of work though, because we'd have to edit every single table so that the title isn't under the episode number column. Matthewedwards (talk · contribs) 23:20, 19 May 2012 (UTC)

1) Mathew, I would like you to answer the question I posed above. If I read RexxS's comment correctly, it seems he has no objection to Titles being shown as bold. 2) Re: the title be the first column. I'm sure there are some shows that do not have titles, only numbers. The reason that the original layout had number first and titles in bold was so you could scan down a list and quickly find an episode by number, or change your attention to the titles. There was a logic to this layout, it effectively gave you two indices to the table, it wasn't just a random mess needing the guiding hand of the MOS to sort out. Its impossible to say which of these indices is the most important. And where are all the blind readers we are turning all these articles upside down for? Do they really benefit from these changes, which make the experience worse for the 99% of normally sighted readers? Barsoomian (talk) 03:06, 20 May 2012 (UTC)

I believe he implied that if we (the people who use the template and edit the pages) choose to emphasise episode titles as actual row headers, we can remove "plainrowheaders" which will auto bold-face and center the titles. But if we want to treat episode titles as normal data, we should leave the font weight as normal. I don't think he gave us his preference. My preference is to make them headers but style them as normal data. He also said we should decide if we do want titles as the row header in the middle of the table or if we want the episode number at the left edge of the table as the row header. I didn't say moving the episode title was ideal, in fact I don't think we should, it's just an option. Maybe we didn't improve everything in one go, but we're working on it. Do you really think we're turning articles upside down? I see it as improving them for all our readers, sighted and non-sighted, the latter of whom previously could not access our articles well. Now they can, and even with the shaded background and normal font weight, sighted readers can still access it. It doesn't matter if there's a million unsighted readers, or one. It's now accessible. And RexxS also said we should "reach consensus on whether there is real value in having background, text, and border colours freely definable." Matthewedwards (talk · contribs) 04:47, 20 May 2012 (UTC)

Addressing some of the above points:

• "in your examples of what a blind user will hear from their reader, where would the episode title be read....." - I have JAWS 13.0 installed on one of my machines and presently, even with "th" on Title, JAWS 13.0 does not say what Rexx says it should. What you hear, using the first row of List of NCIS episodes#Season 1: 2003–04 as an example, is "one one quote Yankee White quote link Donald Bellisario Donald Bellisario and Don Mc Gill September twenty-third <pause> two thousand three thirteen point oh four same page link left bracket sixteen right bracket". It then shoots straight to episode 2 without pausing. This was something I pointed out at the List of Friends episodes FLC discussion.
• "it is my preference to leave the episode title as the row header so that screen readers say the title first" - While vision impaired readers are forced not to hear the same as what sighted readers see, we shouldn't be forcing them into a different format. If we see "|EpisodeNumber= |Title=" then that's what they should hear, not "|Title= |EpisodeNumber=". EpisodeNumber provides a simple sort key; it's a lot easier to remember a number's position in a sequence than an episode's title in the episode sequence. After listening to a few episode lists, I'm convinced of this.
• "The reason that the original layout had number first and titles in bold was so you could scan down a list and quickly find an episode by number" - I'm sorry, but that doesn't make a lot of sense. Bolding only serves to emphasise something and if you "scan down a list and quickly find an episode by number", you're looking at the number, not the title, so the title doesn't need to be emphasised. Bolding doesn't make it any easier to find a particular episode title when all titles are bolded.
• "Do they really benefit from these changes" - Based on my rather horrific experiences with JAWS, I can't see how they would but I agree with Matthewedwards; we should be aiming at improving the experience for all readers. That said, my experiences in project management have taught me that you need to be realistic. If 99.99% of readers are sighted, you don't expend 10% of effort in making pages accessible to vision impaired readers. This is why I opposed the changes made to List of Friends episodes. It makes far more sense to fix one template than have to rewrite 5,000+ pages in order to ensure MoS compliance. Arguing over which field should be bolded and which should be treated (not made into) a row header is a waste of time. Bolding is gone, we need to forget it and move on. We can't seem to get away from shading easily so let's shade the left-most column and be done with it. EpisodeNumber is always there, it's one of the narrowest columns and will cause the least disruption to episode lists, even those using TopColor. There's a little bit of compromise involved but, as the old saying goes, you can please all of the people some of the time and some of the people all of the time, but you can't please all of the people all of the time.
• "we can remove "plainrowheaders" which will auto bold-face and center the titles" - It also bolds the quotation marks, which shouldn't be done. --AussieLegend (talk) 09:38, 20 May 2012 (UTC)

" 'The reason that the original layout had number first and titles in bold was so you could scan down a list and quickly find an episode by number' - I'm sorry, but that doesn't make a lot of sense. " Okay, I'll try again: The number is first, so that is obvious when you look down the left edge of the table. (So making that column a different colour isn't necessary in my opinion.) Titles in bold makes it easy to pick them out from two or three columns in. (Not to pick them out from the other titles also in bold. ) Yes, readers don't "need" this, they can cope if not. But it makes it easier to locate the title. In a transcluded summary table, with no summaries in between, the title column is continuous and you don't need that so much. But in the full table, where there is a substantial slab of text in the plot summary between each episode header/heading/ whatever the hell they are officially, you can't track vertically so easily. And all the text, header, and summary, is in the same undifferentiated font. A big grey slab of text. "Bolding is gone, we need to forget it and move on." You can forget it. Not me. I had it rammed down my throat and one of the things used to push it was the "Titles aren't headers" statement, which is now untrue. "It also bolds the quotation marks, which shouldn't be done." Why should anyone notice, or care, if a punctuation mark was bold or not? That's entirely trivial. Barsoomian (talk) 11:38, 20 May 2012 (UTC)

The number column is indeed obvious and I agree that it doesn't need shading. Titles are inside quotation marks, so they already are emphasised. They don't need to be bolded as well. It's easy enough to locate them because they're always the second or third column; the template was designed that way. The "Titles aren't headers" statement is not untrue; as Rexx explained, they're just pieces of data being treated as a header, which is a mistake. Headers are always the most prominent fields. Column headers are always placed at the top of the column, not a few rows down. Similarly, row headers are on the left, as we read left to right. Why do we not bold punctuation? Because, we don't and "it's good enough" isn't good enough. --AussieLegend (talk) 13:36, 20 May 2012 (UTC)

"Because, we don't". Well, thanks for clearing that up then. And "easy enough to locate". Yeah, yeah, sure. You can find them. But it's now less easy as as the font is the same. As for the heading stuff: All text is data, all headings are data. Everything in Wikipedia is data. Your distinction makes no sense. "Column headers are always placed at the top of the column". So what? Who was talking about column headers"? Not me. Just "headers", which can be in other rows. Barsoomian (talk) 03:31, 24 May 2012 (UTC)

Sorry I haven't had chance to reply to the issues recently, but I ought to explain that JAWS from version 13 now supports "Table Layer Keystrokes" which earlier versions didn't, so you may get different experiences depending on which version you are using. I want to see tables marked up to maximise the chances of a visually-impaired user being able to use the table to its full, regardless of what screen reader (or version) they are using. That implies identifying both column and row headers wherever possible and marking them with '! scope="row/col"' (= TH scope="row/col") as that doesn't rely on a screen reader making a guess at what to use for row or column header. For example, blind visitors ought to be able to navigate down a column in a table and hear (at least) a row header before the data in a cell, so that they know which row they are on.

AussieLegend: you don't have to read an entire table row-by-row; you can get JAWS to read out cell-by-cell and navigate in any direction. Please see http://www.freedomscientific.com/Training/Surfs-up/Tables.htm which explains how you can do that using JAWS 13. I'd be interested to hear if you were able to navigate down a column like OriginalAirDate, and whether you found the experience reasonable with the row headers that are currently marked up. Thanks in advance, --RexxS (talk) 13:13, 24 May 2012 (UTC)

Arbitrary section break

I haven't read all of the discussion here, but I thought I could shed some light on the logic of TopColor. It never really got used like I thought it would, but the main idea was just to provide a way for an entry to be highlighted. A special episode of something, or some kind of recap episode, could be mixed in with the main list and highlighted via both TopColor and LineColor. Like I said, never really got used, so it was just one of the experimental options that didn't take off.

TopColor was used sometimes for episode lists that didn't break down into individual seasons, having each season on the same page using a different TopColor, colored a lighter shade than the table header.

I have no strong feelings about TopColor. Do with it what you must.

I will say that I miss the bolding. The episode entries don't pop out easily like they used to. I hope to see that change undone. Episode list has always been a unique template in that it basically became a defacto MoS for episode lists, so quoting the MoS doesn't make any sense. Table MoS's are there for common tables, not all tables. -- Ned Scott 20:17, 20 May 2012 (UTC)

Ah, totally forgot that TopColor was also used for the striping on main lists even without summaries, so TopColor is still needed. -- Ned Scott 20:35, 20 May 2012 (UTC)

Well, I've been the only person making the case for bold titles here. And been attacked and ridiculed for weeks over it. So it would be nice if someone else could step up so they can't just dismiss it. It's justified by an inappropriate application of vague MoS wording. I'm sure that the "silent majority" of editors, if they were aware of this, would not choose to lose the bolding. A couple of editors did turn up to make such comments but were quickly put in their place. Barsoomian (talk) 03:31, 24 May 2012 (UTC)

Oh please. Attacked and ridiculed for weeks? The first time you commented on bold faced titles was 1 May,[4] which continued until 8 May.[5] You were silent on the matter (which was mixed in with transcluding) until 16 May when you decided to go on a "rant" (your words)[6] about my edits, and I did not engage. Don't make like everybody you've come into contact with about this has behaved improperly towards you. You said I sounded like "your stalker friend" when I asked if you'd stop with the histrionics, so you're not innocent of attacking either, and again you return with the theatrics.

I'm sure it would be nice for you if someone else would step up and say WP:IDONTLIKEIT so you can flounce around and insist that bold face must be reinstated. The fact is, it is against the MOS, despite how much you choose to ignore it or interpret it differently. Nobody else has come forward in opposition of it, the "silent majority" you speak are surely aware by now, as bold face has been removed from the tables for over a week, and there's still no opposition to it. Nobody has been put in their place. We all get it: you don't like it. You fail to understand, though, that MOS:BOLD and Wikipedia:MOS#Italics applies to tables as well as prose. We aren't refusing to put back bold faced episode titles because WEDONTLIKEIT; we understand the Manual of Style and have edited the template so that it conforms.

A normal person, even if they don't like it, recognises that. Move on. Matthewedwards (talk · contribs) 04:28, 24 May 2012 (UTC)

I'm a normal person and I disagree with your interpretation of the MoS, Matt.

You're trying to equate the tables mentioned in the MoS to the special formatting that this template creates, which is not that of a normal table. The only part of it that is actually a "table" is the fact that it is generated with HTML table code. We are using table code to make a stylized list. If we could make this template with some kind of table-less CSS then you would have no basis for removing the bold formatting. We use table code to format a ton of things on Wikipedia that would never fall under those MoS guidelines.

If the MoS is the only reason that people here have insisted that the bold formatting be removed then I can assure you that it will be placed back in. I'd like to hear if there is more rational to this than just that. -- Ned Scott 01:07, 25 May 2012 (UTC)

Thinking more about this, while I still believe the same about bold formatting of the title and the MOS, I really can't see this issue being changed without more effort than it's worth. Basically we would need clarification on the MoS page itself, raise discussion there, etc etc, and all for something that is just supposed to help the title stand out more in a wall of text. Even if there was some scientific method to proving which interpretation was correct, without clarification then things like the Friends LOE FLC would happen again and again if the bold formatting stayed. So I'm thinking.. maybe there is something else that could be done that would comply with everything?

That's assuming this is really needed. Maybe I'm biased because I'm used to seeing the title formatted slightly differently. Maybe it doesn't need anything to help it stand out. But hey, as long as whatever formatting looks good and doesn't break any MoS guidelines, then it probably wouldn't hurt. Sometimes the best option is the third option that no one even knew existed.

So what I propose is that myself and anyone else who feels that the title needs a little definition/kick/clarification/whatever, start brainstorming. I'll see what I can come up with, and I encourage others to do the same if they want. Size, font, shading, position, as long as they follow applicable MoS guidelines, can be tweaked to some degree. Then we propose some ideas and go from there. Maybe nothing will change and no formatting is added, maybe we get some cool idea for the template that's unrelated to the title as a byproduct, maybe we turn the whole thing into sparkling pink glitter letters, but it beats going back and forth over bold formatting :) -- Ned Scott 01:34, 25 May 2012 (UTC)

Hi Ned. I'll just reply to both comments here for ease.. OK, I'm not exactly sure what you mean by "Special formatting", so if it refers to the boldface all it was was ''' added to the template code. There's nothing special about that. The template didn't automatically do it magically, the three 's were written into the markup. If it refers to the the way the entire table is constructed, again it's not all that special. It's very helpful, I'll admit it, but all it does is create two rows of data which can be achieved by normal WikiTable markup, and if regular markup is used it wouldn't force boldfaced titles. How many other tables have you seen on Wikipedia (not navboxes or infoboxes, just tables with real content) that regularly make an entire column of data boldface? Nowhere in MOS does it say the MOS applies only to prose and not to information presented in tables, so why should we assume it does? When the MOS doesn't apply to certain situations, it states that, so if it doesn't state that, the assumption is that it covers everything. And in fact, MOS:BOLD does state "Use boldface in the remainder of the article only in a few special cases: Table headers and captions". Help:Wikitable, Help:Table, and WP:Manual of Style/Tables#Captions and headings are clear about what is and isn't a header or caption, and what is data.

I think I'm right in saying you created the template, right? And it was modified from either a template or table used on a Digimon episode list (which I believe you also constructed). If that's true, what was the original purpose of making the episode title boldface? If it was to highlight it or make it stand out, then that too is a MOS vio, per WP:BADEMPHASIS. I'm really curious because it hasn't been stated anywhere why titles were styled like this in the first place. Matthewedwards (talk · contribs) 04:11, 25 May 2012 (UTC)

Again, you are hung up on the technical fact that we use table formatting to create this list. Table formatting is used all the time in non-traditional table situations, like arranging images, overcoming browser bugs for wrapping text, forcing arrangement in ways that works for most browsers/computers, and more. The MOS for tables is talking about normal tables from a visual sense, not from a "what happens behind the scenes" sense (at least, that is the main aim, as there will inevitably be areas where the two go hand in hand).

If we had some other formatting method for this list that had nothing to do with wiki/HTML table code, then it wouldn't be considered a table at all. The table formatting is just a hack, a means to an end, a way to make something look a certain way visually. It is not a traditional visual table, used for stats, definitions, numerical listings, matrices, dates, places, etc. This is a list, not a table, but a list that uses table formatting. Like the template code itself, it's not even the best way to format such things, but it's the best method that we have available on MediaWiki at the moment.

When I talk about "special formatting" I am talking about the over-all appearance of a list generated with this template.

Yes, I created a show-specific version of what later became {{Episode list}}. It was born out of a few basic ideas/goals, like we shouldn't need to edit every entry just to change the look (which at the time was being tweaked), and that we needed it to be easier for new and fly-by-night editors to just come in and add stuff right away. It was just an experiment at first, and one that grew like fire. When it became adapted to be a general template, I came in and started to help. The basic layout came from a manually generated table that had been proposed long ago from WP:LOE, and was popular with some episode lists at the time. There were some variations on it, like some didn't want summaries, some didn't want every parameter filled out, so the aim was to take what was working at the time and turn it into a highly usable, configurable, and effective template.

It made working on episode lists vastly easier to edit. It even made them machine readable while still being human readable, allowing great opportunities for reuse outside of Wikipedia. It spread like fire because people knew without having to look at the template's doc page what needed to be done. Several people worked on it, and we were very proud of the results. Not really because it was our idea, because really it wasn't, it was taking several existing ideas and bringing them together, but because we created a tool that helped thousands of editors do their work more efficiently.

So that being said, I try to not get hung up on the literal appearance of the template, or the exact implementation. I have great faith in you guys, and you've all done a great job furthering the template's improvements and keeping it well maintained. This is one of the best examples of something organically grown on Wikipedia from several people.

MOS:BOLD - the aim of MOS:BOLD is to avoid bold abuse in typical articles. We're dealing with a list, which has enough different considerations with a typical article that most of our processes, guidelines, and even WikiProjects, make a distinction between "list"-style page and "article"-style page. Which is not to say that it doesn't apply at all, but the fact that Articles are the main focus there puts those guidelines into context.

Let's not forget that these are guidelines and not policies for reasons such as this. Guidelines are written in a way that should apply to most, but are not meant to be so ridged that it causes problems for situations not foreseen, or not really meant to be the aim of the guideline (which are often made to fix specific problems).

WP:BADEMPHASIS - It's talking about unnecessary over-use of emphases in traditional pose/article-style, which is very hard to apply to a list. Our lists of episodes are closer to the specifically allowed "Definition lists", in that each episode is an entry, with a title (the object of what is being defined), followed by the definition (summary), and other related facts (air dates, directors, etc.

The reason we went with bold was because, despite having the top row shaded and having colored lines, it still felt like a wall of text where the most important/defining part, the title, was lost in that wall (granted, some shows have very strange titles, like Conan, that have titles that have nothing to do with their episode, but those are the exception and not the rule). Like in a definition list (still not completely the same thing, but the same basic idea) we needed an anchor to specifically stand out to define/lead the rest of the episode entry within the list. When you have some lists with 30 to 50 episodes on a single list/season (which often happened on Anime LOEs that I first worked on), having that title pop out over everything else is a godsend for the reader looking for that one entry.

However, like I said before, I'm not hellbent on using bold specifically. We originally wanted a way to anchor the title, to make it easy to find when scrolling through the list. If we can do that in another way (that, to be blunt, is less time consuming than RfCs, guideline reform/clarification, and everything else that would be needed to bring bold back into this template) then I am all for exploring that. As long as everyone is happy, things follow applicable MOS guidelines (even the sometimes unclear ones), and the main goals/strengths of the template remain, then let's not be afraid to look at alternatives. (just not that cell shading thing that happened before. That looked awful.) -- Ned Scott 18:59, 30 May 2012 (UTC)

Quick question, where is it confirmed that the MOS applies to prose only? I often read it but I have yet to see evidence of it. We shouldn't overuse bold anywhere, that's obvious, we need to do it other ways, hence our WP:ACCESS guidelines. For what it's worth, FLC mandates the use of WP:MOS whether it's a guideline or not. If people are happy with avoiding compliance with MOS at the expense of never getting featured material through FLC, fine. A shame, for such trivial changes, but fine. Life is too short to argue with people who say "I like bold text, so there." The Rambling Man (talk) 19:06, 30 May 2012 (UTC)

It's typically made clear in the examples in the various MOS pages, and the ones in question bring up pose-heavy examples. When these guidelines were made we typically had specific examples in mind, ones that were causing us trouble, like people bolding and throwing italics around like there was no tomorrow. You would be hard pressed to get people to say that the bolding of titles in LOEs created the same problems, such as making things distracting, looking unprofessional, or degrading the effects of bolding when you really need to make something bold.

One FLC made a stink out of the bold titles, and I would not take that as any kind of meaningful consensus alone (perhaps the start of something, but on its own, no). FLC is not an isolated division on Wikipedia. It's a process, and one that we are ALL involved in. The interpretations on the FLC factors come from all editors, thus forming (a sometimes moving) consensus. The people who participate in FAC and FLC are not specially trained against, they're normal editors like you and me. It doesn't bother me that we are questioning the bold titles, but it does bother me that it seems to all stem from isolated incidents and a minority opinion/interpretation.

If I may be honest, I am starting to get offended with these accusations like Life is too short to argue with people who say "I like bold text, so there.". In no way have I said that, and you insult me by ignoring my well written rational. Feel free to disagree with my rational, but to discount it completely like that, to belittle it, is rude.

ESPECIALLY when I keep saying that I would rather not argue for bold titles, and would like to show you guys some other ideas that might make us all happy. Please forgive my abuse of bold in that last sentence, but I felt it needed to be emphasized in face of it being ignored. I am 100% in favor of not fighting over trivial issues and looking for ideas that take less time and avoid offending/polarizing editors. I simply wanted my view on the original bold issue to be clear. -- Ned Scott 19:32, 30 May 2012 (UTC)

"One FLC made a stink out of the bold titles" not true. FLC requires compliance with MOS, MOS says we shouldn't abuse bold text for emphasis. As long as you or others wish to contend that unnecessarily bold emphasis is applied arbitrarily to text in a table, articles containing such tables will fail to meet MOS and not be featured. No big deal as it seems a common response that many folks working on these kind of articles don't want the articles to be amongst Wikipedia's finest. No problem. My comment about "I like bold' wasn't necessarily directed at you, but it seems very strange that we have so many folks coming out of the woodwork to defend bold titles in episode lists, and the best reason that can be offered is "I like it" or "It helps find the episode title". If it needs bold to help our visually able readers to find the title, perhaps the whole template is flawed. The Rambling Man (talk) 19:40, 30 May 2012 (UTC)

Several EOLs have made it through FLC, and even had things like the bold title discussed, and still became Featured lists.

I disagree that this is abuse of bold test for emphasis, I disagree that it is unnecessary, and I strongly disagree that is applied arbitrarily.

"No big deal as it seems a common response that many folks working on these kind of articles don't want the articles to be amongst Wikipedia's finest." This is where you come off as maybe belittling the viewpoint of others. Myself, and others who had no issues with bold episode titles, feel that those things are the very elements that made LOEs amongst Wikipedia's finest.

My point here is that we disagree with each other, but we need to respect each other. I really get the feeling that you believe your viewpoint far more strongly than I, and with that I think to myself "maybe that's because he's put more thought into it, and maybe he is right". I don't know if that's true, but it's one reason why I say I don't wish to push bold titles.

"If it needs bold to help our visually able readers to find the title, perhaps the whole template is flawed." Let's not be afraid to explore that possibility. That's one reason I propose that those editors (such as myself) look for alternatives to bold titles that might still do what we are looking for; making "episode entries" easier to find and stand out in a wall-of-text, but still not causing issues with reasonable interpretations of the MOS (as I find your point about bold titles to be reasonable, even if I disagree with it). -- Ned Scott 20:53, 30 May 2012 (UTC)

Please note that WP:WIAFL has evolved considerably since many episode lists were promoted. We have different and better (and stricter) criteria for promotion these days. Suggesting that historic episode lists that may have been promoted are somehow litmus tests for current episode lists is fallacious. Many people have insisted on an non-adherence to MOS (for various reasons) which automatically excludes lists from being promoted, hence my viewpoint that "many folks working on these kind of articles don't want the articles to be amongst Wikipedia's finest." Excluding certain groups of people from making the most of Wikipedia just because people "prefer" one format or another is entirely isolationist. The Rambling Man (talk) 20:59, 30 May 2012 (UTC)

Changes to sublist

Since we are discussing changes to Template:Episode list/sublist here, I will mention here I have created a parameter for it, to fix the stripping on cases like List of Friends episodes. I still feel that topcolor is being used for deviations, but as Ned Scott and I have just realized, it is needed for sublist to apply the zebra stripping, which I still think should be used on the long list of episodes that use season page transclusion. I hope that we can get rid of the frivolous use of topcolor, but retain the zebras in sublist. 117Avenue (talk) 23:19, 20 May 2012 (UTC)

Is there a way we can remove it as a parameter in the templates, but retain the striped functionality it provides in transcluding? Matthewedwards (talk · contribs) 05:18, 21 May 2012 (UTC)

All I can think of is forking the main template, which I guess won't be a problem, as it is a sanctioned sub-template. 117Avenue (talk) 03:31, 22 May 2012 (UTC)

This is what it looks like. 117Avenue (talk) 06:55, 23 May 2012 (UTC)

As I replied to Andrewcrawford below, I realized why I was using noincludes in the short summaries of the Degrassi pages, while it was using my hack. The problem my hack was producing was listing references, in the reference section of the main list, for the references that were being added to the shortsummary, even though they weren't appearing on the main list. This so called "null #if statement" that I promoted as a harmless addition, was producing content that is supposed to be hidden. I apologize to anyone who put their trust into my template editing abilities, I will start testing a fix to this problem, once my edit protected request is made. 117Avenue (talk) 05:44, 5 June 2012 (UTC)

Sandbox2 and Testcases2

Would anyone have obejection if i amde these sub pages i just want to try and make code to try remove the zxebra effect is speficed and to see if possible i can make code that will remove parameter is speficed, but i rather do the code in a serperate sandbox and test cases so not to infereenre with any current testing which wont be complex as wha ti am suggesting trying to code--Andrewcrawford (talk - contrib) 13:23, 1 June 2012 (UTC)

testcases2 already exists, but why do you want to remove the zebra striping? I thought it was consensus to keep it. 117Avenue (talk) 01:15, 2 June 2012 (UTC)

i want to add the option to remove it if the odd and even numbers are out of squence so giving a weird zebra stipping, i dnt want to remove it form all lists only one that would spefic the parameter to do it. Andrewcrawford (talk - contrib) 07:33, 2 June 2012 (UTC)

Removing it would be a bad idea, since we are trying promote consistency, with making a template that can be used in all circumstances. I created a fix in #Changes to sublist, the new parameter is called RowColor, you can read about how to use it in the documentation, and you can see it being used in the main, and sublist, testcases. 117Avenue (talk) 02:18, 3 June 2012 (UTC)

What would be ideal is having the templates do the striping fix automatically, without having editors having to use "RowColor=On". Can that be achieved? Matthewedwards (talk · contribs) 04:18, 3 June 2012 (UTC)

No. The only way to make it work is to use a parameter. All this template does is make one table row, there is no way for it to detect what is in the previous row, or a different article for that matter. 117Avenue (talk) 05:34, 3 June 2012 (UTC)

rowcolour is basically wha ti was goign to create so no point in me creatig that, but i still need to try create makea and test a |RemoveParameter= so the time team hack could be removed, but the sho i will use rowcolour on will take bit of experimenting to work out if i use no or yesAndrewcrawford (talk - contrib) 08:49, 3 June 2012 (UTC)

This can be done with noinclude tags, example. 117Avenue (talk) 00:12, 4 June 2012 (UTC)

excelent work 117 that works brillant, ill convert all the tlehr seasons a bit later on over the next month and covert to sublist once done ill delete the show hack, ill also add colbert report to my do list for conversion removing the last show hack, again really good work in finding a way to solve the transclusion problemAndrewcrawford (talk - contrib) 10:59, 4 June 2012 (UTC)

RowColor

can we have a option so if the epsiode number is blank we can specfic if it is to be odd or even coloured, maybe even having that as a option as well as with all other parameters to it--Andrewcrawford (talk - contrib) 14:06, 5 June 2012 (UTC)

plenty oif examples there, also for if episode numebr is spefic as N/A so a zebra row colour can be setAndrewcrawford (talk - contrib) 14:10, 5 June 2012 (UTC)

RowColor works for that as well. But I checked out some of the pages in the category, most of them are incorrectly formatted tables, and the few that are good, have a short table, which I don't see the point to zebra. 117Avenue (talk) 04:22, 6 June 2012 (UTC)

there one that doesnt appear on teh list, List of Extreme Makeover: Home Edition episodes the specials at teh botom mostly dnt have episode numebrs when i tried using the rowcolor it didnt apepar to change it, but ill try again--Andrewcrawford (talk - contrib) 12:12, 6 June 2012 (UTC)

my mistake, it does work, it seems when i was typing it i put a '!' instead of a '|' so it never changed the row colour all working fine so no need for wha ti suggested--Andrewcrawford (talk - contrib) 12:14, 6 June 2012 (UTC)

odd number translcusion colour

is there any chance fo usinga slightly darker shade of the colour, sometihng i am noticing on this computer but not my others one is i dnt notice the zebra stripping unless it is scrolled to the top, i rather suspect it is to do witht eh view angle as if i change position it becomes abit more obvious foor the bottom but since we are using zebra strippign to highlight the changes between the rows and viewing angle is different for each person maybe we should look to make it a bit more obvious so it accessible to all, if it is agreed to make it a bit darker i can test it from this comptuer so we dnt make it to dark--Andrewcrawford (talk - contrib) 10:41, 7 June 2012 (UTC)

ok i have made a change i think to the even numebr and amde it more whiter, i will check on my other comptuer see if it more clear if it is we maybe can change it.

but i have noticed a problem even with the current code, if you look at the sandbox cases at the bottom the line colour changes weirdly for some the full line changes but other only part of it changes--Andrewcrawford (talk - contrib) 12:19, 7 June 2012 (UTC)

ok fix that problem it was me that broke it with hwo i changed the code, i have now change the colour to a darker colour and on this ocmputer with the weird viewing angle you can clear see the zebra stripping and the dark colour isnt overpowering as my first change was--Andrewcrawford (talk - contrib) 12:34, 7 June 2012 (UTC)

Manual Archiving or archiving bot age change

this page hasa lot of old talk discussion that is now finished can we manually arching them or hange the bot to say 7d temporaily until it removes them and then change it back to 120d, just means discussion can remain on the things that are still ongoing--Andrewcrawford (talk - contrib) 12:05, 7 June 2012 (UTC)

List of The Colbert Report episodes

This has a show hack just to form a table that normally be done with wikitable, i think this should be converted to standard sublist and the hack deleted, also show page need to be brought up to standard and done right--Andrewcrawford (talk - contrib) 13:50, 19 May 2012 (UTC)

Yeah. It uses the template to produce a strange episode list where the airdate is the second column and other named columns are "The word", "Guest" and "Intro phrase". I don't watch the show, so I don't know if there are titles. Perhaps the Word is the title? Anyway, it could use Alt1 and alt2 for the Word and the Guest, and shortsummary for the phrase. But because this subtemplate is so custom, you should ask on the talkpage there before making any changes. Matthewedwards (talk · contribs) 03:38, 20 May 2012 (UTC)

"The Wørd" is a regular segment. The episodes don't have titles. Barsoomian (talk) 03:45, 20 May 2012 (UTC)

Repeating what I said on the Colbert subpage:

It was created six years ago before the main episode list template had evolved to a point where it could handle situations like this. At that time the main template didn't have the auxiliary options and such. No reason it can't be converted now, just no one has done it yet. -- Ned Scott 19:59, 20 May 2012 (UTC)

just doigna test here, as there appear to be two user who know the show you can comment and say if it is fine or notAndrewcrawford (talk - contrib) 15:34, 7 June 2012 (UTC)

please ingore the ttile field it is because title is required and not optional jsut now, i am not proposing title be used only put heading in to make the table look neater

Template:Episode_list/testcases#List_of_The_colbert_Report_episode fix for title

using episode list without hack

Episode #	Title	"The Word"	Studio guest	Introductory phrase	Original Airdate	Production Code
1	Truthiness[7]	Stone Phillips	"Open wide, baby bird, because mama's got a big, fat nightcrawler of Truth."	October 17	101
Gravitas-Off versus Stone Phillips; Colbert salutes Peter Mayhew's U.S. citizenship with a Chewbaccafigure.
2	Bacchanalia	Lesley Stahl	"Put some pants on, America. The Truth is knocking at the door."	October 18	102
Part one of "Better Know a District" with Rep. Jack Kingston (R) of Georgia's 1st congressional district; First All You Need to Know.
3	Disappointed	Fareed Zakaria	"Strap yourself in and flip the switch, 'cause you're about to get a Truthocution."	October 19	103
First "Tip of the Hat / Wag of the Finger"; First "Stephen Settles the Debate" (Whales and Cod vs. Eskimo Hunters and Seals); First The In-Box, where Stephen reads e-mails for viewers.

sublist

Episode #	Title	"The Word"	Studio guest	Introductory phrase	Original Airdate	Production Code
1	Truthiness[8]	Stone Phillips	"Open wide, baby bird, because mama's got a big, fat nightcrawler of Truth."	October 17	101
2	Bacchanalia	Lesley Stahl	"Put some pants on, America. The Truth is knocking at the door."	October 18	102
3	Disappointed	Fareed Zakaria	"Strap yourself in and flip the switch, 'cause you're about to get a Truthocution."	October 19	103

using show hack

{| class="wikitable" style="width:100%; margin:auto;"
|-
! # 
!! style="width:80px;"| First aired 
!! style="width:80px;"| "The Word" 
!! style="width:80px;"| Studio guest 
!! Introductory phrase 
!! Prod#
|-
{{Episode list/Colbert
|EpisodeNumber=1
|ProdCode=101
|TheWord=[[Truthiness]]{{ref|truthiness}}
|Guest=[[Stone Phillips]]
|IntroPhrase="Open wide, baby bird, because mama's got a big, fat nightcrawler of Truth."
|OriginalAirDate=October 17
|ShortSummary=Gravitas-Off versus Stone Phillips; Colbert salutes [[Peter Mayhew]]'s U.S. citizenship with a [[Chewbacca]]figure.
|LineColor=FF6666
}}
|-
{{Episode list/Colbert
|EpisodeNumber=2
|ProdCode=102
|TheWord=[[Bacchanalia]]
|Guest=[[Lesley Stahl]]
|IntroPhrase="Put some pants on, America. The Truth is knocking at the door."
|OriginalAirDate=October 18
|ShortSummary=Part one of "Better Know a District" with Rep. [[Jack Kingston]] (R) of [[Georgia's 1st congressional district]]; First ''All You Need to Know''.
|LineColor=FF6666
}}
|-
{{Episode list/Colbert
|EpisodeNumber=3
|ProdCode=103
|TheWord=[[wikt:Disappointed|Disappointed]]
|Guest=[[Fareed Zakaria]]
|IntroPhrase="Strap yourself in and flip the switch, 'cause you're about to get a Truthocution."
|OriginalAirDate=October 19
|ShortSummary=First "Tip of the Hat / Wag of the Finger"; First "Stephen Settles the Debate" (Whales and Cod vs. Eskimo Hunters and Seals); First ''The In-Box'', where Stephen reads e-mails for viewers.
|LineColor=FF6666
}}
|} 

comment from user who knwo the show will be appericated, if all is fine AWB to change it will be the best wayAndrewcrawford (talk - contrib) 15:34, 7 June 2012 (UTC)

this shows upa big problem with title being required i think ti time to make title optional and not required.Andrewcrawford (talk - contrib) 15:34, 7 June 2012 (UTC)

ok this is now converted to epiosde list ill now mark the hack for TFD , i have used title for now untilk such time as the sandbox code i have made is live then !Title can be replace with AUX1Andrewcrawford (talk - contrib) 15:57, 8 June 2012 (UTC)

List of Mario television episodes

someone has overrided the bolding on this one, i would remove it ymself with AWB as i have rights to use it, but i never been able to work out how to use it if anyon can give mea brief short descritpion on how to use it i would appericate it then i wouldnt need to post things liek this here ;)--Andrewcrawford (talk - contrib) 12:02, 7 June 2012 (UTC)

The entire page is a pile of mess. The only bolding of titles I see is in the episode summary row of the season 3 table. Just remove those titles. They don't need to be there because they've been given in the title column already. Matthewedwards (talk · contribs) 04:08, 8 June 2012 (UTC)

aussielegend fixed it but yeah ill add it to stuff im goign todo, i tried to clean the page up years ago but gota lot of resistent so left it as it isAndrewcrawford (talk - contrib) 08:27, 9 June 2012 (UTC)