Template talk:Track listing

Quotes around titles

Why do track titles automatically get quoted? It seems like unnecessary clutter, especially with long track lists. It also interferes with track names that are supposed to have quotes around them (for example, several tracks on Music of The_Lord of the Rings film trilogy#The Complete Recordings are supposed to be quoted on their own, but it would just look dumb to have two sets of quotes). – Gardnermj (talk) 09:58, 28 March 2009 (UTC)

It's likely that if we didn't have this rule, it would encourage editors to omit them from paragraphs as well. I kind of agree that they might not be necessary when making a list of titles in a track list section, but we have done it that way for a long time, and I doubt there will be consensus to change the rule. As for the example you gave us, if there are quotes in the track titles, there should be quotes within quotes in the article: single quotes within double quotes.

Also, I notice the track lists all collapse in that article, which might not be deliberate. If that's true, it is probably being caused by a problem where if there is one collabsible list or box somewhere on the page, it makes all other collabsible boxes collapse. It may be possible to fix this by finding the box that's causing it, and making it non-collapsing, if a parameter is provided to allow this. --A Knight Who Says Ni (talk) 22:39, 28 March 2009 (UTC)

That's deliberate, at least it was, when I introduced the template on that page. The track listings of multi-disc releases can be very long, especially soundtracks, as these are often made-up of many, shorter tracks. Adding to that, the article covers several and to some degree even redundant releases, hence its only convenient for readers when at least the lengthier ones are initially collapsed, so that one can navigate around the overall article faster.

Regarding mandatory quotes, we're really just following pre-existing guidelines (WP:MOSTITLE and related bits from WP:ALBUMS) here and I don't think it would be wise to jeopardize consistency just to accommodate a few select tracks that, as A Knight Who Says Ni suggested, would be triple-quoted in other instances anyway. – Cyrus XIII ^(talk) 18:34, 6 April 2009 (UTC)

Is it possible to replace “programmer’s” quotes to “book quotes”? – Klimenok (talk) 08:30, 17 February 2010 (UTC)

Not done per Wikipedia:MOS#Quotation marks. — Huntster (t @ c) 09:43, 17 February 2010 (UTC)

USA bias

In the USA '#' is used to mean 'number', but in other countries it doesn't mean any such thing. In the UK '#' can only mean 'hash', it has no other meanings.

In the UK the abbreviation for 'number', whether in chart placings or anything else, is 'no.'

Can we have less USA culture forced down our throats by Wikipaedia [sic] please?

Or is Wikipaedia [sic] a vehicle for wiping out international cultures and replacing them with the customs and practices (yes, with a 'c' not an 's') of the USA? —Preceding unsigned comment added by 92.25.228.120 (talk) 17:43, 28 December 2009 (UTC)

No, English-language Wikipedia is not supposed to be geared toward American readers more than other English speaking persons, and your accusation of a great cultural conspiracy is rather silly. By the way, in response to one of your complaints, did you know the word "practise" with an "s" was the proper spelling of the word in Middle English, and it comes from the Old French word "practiser"? So if you want to blame a whole nation for corrupting the spelling, the USA is not the place to start. "Wikipedia" is spelled as it is because it was named by an American (and, being a "brand name", any other spelling of it is improper), but that does not mean the spelling of "encyclopaedia" is disallowed; see the article on encyclopedia which shows three spellings of the word, one of which is even more traditional than yours. For more about WP's policies regarding spellings to be used, see MOS:SPELLING (in a nutshell, any proper spelling is acceptable, but there are guidelines on which to use depending on the circumstance). There may be inadvertant use of a symbol not internationally recognized, but its non-universality doesn't get noticed until someone points it out. So thanks for pointing it out, but you didn't have to do it with a big whine. Anyway... the template uses "#" as a column heading, and aside from the claim that it's not used to represent "number" in the UK (which, even if true, probably doesn't mean that UK residents have never seen it used this way, or can't figure out what it means), it isn't a good choice for a column heading anyway, because it doesn't say what the number represents. It just says "number" over top of a column of numbers. "Track" would have been a better choice. Clearly we wanted it to be as short as possible, to allow the column to be as narrow as possible. Maybe an abbreviation of "Tk." would be appropriate, or maybe not. By the way, the Manual of Style concurs with the complaint above, and recommends "No." instead of "#", but as I've pointed out, there is a bigger problem. --A Knight Who Says Ni (talk) 15:13, 29 December 2009 (UTC)

"Track" instead of "#" is a simple compromise which does away with this problem (although I would note that the anon is wrong, and the hash symbol as "number" is recognised in the UK as well). I've implemented it. Chris Cunningham (not at work) - talk 12:46, 16 March 2010 (UTC)

Sub-titles

Does anyone out there know how to accomodate sub-titles using this template? A song may have several sub-sections which have their own subtitle e.g. the Track "Autumn" on Hero and Heroine by Strawbs has three sections each with an individual title (and writer) best Witchwooder (talk) 13:02, 17 January 2010 (UTC)

There have always been discussions at music wikiprojects over when it is appropriate to use the tracklist template vs. a simple list, as that article has now. Many editors agree the simple list should be used unless the tracklist has some "complexity" where a table or template would be more helpful. This is one case where the simple list can show things clearer than the fancier formats. I'd suggest keeping the list as is. In fact, it could be improved by using a double pound sign which both indents and numbers the subtitles, like so:

1. "Autumn" – 8:27
   1. "Heroine's Theme" (John Hawken)
   2. "Deep Summer Sleep" (Dave Cousins)
   3. "The Winter Long" (Cousins)
2. "Sad Young Man" (Rod Coombes) – 4:09
3. "Just Love" (Dave Lambert) – 3:41
4. "Shine on Silver Sun" (Cousins) – 2:46

--A Knight Who Says Ni (talk) 23:30, 17 January 2010 (UTC)

Thank you sir knight! ecki ecki ptang etc.

Witchwooder (talk) 08:48, 18 January 2010 (UTC)

Vocals

do vocals go in "music credits" or do i need to make an extra column?Bread Ninja (talk) 16:16, 2 February 2010 (UTC)

Music credits means songwriting credits. Vocals should go in the extra or note column. --A Knight Who Says Ni (talk) 02:45, 3 February 2010 (UTC)

The auto-quotation marks

I would love to be able to use the {{ref}} template next to title tracks, but the quotation marks are wrapped around them. My would-be workaround is shown in Example Two.

Example One

No.	Title	Length
1.	"Song titlenote 1"	4:44

Example Two

No.	Title	Note	Length
1.	"Song title"	note 1	4:44

–Kerαunoςcopia^◁_galaxies 12:01, 5 February 2010 (UTC)

This probably isn't much better, but...

Example Three

No.	Title	Length
1.	"Song title" ([1])	4:44

--A Knight Who Says Ni (talk) 13:11, 5 February 2010 (UTC)

The Episode list Template contains a "RTitle" field which can be used to add references or notes, and places them outside of the automatically quoted titles. Perhaps something like this could be added to this template. Mizery Made (talk · contribs) 16:53, 5 February 2010 (UTC)

How to Format

I'm currently helping someone make a list of soundtrack article instead of having separate articles. I'm nearly done turning all into tracklist format except for the ones in the Evangelion: The Day of Second Impact, Evangelion: 2.0 You Can (Not) Advance Original Sound Track, and Neon Genesis Evangelion Addition. if anyone can help me, that would be great.Bread Ninja (talk) 16:34, 10 February 2010 (UTC)

box width

Is there any way we could make the width of the box a variable with a default of how it is now? That would be appreciated because there are many articles there there is no change of infobox interference, but the width is simply too narrow (the "notes" and credits flow into the next line - this is especialyl common with the extra column. TheHYPO (talk) 20:11, 7 March 2010 (UTC)

I believe this has been asked in the past (probably frequently), and the response is the box was made to this fixed length to prevent its interference with the infobox in short articles with little more than an infobox and tracklist. (The way they interfere with each other varies by browser.) --A Knight Who Says Ni (talk) 21:38, 7 March 2010 (UTC)

I know that; I read above. My question was, could we alter the template so that it has a DEFAULT margin of what it is now, but for articles where it clearly wouldn't interfere, the margin could be changable... So it would only change from the default if the editor actually intended it to, and obviously did so knowing it wouldn't be anywhere near the infobox? TheHYPO (talk) 22:19, 7 March 2010 (UTC)

Usage clarification regarding Music

Okay, so when it comes to Hip-Hop/R&B (and sometimes Pop) music, the term "producer" is applied to the individual who "wrote" the music. This raises a usage issue with this template, since there seems to be a tendency for individuals to disregard the "music" column in favor of using the Extra column for "Producer" when it comes to usage on album pages from these genres. Should this continue to be the method employed on such pages, or should we instead be using the "Music" column for such information? After all, when it comes to the specified genres, the term is applied to the individual responsible for creating the music of the song in question.

So, I'm looking for some discussion, clarification, consensus on this issue. Is using the Extra column preferred, to distinguish from works of art that have their music more traditionally "written" (with sheet music and whatnot, as opposed to being pieced together on a board or whatnot)? Or should these articles be taking advantage of the Music column, since it's there for the creator of... well, the music? A third option (that is likely to be viewed as unnecessary), would be some kind of switch or "Header override" function to the template (if that's at all possible). With that, the Music column header could be altered to "Producer" for articles belonging to a genre where that terminology is more common and still leave the Extra column for other uses.

What is everyone else's thoughts on the matter? - Mizery Made (talk · contribs) 03:00, 17 March 2010 (UTC)

This is news to me. I've never heard of "producer" being used to refer to "songwriter". Producers usually belong to a union, and I find it hard to believe a Producer's union would allow the definition, for the purpose of its membership, to vary by genre. Furthermore, songwriters register their creative ownership through a publishing company which collects royalties for them, and I can't see why publishers would call songwriters "producers" for a certain genre. It is true that producers often get a good cut of the profits, and the word "royalties" can apply to either songwriter or producer income, but the producer's profit comes from the record company, while the songwriting royalty comes from the publisher.

Music is not necessarily registered with a publisher using sheet music. A copy of the recording (either the finished product or a demo) can be used. But even so, it is the melody, harmony, and lyrics that are being copyrighted by the publisher, and the actual recording of the song that the producer gets credit for.

When artist B covers a song by artist A, the songwriter (who could be artist A, or the producer of artist A, or someone else altogether) gets the same royalty from both versions, while the producer of artist A's version gets nothing from artist B's record's profits. I can't see this arrangement being different when the genre is different. Can you point us to instances where this is not the case?

Of course there will be cases where the producer is officially credited as a contributor to the songwriting, and this may well be a common occurence in hip hop. But that's not the same thing as saying songwriters get credited as producers, when they had no involement in the recording process, and weren't even in the studio. (If that's what you're saying.) --A Knight Who Says Ni (talk) 12:34, 17 March 2010 (UTC)

Producer: "Hip hop producer, creates hip hop music using electronic instruments". - Mizery Made (talk · contribs) 21:47, 18 March 2010 (UTC)

A producer is not the same thing as a songwriter. Mizery Maid's confusion stems from, I believe, the fact that in contemporary hip hop and R&B (his area of interest), the producer is also frequently one of the song's writers OR (similarly) contributes enough to the track to receive a songwriting credit. Just because the line between the two roles are occasionally blurred does not mean the original definitions change. TheJazzDalek (talk) 00:34, 19 March 2010 (UTC)

Wait, i have a question, for those who compose/arrange the music or song, does that fall in music credits or writing credits???Bread Ninja (talk) 16:19, 30 March 2010 (UTC)

That would be writing. TheJazzDalek (talk) 17:38, 30 March 2010 (UTC)

To clarify: "music" is used when there are separate "music" and "lyrics" credits present; "writing" is used when the same person(s) did both, or the breakdown is not known (or at least not officially acknowledged), or for songs without lyrics. An arranger is usually credited together with the writer: "(person A, arr. person B)". BUT if someone were to arrange a song whose original credits had a music / lyrics breakdown, the arranger would have to be credited under music. For example: (music: Elton John, arr. A Knight Who Says Ni, lyrics: Bernie Taupin). Now if the arranger changed the lyrics as well... give up! :) --A Knight Who Says Ni (talk) 15:23, 31 March 2010 (UTC)

So what your basically saying is arranger is the one who gets credited along with the lyrics/music unless they arranged a song that originally had song/lyrics breakdown, because that would be "music".

But you don't know if what to mark the arranger as if s/he changed the lyrics. i think that would fall in lyrics and writer.Bread Ninja (talk) 16:47, 31 March 2010 (UTC)

I just threw in the bit about changing the lyrics as a joke; note the "smilie" at the end of the sentence. For more complicated cases, use the official credits as a guide. When lyrics are changed (as in song parodies, for example) this is often credited as "adapted by..." and would indeed be associated with the lyrics credits. But again, you said "lyrics and writer", and as I said, "writer" means music and lyrics combined, so you would never use "writer" and "lyrics" in the same song credit. --A Knight Who Says Ni (talk) 17:00, 31 March 2010 (UTC)

Ok, what about those who are just merely performed the song?Bread Ninja (talk) 18:07, 31 March 2010 (UTC)

They are the recording artist. --A Knight Who Says Ni (talk) 12:45, 1 April 2010 (UTC)

While you're answering the question above, perhaps you could clear up my original "confusion" (as Jazz put it), and suggest how to apply this to contemporary Hip-Hop & R&B. (Often) When it comes to these types of albums, there will be a "Written by" (or similar) credit, along with "Producer" or "Production by" for each song in the liner notes. For whatever reason, in the world of Hip-Hop (and contemporary R&B at times) carries a different definition for "Producer." The "Written by" credit generally applies to the lyricist(s) of the song, while the "Producer/Production by" for this genre refers to the person responsible for the music for said song. The current workflow is to use "Writer" for the "Written by" (Lyricist) credits, and them use the Extra column for "Producers." Whereas the "Producers" for these types of albums seems like they would be better fitted for the "Music" column. Thoughts? - Mizery Made (talk · contribs) 20:53, 31 March 2010 (UTC)

You say that "producer" refers to the person "responsible for the music". I believe this means they were responsible for supervising the recording session. That is what a producer does. I realize what you're saying; the "songwriter" of a hip hop (rap) song often just wrote the lyrics, and the producer provides (composes) the background music, which is often of lesser importance. Nonetheless, in referencing the official album or song credits, we should find the person who composed the background music is credited as "music", and the person who supervised the recording session is credited as "producer". If the singer is credited as "writer" but someone else (such as the producer) is explicitly credited with composing the music, and from that you infer that the "writer" really only wrote the lyrics, you can show it that way in the article. But we shouldn't assume the producer is also the music composer, or vice versa. Nor should we assume that in the case where the singer is credited as "writer", and nobody is credited with writing the music, that the "writer" only wrote the lyrics, and the producer wrote the music, uncredited. We have to go with official credits and not try to reinterpret them based on assumed alternate standards for a genre. --A Knight Who Says Ni (talk) 12:45, 1 April 2010 (UTC)

what i meant to ask, where would performer go in the tracklist template>Bread Ninja (talk) 22:58, 5 April 2010 (UTC)

See National Lampoon's Animal House for an example of a various artists album. --A Knight Who Says Ni (talk) 23:59, 5 April 2010 (UTC)

oh nevermind.....they just add in an extra column....Bread Ninja (talk) 15:24, 6 April 2010 (UTC)

Tools for your convenience

Text file with fields for 1-99 listed:

• Google Docs format
• Plain text format (downloadable)

Excel spreadsheet (1-99) for easier data entry that creates a formatted column:

• Google Docs format
• Excel 2003 format (downloadable, recommended)

Suggestions or problem reports would be appreciated. Ponydepression (talk) 18:36, 17 April 2010 (UTC)

Your Excel Sheet doesn't seem to play too nicely with the lengths. You input "6:04" and end up with "| length1 = 0.252777777777778," but it's certainly possible I've done something wrong. What about adding the "global options" to the top of the spreadsheet as well? Perhaps with the ability to correctly calculate the Total Time as well? – Mizery Made (talk · contribs) 12:44, 25 April 2010 (UTC)

hAudio microformat

Unresolved

I plan to add the hAudio microformat to this template; but first it would be useful to have the parameters of {{Tracklist/Track}} {{Track listing/Track}} documented. Can anyone oblige with that, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:27, 18 April 2010 (UTC)

Andy, the template was moved from {{Tracklist}} to it's current name on 16 March (this edit}. However, the editor who did this omitted to move all the its subpages. Before doing anything else, don't you think those subpages should be moved along for consistency? And would you mind explaining what's the benefits of hAudio microformat to Wikipedia? The link you provide above is wrong I think. – IbLeo^(talk) 13:50, 25 April 2010 (UTC)

Sorry; link fixed. Yes, I suppose the sub-pages should be moved. For more information on microformats, see the microformats project. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:08, 25 April 2010 (UTC)

I have moved the remaining subpages. —TheDJ (talk • contribs) 20:44, 25 April 2010 (UTC)

This documentation is still required, please. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:39, 12 May 2010 (UTC)

Recent change: width

I notice an editor has changed the template so that "width" is a "new" parameter. The parameter has not been added to the documentation, nor was it discussed or even announced here. The change does NOT expand the width of the table, and I wonder if the editor intended that to be the effect. If not, I'm not certain of the purpose of this change. Should we revert? And isn't it time we protected this template so only admins can update it, considering the many articles it's used in, to prevent it from being affected by vandalism, not to mention well intentioned but untested / undocumented / unapproved changes? --A Knight Who Says Ni (talk) 12:31, 1 May 2010 (UTC)

I also wondered what the xxxx that change was all about... I agree to revert it and ask for full protection of the template. But before we do so, I suggest we replace "Tracklist/Track" by "Track listing/Track" in the code. It's kind of stupid that the template invokes it's own subtemplate over a redirect. – IbLeo^(talk) 13:10, 1 May 2010 (UTC)

You're reading my mind! I was just going to look into that. (Hope you're not already working on it.) I also notice this template has a sandbox page that is not working, or at least not working the way it's supposed to or the way someone is currently trying to use it. So that will be the next task. Anyway, I'm looking at how to update the template code. My browser does not have a find/replace function that works on WP's edit window, so I think I'll have to copy to a text file. --A Knight Who Says Ni (talk) 16:55, 1 May 2010 (UTC)

Done! I also reverted the width change and let the user know. --A Knight Who Says Ni (talk) 17:30, 1 May 2010 (UTC)

I was actually going to do those changes but didn't dare without testing first. So while I was setting up some proper test cases for the sandbox (and in parallel defending myself of accusations for being a philistine :-)) you overtook me and did the changes directly in the template space. Brave man! And well done. PS. I would also have used a text editor for that task. – IbLeo^(talk) 17:57, 1 May 2010 (UTC)

IbLeo, you're reading my mind again. Stop that! :) Before I posted the last few replies above, you already created a "testcases" page and fixed the sandbox page. Great! I've now updated the sandbox again to move the current version. I also decided to remove the documentation transclusion, but keep the little box at the top, which I presume you customized. I can't see where it comes from, though. So I put the documentation back.

Re. my update, I looked at "show changes" and was confident that copying to/from a text file didn't change anything unintentional. On to other things... There should probably be a note on the Track listing template reminding updaters to copy changes to the sandbox. Also, when we ask for admin-only edit protection, we will have to ask for it on the Track sub-page too. (Oh yeah, that reminds me, should we not have a sandbox/track, and should the sandbox version point to that instead of the "real" track template? Or would it do that anyway, without changes? I was going to look into that, but forgot. I probably won't get to that today.) --A Knight Who Says Ni (talk) 18:04, 1 May 2010 (UTC)

