Template talk:Track listing

Requested edit

Border There is a huge and wildly unnecessary gap between the padding on the left and the right side of this track listing template. On my browser--Firefox 3.6, Windows Vista--there is are 18 pixels between the left side of this template and the vertical line that separates the article from the sidebar (using Monobook) and a 143 pixel gap on the right side of the template to my browser's chrome. (See two screenshots: one where my browser is the size I usually keep it and one full screen. Sorry for the Flickr resizing.) Why is this padding nine times larger on the right side? I suggest a much wider template that has a more equal distribution of padding; this empty space to the right isn't getting used for any purpose and it's unnecessarily scrunching information, especially when three or more columns are used. —Justin (koavf)❤T☮C☺M☯ 22:06, 26 October 2010 (UTC)

Firstly, I have removed the Edit Request template (for the time being). The "proposal" should likely be discussed first, and your request hasn't been thoroughly presented. That said, I don't see a considerable margin on the left, anymore than the normal margin that is. Perhaps a few pixels, but I don't see how that creates any large problem. The margin on the right is serving a purpose. It prevents the track list from being pushed down the page (creating an even larger white space between the section header and template) on short articles, due to the Infobox. "We" have tried finding a solution that allows it to expand as needed, but there has yet to be a solution found that works correctly (most end up making the infobox and track list overlap). – Mizery Made ^{(talk · contribs)} 23:01, 26 October 2010 (UTC)

Would it be possible to add another parameter that could be used to modify the right side border on a case-by-case basis? I understand the desire to not overlap the infobox, but that can be avoided using other formatting tricks in the article, and there are a few track lists that look really ugly, with multiple lines per song, that could be corrected by widening the template to the right. It could simply default unless specified. —Torchiest ^talk/_edits 23:07, 16 November 2010 (UTC)

Possible? Yes, but I don't think it's a good idea to add yet another option for a purpose that is a) purely aesthetic and b) only useful for a limited subset of articles. – Cyrus XIII ^(talk) 15:22, 18 November 2010 (UTC)

Usually, it's because of notes or super long information. If possible, iw as thinking making the notes go under the track title, instead of next to it>Bread Ninja (talk) 00:03, 17 November 2010 (UTC)

Unnecessary sentence fragments

| all_writing     = Joe Writer

gives: All songs written and composed by Joe Writer.

| all_lyrics      = Fred Lyricist
| all_music       = John Composer

gives: All lyrics written by Fred Lyricist, all music composed by John Composer.

The fact that these are incomplete sentences seems unwarranted; it stands out particularly because these fields appear to blend in with any prose preceding the track listing, due to their placement outside the table and the lack of any special text formatting. Sentence fragments like this are inappropriate outside of an infobox or table. I'd suggest adding a verb to each phrase and changing the comma in the latter example to a semicolon or a period. AtticusX (talk) 12:05, 29 October 2010 (UTC)

Ignoring for a moment that these phrases are common language in this respective context, could you provide an example of an article where they blend in with the preceding prose? – Cyrus XIII ^(talk) 15:30, 18 November 2010 (UTC)

See Arya 2#Soundtrack or Brindaavanam#Soundtrack for examples of such situations. Not perfect examples, as both captions are redundant in their respective contexts. But that's what it looks like when the caption isn't the first text in its section. It reads as a grammatical mistake, due to the lack of a verb despite the presence of final punctuation. The error is made obvious when it happens to immediately follow regular text, but even when the caption is the first text in its section, it's still an awkward hybrid.

To restate the problem more clearly: the current implementation of these credits is awkwardly trying to straddle the line between caption (fragment) and prose (complete sentence). It needs to pick one or the other. If it wants to present itself as prose, it should obey the rules of prose, and if it's content to exist as a sentence fragment, it ought to present itself as such.

