Template talk:Episode table/Archive 2
 | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 | Archive 3 |
Template-protected edit request on 21 February 2020
{{edit template-protected|Module:Episode table|answered=no}} Please sync the module with Special:Permalink/941969397. It adds a new wrapper template for use at the end of the constructed tables.
Tested: here –MJL ‐Talk‐☖ 19:32, 21 February 2020 (UTC)
- MJL, why would a duplicate header row at the bottom of the table? In which scenario would this be required? In almost six years of being a WP:TV editor, I have never seen such a case. -- /Alex/21 21:30, 21 February 2020 (UTC)
- @Alex 21: I was making List of Homicide episodes at the time I wrote that, and seasons of the show had upwards of 45+ episodes. At it certain point it becomes more inconvenient to scroll upwards than downwards to figure out what each column means. Of course, I might've done something wrong there... –MJL ‐Talk‐☖ 21:40, 21 February 2020 (UTC)
- I saw the article, and I've never seen this idea in practice before. I think it may be best for a discussion to be held on the topic and a consensus gained first before implementing it. (Especially given that the code is mostly duplication, which is never good for upkeeping, and major issues could occur between differing widths set in the header and "bottom" rows.) -- /Alex/21 21:42, 21 February 2020 (UTC)
- Alright, I'll nominate {{Episode table/bottom}} for deletion and post notes at the relevant WikiProjects.
–MJL ‐Talk‐☖ 21:45, 21 February 2020 (UTC)
- Alright, I'll nominate {{Episode table/bottom}} for deletion and post notes at the relevant WikiProjects.
- I saw the article, and I've never seen this idea in practice before. I think it may be best for a discussion to be held on the topic and a consensus gained first before implementing it. (Especially given that the code is mostly duplication, which is never good for upkeeping, and major issues could occur between differing widths set in the header and "bottom" rows.) -- /Alex/21 21:42, 21 February 2020 (UTC)
- @Alex 21: I was making List of Homicide episodes at the time I wrote that, and seasons of the show had upwards of 45+ episodes. At it certain point it becomes more inconvenient to scroll upwards than downwards to figure out what each column means. Of course, I might've done something wrong there... –MJL ‐Talk‐☖ 21:40, 21 February 2020 (UTC)
Recent changes to markup
Recent changes to Wikipedia have made parts of this template practically unreadable on the mobile site. For example, the header "Directed by" now looks like this:
- Dir-
- ect-
- ed
- by
Likewise, the header "No. overall" looks like this:
- No.
- Ov-
- er-
- all
I don't know why these changes were made (and I don't think it will last), but would it be possible to put a nowrap template in to make it readable? Mclarenfan17 (talk) 04:37, 21 March 2020 (UTC)
- Which article are you referring to and on which device? Both of those are important to know because some articles may display more optional fields, and a small display might also cause problems. For instance, on an iPhone 6s, using Safari, and in portrait mode on List of Murdoch Mysteries episodes#Television films (2004–05) I see
No. Title Directed
byWrit-
en byOriginal air
date
- but further down
No.
over
allNo.
in
sea
sonTitle Directed
byWriten
byO
- I'm sure wider tables are worse, but this can be compensated if taken to landscape mode. No matter how hard I tried, I could not make that happen in a desktop browser, and I tried with Firefox, Chrome and Safari. Curious. Walter Görlitz (talk) 05:08, 21 March 2020 (UTC)
Use of Aux column for running times?
Hello, I recently created the article List of The Masked Singer (American TV series) episodes with episode tables that included the use of the Aux1 column for adding the running time of each episode in the table. The times were sourced from Fox's official website and I even added archive dates to the references as some of the links are not currently available. (See this edit for how this looked like). However, they were removed by Magitroopa who stated they were "not necessary whatsoever." While I realize that running times are not present on any other episode list article I could find... I don't see why there so unnecessary as though they're completely irrelevant from an episode list and must be removed. I mean... it's an episode list (isn't the runtime of an shows's episode an important piece of information about it?) and there are aux columns for a reason. I don't see what's so bad about using one of them to add running times! I would appreciate anyone's feedback on this, thanks. Heartfox (talk) 04:47, 29 March 2020 (UTC)
- Over on the talk page for said article, I've just brought up this past discussion. I've never come across any other article that lists the runtimes in for each individual episode in the table, it should be fine being listed in the infobox of the main article, like it already is. It doesn't really benefit the reader whatsoever knowing if an episode is 41, 42, or 43 minutes long. Magitroopa (talk) 05:03, 29 March 2020 (UTC)
- Also, see this more recent question. There's only one or two instances of a double-episode. There's no reason to specify if an episode is 44 or 42 minutes long. It's the standard- they're all about the same length, give or take a minute. Magitroopa (talk) 05:30, 29 March 2020 (UTC)
- Yes, as with Magitroopa, there's no need to add runtimes as a column. Especially since each episode is running between 42-44 mins long. Double episodes can be noted on the season articles. - Favre1fan93 (talk) 17:10, 29 March 2020 (UTC)
- Also, see this more recent question. There's only one or two instances of a double-episode. There's no reason to specify if an episode is 44 or 42 minutes long. It's the standard- they're all about the same length, give or take a minute. Magitroopa (talk) 05:30, 29 March 2020 (UTC)
Space before references
Contrary to MOS, this template implements a space between the table headings and any references provided for each column. An example is List of The Masked Singer (American TV series) episodes, where you can see: "Title [12][13]" and "Original air date [12][13]" etc. If we're going to use these templates across multiple articles (and I believe this is used across more than 11,000), at least can we code it correctly? Cheers. The Rambling Man (Stay indoors, stay safe!!!!) 07:46, 9 June 2020 (UTC)
- What exactly are you trying to have adjusted? - Favre1fan93 (talk) 14:57, 9 June 2020 (UTC)
- The Rambling Man, it seems to me that the space is there for readability, as the citation is highlighted in white and the table headings are usually colored. When not on a white background, I think it would look strange for, using your example List of The Masked Singer (American TV series) episodes, the white highlight to touch the white lettering of the S1 column titles.— TAnthonyTalk 15:47, 9 June 2020 (UTC)
- The should be no spaces between text and references. That is MOS. If other issues are clouding the matter such as highlighting against background colour etc, that's a different matter altogether. The Rambling Man (Stay indoors, stay safe!!!!) 16:52, 9 June 2020 (UTC)
- Agree with The Rambling Man that the MoS states that references should be presented without space. Walter Görlitz (talk) 16:28, 11 June 2020 (UTC)
- The should be no spaces between text and references. That is MOS. If other issues are clouding the matter such as highlighting against background colour etc, that's a different matter altogether. The Rambling Man (Stay indoors, stay safe!!!!) 16:52, 9 June 2020 (UTC)
- The Rambling Man, it seems to me that the space is there for readability, as the citation is highlighted in white and the table headings are usually colored. When not on a white background, I think it would look strange for, using your example List of The Masked Singer (American TV series) episodes, the white highlight to touch the white lettering of the S1 column titles.— TAnthonyTalk 15:47, 9 June 2020 (UTC)
Anchor parameter sometimes causes Lua error in Module:Episode_table at line 166
Adding parameter |anchor=s1 to Episode table in 99-1#Episodes, An Unsuitable Job for a Woman (TV series)#Episodes and Murder in Suburbia#Episode list causes
Lua error in Module:Episode_table at line 166: bad argument #1 to 'gsub' (string expected, got nil).
but worked in Always and Everyone#Episodes.
These are the only UK TV series articles that I’ve found so far that use Episode table. The majority of UK TV series articles use Episode list without Episode table. Around half of these have repeated episode numbers and no production code. Is it possible to set the anchor prefix in these cases? If not, could Episode list create an anchor using the episode title, or have a parameter to specify a text anchor, please? Jim Craigie (talk) 10:44, 19 June 2020 (UTC)
- Using parameters incorrectly can cause breakage of the code, and the module should not be coded to handle these. Looking at An Unsuitable Job for a Woman (TV series)#Episodes I see two problems. The first is that it is using {{Anchor}} inside the table. That is not supported in anyway. The second is that the {{Episode table}} is not using
|overall=. When you have two series (=seasons) you should use the|overall=parameter and it's numbering as that is how the template (and the TV MoS) are designed to work. Once you fix these issues it should work correctly without needing you to add an anchor. --Gonnym (talk) 15:06, 19 June 2020 (UTC)- @Jim Craigie and Gonnym: I've implemented the changes Gonnym said. Jim, you can now link to each episode as follows: An Unsuitable Job for a Woman (TV series)#ep1, where the last number is the "overall" number, as that is its unique anchor id. - Favre1fan93 (talk) 16:11, 19 June 2020 (UTC)
Link Production Code with its page definition
Something like:
[[Production_code_number|Production code number]]: Production code number
--Stdedos (talk) 17:05, 14 July 2020 (UTC)
- We don't link any other info in the headers, and I don't see the need for this to be linked. - Favre1fan93 (talk) 17:32, 14 July 2020 (UTC)
Implementing Template:Sronly
| This discussion has been closed. Please do not modify it. |
|---|
| The following discussion has been closed. Please do not modify it. |
|
Koavf, state your opposition to the edit. -- /Alex/21 14:05, 8 August 2020 (UTC)
Koavf,
Koavf, please discuss content, not conduct. I'll need to ask you again, where I have not answered a question about the captions, the module, the template or the episode tables themselves? You specifically stated
@Alex 21: Will you be reverting yourself as you should not have made this edit without prior consensus? ―Justin (koavf)❤T☮C☺M☯ 03:18, 25 August 2020 (UTC)
|
- Mdaniels5757, it's time to {{hat}}/{{hab}} this discussion, so we can proceed with the discussion on how to implement the changes, as per your proposal, as well as discussion on my pre-prepared sandbox edits and testcases. Would you be able to do this, please? Cheers. -- /Alex/21 04:16, 25 August 2020 (UTC)
- @Alex 21:
Done. —Mdaniels5757 (talk • contribs) 14:41, 25 August 2020 (UTC)
- @Alex 21:
Implementing Template:Sronly: sandbox and test cases
As part of the compromise suggestion that I provided in the earlier discussion, I have implemented sandbox and test case edits. There are three cases:
- The first episode table uses
|caption=, the standard parameter, which provides a hidden caption. - The second episode table uses
|visiblecaption=, a new parameter, which provides a visible caption and a tracking category (Articles using Template:Episode table with a visible caption). - The third episode table uses both
|caption=and|visiblecaption=; this would cause a conflict, and thus|visiblecaption=overrides|caption=, to provide a visible caption and a tracking category (Articles using Template:Episode table with two caption parameters).
-- /Alex/21 14:50, 25 August 2020 (UTC)
- Alex 21, Will you be reverting yourself? Why are you making the default behavior different from what it originally was when there is no consensus to do that? If anything, you should have
captionandinvisiblecaptionas options. ―Justin (koavf)❤T☮C☺M☯ 05:01, 27 August 2020 (UTC)- Koavf, please discuss the content. I have made a compromising suggestion that requires discussion. Thank you. -- /Alex/21 06:40, 27 August 2020 (UTC)
- Alex 21, So, that is a no, you will not be reverting yourself? Note how I did discuss the content and you ignored it. ―Justin (koavf)❤T☮C☺M☯ 07:49, 27 August 2020 (UTC)
- If you wish to discuss conduct, you're more than welcome to use my talk page, and I'll happily answer there.
If anything, you should have
A default parameter should exist for the most commonly occuring situation, and an alternate parameter should exist for the least commonly occuring situation. For example, we track episode tables with incorrect colour usages and don't track episode tables with correct colour usages, not vice versa. Same concept here. We track and provide for the minimal situation.captionandinvisiblecaptionas options.- Episode tables most commonly exist in their own section by themselves without other prose, as per MOS:TV, meaning that not requiring a visible caption is the most commonly occuring situation. Hence, the most commonly occuring situation would be to provide a hidden caption with the pre-existing
|caption=, and the least commonly occuring situation would be to provide a visible caption with the new parameter|visiblecaption=. -- /Alex/21 08:24, 27 August 2020 (UTC)- In the vast majority of cases, a caption isn't necessary, so the default should be not show, with the option to show, not the other way around. - Favre1fan93 (talk) 17:18, 27 August 2020 (UTC)
- Alex 21, So, that is a no, you will not be reverting yourself? Note how I did discuss the content and you ignored it. ―Justin (koavf)❤T☮C☺M☯ 07:49, 27 August 2020 (UTC)
- Koavf, please discuss the content. I have made a compromising suggestion that requires discussion. Thank you. -- /Alex/21 06:40, 27 August 2020 (UTC)
- @Alex 21: A few comments. Seeing as I don't know Module editing, can't you just have
|caption=and then a flag paramater such as|show_caption=set with "y/Y" etc.? Or is that what's happening? Also, do we need to create a tracking category for this? - Favre1fan93 (talk) 17:18, 27 August 2020 (UTC)- We certainly could have
|show_caption=, if you think that that works better. In that case I've suggested, it's simply a matter of replacing|caption=with|visiblecaption=to toggle between not displaying and displaying it. The first tracking category is to find articles that incorrectly use|visiblecaption=where it's not needed (although the category won't be a tracking sort that needs to be empty, as there will be correct usages of it), and the second tracking category is to find conflicting situations where both|caption=and|visiblecaption=are used; clearly in that case, one parameter needs to be removed (this category should always be empty). While the second category is required, the first might not be needed as much. -- /Alex/21 09:48, 28 August 2020 (UTC)- I think having two distinct parameters where one could show the caption and one can't could get unnecessarily cumbersome. That's why I suggest the flag option. Here's what I would suggest if I was coding it in wikitext
{{#if: {{{show_caption|}}} | {{{caption}}} | {{sronly|{{{caption}}} }} }}
And then for tracking, do{{#if: {{{show_caption|}}} | {{main other| [[:Category:Articles using Template:Episode table with a visible caption]]}} }}
. So however that translates over to module editing, should be what should be implemented. - Favre1fan93 (talk) 16:00, 28 August 2020 (UTC)- Agreed. I think we're better off going with a flag option. - Brojam (talk) 18:18, 28 August 2020 (UTC)
- That's certainly doable, and if there's more agreement for it, then I certainly agree with it myself! I've updated the sandbox and test cases for this; if there's no further disagreement, I can implement this. -- /Alex/21 01:09, 29 August 2020 (UTC)
- Agreed. I think we're better off going with a flag option. - Brojam (talk) 18:18, 28 August 2020 (UTC)
- I think having two distinct parameters where one could show the caption and one can't could get unnecessarily cumbersome. That's why I suggest the flag option. Here's what I would suggest if I was coding it in wikitext
- We certainly could have
"Caption" not working?
It seems as if the | caption = is not working, which is a violation of MOS:ACCESS. Any way to remedy this? livelikemusic (TALK!) 04:19, 12 September 2020 (UTC)
- Livelikemusic, see the documentation for the parameter. MOS:ACCESS has indeed been conformed to. -- /Alex/21 04:38, 12 September 2020 (UTC)
- Ah, yes, I see that now. Thank you. livelikemusic (TALK!) 12:36, 12 September 2020 (UTC)
"total_width" issues
Hello, I'm a bit puzzled because I haven't been involved in this template before, but it doesn't seem like the total_width parameter is being correctly applied. A number like "75" will work, yielding an HTML property of {{{1}}}, but specifying "auto" (which the documentation says is a valid option) will yield the invalid property {{{1}}}. Naming the parameter but leaving it blank yields {{{1}}}, also invalid, though my browser defaults to using something like "auto" for the table, so it looks okay. Not supplying the parameter at all defaults to 100%, which seems to be an improper choice because it causes a bad interaction with any table floating on the right such as an infobox. For an example, see this revision of "Bamboo Blade" and set your browser's viewport to no more than about 1350px width, and the episode table will be pushed down below the infobox on the side. Can the template please supply a default value of "auto" for this parameter so it plays nicely with other tables? --Iritscen (talk) 11:17, 21 September 2020 (UTC)
- Iritscen, I've added a width clause to the module, that determines between a set numeric with, an auto width, or the default of 100%. So,
|total_width=75and|total_width=75%will produce width: 75%;|total_width=autowill produce width: auto;|total_width=will produce width: 100%. - However, given that the episode table you provided as an example includes episode summaries, the default/automatic width of the table will be 100%. That's outside of this template's control and lies with the HTML automatically stretching the table to fit the summaries. -- /Alex/21 11:57, 21 September 2020 (UTC)
- Thanks. That was fast! Re: auto vs. 100%, my experiment with the Bamboo Blade page shows that width:100% will cause the two tables to collide (which is happening right now, with the template/module code the way it is currently), but width:auto will allow the tables to sit snugly next to each other. Specifying no width or a bad value causes the browser to default to width:auto, the desired behavior, although I haven't tested this in multiple browsers (I'm primarily using Opera). But based on that test, it seems to me that you would want the table to default to auto, not 100%, to allow the tables to always interact nicely. --Iritscen (talk) 12:16, 21 September 2020 (UTC)
- Yes, that's a common occurence in the WikiProject Television, unfortunately. We combat this by changing the set width or reorganizing the content so that the episode table is below the infobox. In the case of Bamboo Blade, auto seems to fix this problem. Cheers. -- /Alex/21 12:31, 21 September 2020 (UTC)
- Thanks. That was fast! Re: auto vs. 100%, my experiment with the Bamboo Blade page shows that width:100% will cause the two tables to collide (which is happening right now, with the template/module code the way it is currently), but width:auto will allow the tables to sit snugly next to each other. Specifying no width or a bad value causes the browser to default to width:auto, the desired behavior, although I haven't tested this in multiple browsers (I'm primarily using Opera). But based on that test, it seems to me that you would want the table to default to auto, not 100%, to allow the tables to always interact nicely. --Iritscen (talk) 12:16, 21 September 2020 (UTC)
Default background color not working?
I'm noticing today that the {{Episode table}} template is currently not defaulting to #CCCCFF as the background color – e.g. List of Handy Manny episodes.
Can anyone with coding knowledge take a look into this please, and hopefully find a fix? Thanks. --IJBall (contribs • talk) 03:30, 8 November 2020 (UTC)
- That's deliberate. Last week, I updated the default colour for an episode table header, to match the colour used by a regular wikitable header, like the table at WP:DTABTUT#Overview of basics. There's no need to differentiate them, and if colours aren't needed, they should reflect a regular wikitable header's default. Furthermore, if colours aren't needed, they can be remove from {{Series overview}} as well, as seen at List of Unsolved Mysteries episodes. -- /Alex/21 03:38, 8 November 2020 (UTC)
- This change should have gotten more discussion, or at least a lot more advance warning IMO. I've purposely left default colors out of the table code at a number of articles because I knew it would default to
#CCCCFF. Now I would have to go back and fix those tables manually (and I don't have such a list). And while I agree that {{Episode table}} and {{Episode list}} should have the same default color, I'm not sure that it should be the default wikitable color. (I'm not against making that an option – perhaps something like "background=wikitable" could be the coding choice for that.) But I think#CCCCFFshould be restored until we figure out how others feel about this, and can maybe see a list of how many articles this would affect, and if there are other approaches here. --IJBall (contribs • talk) 03:46, 8 November 2020 (UTC)- Hm. Why the set need for a random default colour? Why do they need fixing, what does #CCCCFF provide? There's no difference between what an episode table and a raw wikicode table provide in terms of a table, they're both wikitables and should thus go by the same defaults. -- /Alex/21 04:19, 8 November 2020 (UTC)
- That's not the point – the point is that this should have been discussed before being unilaterally implemented, as it affects a number of articles, and represents a change to relatively long-standing practice. --IJBall (contribs • talk) 04:35, 8 November 2020 (UTC)
- Sure. Can I see where this long-standing practice was initially agreed upon? Did we use #CCCCFF as a default before this template was created? -- /Alex/21 04:50, 8 November 2020 (UTC)
- Again, not the point. If you think the initial way this has been handled is wrong, it's on you to start a discussion on it. Other editors may or may not have agreed with you on it, but this is what should be done when a long-standing practice like this is changed. Again, I personally like the
#CCCCFFcolor much more than the "standard Wikitable format color", and would have liked, at a minimum, a heads up that a change was coming, along with a list of exactly which articles this change was affecting, so I could have made contingencies. Of course, the even better solution would have been something that allowed for the old practice to continue, while also allowing the "new" way to go forward. --IJBall (contribs • talk) 15:10, 8 November 2020 (UTC)- I'm sorry, I'm just not seeing anything that supports this "relatively long-standing practice", or any outside agreement as to its beginning and usage, and only what one editor personally likes. Unfortunately, we don't base Wikipedia around our personal likings. What about my two previous questions? Adding a third question, what is the major difference between an episode table and a wikicode table that determines that we need a different colour? -- /Alex/21 23:46, 8 November 2020 (UTC)
- Of course you don't – you think you are right, and to hell with anyone who disagrees with you. But it would be nice if, for once Alex, you remembered that you don't exist in a vacuum and what you do affects other editors. This whole thing is an example of the twisted environment of Wikipedia where template editors think editors serve their whims, and editors think readers serve their whims, which is the exact opposite of how this is also supposed to work.
- So, Alex, can you at least provide a list of which articles have {{episode table}}s with no background color so that the rest of us can fix your massive change without discussion if we want to?! That would be super considerate of you. Thanx. --IJBall (contribs • talk) 14:46, 9 November 2020 (UTC)
- "Of course you don't"? Of course I don't see the support for a "relatively long-standing practice"? I don't get your comment there, I just asked where this practice started or was discussed, that's all. I don't think I'm "right". I'm just not seeing how I apparently "arbitrarily" changed a colour (which wasn't arbitrarily at all, but based on Wikipedia styling that's been in place for at least a decade) that was picked arbitrarily with no consensus, discussion or agreement.
- What needs fixing? Again, what does #CCCCFF provide that no other colour does not? -- /Alex/21 23:26, 9 November 2020 (UTC)
- I'm sorry, I'm just not seeing anything that supports this "relatively long-standing practice", or any outside agreement as to its beginning and usage, and only what one editor personally likes. Unfortunately, we don't base Wikipedia around our personal likings. What about my two previous questions? Adding a third question, what is the major difference between an episode table and a wikicode table that determines that we need a different colour? -- /Alex/21 23:46, 8 November 2020 (UTC)
- Again, not the point. If you think the initial way this has been handled is wrong, it's on you to start a discussion on it. Other editors may or may not have agreed with you on it, but this is what should be done when a long-standing practice like this is changed. Again, I personally like the
- Sure. Can I see where this long-standing practice was initially agreed upon? Did we use #CCCCFF as a default before this template was created? -- /Alex/21 04:50, 8 November 2020 (UTC)
- That's not the point – the point is that this should have been discussed before being unilaterally implemented, as it affects a number of articles, and represents a change to relatively long-standing practice. --IJBall (contribs • talk) 04:35, 8 November 2020 (UTC)
- Hm. Why the set need for a random default colour? Why do they need fixing, what does #CCCCFF provide? There's no difference between what an episode table and a raw wikicode table provide in terms of a table, they're both wikitables and should thus go by the same defaults. -- /Alex/21 04:19, 8 November 2020 (UTC)
- This change should have gotten more discussion, or at least a lot more advance warning IMO. I've purposely left default colors out of the table code at a number of articles because I knew it would default to
Alex 21, to IJBall's point, whether or not have #CCCCFF as a default had any merits or functionality beyond it just being chosen as such, it still has been the "standard" for the TV project as long as I've been here for that to be the default table color. And going in and changing it to not be that, can be viewed as disruptive. It's a small thing yes, but there was nothing wrong per se with it being used, as it was accessibility color compliant. I will say, given that vast majority of tables pick some sort of color, having CCCCFF default helps distinguish the table as being an episode table from another wikitable. I would like to see it restored until a larger discussion is had. - Favre1fan93 (talk) 23:39, 9 November 2020 (UTC)
- Thank you for a civil response. I've temporarily restored the #CCCCFF colour.
- However, about your comment on distinguishing an episode table from another wikitable takes me back to my comments from earlier: what is the difference? They're both wikitables, there is no difference between them.
There's no difference between what an episode table and a raw wikicode table provide in terms of a table, they're both wikitables and should thus go by the same defaults.
- If the colour does not have "any merits or functionality beyond it just being chosen as such", then there is no use for it. Wikipedia does not use colours just for the sake of them, we use them to differentiate content, which is why we use different colours for different episode tables, to differentiate between separate seasons. However, if there is no colour needed to differentiate between episode tables, such as at List of Unsolved Mysteries episodes or List of Handy Manny episodes, then a colour should not be used, and it should be presented as a regular wikitable. Can you show examples of other regular wikitables that use a standard colour? -- /Alex/21 23:56, 9 November 2020 (UTC)
- I gave you about 17 "civil" responses, and you simply stonewalled me. As to the broader point, not everything has to have a pure "functionality" component. You may have a point that many-season TV series tables should possibly simply dispense with the colors and do a standard "wikitable". But for our usual 2–7 season TV series, having colors to differentiate the seasons is a good idea. Unfortunately, not all TV series have had someone "pick a color for every season" (e.g. List of Handy Manny episodes), so having them default to
#CCCCFFin the meantime is useful. Frankly, the "plain wikitable" color is unappealing, esp. considering we've been using#CCCCFFfor a long time. That should not be changed willy-nilly on the whims of one template editor. --IJBall (contribs • talk) 02:13, 10 November 2020 (UTC) - P.S. And I again a request a list of articles using {{Episode table}} with no background color – how many articles we're talking about is an important part of this discussion. Is it a few articles, or many? --IJBall (contribs • talk) 02:17, 10 November 2020 (UTC)
- So, given that it's "unappealing", it's based on what's aesthetically pleasing, that's it?
- You can easily use the search function to find transclusions of {{Episode table}} that don't use
|background=. -- /Alex/21 02:21, 10 November 2020 (UTC)- And now you're assuming that every editor is as technically savvy as you are – plenty are not. It seems like you're willing to be "helpful" to certain editors but not to others – I have a suspicion if Favre1fan93 had asked this question, you would have already have answered it. So we're back to stonewalling. --IJBall (contribs • talk) 02:25, 10 November 2020 (UTC)
- I said no such thing. In the case of being "helpful", it was because there were more editors who disagreed with the change instead of just one, so I respected that and reverted it. There's help pages where you can look up how to do these things; no offense, but you shouldn't expect other editors to do all of the work for you. -- /Alex/21 02:29, 10 November 2020 (UTC)
- Oh, I definitely don't expect you to do work for anyone else. P.S. Even one editor objecting, as I did, should have been enough to trigger WP:STATUSQUO. But, like I said, apparently it depends on who does the asking... --IJBall (contribs • talk) 02:31, 10 November 2020 (UTC)
- STATUSQUO is an essay, not a guideline or policy, and does not state that the edit must be reverted. Would you like to get back on topic now, or? -- /Alex/21 02:35, 10 November 2020 (UTC)
- I understand and agree with IJBall's point that it's possible some editors do not put their own background color because it defaults to the CCCCFF, and so they use that. To your question about the difference in a wikitable and this. Yes, they are both wikitables, but our WikiProject encourages the use of heading colors, so if we wish to conform to our guidelines and practices, a default color should be utilized. I also suggest a new discussion be started below or at the TV project talk regarding if the default color should remain, so more editors can weigh in beyond the three of use. It can link back to this one for other editors to reference. - Favre1fan93 (talk) 15:28, 10 November 2020 (UTC)
- STATUSQUO is an essay, not a guideline or policy, and does not state that the edit must be reverted. Would you like to get back on topic now, or? -- /Alex/21 02:35, 10 November 2020 (UTC)
- Oh, I definitely don't expect you to do work for anyone else. P.S. Even one editor objecting, as I did, should have been enough to trigger WP:STATUSQUO. But, like I said, apparently it depends on who does the asking... --IJBall (contribs • talk) 02:31, 10 November 2020 (UTC)
- I said no such thing. In the case of being "helpful", it was because there were more editors who disagreed with the change instead of just one, so I respected that and reverted it. There's help pages where you can look up how to do these things; no offense, but you shouldn't expect other editors to do all of the work for you. -- /Alex/21 02:29, 10 November 2020 (UTC)
- And now you're assuming that every editor is as technically savvy as you are – plenty are not. It seems like you're willing to be "helpful" to certain editors but not to others – I have a suspicion if Favre1fan93 had asked this question, you would have already have answered it. So we're back to stonewalling. --IJBall (contribs • talk) 02:25, 10 November 2020 (UTC)
- I gave you about 17 "civil" responses, and you simply stonewalled me. As to the broader point, not everything has to have a pure "functionality" component. You may have a point that many-season TV series tables should possibly simply dispense with the colors and do a standard "wikitable". But for our usual 2–7 season TV series, having colors to differentiate the seasons is a good idea. Unfortunately, not all TV series have had someone "pick a color for every season" (e.g. List of Handy Manny episodes), so having them default to
Director parameter
I recently asked (and got answered) about a similar thing involving television infoboxes at Template talk:Infobox television#Producers question.
For the episode tables themselves, would the same thing apply? As in only those listed as 'director' and not anything else (ex: 'supervising director') should be listed in the tables? For example, the director credits were recently added to Kamp Koral: SpongeBob's Under Years here, but all of them are either supervising or storyboard director.
Not sure if there are any exceptions, such as a show that doesn't list main directors. For example, the first episode, "The Jellyfish Kid" now has the supervising directors and storyboard director listed in the episode table. Looking at the opening credits, the only credits given are 'Written by', 'Storyboard director', 'Supervising directors', 'CG supervisor', 'Co-executive producers', and 'Executive producer'- no main 'director'. So would this be an example where it's fine to list supervising/storyboard directors, or should only writers be listed and leave the directors out like previously? Magitroopa (talk) 20:47, 4 March 2021 (UTC)
Any way to make this table template sortable?
I think it would be great if one could sort the Episode-number and Production-code columns, especially in cases where episodes were aired out of order like in List of Lizzie McGuire episodes and List of Sliders episodes. Is there any way to make this happen? Shāntián Tàiláng (talk) 19:40, 8 March 2021 (UTC)
Calculate text color automatically depending of the table header background color
Is it possible to add some logic for style calculation of the table header or restrict styling of these elements? For dark/black themes in iOS/Android might happen issue with colors overlap like in this example (check Episodes section) - https://en.wikipedia.org/api/rest_v1/page/mobile-html/The_West_Wing_(season_7)?theme=dark Additional details - https://phabricator.wikimedia.org/T284327 VadimKovalenkoSNF (talk) 08:23, 6 September 2021 (UTC)
Reference Spacing
I had this issue brought up at at an FAC of mine. Not sure if this is an issue with every reference that is added into the table but with |airdateR= it adds what appears to be a partial space between the text in the reference. (Original Air Date [1] instead of Original air date[1]). It wouldn't copy and paste here exactly as it appears, but if I paste it into a web browser field, and remove the space and then hit my space bar the spaces are not the same size. Hopefully that explanation wasn't too confusing but unless there is a specific reason can this issue be fixed so that there is no space there? TheDoctorWho (talk) 15:32, 13 October 2021 (UTC)
- Module:Episode table#L-34 uses
 which is the space used for Template:Hair space. For why that is, Alex would probably know. Gonnym (talk) 15:43, 13 October 2021 (UTC)- Pinging @Alex 21: just to bring attention. If there's a specific reason I can bring that up at the FAC, thought I'd ask though since we don't typically space between the text and the reference. TheDoctorWho (talk) 15:57, 13 October 2021 (UTC)
- Yes – this styling has always violated MOS:REFPUNCT. If there is no good reason for it, the "extra space" should be removed. --IJBall (contribs • talk) 18:34, 13 October 2021 (UTC)
- @IJBall Incorrect. MOS:REFPUNCT very clearly states that
[a]
, so no, it's never "violated" anything. Thank you.<ref>...</ref>tag can be spaced apart from the preceding content by a hair space in the unusual case that the results of not spacing could be visually confusing - Anyways, a reference in an episode table cell is sometimes provided with an automatic background colour due to WCAG contrast requirements, and thus the above is why the hairspace was added, given that coloured text and a reference with a coloured background directly next to each other can be visually confusing. However, this should not affect a FAC at all, and if it does, you can simply quote this reasoning and how it is completely acceptable per REFPUNCT. -- /Alex/21 20:28, 13 October 2021 (UTC)
- @IJBall Incorrect. MOS:REFPUNCT very clearly states that
- Yes – this styling has always violated MOS:REFPUNCT. If there is no good reason for it, the "extra space" should be removed. --IJBall (contribs • talk) 18:34, 13 October 2021 (UTC)
- Pinging @Alex 21: just to bring attention. If there's a specific reason I can bring that up at the FAC, thought I'd ask though since we don't typically space between the text and the reference. TheDoctorWho (talk) 15:57, 13 October 2021 (UTC)