As I said, I don't have time to look at this more today, but I'm thinking that instead of Track listing/Track, it could just be /Track, meaning the Track sub-page of whatever page this code is on. --A Knight Who Says Ni (talk) 18:10, 1 May 2010 (UTC)

Gee, didn't know that I can read peoples minds. That opens up a whole new bash of possible career paths for me :-). I have no previous experience in templates coding, and I am as puzzled as you about that little box at the top. No, I didn't customize it and I don't understand where it comes from either. Regarding your proposal to leave a note on the track listing template, I would say that it is the responsibility of whoever starts playing around in the sandbox to assure that (s)he starts out from the current version of the template. At least, this is how I understand that it works for other templates, and I have never seen such a note anywhere else. Now, regarding the /Track sub-template, I think the best solution would be to get rid of it altogether, as it would resolve the sandbox issue completely. It's raison d'être is to avoid repeating the same code for each of the 99 possible tracks. In other words, it works as a subroutine. I wonder if there is not another way to implement a subroutine without using a sub-template? Or, alternatively, implement a loop from 1 to 99 and move the /Track code into this loop so there still would be only one instance of it? Unfortunately I don't know enough about template coding to do this myself, but I would be surprised if it isn't feasible. – IbLeo^(talk) 07:19, 2 May 2010 (UTC)

Hmm, I'd rather keep using the /Track template, as I think repeatedly copying it into the main template would make it horribly complicated. But I'll be darned if I can get the sandbox template to point to it, unless I explicity say Track listing/sandbox/Track (which I just created). I've tried the following (I'm omitting some brackets here): /Track, PAGENAME/Track, BASEBAPGENAME/Track, TemplatePAGENAME/Track (this is someone's user created fake magic word, it's really a template), SUBPAGENAME/Track, and SUBJECTPAGENAME/Track. Some of these generate a path that includes "testcases", but none will put "sandbox" in the path name. Right now, sandbox/Track exists, but is not being used, which could be confusing to testers. But I don't want to delete it if there is a way to implicitly point to it. I don't know if it's worth asking a template coding expert. I'm not even sure where they hang out. (Unless Wikid77 knows the answer; I think he knows the most about templates out of the three of us!) --A Knight Who Says Ni (talk) 14:42, 2 May 2010 (UTC)

I am afraid you misunderstood me (or rather, I was probably not expressing me clearly). If implemented as a function or within a loop, the current /Track template would only be copied once into the main template. If only I knew how to do it... you are right, let's put our hopes on Wikid77. At least, I have clarified the mystery about the boxes at the top: Template subpages /sandbox and /testcases are recognized and those boxes placed there automatically. See WP:TEMPTEST for the details. – IbLeo^(talk) 14:53, 2 May 2010 (UTC)

Re. function, okay, I understand. Re. the mystery box, that was the the only explanation after you said you didn't write it. It was just surprising to see a coherent help box being generated automatically. There is hope for sentient computers, then. :) --A Knight Who Says Ni (talk) 15:17, 2 May 2010 (UTC)

• The width parameter allows changing the table width (such as "width=300px") as in many similar templates. Some articles have right-side infoboxes or photos which require the track-listing to be narrowed to fit, alongside the left margin of the page. By default, the width=100% will appear unchanged in all other articles using the template. That's why the template had seemed functionally identical to the prior revision. It is possible to redesign the width to auto-narrow when alongside infoboxes, which would perhaps be a better solution. The current width=100% is a "magic number" that demands shifting the track-listing table into an area of the page which has the complete width of the page (no images/infoboxes there). For that reason, tables also have trouble formatting when a single column of a table is set width=100%, as a logical conflict with the width of the whole table being above 100% (although that is possible, such as width=105% to trigger a bottom scrollbar). Often, tables are designed with no explicit width, but rather having spacer columns between text columns, and the table will then automatically change width, auto-narrowing alongside infoboxes or images in each article. Basically, defaulting a table as width=100% will usually cause trouble in short articles with infoboxes. As far as I know, there is no essay fully explaining this issue, so few editors are aware of the tricks to make tables auto-narrow alongside infoboxes (in short articles). I have written about other problems; for example, see essays:

• WP:98 percent table width anomaly
• WP:Advanced table formatting

I will check back here for continued discussion, because there seems to be interest in making this template fit well into thousands of articles, and we can do that: by removing the width=100% and re-thinking the table width. See topic below: "#Proposal to auto-narrow width". -Wikid77 (talk) 21:30, 1 May 2010

Proposal to auto-narrow width

The following example (live) shows how the track-listing table aligns with an infobox & image. When a table is set as width:100%, then that table is forced down a page until it can span the full width of the page (with no infoboxes or images alongside). The track-table is displayed by {{track_listing/sandbox}}:

Column 1	Column 2
Row 1 label:	Row 1 data
Row 2 label:	Row 2 data

The Beatles & singer Lill-Babs.

Side one

No.	Title	Length
1.	"Back in the U.S.S.R."	2:43
2.	"Dear Prudence"	3:56
3.	"Glass Onion"	2:17
4.	"Ob-La-Di, Ob-La-Da"	3:08
5.	"Wild Honey Pie"	0:52
6.	"The Continuing Story of Bungalow Bill"	3:13

To close a large gap above a wikitable, remove the style option "width: 100%;" from the table header in the template, and allow the width to auto-narrow. Large gaps often appear in short articles which mix an infobox with a table, as in the example here.
The next issue is to narrow the table, in general, to prevent an over-wide display, by reducing the 2nd 100% to be 80% as:

