Template talk:Track listing/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Archive 7

Archive 8

→

Archive 10

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)

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)

Implementation

{{editprotected}} 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)

 Done — Martin (MSGJ · talk) 16:06, 11 June 2010 (UTC)

Collapsed

What is up with the new format? Specifying collapsed only leaves the track listing as a table. It should be hidden as before so that pages with several lists don't look overwhelmed by simply track listings. -- ipodnano05 * ^{leave@message} 23:53, 14 June 2010 (UTC)

This was a temporary bug with the collapsed code. Bypass your browser cache and the problem should be fixed. —TheDJ (talk • contribs) 23:58, 14 June 2010 (UTC)

Thank you. It works perfect. I'm sorry. -- ipodnano05 * ^{leave@message} 02:59, 15 June 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)

Now that the collapsed template changes have been implemented (nice job), could the total length alterations now be agreed? Memphisto (talk) 13:05, 16 June 2010 (UTC)

Apologies for not following up on this sooner, I didn't notice the more recent replies in this thread until this afternoon. Testing proposal 4.1 in a few Linux browsers, it looks fine (and indeed more elegant) in Chrome but there seems to be a width issue in Firefox, resulting in a line break between "Total" and "length" (1st screenshot). Widening the respective div from 7 to 7.5em, the line break is gone, but the overall field looks very unsymmetric, lacking any padding on the left (2nd screenshot). With an extra padding of 10px on the left, mirroring the one on the right, it does look more balanced, but as far as looks (and probably code) go, we're also pretty much back at proposal 4.

• 
  Current 4.1
• 
  Div widened to 7.5em
• 
  10px padding-left added

Could someone take a look at the sandbox via Safari? – Cyrus XIII ^(talk) 16:28, 16 June 2010 (UTC)

Sandbox version 4.1 looks fine in Explorer/Firefox/Chrome/Opera on my Windows Vista system. Memphisto (talk) 17:19, 16 June 2010 (UTC)

Also looks fine in Safari (5.0), Firefox (3.6) and the current Chrome Dev build on OSX. FjtDo (talk) 17:38, 16 June 2010 (UTC)

I'm working from Windows (Vista) as well, so I was unaware of any issues with Linux. I'm not strongly opposed to version 4(.0), I just saw the extra spacing which looked a little off to me and tossed up a "tighter" version as a suggestion. Didn't do too much testing with cases of more than five characters (four numbers and the :), seeing as CDs won't hold more than 80 minutes, and I've always used "80:00" as opposed to "1:20:00" to match with the style of the Infobox. I'm not sure it would be much issue though since the length is in it's own cell. (I did go in, I believe, and add a little padding to the right of the "Header" though, just in case) If there is an issue on Linux though, then it doesn't matter all that much. That's the trouble with web development, so many different browsers, in different environments, different reso's, etc. It's a pain.

Looks as though #3 and #4 are the contenders (pending the verification of the issues of #4.1 on Linux?) Either one would be okay with me. Any of the three(3, 4 or 4.1) would be okay with me. I kinda think that #3 has a nice "bookend" type of effect, with the bottom bar stretching across like the top header(s). However, I think it also looks nice where it only covers the needed space. – Mizery Made ^{(talk · contribs)} 21:42, 16 June 2010 (UTC)

Would option #3 be more browser neutral? Also agree that it has a "bookend" effect. Memphisto (talk) 09:25, 17 June 2010 (UTC)

It would, same goes for #4. I'd still prefer if a "Total length" bar would not be the "No./Title/Length" header's visual equal, as it seems visually and semantically more concise. Hence, I'd raise my hand for #4 or any tightened up revision that displays well across the board. – Cyrus XIII ^(talk) 17:12, 17 June 2010 (UTC)

Should I drop an edit request for #4 then (leaving a wider tested #4.1 for a future revision)? – Cyrus XIII ^(talk) 09:29, 21 June 2010 (UTC)

Seems like a good approach. Memphisto (talk) 09:37, 21 June 2010 (UTC)

{{editprotected}} Alright then, I'd like to ask one of our friendly neighborhood admins to implement this revision of the sandbox, which merges the current code with #4. – Cyrus XIII ^(talk) 09:52, 21 June 2010 (UTC)

I had this reply written, but got an edit conflict notice as you put up the above while I was in the process. Posting it anyway: I say go for it as well. As I've said, I'm not opposed to version 4. It accomplishes what was set out to be accomplished, which is to set apart the Total Length from the rest, and explain for those unfamiliar with the template, what it is via the 'header.' It's not as if the template is set in concrete after the edit, so if a better approach is thought up afterwards, we can rejoin this debate. – Mizery Made ^{(talk · contribs)} 09:57, 21 June 2010 (UTC)

I have made the requested change. However I do question whether this is the best way to achieve what you want. Putting a div inside a table seems to over-complicate it. — Martin (MSGJ · talk) 12:16, 21 June 2010 (UTC)