Obviously, music credits are frequently and correctly presented without verbs or punctuation, as sentence fragments. Such usage is correct only in non-prose contexts, such as in free-standing lists of credits or as part of album cover graphics. But sentence fragments do not get to have final punctuation (see Wikipedia's guidelines regarding sentence fragments in captions and disambiguation page entries for similar cases).

One obvious difficulty in following my initial advice (i.e., taking the implementation all the way toward prose) would be choosing the verb tense: some cases would merit a present tense ("All music is composed by..."), while others would be better served by the past tense. Having studied this further, I am now inclined to believe that the easiest resolution would be to take it the rest of the way toward sentence fragmenthood. Which would probably mean fiddling with the text's placement or formatting to make clear that it belongs to the table, as well as removing its final punctuation. AtticusX (talk) 11:55, 19 November 2010 (UTC)

Table too wide

The track listing table seems to be a bit too wide on my Opera (v10.63) browser: the table clashes with the album infobox and forces it to appear below, rather than next to, the infobox. So, I'm requesting that 0.5em or more be added to the right margin. Of course, it might just be a problem specific to me, so it would be great if someone could confirm the issue. —Quibik (talk) 08:51, 1 November 2010 (UTC)

The template is designed to work with the Infobox by default. If you have a different setting for Thumbnail sizes, then that is likely the cause of your problem (as that stretches the infobox and pushes the Track listing down). The default is 220px. – Mizery Made ^{(talk · contribs)} 01:50, 2 November 2010 (UTC)

That seems to be the case. Thanks. The "Infobox album" template was indeed changed about a month ago from a fixed image size of 200px to the user's default thumbnail size. Too bad, I don't think I'm going to lower my default thumbnail size just to fix the tracklist issue. I did a more precise test and with my default thumbnail size of 250px (only 300px is higher), the required margin increase for the table is about 0.2em – roughly a millimeter on my screen. I doubt that I'm the only one experiencing this issue, so perhaps the template can be changed. —Quibik (talk) 13:36, 2 November 2010 (UTC)

I am also getting this problem... I don't log in to view Wikipedia, so I don't have a setting for Thumbnail sizes. The thumbnails seem to be 220px wide, not 200, so perhaps the template needs to be edited to reflect this change? All short album articles have their track listings being pushed below the infobox. (Firefox 3.6.12 on Arch Linux) —Preceding unsigned comment added by 99.238.35.236 (talk) 07:28, 14 November 2010 (UTC)

I forgot to mention, the "Professional ratings" box is wider than the infobox, so that will affect the tracklisting template as well. —Preceding unsigned comment added by 99.238.35.236 (talk) 07:31, 14 November 2010 (UTC)

Could anyone point out the bit of code that the Infobox uses to adapt to that user setting? We might just have to use it too, to ensure compatibility. – Cyrus XIII ^(talk) 15:35, 18 November 2010 (UTC)

I don't think the Infobox is doing anything special to adapt to the user setting. Before, I believe the images were restricted to 200px (which created a "border" around them. It was discussed and argued that it made no sense for them to be restricted to be small than any other thumbnail (as per the Wiki default, and users settings). Thus it was changed to no longer restrict the size so I assume the "[[image:]]/[[file:]]" itself pulls the users' thumbnail settings. It does use "{{px|{{{Cover size|}}}|frameless}}" instead of "{{min|200|{{{Cover size|}}}}}px|..." now, perhaps that holds some relevance? Previously it used "[[image:]]" while now it uses "[[file:]]" to call the image too. – Mizery Made ^{(talk · contribs)} 17:01, 18 November 2010 (UTC)

I have the same issue, my preferences are set to 250px, the reason this is especially annoying is because the tables don't appear to be in each other way, they look like they fit perfectly next to each-other and would not overlap, but they refuse to do so. Image example This is especially defeats the entire purpose of collapsing the list to save space. Image example Isn't it possible to make the table stretching the entire with of the age and only get smaller when something else is in the way, similar to how text wraps around images and info-boxes? _Xeworlebi ^(talk) 22:55, 28 November 2010 (UTC)

A few individuals (including myself) attempted to find a solution to do just that several months ago. I don't believe it's possible, and even if it were possible to get it working, there would potentially be trouble with it working across all common browsers. You're more than welcome to try and find a working solution, if you have any ideas. – Mizery Made ^{(talk · contribs)} 23:08, 28 November 2010 (UTC)

So the width paramenter wont work on this? like percentage of how wide it would be or so?Bread Ninja (talk) 06:30, 29 November 2010 (UTC)

Modification of the width parameter alleviates, but does not solve, the issue. Still, how about increasing the margin by 0.5 em (barely noticeable), which would solve the issue for everyone but the people with 300px thumbnail sizes, as a temporary fix? —Quibik (talk) 16:21, 29 November 2010 (UTC)

I'm not so sure what you mean by it alleviates but does not solve.Bread Ninja (talk) 22:54, 29 November 2010 (UTC)

It means it patches it but does not actually solve the problem. It would solve it for those using 250px, but for 300px it doesn't. In essence creating a work around instead of fixing the issue. _Xeworlebi ^(talk) 23:00, 4 December 2010 (UTC)

I"m not so sure, what you mean by 250px-300px. Are you referring, it wouldn't work when we alter them by ##px size, or that if the tempalte itself is bigger than 300px, the percentage of the width wouldn't work.Bread Ninja (talk) 01:10, 5 December 2010 (UTC)

I believe Xeworlebi is referring to the value of the "thumbnail size" parameter in the "Appearance" tab of your preferences. This parameter determines the maximum size of the cover image in the infobox, and it sounds to me like this problem only appears for people who has it set to 250px or 300px. I personally use the default value of 220px and have no problems, neither with Firefox, Google Chrome nor IE. – IbLeo^(talk) 08:38, 5 December 2010 (UTC)

IbLeo is correct. This entire issue is because of the non-support for bigger thumbnail sizes. The issue here is that this template is "hard coded", does not scale for potential interference, and does not work well with a custom preferences. _Xeworlebi ^(talk) 11:41, 5 December 2010 (UTC)

What I have currently in my sandbox works half. The collapsing doesn't work anymore. No offense to the people who made this template, but it's a mess. Counting the number of columns and allocation a % based on that? really?. Is there a place we can go to ask for help on templates? Because what I've seen in the code here could use a complete rewrite. _Xeworlebi ^(talk) 23:12, 29 November 2010 (UTC)

I've requested at Wikipedia:Requested templates that someone with some better template making skills can take a look at this template and hopefully fix this issue. _Xeworlebi ^(talk) 22:59, 4 December 2010 (UTC)

None taken. In our defense, at the time of this templates creation, the combination of HTML/CSS and wiki-markup didn't really lend itself to an any more dynamic approach than, say, counting columns. If this hasn't much changed in the intervening years (word on WP:RT suggests it has not), then we are left with either digging up some sort of global variable for the user-set thumbnail size or increasing the static right margin by a few deci-em and hope that this works for most people. – Cyrus XIII ^(talk) 12:07, 15 December 2010 (UTC)

Edit request from Deblopper, 13 December 2010

{{edit protected}}

Width Parameter Required

For customizability, there should be a width parameter for the entire list (can have the default value what it has now, but the flexibility to be custom set, if the user/article require). See for example Assassin's_Creed_Brotherhood#Music (today's revision, if gets modified later on), a very bad layout problem can be found, which makes the list appear either previous or next to the album infobox making a huge blank space left to it.

I know this can be solved putting them in a same rwo of a table, but why try the hard way?

– Deb ‖ Poke • EditList ‖ 06:08, 13 December 2010 (UTC)

APparently it has been attempted before but it didn't work on all formats. I also requested this a while back>Bread Ninja (talk) 06:17, 13 December 2010 (UTC)

I have disabled the request for now. Please discuss what needs to be done and then reactivate if needed. — Martin (MSGJ · talk) 10:15, 13 December 2010 (UTC)

Ugly effect when template is used in an article with a long infobox

See here. BNutzer (talk) 21:25, 14 December 2010 (UTC)

Issue known, see two sections before this one. _Xeworlebi ^(talk) 21:29, 14 December 2010 (UTC)