• Reduce widths to be:     "0 = width:80%; | 1 = width:60%;"

Those 2 settings should allow the table width to auto-narrow, as specifically needed in each article. -Wikid77 02:53, 2 May 2010 (UTC)

Thanks for explaining your proposal. However, I must say that I fail to see the problem. I have tried on both my computers, with both IE and Firefox, with and without bookmarks, and in all cases the width of the track listing adapts perfectly so it is displayed next to the infobox and the image, without any whitespace being produced. Am I missing something? 82.236.40.207 (talk) 05:52, 2 May 2010 (UTC) Sorry, that was me, from my other browser. – IbLeo^(talk) 05:55, 2 May 2010 (UTC)

For me, there is whitespace. It may be that IbLeo has an extra wide screen or finer pixel setting than me, so the table fits for him. Try shrinking your browser to a non-full-screen window. I'm using IE, but it's an old version of IE. (I'm also looking at it on my other computer, a laptop, with a different old version of IE. I'm seeing the whitespace there too.) As for the 100% thing, the whole tracklist box seems to be a fixed width which is less than the available space. Looking at the example, on my screen's width and pixel settings, I see the tracklist looks like it shouldn't interfere with the infobox, because it doesn't reach all the way to it, and I believe that's the reason it's the width that it is. Of course, this raises the familiar problem that not everyone is viewing Wikipedia under the same conditions. Some may be viewing with their browser in a non-full-screen window. Do those users have the same problems, in the same selection of articles as those with full screens (no more problem articles, and no fewer), and does the proposed solution address all situations equally? Sorry to be wording this so restrictively, but these issues have come up before, where a problem and its solution are only applicable to certain viewing conditions, and neither the problem nor (more importantly) the solution is universal. And the proposed change is therefore rejected.

By the way, did you test this change to verify that it does give the intended results? Is there somewhere we can see the test? --A Knight Who Says Ni (talk) 13:00, 2 May 2010 (UTC)

• I have made many similar changes (removing "width:100%"), but I tested it in this topic by using {User:Wikid77/Template:test} instead of template {track listing} for those Beatles tracks. When I tried the current revision in Firefox, I see that browser did ignore the "width:100%". I usually go to a public library to see what some users, who can't change their computers, will see by default. Logically, it just makes sense to remove "100%" because common sense would conclude "width:100%" means 100% wide. Take the simplest solution, and move on to other articles. -Wikid77 (talk) 13:40, 2 May 2010 (UTC)

You are pointing to your copy of the template, but not to the page that tests it. Anyway, at this point I'm willing to accept there is a use for the change you put in, and it won't have any effect on existing uses of the template. Is it possible (or useful, do you think) if you could explain how to use the field in the template documentation? --A Knight Who Says Ni (talk) 14:28, 2 May 2010 (UTC)

• I have updated {{Track listing/sandbox}} and used it in the example (above), to show the effects of removing "width:100%" and setting "0 = width:80%;". There are so many browsers, to consider testing, that I would do the most-logical change and remove "width:100%" since any other browser would likely think, "100% means force the table as 100% wide". Again, after years of analyzing wikitables, I have found the best tables have almost no width=xx options set anywhere in the tables: let the columns shift depending on how long the titles are. However, we could add a parameter "width=500px" when people want to force large, multiple track-tables into a consistent pattern of width. Have you viewed the track-tables on the "Safari" browser? -Wikid77 (talk) 21:26, 2 May 2010 (UTC)

I'm confused. What is the intention here ? I tried reading the above and i'm totally confused.

• What problem are we fixing ? (answer: wrapping on narrow screens; sight-impaired viewing; tables@infoboxes)
• Who is affected by the problem
• What are we changing (answer: column width settings & new width=580px. -Wikid77 )
• Who is affected by the change ? (answer: over 10,000 articles)

—TheDJ (talk • contribs) 21:49, 2 May 2010 (UTC)

• See below: "#Proposal to redesign table width to fit longer titles". -Wikid77 (talk) 22:11, 2 May 2010 (UTC)

Proposal to redesign table width to fit longer titles

I have redesigned the template in "/sandbox2" to auto-widen for long titles to fit the full page width, if needed. There have been multiple problems with the table width:

• On some browsers, the track-table could not be displayed alongside an infobox or images.
• Even with long titles, the track-table would not auto-widen to fit across the screen, forcing a narrow table that wraps long titles.
• With short titles, the table became too wide (on wide laptops).
• For WP:Accessibility, the table has needed to expand for larger-text-size readers.
• New parameter titlewidth=200px allows setting titles shorter (or longer).
• See example: Led Zeppelin article Mothership (album) where the 3 discs have seemed too crowded when the window is narrowed.

The new revision will auto-widen the track-table when titles are very long, and no longer leave white-space at the end of the table, unless using new parameter marginright=10em. -Wikid77 04:42, 3 May 2010 (UTC)

See subtopics below:

• "#Cause of over-wide tables" - how the problems occurred.
• "#Examples of /sandbox2 to auto-widen" - before-&-after.

The problem seems very complex because multiple issues are being fixed, all at the same time. -Wikid77 (talk) 15:22, 3 May 2010 (UTC)

Cause of over-wide tables

The problems of unusual table widths were caused by multiple issues:

• Use of "margin-right:21em" forced a wide margin on narrow windows.
• The "width:n%" options prevented the wikitable from expanding, only as needed, to fit the available window space.

Those were fixed, as follows:

• The option style="margin-right:21em" was too wide for narrow windows, and caused long titles to wrap in track-tables forced to only half-window wide. The "21em" was replaced with auto-adjusted amounts, depending on the columns displayed, or users can set new parameter "mr=10px" or "marginright=10px" to control the margin at the right-side of the table.

The solution involves making the width settings to be optional parameters, but also defaulting the column widths in pixels (such as 270px, not as percent 60%) to fit the size of the titles given. When a user widens a browser screen, then the table will auto-widen to fit the space, but not wider than needed. -Wikid77 15:22, 3 May 2010 (UTC)

Impact of auto-widened tables

Rather than span the entire page, an auto-widened table tends to be only as wide, as needed, to fit the actual titles, writers, and other entries for a specific album. For years, the display of track-tables had been geared to span across wide laptop screens, where track tables were typically very wide tables, similar to accountant ledger sheets. Now, the spacing between columns will be controlled, if needed, by setting the spacer gapwidth=35px (or similar) when wide tables are needed in an article. For a list of other parameters used to widen a table, see subtopic below: "#Customizing auto-widened tables". -Wikid77 19:25, 3 May 2010 (UTC)

Customizing auto-widened tables

With the table columns defined by pixel widths ("270px" or "95px"), it is possible to precisely set the width of each column, and now spacer-gap columns will be used to spread columns across a page. This capability is needed for WP:Featured articles, where the quality of typesetting can be an important issue.

The new parameters, for width-control, are as follows:

• titlewidth=300px  - the width of the Title column (in pixels)
• gapwidth=25px     - width of spacer gaps between columns (pixels)
• width=580px        - the width of the whole track-table
• mr=30px              - width of margin-right (also: marginright=30px)

When there are multiple track-tables, stacked together as a set, it might be necessary to set each table with titlewidth=350px (or similar) so that short-title tables align with long-title tables. By default, each track-table will auto-widen to fit whatever long titles are listed. So the various techniques for aligning multiple track-tables are:

• titlewidth=350px - set Title column width long enough for all
• <br>                - insert breaks into long titles/writers to force wrapping
• width=580px       - force width of each track-table to same width

In rare cases, such as group song collaborations, it might be necessary to insert multiple "<br>" breaks in a Writer's list, so as to wrap all the names down the screen. There is no "one size fits all" plan for displaying tracks of an album, so that's why customizing of column widths is needed, in rare cases. Consider users with narrow windows, versus wide laptop screens. Sometimes, an extremely long title should be force-wrapped by inserting a "<br>" break. -Wikid77 (talk) 19:26, 3 May 2010

Examples of /sandbox2 to auto-widen

The examples below show the current table-format, versus the proposed /sandbox2 table-format for various album tracks. The difference is most obvious when the browser text-size is increased (as with sight-impaired users) or the browser window is narrowed to 800x600 width, or even narrower for hand-held devices.

---

Current revision:

Disc one

No.	Title	Writer(s)	Length
1.	"Good Times Bad Times" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:48
2.	"Communication Breakdown" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:30
3.	"Dazed and Confused" (from Led Zeppelin, 1969)	Page	6:27
4.	"Babe I'm Gonna Leave You" (from Led Zeppelin, 1969)	Bredon, Page, Plant	6:42

Disc two

No.	Title	Writer(s)	Length
1.	"The Song Remains the Same" (from Houses of the Holy, 1973)	Page, Plant	5:31
2.	"Over the Hills and Far Away" (from Houses of the Holy, 1973)	Page, Plant	4:50

---

Proposed /sandbox2: Template:Track listing/sandbox2 Template:Track listing/sandbox2 For wide-screen windows, the examples for the current version & /sandbox2 will appear similar in table width. When set properly, the title-column will have the same width for each disc in a set. Again, the track-tables should still be readable with large browser text-size settings, per the WP:Accessibility policy. -Wikid77 (talk) 13:06, 3 May 2010 (UTC)

There were some errors in the sandbox, so i fixed them. I suggest screenshots + Browsers, otherwise we will never get grip on this. So for me (Safari 4), tables always float next to infoboxes and images. The above renders for me like this: wide narrow. —TheDJ (talk • contribs) 13:29, 3 May 2010 (UTC)

Firefox 3.6.4 comparison wide narrow

Opera 10.10 comparison wide narrow —TheDJ (talk • contribs) 13:38, 3 May 2010 (UTC)

I added sandbox2 to the testcases. Not the issue with collapsible versions. —TheDJ (talk • contribs) 13:51, 3 May 2010 (UTC)

Good move, TheDJ (although I don't really understand why we need two sandboxes, I think one would be enough). Anyway, I see two issues with current /sandbox2 version: (1) In section 1.3 there is a huge whitespace btw. Side one and Side two. (2) In section 1.3 (and also in 1.2), [show]/[hide] moves horisontally on each click to show/hide the content, which find pretty confusing. I am using Firefox 3.6.3. with a large screen. – IbLeo^(talk) 16:10, 3 May 2010 (UTC)

I think the wide space is necessary though, it allows us to see whats the title and which is the artist, in the current article I'm working the tracklist is so cramped you can barely read it. I was actually thinking that the note would be under the title if possible.Bread Ninja (talk) 18:20, 3 May 2010 (UTC)

We can set some right paddings on table columns i guess. Something like 30px right of the title will probably do. —TheDJ (talk • contribs) 22:14, 3 May 2010 (UTC)

• Currently, gapwidth=12px is the default spacing, after the Title (or before the Writer, Lyrics, Music or extra-column). Each track-table can increase that gapwidth, if there is a crowding problem. The 800x600 width is noted by WP:Accessibility, but the template is not the wiki-police, so I allowed it to force a table to width=700px (or more), if the writers of an article feel a track-table should be that wide. -Wikid77 (talk) 03:43, 4 May 2010 (UTC)

• Blank-line bug in /sandbox2: The whitespace gap above testcase-1 "Side Two" was caused by /sandbox2 skipping a blank line for each 2 tracks omitted, starting on Track 9 (skipping 8 tracks, or 4 blank lines). I put HTML comments between rows to suppress those wiki-spastic newlines (it always takes me too long to find where MediaWiki newlines are being inserted). Hence: Kids don't do this: Don't ever invent a spastic markup language which spawns newlines; don't drop out of college but stay and learn about "context free grammar" & "string grammar" and help stamp out newline madness. -Wikid77 (talk) 20:43, 3 May 2010 (UTC)

I assure you that I didn't drop out of college, and I still don't understand what you are saying. However, putting "HTML comments between rows to suppress those wiki-spastic newlines" sounds more like a quick-and-dirty fix to me like a clean solution. Do you plan to leave it like that? – IbLeo^(talk) 05:01, 4 May 2010 (UTC)

• I see no problem with those HTML comments between rows, as a safety net. Perhaps some people think of a spare tire as a "quick-and-dirty fix" for having a flat far down the road, but I see spare tires as just one, of multiple options, to keep a car in operation. For decades, people have suggested "defensive programming" of software, adding multiple levels of safety nets, rather than try to solve a problem in just "2 lines of code" which would fail on related problems or mistakes in the future. The most important issue is to keep moving to provide better formatting of track-tables, such as customizing the layout in WP:Featured articles, or allowing larger text-size for sight-impaired readers using narrow screens. -Wikid77 (talk) 09:25, 4 May 2010 (UTC)

I was honestly unsure of where to place this, as the "auto-widen/width" topic has been split off into several sub-topics, but since I'm giving an example with my concern, I figured I would place it here. I think the width issue needs to be rethought, as while I can see the need for it to be adjusted for those with smaller screens, the changes are having an undesired effect on larger screens (if you ask me.) Take a look at this "real world" example of a busier table than the example shown:

Original Template: K.O.D.

No.	Title	Writer(s)	Producer(s)	Length
1.	"Show Me a God"	A. Yates	Matic Lee	3:41
2.	"The Warning (Skit)"	S. Watson	Seven	0:31
3.	"Demons" (featuring Three 6 Mafia)	A. Yates, J. Houston, P. Beauregard	Matic Lee & Seven	5:23
4.	"Blackened The Sun"	A. Yates	Ruben Armstrong	4:26
5.	"Strange Music Box" (featuring Brotha Lynch Hung & Krizz Kaliko)	A. Yates, K. Mann, S. Watson	YoungFyre & Karbon (add. prod.)	4:11
6.	"Sundae (Skit)"		Robert Rebeck	0:25
7.	"Check Yo Temperature" (featuring Sundae & T-Nutty)	A. Yates, S. Austin, T. Jones Jr.	YoungFyre & Demolish Beatz (add. prod.)	4:32
8.	"B. Boy" (featuring Big Scoob, Bumpy Knuckles, Kutt Calhoun & Skatterman)	A. Yates, M. Calhoun Jr., S. Ashby Jr., S. Landis	YoungFyre & Karbon (add. prod.)	5:29
9.	"Hunterish" (featuring Irv Da Phenom & Krizz Kaliko)	A. Yates, M. Irving Jr., S. Watson	YoungFyre	3:47
10.	"The Pick Up (Skit)"	A. Yates	Robert Rebeck	1:15
11.	"In The Trunk"	A. Yates	Ruben Armstrong	4:25
12.	"Pinocchiho"	A. Yates	Matic Lee	2:10
13.	"Horns" (featuring King Gordy & Prozak)	A. Yates, S. Shippy, W. Alford II	Robert Rebeck	3:59
14.	"Interview With Jason Whitlock (Skit)"		Robert Rebeck & Seven	2:21
15.	"It Was An Accident" (featuring Alan Wayne)	A. Yates, Wayne	Seven	3:44
16.	"Shadows On The Road"	A. Yates, S. Watson	Seven	3:28
17.	"Low"	A. Yates, S. Watson	Ruben Armstrong	3:33
18.	"Messages (Skit)"		Robert Rebeck	1:38
19.	"Killing You"	A. Yates, S. Watson	Matic Lee & Seven	3:36
20.	"Leave Me Alone"	A. Yates, S. Watson	YoungFyre & Karbon (add. prod.)	3:52
21.	"Prayer - By Brother K.T. (Skit)"	K. Taylor	Robert Rebeck	0:42
22.	"K.O.D." (featuring Mackenzie O'Guin)	A. Yates, B. Fraser, S. Watson	Seven	5:14
23.	"The Martini" (featuring Krizz Kaliko)	A. Yates, S. Watson	YoungFyre	5:27
Total length:				77:49

The proposed version is unnecessarily scrunching the table and causing wraps that aren't needed on larger screens. As stated, I can understand needed to adjust the template so it plays nicer with smaller screens, but I don't think that should come as a penalty to larger ones. You have implemented the width option to override the default width, but by default I think it should better adapt to the screen size.

This example also brings up a tiny issue that I think should perhaps been looked into. In the example of the revised version, I have a total_length set, as well as addtotal (which, perhaps should be "add_length" or "add_total_length"?) and it results in both being shown. Now obviously this isn't the "correct" usage, but I think the template should have some kind of check for this type of redundancy. I believe only one value should be shown (if possible). In that case, I think manual should override auto. – Mizery Made ^{(talk · contribs)} 19:07, 7 May 2010 (UTC)

I have the same "scrunching" issue as you when I use my default browser, Firefox. However, it's interesting to note that with IE 8 the new version displays nicely, actually better than the original template as it detects that there is no pictures or infoboxes in the right margin and takes that space into use. It would be perfect if the new version could be enhanced to do the same thing in all browsers. – IbLeo^(talk) 06:40, 9 May 2010 (UTC)

I had not checked the page with anything other than Firefox, however when I brought up IE8, it was appearing just as it does in Firefox. It was only after I turned on compatibility mode in IE8 that I saw your findings (the new template stretching). Definitely still in need of some work. Looking over the mark-up for the template (and this may just be not understanding what Wikid is trying to do) I notice what appears to be a redundancy. "<!-- -->{{#if:{{{width|}}}|width:{{{width|585px}}}; }}<!-- -->," what appears to be the "default value" (585px) is never being used. A check runs to see if the Width option is set, if it is then it uses whatever value you have set. If it's not set, then it comepletely omits the Width argument. Looks like it needs to be just "<!-- --> width:{{{width|585px}}};<!-- -->" as then, it either uses the "Width" option value, or if it's null, defaults to 585px. However, using "static values" like that is I believe the cause of the "scrunched tables." Setting the width and the ilk in px restrticts it to that many pixels (so it's even if you have 1280 pixels to work with horizontally, it's still only 585px). For an "auto-widening/shrinking" table, shouldn't percentages be used to set widths and such? – Mizery Made ^{(talk · contribs)} 07:00, 9 May 2010 (UTC)

Interesting... I actually haven't changed any settings in my IE8, it installed itself with that configuration. What you say about percentages sounds reasonable to my ears, although I can easily imagine that the calculation to find the best display for each column could be a tricky affair. Why don't you give your ideas a chance in the sandbox? You can always self-revert if it doesn't work... – IbLeo^(talk) 07:19, 9 May 2010 (UTC)

I actually set up my own sandbox to mess with the other night (see: Template/Test Page), as I don't want to step on Wikid's toes, or pollute the other with my experimenting. I'm no HTML/CSS expert however, so I've mainly just been tinkering. The main problem remains the infoboxes and other floating objects. The tracklist and these objects can bleed together (which can also happen with the other two templates, if you make the window small enough). That's the original reason for setting the 21em margin on the right side, to avoid colliding with the Infoboxes on stub articles. – Mizery Made ^{(talk · contribs)} 07:30, 9 May 2010 (UTC)

Migration plan for auto-widened tables

04-May-2010: In general, the use of auto-widened track-tables should require editing of only a few album articles, to migrate into the new format, such as using customized width parameters. As could be expected, during prior years, many articles have already placed images, or infoboxes, alongside the track tables, to limit their extreme width on wide, laptop screens. In many cases, those track-tables (viewed on laptops) will appear only slightly narrower, in width, when auto-widened to fit long titles. The greatest gains, in table readability, will come in tables with just Title+Length, or to users of narrow-window screens, such as on desktop monitors, or narrow half-screen windows. Because most music tracks have titles with fewer than 10 words, the vast majority of auto-widened tables should appear "normal" even if narrower than before. The greatest surprises will come in tables with one extremely long title, or 4 people writing a single song, and those tables should be customized, such as splitting the long title (with "<br>") to avoid an excessively-wide table, due to one long song title or 4-6 songwriters (etc.). In migrating to auto-widened tables, the new customized width parameters (titlewidth=350px, gapwidth=25px, width=585px, or mr=10px) will allow refining the appearance of track-tables in WP:Featured articles, for the first time in years. In general, spot-check several, perhaps 29, of the "somewhat popular albums of all time" to ensure that the most surprising table layouts have been adjusted. Far more albums in articles, now, will gain clearer track-tables, rather than become awkward, or unbalanced, lists of recordings. No longer will 2 columns of a track-table have words which run-together, such as the last word of a title join to a Writer, as word+name ("Bridge over TroubledPaul Simon"). On balance, most track-tables should appear clearer than before. -Wikid77 (talk) 03:17, 4 May 2010 (UTC)

Before talking about migration, I think we need to first establish a wider consensus that the proposed /sandbox2 version is the way to go. I will leave a comment over at WT:ALBUM to allow people to jump in. Secondly, you keep changing /sandbox2 so it is unclear to me if you believe that the current version is stable enough for us to look at. In my eyes there are still issues with the test cases, but I don't want to waste my time bringing them up now if you are going to change the code in the next 10 minutes. – IbLeo^(talk) 05:09, 4 May 2010 (UTC)

• All these issues need to be considered, all together, so that everyone can be prepared to move forward, with the re-formatting, or customization, of track-tables. We should avoid getting trapped in a "paralysis of analysis" - the track-tables have been awkward for over 3 years, so we need to keep moving to make progress. I don't mind making more improvements once-a-week, if that is needed to provide better functionality for more users. The issue of the shifting "show/hide" buttons, noted above, is another concern: the "[show]" button remains at the end of a table when parameter width=510px (etc.) is specified, but we also need to allow the table width to be variable, when the "[show]" button will slide to the left. I regret that so many issues are being juggled here, but it has been 3 years waiting to allow customized track-tables. -Wikid77 (talk) 09:25, 4 May 2010 (UTC)

• Weak support, because I only vaguely understand pixel padding. I do think that an important part of this work, is documenting it for the template instructions, in a way that non-technical people can understand. Support would probably improve if the documentation were prepared now instead of later or as an afterthought. --A Knight Who Says Ni (talk) 12:42, 4 May 2010 (UTC)
• Weak support. By playing around with the window size on the test cases I can appreciate the benefits that the /sandbox2 proposal brings to narrow screen displays. Furthermore, the issue of the shifting "show/hide" buttons is not a showstopper for me; I think this is something we can get used to. However, I think the proposal has a serious issue when displayed on standard laptop or desktop full screens. It looks like the table narrows itself more than necessary, leading to some of the cells being displayed over multiple lines when it's not really necessary. The worst example is in section 4.3 where the Writer(s) column is so narrow that track 9 ("Paul Rodgers, Paul Kossoff, Andy Fraser, Simon Kirke") is displayed over 4 lines(!), while there is a huge amount of whitespace to the right of the table. That's totally unnecessary and I believe the table should be able to auto-adapt better without us having to parametrize it manually. The same phenomena is also seen in section 2.3 where the title (incl. the note) often displays on 2 rows while, again, there is lots of whitespace to the right of the table. Finally, I agree wholeheartedly with Knight on his demand regarding the documentation. – IbLeo^(talk) 21:06, 4 May 2010 (UTC)

• See below: "#New parameter endnotes & endnotes_color". Only some browsers will auto-widen the columns to fit longer text, so the handling of extra-wide text could be helped by putting a bottom end-note as "4 authors^[a]" and defining [a] for the long text, with new parameter "endnote=[a] - The 4 authors are...". -Wikid77 17:49, 5 May 2010 (UTC)

It looks like you are right about browser support. The problems that I signaled above are observed with Firefox 3.6.3, while when I switch to IE 8.0 no line wrapping takes place; instead the tables auto-widen and they look great—even the cell with 4 authors nicely displays on one line, contrarily to the current version where it wraps into two lines. I would much prefer to find a solution that works as good in most browsers, rather than your end-note proposal. I am not a fan, it's only over-complicating the template usage and I don't like the idea of displaying those end-notes inside the table itself. If needed, we might as well use classic footnotes for this purpose. – IbLeo^(talk) 20:11, 5 May 2010 (UTC)

• It would be great if we had to templates, because those related to game OST, one would slightly be larger than the other. we seen multi templates for stuff like this, why not for tracklist? i was thinking it would have two extra sections, extra and extrab i honestly don't see what the problem is for having a bit of extra space thoughBread Ninja (talk) 18:36, 5 May 2010 (UTC)

I agree that having 2 track-list templates is a better solution, allowing some new features, without scaring users over the existing track-tables in 15,000 album articles. See below: "#Proposal for limited use of 2nd Template:Tracklist_custom". -Wikid77 00:47, 6 May 2010 (UTC)

New parameter endnotes & endnotes_color

The new parameter "endnotes=XXX" (in /sandbox2) would put text at the bottom of a track-table, with the default endnotes_color=#F3F3F3 (light gray). Many readers have wide laptop screens, so extra thought is needed to design tables to also fit in narrow square windows (such as 800x600). For testing as square windows, the table width can be restricted as width=585px, then observe the spacing of table columns. Only some browsers auto-widen the columns to fit longer text, so the handling of extra-wide text could be helped by putting a bottom end-note to explain the entry "4 authors^[a]" and defining note [a] with new parameter "endnote=[a] - The 4 authors are...". For multiple notes [a], [b], [c] (etc.), the endnote text could contain "<br>" breaks or use the colon-indent for each note line after "| endnotes=". Template:Track listing/sandbox2 The endnotes (above), in markup language, spans 3 lines, as follows:

| endnotes_color = #F0F0F0 | endnotes=Notes:<br>
&nbsp; [a] - This song was recorded in 1 take, selected as best version.<br>
&nbsp; [b] - The 5 writers are Paul McCartney, John Lennon, C, D & E.
| length1= 4:13

The endnotes=xxx is basically free-form text, to allow any style of table footnotes. The use of note letters "[a]" & "[b]" is customary, to distinguish from an article's numbered footnotes [1], [2], [3] (etc.). Those letters can have the "sup" superscript tag ("^[b]"). Now, with an article intended for young readers, the first note could be clarified to emphasize its location inside the table: "(see table note: [a])" being more obvious to young readers. As always, any use of reftag footnotes will list those notes at the bottom of the page in the Notes/References sections. By using endnotes=xxx, there will no longer be a need to force any column to contain an extremely long entry. -Wikid77 (talk) 17:49, 5 May 2010 (UTC)

I don't like this proposal at all. I find it ridiculous to have some information directly contained within the table (ie, "John Doe" for Track 2), and then have other information of the same nature broken off into another section (below the table, ie "The 5 writers are..."). I find that it defeats the purpose of condensing it all into a table, and if this is the route taken, might as well stick with the other method of just listing track titles and times in the Track listing and the having a "Credits" section. It may be useful to have a notes/ref section in the template that would allow notes/references to be placed on the title without it being within the quotes, similar to that of the Episode list template. Besides, if you were to use such a method to move "longer text" from the table, you then have to determine what should be moved and what shouldn't. Three names or more? An instance of two writers could be longer in text than one with three however. 20 characters? Strange that one that's only 19 characters is fine, but one more and the string must be moved, etc. – Mizery Made (talk · contribs) 18:12, 5 May 2010 (UTC)

• Endnotes for more than just Writers: The endnotes text is also used for other entries, beyond just the writers, and could be used to explain, as an endnote, that a particular track's length is the midpoint between 2 songs that run together, sounding as if both songs were only one track. Similar table endnotes are used in numerous Wikipedia articles, such as explaining the source of city population statistics. An endnote could be used to indicate the primary writers, versus perhaps 3-5 other collaborators who had only minor contributions to the lyrics. I realize that readers with wide laptop screens are not often aware of the readability problems for users with square windows, or who read the track listing on an iPhone or small handheld device. The layout of a track table needs to reflect consensus of the various readers affected. -Wikid77 00:20, 6 May 2010 (UTC)

As I stated before, I can see some use for an endnote system when it comes to notes (such as your length example), but I still don't like the idea of it being used to fork information off into a separate section. Be it moving all writers (when there are several) or just "minor ones" (and this view applies to other fields too, beyond writer.) Besides, if used to separate main and minor contributors, who's call or what criteria would be used to determine who is considered a "minor contributor"?

To be honest, looking over the example provided, I can't see a real benefit in the current implementation. You're pretty much writing the foot/notes section yourself, which in my opinion, kind of makes it being included in the template pointless. Perhapps it would be better if there were something like "|title1_note=" or "length1_note=" where you would input text (such as, "This track appears at the end of the previous track" and then the template automatically built the notes section and placed markers appropriately (linking back and forth). Otherwise... I don't really see why it couldn't just be manually done through the note and ref templates, or some other method. That is, unless your example is just an early mock-up? – Mizery Made (talk · contribs) 00:50, 6 May 2010 (UTC)

New parameter addtotal=yes

The new parameter "addtotal=yes" (in /sandbox2) will add the track lengths (minutes/seconds in dot colon format mm:ss) and show the total of those numbers (length1 + length2 + length3...) at the bottom of the Length column. The total would be in the same location as with parameter "total_length=mm:ss". However, the sum of minutes/seconds for addtotal=yes would be calculated, live, by adding each of the parameters (length1=mm:ss) in the track-table. -Wikid77 (talk) 19:56, 6 May 2010 (UTC)

Initially, I like the idea of the time being automatically calculated. It's something I've actually wondered about over the last couple of years. However, now that you've brought the topic up and I've stopped to actually think about it, I'm not so sure I like the idea anymore. Afterall, once a track listing is set up, what are the odds that it will change? Only case I can think of would be if an issue is released with a bonus track down the road and it's added to the track listing with a Bonus Track status being noted in the notes section. However (and this is a general issue), in that case, the total time would inaccurately reflect the total time of the "main issue." That said, the calculation of the time would essentially be a one-time task and may be something better served to leave as a manual task, instead of it needing to be automatically calculated each time the page loads. Afterall, the total time would need to be added to the infobox anyway.

It also wouldn't be too useful when it comes to handling the bonus track issues, as these are at times broken off into a second template with a headline noting the issue (ie, "Best Buy exclusive Bonus Tracks"). If the bonus tracks are at the end of the disc, then the total time for this one should reflect the total time of the entire set (main CD, plus these bonus tracks) and would need to be manualy input anyway. One other important note, using "mm.ss" as the format fails MOS#Times, does it not? It specifies that "colons separate hours, minutes, and seconds." – Mizery Made (talk · contribs) 20:20, 6 May 2010 (UTC)

I have merely changed the time format to use minutes/seconds as format "mm:ss" per WP:MOS. I have noticed that many articles could show the track totals for each disc in an album, so the live calculation of total track lengths would be of benefit in numerous articles. Of course, editors could still total all the various track lengths, by hand, whenever they have a lot of extra time for making all those manual updates. Just because a feature is 100x times faster doesn't mean people will be forced to use it. Setting addtotal=Total is just an optional feature. -Wikid77 10:36, 7 May 2010 (UTC)

I appreciate you addressing the issue regarding the failure of WP:MOS. However, I've found two more concerns of greater importance. This function appears to be the cause of a fatal issue. I was looking over the track listing of Mixtape Messiah 7 and decided to fix a couple things. While in there, I figured I would do the length totals since they were missing. Do it part to feeling a little lazy at the time, and partially in an effort to test this future in a "real world" setting, I directed the four discs to your revision. All was well, however, when the "| addtotal =" param is set for all four discs (or three for that matter in my testing), attempts to preview the page always results in an error page with "Error: ERR_READ_TIMEOUT, errno [No Error] at [...]." Removing this option from the templates allows the page to preview fine (and using it on only two discs works okay, but seems to slow the loading considerably). Perhaps someone else can test this to better confirm that the erroring out is as a result of this function on a large number of tracks/discs?

It might be that this error is as a result of my other concern. Looking at the template you've set up to calculate the times, it specifies that it only accepts 50 parameters. None of the discs have more than 50 tracks, and I would think each disc would be it's own routine, so I doubt it's actually the cause. However, it does raise an issue in the fact that the Track listing template supports up to 99 tracks (which I believe is the number of tracks supported by CDs), but the routine to automatically calculate the times can only handle half that. Is this a limitation in the functions you're using for the helper template? If not, then it should be adjusted to work with all 99 possible tracks. If it is a limitation... well, not really sure, might be reason to abandon the idea? Don't know. Either way, thoughts or comments (or confirmation or lack thereof regarding the first) about these two concerns are welcomed. – Mizery Made ^{(talk · contribs)} 05:01, 8 May 2010 (UTC)

• I have modified the option addtotal=Total to calculate the total length much faster, so the fatal error should be gone now. There is enormous overhead in preparing to total (or list) 99 tracks, so that is why I set the limit to 50, as obviously being, at least, twice as fast. If there are track-tables which use more than 50 tracks, I would suggest replacing them with an embedded table, and not use a template for those rare cases. As you have found out, there are, indeed fatal template limits, and "Don't worry about performance" is no longer good advice. Instead, everyone should be prepared to learn what runs "100 times slower" and be prepared to work around those limits. -Wikid77 (talk) 14:32, 13 May 2010 (UTC)

Proposal for limited use of 2nd Template:Tracklist_custom

06-May-2010: I agree that having 2 track-list templates is a better solution: in a volunteer project, it is too difficult to expect everyone to take time to consider, and refine, all the new options "forced" onto everyone, as a single track-list template. A new Template:Tracklist_custom, as a vanguard template providing new features, will lessen the impact to all those 15,000(?) album articles, and allow long-term live testing of features, so more people will have ample time to evaluate the impact of new features. Some new features, after being evaluated in {Tracklist_custom}, long-term, could then be added into {Track listing}, after many people have taken the time to consider the new functionality. Again, volunteers do not have time to evaluate the potential of widespread changes to over 15,000 articles, in a few weeks. The 2nd template would simplify the exploration of new features, without scaring the current users about impacts to the other 15,000 articles. We would annotate the documentation subpages to note the use of those 2 templates (one for most articles, the other for custom tables, with similarity between the two), allowing a broader range of features to support the entire user base of Wikipedia. -Wikid77 (talk) 00:47, 6 May 2010 (UTC)

I would oppose a second template for several reasons. First, you will have the situation where improvements and formatting changes get made to one, but not the other, causing them to become less similar through time, or causing one of them to become less useful because it is not being kept up to date. Second, you say a reason for doing this is to not force new options on everyone. If they are just options, and editors don't use them, will the new template then look just like the old one? There seems to be no point to having one template with features not available in the other, on purpose! A third problem is that the proposed changes are not just to the formatting, but to actual listings standards, i.e. to not show composer credits in the same line as the song title. Too many things are changing at once, including things that are outside the scope of a template change. A fourth problem is that, even if you don't mean it to be this way, it looks like you are creating a second template because you want it to have features that you don't think would be accepted in the main one. A really big problem is that it invites others to do the same, and soon we might have a great many custom templates, all out of sync with each other in terms of implementing future features, and some deviating in listings standards. And if the reason you want to put a long list of writers in a footnote, is because putting them in a regular table cell won't work well after proposed changes are made to the template, then the proposed changes are wrong, and should not be implemented. Sorry to be so negative, but I think it's fairly established that forked custom templates are to be discouraged, and get deleted where discovered. --A Knight Who Says Ni (talk) 12:27, 6 May 2010 (UTC)

• There are many other templates which have variations, but I understand that some people worry about the diversity, and spend enormous amounts of time trying to delete such variations of templates. Again, it has been about 3 years that Template:Track_listing has appeared as an over-narrow template on square windows (such as 800x600 pixels). As of 2010, those users with narrow windows can no longer be ignored, per WP:Accessibility. The major conflict is between the main standard template, which is used in "countless" articles (perhaps 15,000?), and attempts to add enhancements, without subjecting all articles to somewhat unproven options, which could have unforseen consequences, not to mention alarming the numerous users unaware that major changes were being made. As far as other variations, simply recommend that users consider making changes to one of the 2 existing templates, rather than create a third or fourth variation template. Please consider the frustrations of people who do not have time now, during the current 2 weeks, to ensure that proposed changes would be compatible with their plans for article track-tables. The use of a single track-table template has stifled improvements for years, but we don't need to try to force everyone to accept improvements now, while allowing improvements to be used in some articles. Once a standard template has been modified, there is the danger of unforseen consequences, so using a 2nd, customized, template avoids many, many problems, while planning to update the main template. -Wikid77 (talk) 16:40, 6 May 2010 (UTC)

I think you're doing great work on addressing problems with the template, and you have more technical expertise than I do. So I hate to be argumentative. You say we should discourage other editors from creating a 3rd and 4th version, and tell them to incorporate future changes into the existing two. I'm doing just that, except trying to keep it down to one. I don't believe that having one template for 3 years has "stifled" progress; rather, it's the Wikipedia community's insistence on not allowing insufficiently tested and unapproved templates to go live, or to become widely used, which could become a problem. If a variant is used on just a few articles, it's a problem, because it sounds like your version isn't intended to be permanent, so sometime later we will need to identify and convert articles that use it.

Regarding insufficient testing and non-approval of a change to Track Listing, the solution is to keep testing it, and get it approved. I don't foresee any great resistance to the change, and what is there, is not resistance just for the sake of resistance. We just want to make sure the solution works universally, and is not a half-measure, or something that looks good on some people's browsers, but not others'. I also asked for documentation, and this is something we can all help with, although I would like to ask you to set up the first draft, because you clearly understand your change better than the rest of us, and I think you're the only one who could do it! --A Knight Who Says Ni (talk) 19:59, 6 May 2010 (UTC)

The changes are quite extensive, so it will take some weeks to fully document. Redesigning a widely-used template is not a task suited to incremental changes and debates about each feature. -Wikid77 Wikid77 (talk) 15:29, 7 May 2010 (UTC)

Not really, you don't have to document on a technical level, but on a user level, explaining to users how each parameter is to be used, in a non-technical way. In any event, you have to document the changes, whether they would be in an alternate template or not. An undocumented template would not be accepted. The same goes for "debates about each feature"; they are being discussed here anyway, and cannot go live until agreed upon, regardless of whether they are in the current template or a new one. Furthermore, these aren't really "debates" about whether or not to use the features; discussions seem to be focussed on getting the bugs out. We don't want a template with bugs to be used in live articles, and having those bugs only in an alternate version of the template doesn't resolve anything. New templates are not an end-run around missing documentation, debugging, and approval. There is rarely a valid reason to create new versions of existing templates. --A Knight Who Says Ni (talk) 20:34, 7 May 2010 (UTC)

• I strongly oppose a forked template, per all the good reasons already stated by Knight. Furthermore, Wikid77, I feel that adding all those options left, right and center is working against you. Although some of them, are really good ideas (like the automatic addition of track lengths), they are logically independent from the raison d'être of this discussion—i.e. the attempt to improve the auto-widening capabilities of the template—and should go into separate threads. So I suggest at this point to concentrate on the auto-widening and leave the other improvements aside for later. If you can get the new version to work well for the vast majority of readers that use a standard laptop or desktop screen (see Mizery Made's concern above) I am with you. – IbLeo^(talk) 06:29, 9 May 2010 (UTC)

Fine, see below: "#Proposal to adjust tables by width parameter". I will try to just "patch" the current convoluted template, as a quick-and-dirty twist to force some amount of normal functionality. -Wikid77 20:37, 9 May 2010 (UTC)

Automatic Track Listing Converter

Hey everyone. I realize always having to manually enter in all of the track information is a drag, even with templates, so I created a program to do most of the heavy lifting. Essentially you paste in the old track information, select the options, and click convert. The output will be directed to Notepad.

Note that since this requires Notepad, it will only run on Windows systems. I've only tested it on Windows XP specifically.

It comes with no warranty, but it does come with the source code ;) It was written in AutoIT.

It also only pipes out the Track title and Length automatically; any notes must be entered manually, although the blank form is generated.

For instance, at the intial screen, copy and paste this:

# "Razor" - 6:48 ([[Dave Grohl]])

# "Over and Out" - 5:56 (Grohl, [[Taylor Hawkins]], [[Nate Mendel]], [[Chris Shiflett]])

and, depending on the options, this is the output.

{{Track listing

| title1 = Razor

| length1 = 6:48

| title2 = Over and Out

| length2 = 5:56

}}

Again, everything should be checked for accuracy; this just does most of the gruntwork. However, it should allow for much easier horizontal rather than vertical comparisons.

Please try it out and get back to me.

It can be found here...

http://sourceforge.net/projects/tlconverter/files/

Cheers, Foofighter1337

P.S., I'm new to editing Wikipedia, so I'm terribly sorry if I violated any rules. —Preceding unsigned comment added by Foofighter1337 (talk • contribs) 08:52, 5 May 2010 (UTC)

Hi, and welcome amongst us. I left a welcome message on your talk page with some links that you can use to get better acknowledged with how it works around here. Regarding your tool, I just want to point out that according to WP:ALBUM, that provides the guidelines for album articles, there is no recommendation to migrate existing list-style track listings to {{Track listing}}. In fact, one is as good as the other, and you shouldn't do such migrations just because you might think that they look better. Happy editing! – IbLeo^(talk) 19:52, 5 May 2010 (UTC)

But it's ok if we do fix them right? I think it looks substantially cleaner, and it also looks much more consistent. I've actually made some modifications to the program, and will likely make a few more. Given the right options checked, it takes about 30 seconds start to finish to convert them, whereas it used to take me personally about 3-5 minutes, even with a template. It just seems like a useful tool for those who would like to convert from the old format, even for aesthetic reasons.Foofighter1337 (talk) 23:01, 5 May 2010 (UTC)

You're saying it "fixes" the listings, but there is nothing broken or outdated about track lists in non-table format. It is the simplest, basic format. Your feeling that the tracklist is "cleaner" is not agreed upon by others, and I don't know how you can say it's more "consistent" - consistent to what? There are standards that establish how a non-table tracklist is to look. And while it's true that editors are capable of deviating from the standards, they are just as capable of doing that while using the template. I'm also not sure what you mean by "aesthetic" reasons. We acknowledge there are complex cases where tables can organize lists better than the non-table format, and maybe that's what you mean. But if you feel all tracklists should be tables, and would look better if converted, I disagree. And in past discussions, where it has been proposed that this template be the standard for album articles, many others have stated an "aesthetic" preference for the non-table tracklist, and also stated that there should be a specific reason for converting; it should not be done arbitrarily.

Not that all this has anything to do with your conversion program, which is perfectly fine when used for a conversion that someone had intended to do anyway. I think it's getting off topic to imply that all track lists should be converted. And I'm not sure you even meant to imply that! But if you did, you will find that attempts to convert track lists for no reason are likely to be opposed. There is no evidence that there is a gradual trend toward using it to the point where it becomes the standard. --A Knight Who Says Ni (talk) 12:39, 6 May 2010 (UTC)

What I meant by "cleaner" is that rather than having the track lengths, data, etc, in a giant string/jumble of letters, they are all put in a nice neat column. And what I meant by "consistent" is that it seems tacky to look at one album by an artist with track listing in non-table format, clicking to the next album in their discography and having that album in a table format, the next in non, etc. Currently clicking through most bands discographies (i.e. The White Stripes or Foo Fighters), the track listings are all over the place. And if you change a table to a non, some user gets angry, and if you change a non to a table, some user gets angry.

I would like to click through my favorite bands discographies and see some sort of clean, consistent approach. I'd even convert the "unnecessary" tables back to a normal format if that's what the majority wants. I just figured since the template approach looks good to me, and is relatively common, I'd make a tool to help implement that. But the current system seems like a lot of users bickering and undoing each others changes, and the result is a jumbled mess. I guess both tables and the non-list approaches are supposed to have their place, but the rules of application as lined out at WP:ALBUM just seems very unclear. foofighter1337 22:53, 6 May 2010 (UTC)

There have been many discussions about the pros and cons of this template at WT:ALBUMS, some of the most recent are here and here (but you'll find plenty more in the archives). The current consensus is basically that while the template is useful for more complicated track listings, a simple approach is preferable for simple track listings (ie track number, track name, track length) and that this complies with WP:TABLE and WP:LIST. However, it is accepted that if the template is used from scratch on an article, it shouldn't be converted to plain text and likewise simple track listings shouldn't be converted to use the template. --JD554 (talk) 07:37, 7 May 2010 (UTC)

Thank you for your swift response JD554. I read through a lot of the Talks, but I'm still confused as to why there's an aversion to any changes, especially because a new user like myself may create an article and be oblivious to whether they should use the non-table or the table formatting, because even after reading all of these talks and the notes at WP:ALBUM, which are designed to help a new user, it still seems very unclear. Why should the article be locked in to one style or the other based on a noob's "mistake"?

For instance, the difference in these two articles, The White Stripes (album) and Elephant (album). Both of these albums have roughly the same amount of information, and the same "complexity". But the first is in the table format, and the latter is in the non-table. And yet when an attempt is made to change one or the other, someone (like yourself) will undo them. Why is that? Is it really because the first person to author an article gets some sort of artistic control of its presentation? That hardly seems fair to the rest of the world and the users that have to look at it.

I realize this topic is probably turning into something that should be in a separate thread, as it originally just started out with me attempting to help by creating an (apparently unneeded but wanted by some) conversion program. But go ahead and comment on this post anyways. foofighter1337 18:44, 7 May 2010 (UTC)

That's the consensus, you're more than welcome to try to change it. But the correct place to do so would be at WT:ALBUMS. --JD554 (talk) 05:40, 8 May 2010 (UTC)

Proposal to adjust tables by width parameter

09-May-2010: A simple solution for the width of most track-tables, displaying as either too wide or too narrow, could be to set a new parameter width=nnnpx for table size. In rare cases, where the default width would cause crowding, then those articles could be adjusted by setting width to a percentage, such as width=96%. The prior proposal, to redesign {Track_listing} to auto-widen a track-table for long titles (as an ultimate comprehensive solution), had raised much discussion and debate, so the current proposal now, is just to vary the table width, and allow some articles to specifically set width=96% (or similar). The following examples show the results.
Current revision:

Disc with no writers

No.	Title	Length
1.	"Good Times Bad Times"	2:48
2.	"Communication Breakdown"	2:30

Disc one

No.	Title	Writer(s)	Length
1.	"Good Times Bad Times" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:48
2.	"Communication Breakdown" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:30
3.	"Dazed and Confused" (from Led Zeppelin, 1969)	Page	6:27

Disc two

No.	Title	Writer(s)	Length
1.	"The Song Remains the Same" (from Houses of the Holy, 1973)	Page, Plant	5:31
2.	"Over the Hills and Far Away" (from Houses of the Holy, 1973)	Page, Plant	4:50

---

Proposed /sandbox:

Disc with no writers

No.	Title	Length
1.	"Good Times Bad Times"	2:48
2.	"Communication Breakdown"	2:30

Disc one

No.	Title	Writer(s)	Length
1.	"Good Times Bad Times" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:48
2.	"Communication Breakdown" (from Led Zeppelin, 1969)	Bonham, Jones, Page	2:30
3.	"Dazed and Confused" (from Led Zeppelin, 1969)	Page	6:27

Disc two

No.	Title	Writer(s)	Length
1.	"The Song Remains the Same" (from Houses of the Holy, 1973)	Page, Plant	5:31
2.	"Over the Hills and Far Away" (from Houses of the Holy, 1973)	Page, Plant	4:50

For wide-screen windows, examples with many columns, in either the current version or /sandbox, will appear slightly wider in table width. When set properly, the table width can be forced to the same for each disc in a set. The track-tables should still be readable with large browser text-size settings, per the WP:Accessibility policy. Again, this new proposal is a basic simplified change to set "width:nnpx" rather than requiring a total redesign. -Wikid77 20:37, 9 May 2010 (UTC)

I am looking at this on my 15' laptop screen with a 1280 x 800 screen resolution in full screen mode with Firefox 3.6.3. A rather standard setup, I would say. What bothers me with your new /sandbox proposal is that 4 of the 7 song titles wraps over into two lines, while there is lots free whitespace to the right of the table. In other words, with the risk of repeating myself, I don't see the point in degrading the display quality for the large majority of readers (like myself) who use Wikipedia in a rather "standard" fashion. And that's also the major problem with your /sandbox2 proposal largely discussed above. – IbLeo^(talk) 19:51, 12 May 2010 (UTC)

• I understand, so the table needs to widen for very wide screens. Basically, few people are willing to accept, even in some articles, the multi-wrapped display that sight-impaired readers have seen all these years(!). Check the appearance again, now I have reset width as percentages of screen size. I don't think a table defined in percentages can avoid becoming over-wide on very wide screens, but at least people are accustomed to seeing those wide-format tables as "normal" so this format can be continued for now. Narrow the window to half-screen and compare. Then we need to get consensus. -Wikid77 (talk) 05:22, 13 May 2010 (UTC)

I have updated the test cases to show both sandboxes for all the examples for a better appreciation. True, now that the /sandbox version stretches over the whole screen (when no infoboxes or images are present to the right), there is hardly no wrapping left. I must also admit that it works much better than the current version when I reduce my screen to half width. However, where I see that opposition could potentially occur is in section 6.2 where Disc 1 and Disc 2 have different widths because the image and the infobox aren't equally wide. I also observe by looking at section 3.2 that each column seems to take up a fixed amount of space, no matter whether it's really needed or not. Consequently there is quite an amount of whitespace between each column. Do you think it would be feasible to implement a more "intelligent" distribution of the columns based on how much text there is to display in each, and then keep the current max width? In my opinion it would solve most of our issues, and also make the need for user-specified width parameters redundant. – IbLeo^(talk) 19:41, 17 May 2010 (UTC)

Total Length

I was thinking, whenever i see total length, i always get confused why it's there. i know it's there, but i always wonder why it looks like any other track list length. i was wondering if we should add automatic parenthesis on them whenever it's available on a tracklist.Bread Ninja (talk) 18:17, 11 May 2010 (UTC)

Interesting point. But I don't see why brackets would imply a total, so I don't think that's the solution. If there were a way to put a "column addition" horizontal line above the total, that might do it, but I'm not sure how to go about it. When I've made track lists with a word processor, I just manually underline the last timing, to make a bar. That may not be possible here. --A Knight Who Says Ni (talk) 12:28, 12 May 2010 (UTC)

Well brackets were there to just help differentiate the track from the other track, but your right it will still be confusing to know why. A like could help too. if anyone knows any other way then maybe it can be mentioned here.Bread Ninja (talk) 15:39, 12 May 2010 (UTC)

I honestly don't see the issue with it, as is. The total length is already in boldface to set it apart from the "other lengths" (and is likely to be the only length with four digits, but that's not always the case). However, I fiddled around and came up with this: User:Mizery_Made/Sandbox2/Test. To achieve what I had in mind however, I ended up adding some mark-up to the template that seems like unneeded overhead. The Total Length row is only one cell in the template, so the top border would stretch across the entire table. However, I added empty cells in the places where others could be (No, Title, Writer, etc). Had to use similar markup for the heading however, seeing as the Writer, Music, etc columns may or may not be there. *Shrugs* – Mizery Made ^{(talk · contribs)} 18:31, 12 May 2010 (UTC)

I don't see anything in there. The problem is do people know what the bottom mysterious bolded length know what it's for. maybe us in Wikipedia do, but those who just read it won't know....another thing i find a little difficult is the collapse template. i personally don't have a problem with it, but whenever i merge a few soundtracks together, some new editors always revert because the track listing was gone and i have to explain it to them that it's not missing, it's just collapsed. Maybe we could do something about that? like even when collapsed it would stay shaded so people can know it's a collapsed template?Bread Ninja (talk) 18:36, 12 May 2010 (UTC)

I have added a second approach toward the Total Length row which may better inform readers what the value is for. Also in doing so, I found a way of reducing the markup for my first method. Mind you there are two total length rows only to display my two thoughts on how to display them. One just adds a top border to the Total Length cell which fits with what Knight was saying, and the second adds a "header" to describe what it's for. Thoughts? (PS: Still refering to the page here: User:Mizery_Made/Sandbox2/Test) – Mizery Made ^{(talk · contribs)} 19:14, 12 May 2010 (UTC)

I like the one with the header much better.Bread Ninja (talk) 19:18, 12 May 2010 (UTC)

I like them both! A Knight Who Says Ni (talk) 12:42, 13 May 2010 (UTC)

So we will be able to decide one?Bread Ninja (talk) 23:03, 27 May 2010 (UTC)

I prefer the lower version, although I am confused as to why the dark grey background does not extend all the way across the template to include the track time (to mimic the template header). Also, I wonder what this template will look like if you have an even number of tracks - final track details on a light grey background next to the track time details on a dark grey background? Memphisto (talk) 09:40, 28 May 2010 (UTC)

I believe my thought process when writing up that version was that doing it that way separated the "information" from the "header" and also helped the time actually stand out. I went in and set up three options on my test page, the first two split up the two options that were already present so you can see how they "really" look (since the 'overscore' version is no longer between the track list and the second option). The third is an alteration of the second, with the total time cell in gray like the headers. Each option has two tracklists, one showing even tracks and one odd. – Mizery Made ^{(talk · contribs)} 14:44, 28 May 2010 (UTC)

Many thanks for creating the new previews Mizery Made. My personal preference is for Option 3 and definitely for a version that includes the "Total Length:" text. Memphisto (talk) 16:08, 28 May 2010 (UTC)

I've added a fourth approach (same as the third but with the background color limited to the text), because adding another element that would match the header's visual weight (if that makes any sense) didn't feel quite right in my opinion. Thoughts? – Cyrus XIII ^(talk) 13:38, 29 May 2010 (UTC)

Jumping in quite late to give my 2 cents: I like the overall idea. I definitely prefer proposals 3 and 4 over 1 and 2. Between 3 and 4 I have a small personal preference for 4, for pure aesthetic reasons. But 3 would do the job as well. – IbLeo^(talk) 20:19, 29 May 2010 (UTC)

It may be my browser, but is the Total length cell slightly thicker than the header? Thanks for Option 4 Cyrus XIII. Memphisto (talk) 10:51, 30 May 2010 (UTC)

I'm getting a consistent height of 19px in Chrome and Firefox on Linux and Internet Explorer via a net renderer. Might be psychological, due to the bottom cell being more densely filled with text than the header. – Cyrus XIII ^(talk) 12:39, 30 May 2010 (UTC)

I think I must have been looking at the Option 2 cell (which is thicker). Memphisto (talk) 16:50, 30 May 2010 (UTC)

Option 2 is thicker, as it has a "thin" border around it. Though, the "thin" border appears thicker in IE than it does in Firefox. – Mizery Made ^{(talk · contribs)} 18:49, 30 May 2010 (UTC)

Since the discussion looks to be winding down on the subject of the accessibility of collapsed tables, perhaps we could reach a conclusion on this one as well? Option 4 would be alright with me, my only comment is that I believe the "Total Length:" could stand to be a little tighter in on the length cell (similar to that of Option 2 and 3). Am I the only one? – Mizery Made ^{(talk · contribs)} 20:42, 2 June 2010 (UTC)

I went ahead and toyed around with approach 4, to "tighten it up" a little, adding it as approach 4.1 on the example page. Looking at it in both Firefox and IE, it looks good to me. It's something to consider, but I may be the only one that thought 4 looked a little off with the extra spacing. – Mizery Made ^{(talk · contribs)} 23:43, 2 June 2010 (UTC)

We should leave the extra space, as per option 4, in case it's used for a DVD disc (often included as a bonus disc with audio sets) longer than 99 minutes, or expressed as h:mm:ss. --A Knight Who Says Ni (talk) 00:00, 3 June 2010 (UTC)

Hide length

I proposed the addition of a hide_length parameter on this talk page a while ago to hide the length column where it is inapplicable, such as in concert films or on releases where no length is listed and/or the length differs between versions. The users who replied said it was a good idea, but I just never got around to doing it. I finally implemented it today, but since there was no (recent) discussion, it was reverted. My code has been fully tested and works fine. Unless anyone objects, I think the template should be reverted to include my edits. I know I made a couple minor mistakes (left in the sandbox header, forgot one bracket), those could have simply been easily fixed instead of being reverted. –Dream out loud (talk) 01:03, 26 May 2010 (UTC)

My concerns largely revolve around over-specialization and feature creep vs. the KISS principle. If I'm not mistaken, only two additional options have been added to the template since its initial version two years ago. Now we are discussing a switch to hide the length column, a bit further up an option regarding the width of the template was considered. I do not believe that there are enough use cases to merit the addition of either option, as this would also render the template more difficult to use in general, particularly for newcomers.

Also keep in mind, that the original rationale of the template was to present track listings in a cleaner, more readable fashion. Without track lengths that would unevenly trail the information in each respective row of a regular numbered list, much of that rationale goes right out of the window. – Cyrus XIII ^(talk) 01:49, 26 May 2010 (UTC)

yeah i don't see the need for it. i thought you could add the template without the length column, but if it was released in a CD and the article states a special section for it, i dont see why not it should have length columns.Bread Ninja (talk) 02:01, 26 May 2010 (UTC)

I don't really buy into the argument that adding an additional optional parameter will confuse newcomers or dissuade them from using the template. If it's optional, it doesn't need to be used. Thus, newbies can go on using the template without knowing it exists and it will be just as useful to them. Y2kcrazyjoker4 (talk) 02:05, 26 May 2010 (UTC)

There are plenty of articles out there that could benefit from this. The only thing is that these articles don't currently have this template because of the length column that would be left blank. I think this feature could be used in every single concert film or live video album article, most of which simply use the numbered list to display their track listings. –Dream out loud (talk) 02:30, 26 May 2010 (UTC)

And what is wrong with that exactly? – Cyrus XIII ^(talk) 11:20, 26 May 2010 (UTC)

Question: I saw the change Dream Out Loud attempted to implement, and it appeared "hide length" was a parameter on each song title line. However, as has been pointed out, length is not mandatory. If you leave it out of every entry, the column is blank. The only clue to its existence is a "Length" column heading. Wouldn't it have been better to have an option to blank out the word "Length" in the heading? I'm thinking something like "nolength=yes" as a parameter to the whole table, to indicate you won't be using lengths.

And a comment: Dream Out Loud said he had approval for this change some time ago. I didn't remember it, so I checked back. The discussion took place in September 2008! And the suggestion Dream made, was to "make the time column optional" (as I've suggested above), not to make it a hidden field line by line. I can't find any place where that was proposed. The discussion is at Template talk:Track listing/Archive 3#A few suggestions....

And another comment: There was also an issue, which appears to be resolved, about whether consensus was achieved, and also the fact that some errors did get into the change briefly, which leads me to make this request again: Templates that are used in a great many articles are usually protected so that only an admin can make changes, which is only done when consensus is reached and a change request is made formally by placing a template on the talk page. This protects against vandalism, but it also does several other things. It forces a second pair of eyes to check and make sure only the code that was intended to go in, goes in. It also creates a situation where someone who was probably not involved in the discussion prior to the "admin request" being made, to come into the discussion fresh, and will check to make sure consensus for the request was clear. So I'd like to request again: Can we please make arrangements for this template to be permenantly edit protected for most users? I think I may have dropped the ball last time; I did make a request at an "admin requests" page, and was told it was the wrong place to ask (though it did seem like the right place), and didn't get around to finding where it should have been requested. If someone on here knows an admin, maybe they can get advice on where to make the request. --A Knight Who Says Ni (talk) 13:36, 26 May 2010 (UTC)

You're looking for Wikipedia:Requests for page protection, were I've just filed a request for full protection. Back in 2008, settling for semi-protection seemed like a good idea, avoiding random vandalism while still offering regular editors (myself included) the ability to implement changes without the need for admin-assistance. But I agree, with the template being used in roughly ten times as many articles as back then, there might be the need for a stronger emphasis on stability.

As for the proposed hide/no lengths option, I'll be happy to help with both the technical and usability aspects, should consensus disagree with my concerns. Could we bring in additional opinions from WT:ALBUMS though? I might be wrong, but I imagine that the "Why then use it at all?" line of thought could be rather prelavent among project regulars. – Cyrus XIII ^(talk) 14:38, 26 May 2010 (UTC)

I would support to add a global parameter to remove the track lengths for all tracks on the album, as suggested by Knight. I could see the use of such feature on future albums where nothing more than the track titles are known, that would have the potential to grow into a complex table once the album has been released. I don't see any use case to have the option at track level. Cyrus, I understand your concern about instruction creep and agree to KISS (especially seen in the light of a recent discussion on this page). However I believe that a single global switch wouldn't be beyond the capabilities of the editors to grasp. – IbLeo^(talk) 16:58, 26 May 2010 (UTC)

A global switch would still need to "turn off" the length for each track, otherwise you will have a cell for the tracks, but no cell for the header which I believe would lead to a "broken" table. However, I personally don't see the necessity of this change. If there is nothing more than a track number and a track title for the track list, then a table or this template is unnecessary. There's nothing wrong with those lists being in place text, as it's an "uncomplicated" list. Even in the case of "upcoming albums" where lengths aren't known, I can't see the need for hiding the length column. Just leave it blank, it hurts nothing. – Mizery Made ^{(talk · contribs)} 17:55, 26 May 2010 (UTC)

Note: It should be pointed out that Dream out loud never proposed anything but a single switch on the options level and that his revision correctly addressed the necessary per-row changes on the code level. – Cyrus XIII ^(talk) 18:13, 26 May 2010 (UTC)

Okay, my mistake, apologies for reading it wrong. I notice the template now has protection, but only for 3 days, and the reason given is "dispute" which isn't really true; the changes were made in good faith, and everyone is co-operating. Perhaps the admin who added the protection misunderstood the request. --A Knight Who Says Ni (talk) 22:44, 26 May 2010 (UTC)

Accessibility

I noticed that whenever the tracklist is collapsed it is unoticable for someone to see that it's a collapsed tracklist due to the hide/show button being so far. So this is what i had in mind, Add a black box over it or shade it grey so that people can see they are connected. ANother thing i wanted to ask was another example of how tracklist works. Such as compilation albums being seperated by sections inthe tracklist. I was wondering if it was possible to do that for the same disc. for example: Music of Neon Genesis Evangelion#"Evangelion Classic/ J.S. Bach: Suite Solo No.1" holds a number of sections and wanted to split it into it's respected sections. Afterward maybe the example could also be placed inside the template as one of the examples so some people can know another way of working with these types.Bread Ninja (talk) 23:42, 28 May 2010 (UTC)

I'm used to seeing hidden content marked by a box or bar...

...like this...
All right, move along people, nothing to see here.

...so maybe that's what's needed. I notice Template:Collapse (as used above) has a "bg=pink" (eg.) option to change the background colour, which could do the trick. It need not be an option; it could be turned on automatically for collapsed lists. That page you mentioned sure has a lot of collapsed lists! It's not too readable, in my opinion, but that's off topic. Regarding breaking a track into sub-tracks, I'm not sure this is possible, it's likely a deficiency of the template. If you can find a way to do it, by all means, put an example in the documentation. --A Knight Who Says Ni (talk) 00:26, 29 May 2010 (UTC)

I must admit that, like Bread Ninja states, I have been confused about a collapsed track listing more than one time in the past. Adding a background color in the collapsed state is a good idea that I would support. Maybe the background color could be chosen to match the infobox color (via a "type" parameter)? – IbLeo^(talk) 20:40, 29 May 2010 (UTC)

A number of sections as in cycles? This may be solved by multiple lists (see this example). Conversely, if a single track contains multiple songs, you can enter something like

Song 1"<br />"Song 2"<br />"Song 3

in a single title field. Regarding the confusion about collapsed lists: Does anyone know if collapsed tables allow for any state-specific changes (besides visibility, obviously)? – Cyrus XIII ^(talk) 21:39, 29 May 2010 (UTC)

A better method is to use the new {{unbulleted list}} template:

{{unbulleted list|Song 1"|"Song 2"|"Song 3}}

which uses proper HTML list mark-up and renders as:

• Song 1"
• "Song 2"
• "Song 3

Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:50, 29 May 2010 (UTC)

Cyrus, that is what iw as referring to, still, i tihnk it should be used as an example or the templates. Also Andy, i don't think your method works. in fact i don't think your on subject or maybe i'm not understanding clearly.Bread Ninja (talk) 01:24, 30 May 2010 (UTC)

Cyrus suggested separating items in a list with line breaks; I showed a better method. What's not "on subject" about that? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:18, 30 May 2010 (UTC)

yeah i misunderstood. still cyrus version is better for a tracklist template.Bread Ninja (talk) 23:50, 30 May 2010 (UTC)

Anyways, bback to the main subject. Anyone want to approve this? i see no real flaw to this. i reLally want this to be passed so it could make it easier for readers and new wikipedians.Bread Ninja (talk) 00:01, 31 May 2010 (UTC)

What do you mean, adding the Antichrist Superstar tracklist to the examples or implementing a means to make hidden lists more visible? No objections to the former, but for the latter, I'd prefer if we threw some code around in the sandbox first. – Cyrus XIII ^(talk) 13:04, 31 May 2010 (UTC)

I've cooked up a demo of how a collapsed list could be made more visible. It's not ideal, as I'd really prefer it if the newly colored bar would revert to its former white once the reader has clicked on [show] (hence my earlier inquiry about states). – Cyrus XIII ^(talk) 15:04, 31 May 2010 (UTC)

If it were white, and if "side one" in your example had an odd number of tracks, the bar would have the same colour as the last track, and the two would run together. You don't want that. I think it looks okay the way you have it, with the same darker grey colour as the title bar. --A Knight Who Says Ni (talk) 21:30, 31 May 2010 (UTC)

I'm not fond if it being the same color as the headers, as it doesn't look too good once it's opened up. I'm also not sure it's a good idea to have the title be white for non-collapsed ones and then gray for ones that are. The purpose of the template is consistency in display, isn't it? – Mizery Made ^{(talk · contribs)} 23:17, 31 May 2010 (UTC)

I'd like to think so, that's why adding borders isn't something I'd really consider either, same goes for having [show] appear next to the headline (different placement of each [show] in a multi-disc release, jumps around on opening/closing). Let's take a step back for a second: Can we assume, that it is not good practice (and in fact fairly uncommon) to ever present a collapsed list without headline? One measure to improve matters at least a little could be to make headlines mandatory for collapsed lists, adding "Track listing" as a default, if nothing else is set. This could go a bit further, by increasing the visibility of that default headline with bigger text (<big>…</big>) or outright formatting as a section header of a track listing-typical level (<h3>…</h3>). See testcases3 for a demo. – Cyrus XIII ^(talk) 07:55, 1 June 2010 (UTC)

Again, I'm finding the idea of introducing (large) inconsistencies on how certain elements are handled in various cases to be a strange move to be making. Yes, I can agree that having a track listing collapsed with no header is big no-no and shouldn't be done. Thus, I can understand the need for some type of prevention against this. However, I don't think the difference needs to be that drastic. Why should un-named collapsed lists be presented with an <h3> header, whereas a regularly titled one is presented as-is? I think a sufficient approach would simply be adding a default title of "Track listing", which would differentiate from named ones appearing as "Track listing" (though obviously the text would be the manual name provided). It fulfills the purpose of not having a "[show/hide]" off to the right with nothing to the left to pair it with, whereas it doesn't introduce a drastic difference between named and un-named lists. Using headers in this way too, could introduce some reduncency in the TOCs, as you might end up with the manually added "x Track listing" header, as well as the "x.1 Track listing" that would be added by this approach.

On the previous subject of a colored bar, I'm actually starting to like an idea thrown out some time ago. That is, to add another parameter to the template which set the color based on the type of release. Thus, the bar presented should match the color given in the Infobox for the article. After all, the Musical artist Navbox uses this method to color it's bar to match what should be present in the Infobox of the artist. PS: It's late, so I may not be thinking clearly. – Mizery Made ^{(talk · contribs)} 08:31, 1 June 2010 (UTC)

No objections to dropping formatting differences between automatically and manually set headlines. That was really just a suggestion on how far this could be taken (as opposed to should). – Cyrus XIII ^(talk) 10:23, 1 June 2010 (UTC)

I like the idea of the collapsed tracklists background colour matching the Infobox album. Memphisto (talk) 09:43, 1 June 2010 (UTC)

I'm not sure yet how I feel about the general idea, note that "collapsed" is currently the only option that is purely concerned with appearances and avoiding these has been essential to maintaining previously mentioned consistency. But just for the sake of the argument, one could avoid another option by making "collapsed" sensitive to color-related inputs (similar to the "background" setting of navboxes) with "yes" defaulting to the demoed grey or the earlier white. – Cyrus XIII ^(talk) 10:23, 1 June 2010 (UTC)

After messing around with it just for kicks, I have to say that outer borders look a lot better than I expected. They highlight the collapsed content quite nicely without being to invasive of the original design (probably on account of remaining "outside"). – Cyrus XIII ^(talk) 11:28, 1 June 2010 (UTC)

Is this the kind of thing we are talking about?

Evangelion Classic/ J.S. Bach: Suite Solo No.1

No. Title Length 1. "Prélude" 2:42 2. "Allemande" 3:49 3. "Courente" 2:35 4. "Sarabande" 2:44 5. "Menuets I And II" 3:15 6. "Gigue" 1:46 7. "Prélude" 4:20 8. "Loure" 3:38 9. "Gavotte En Rondeau" 3:02 10. "Menuets I And II" 3:52 11. "Bourrée" 1:07 12. "Gigue" 1:33 13. "Ouverture" 3:47 14. "Air" 5:27 15. "Gavottes I And II" 2:41 16. "Bourée" 6:20 17. "Gigue" 2:11 18. "Chorale From Kantata No. 147" 3:12

Memphisto (talk) 13:30, 1 June 2010 (UTC)

My guess is that Cyrus XIII is referring to sandbox5 as shown in testcases3. I like it – it's simple, sober and elegant and it makes it obvious that the track listing is collapsed. – IbLeo^(talk) 17:01, 1 June 2010 (UTC)

I like "sandbox5" too, because its differences from the current version are minimal. The "Track listing" heading only appears when the list has collapsed=yes option turned on. The version Memphisto added above (if it's a proposal for a solution) has a problem, in that its box takes up the full width of available area, while the track listing inside does not, and the fixed table width does have a purpose. (I know the issues of total table width were being discussed elsewhere, but since that's on the back burner for now, I perfer not to factor it in.) --A Knight Who Says Ni (talk) 21:54, 1 June 2010 (UTC)

Should we ask for admin assistance then (via {{Editprotected}}) to have the current revision of sandbox5 copied to the template page? That would make the frames and automatic headlines (if empty, no special formatting) for collapsed lists permanent. – Cyrus XIII ^(talk) 10:51, 2 June 2010 (UTC)

Endorse and don't forget to prepare an update to the documentation. --A Knight Who Says Ni (talk) 12:21, 2 June 2010 (UTC)

I personally feel that it's not quite ready to "go live." I have added another (common) example to the testcases3 page, showing an instance where there may be a "main disc" that isn't collapsed, while subsequent "pieces" are. There are numerous articles where this occurs, where the "standard pressing" is displayed uncollapsed, and various bonus discs or tracks are then broken off into a separate template following the main list. Such as on the page for Britney Spears' Circus. When looking at a test case for this situation, you can notice considerable inconsistency between the two. Namely, the collapsed tables aren't as wide as those non-collapsed and the two don't properly 'line up' as they would before. I haven't messed with markup that's been proposed in Sandbox 5, but one thought that comes to mind as I look at it is, I believe the padding (or margin, whichever is at work here) between the border and the track listing may be able to be tightened up a little more. Perhaps even all the way. I feel like a broken record, since I keep mentioning "consistency," but I think the border could stand to be added to the non-collapsed version as well to give a consistent display of both versions (aside from the obvious collapsing of the collapsed version, and the Show/Hide toggle.) – Mizery Made ^{(talk · contribs)} 13:51, 2 June 2010 (UTC)

How does this look? – Cyrus XIII ^(talk) 15:12, 2 June 2010 (UTC)

I find this to be an improvement, as the tables are now of equal size. I see you tightened the border up a touch, which I appreciate as it looks a little cleaner to me with the reduced whitespace. The border only being present on the collapsed version is a point I'm willing to conseed, as I don't want to continue coming across as "No, No, No." If others approve of the changes you've made in your sandbox, then we might be good. – Mizery Made ^{(talk · contribs)} 20:38, 2 June 2010 (UTC)

I think Mizery Made makes a valid point regarding consistency btw. non-collapsed and collapsed tracklists. It looks really weird with borders only around the latter; I would support adding the border around both. Nevertheless, it's not a showstopper for me either. – IbLeo^(talk) 21:32, 2 June 2010 (UTC)

I recommend limiting that outer border to collapsed lists for now. The way we've been considering various approaches back and forth seems indicative of a "can't have the cake and eat it too" type of conundrum; finding a fix that works but isn't too invasive of a familiar and generally accepted presentation. Collapsed lists are after all, in the minority, articles that mix either variant even more so, hence if we were to apply borders to every list, I suspect there would be a backlash in some form, while chances are that with the current proposal, we won't hear about this again in some time. Of course, I could be wrong about that, but then again, we can always take this one step further in a future update.

Speaking of updates: One thing I really do like about Template:Tracklist custom is that it has a changelog. When it comes to complex templates, the regular edit summary can be a little limiting, especially if one want's to link to respective discussions (and later update those links to archive pages). Is there any generally accepted approach to do this? Otherwise I'd just start one at Template:Track listing/changelog once the next revision goes live. – Cyrus XIII ^(talk) 03:07, 3 June 2010 (UTC)

This is just me theorizing here (since it's impossible to know exactly how people will react, especially since everyone can have their own opinion), but I'm thinking it would be far more confusing for people to pull up a page when this goes live, and see that there's a border around one table, and not another. Whereas if it were added to all instances, it may appear more as a "design alteration." Granted, the docs would be updated to reflect the change and thus carry information that the border is there to make collapsed tables more visible but... I don't know.

As for a change log, if one is to be implemented, then I believe your idea may be best. That way, the template's page doesn't become bloated with said change long. It could then either be linked to from the Docs somewhere, or transcluded? – Mizery Made ^{(talk · contribs)} 03:22, 3 June 2010 (UTC)

I suppose what we can agree on is, that either of us could be wrong about about the general acceptance of either course of action, my point being that should the need for further adjustments arise, it would be easier to expand on a change than to take some of it back.

Regarding placement of the changelog, I was considering a link at the top of the talk page. – Cyrus XIII ^(talk) 09:17, 4 June 2010 (UTC)

With no further comments in a week, I'm going to be a little bold here and assume that we have consensus to

• add mandatory headlines for collapsed lists
• add borders to collapsed lists (at least)

as reflected by the current revision of sandbox5. (Note to admin: {{pp-template}} has been commented out in the sandbox draft.) On a related note, the changelog is live and respective prose for this update has been added to the documentation (commented out for now). – Cyrus XIII ^(talk) 15:26, 11 June 2010 (UTC)