Template talk:Track listing/Archive 7

Archive 1

←

Archive 5

Archive 6

Archive 7

Archive 8

Archive 9

Archive 10

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)

Well it looks like we got a bit off-topic here. I'm simply trying to propose the new addition of a beneficial feature and this somehow turned into a discussion about protecting the template. Well I apologize for not discussing my proposal before making the edit, but honestly this whole thing seems more like a case of WP:POINT. Anyway, this template is currently being used in both U2 360 at the Rose Bowl and U2 Live at Red Rocks: Under a Blood Red Sky, both of which are concert films and have no track times listed. The column in the first article is blank (although it was absent before the hide_length parameter was reverted). The second article does not have the column because I had to use to crazy custom code using {{Track listing/Track}} and a Wikitable. That code should not be necessary but I had to do it like that because there is no option for hiding the length column. If you look at the article you'll see what I mean. Now that the template is protected, I'd like to get back onto my original discussion about this feature. –Dream out loud (talk) 05:09, 20 June 2010 (UTC)

Again, please explain how such an option would be useful, given that it cancels out much of the template's intended purpose and why are regular numbered lists inadequate for the use cases you mention? – Cyrus XIII ^(talk) 09:27, 21 June 2010 (UTC)

Clicking Show/Hide Moves cursor to Start of Page

I've added the following templates and the table displays properly:

• Template:Tracklist
• Template:Track listing
• Template:Track listing/Track
• Template:Collapsible list

The Show/hide links works by showing the table or hiding it when the link is clicked. However it also moves the cursor to the start of the page. Can anyone please tell me how to fix this? Holygamer (talk) 07:10, 21 June 2010 (UTC)

That's an odd one. I have no idea what might cause this, but you will probably find better help on a less specific talk page, for example at Help talk:Collapsing. – Cyrus XIII ^(talk) 09:41, 21 June 2010 (UTC)

Thanks, I've done that Holygamer (talk) 18:36, 24 June 2010 (UTC)

Album name + artist

I'd like to develop this template by including optional album name and artist table headers. It can then be made to emit the hAudio microformat. For example, in this template's own documentation, "Greatest Hits by Queen" would be part of the template and thus within the resultant HTML table. Any questions, or suggestions as to how best to do this? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:13, 8 August 2010 (UTC)

there is the "Extra", if you ever want to add in another section in the template that we dont have, the Extra will allow you to add it in.Bread Ninja (talk) 19:36, 8 August 2010 (UTC)

Thank you, but I want to add specific fields; that way, we can apply HTML classes to them and make the template emit an hAudio microformat. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:04, 8 August 2010 (UTC)

Hm....well i don't know, it seems a little guide-like if we focus on something like that.Bread Ninja (talk) 20:42, 8 August 2010 (UTC)

"guide like"? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:54, 8 August 2010 (UTC)

Yeah, i don't really understand why we need to include this....Bread Ninja (talk) 21:16, 8 August 2010 (UTC)

Anyone else have a view? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:20, 14 August 2010 (UTC)

This is really what note_n and extra_column are for. Too many concurrent columns would result in rather crammed and therefore reader-unfriendly lists, especially on lower resolutions. – Cyrus XIII ^(talk) 11:54, 16 August 2010 (UTC)

Those columns are not suitable; because they can also be used for other things, so it's impossible to determine that the data entered actually represents an artist or album name. Besides, I wasn't asking for extra columns, but something in the header area. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:08, 16 August 2010 (UTC)

I font think the template is meant to hold every little detail about the tracklist. either way, Cyrus XIII already said those can be used. they are perfectly suitable.Bread Ninja (talk) 20:01, 17 August 2010 (UTC)

Nobody is proposing the inclusion of "every little detail about the tracklist" - the name of the artist and record are rather significant properties of the tracklist, are they not? Cyrus XIII refers to columns, not the header, and as I have already explained, those are not suitable for the purpose I propose. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:41, 21 August 2010 (UTC)

only becaue you want to put it in hAudio microformat? why can't it be in prose format? the Extra column really seems appropriate. though i don't know much about it, and last time i saw a link to it, it didn't help me. a specific artist section i guess would be ok but it just doesn't sound so urgentBread Ninja (talk) 10:41, 21 August 2010 (UTC)

Nobody said anything about urgency. You are still talking about a column, intended for per-row values, when I'm suggesting a one-off value in the header. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:02, 21 August 2010 (UTC)

What i meant by urgency is that it's not really so important to get it done with. still feels like we're filling up the tracklist as much as possible. i don't see where this will be useful to it's max. Some articles of albums already explain the artist in the opening post or opening paragraph.Bread Ninja (talk) 19:41, 21 August 2010 (UTC)

Headline

It's probably far too late to make this change, but there is absolutely nothing intuitive about "headline". I can usually figure out the template from memory, but I always think this parameter is supposed to be "header" or (when that doesn't work) "heading". Headline makes no sense, this isn't a newspaper. Would love a change, but if it's too much of a hassle, then this is just for the record. – Kerαunoςcopia^◁_galaxies 04:26, 12 August 2010 (UTC)

Remove quotations mark

Hey, I just wanted to know how to remove the quotations mark on the template. I've been editing on the sandbox version of this template and found that I still can't seem to remove them. Don't worry, I don't want to remove the quotations mark on this template or any other, but I wish to just get a better understanding and for future reference of how this works. Thanks! :D DoctorStrange (talk) 15:28, 2 September 2010 (UTC)

That is done on the sub-template Template:Track_listing/Track. Looks like you would change "{{{2}}}" to {{{2}}}. – Mizery Made ^{(talk · contribs)} 19:00, 2 September 2010 (UTC)

Oh, I see! Thanks Mizery Made! :)--DoctorStrange (talk) 20:45, 3 September 2010 (UTC)

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)

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)

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)

As followers of this talk page certainly know, this issue has existed since the "childhood" of this template, depending on people's browser version and screen size. However, I believe that the problem has considerably worsened since 27 September 2010 where a change to the album and singles infoboxes was implemented. Prior to that change, the cover image was "hardcoded" to always display at 200px (or lower if manually overridden); now it displays as it's own size, capped by the users thumbnail size in his preferences. While this is a more generic approach (the user can decide for himself), it implies that the infobox has become wider than before for users with a preferred thumbnail size of 250px or 300px, and consequently it increases the probability of an overlap between the infobox and the track listing for such users, causing the track listing to be "pushed down" in the article. Now, we can hardly blame you, Cyrus XIII—the template's original creator—for this; you coded the template based on the premises valid at that point in time. In my opinion, the best solution to the problem would be to somehow take the users thumbnail preference taken into account when calculating the width of the track listing. If possible. Unfortunately my own template skills do not allow me to judge on the feasibility. – IbLeo^(talk) 12:27, 15 December 2010 (UTC)

FYI: For me, the problem also occurs in Firefox with 220px, not with a setting of 200px, though. Monitor size and resolution also matter, IMHO - in addition to browsers: in Konqueror 3.5.10 on the same monitor, the problem does not occur with 220px. BNutzer (talk) 01:08, 16 December 2010 (UTC)

I have yet to find a way of pulling the users Thumbnail setting so that the template may dynamically be set to fit accordingly. Furthermore, I believe this Template/Infobox issue is wide spread and not just contained to this template. I have yet to find a template that is intended to fill the entire width (like has been requested of this one on many occasions) that plays nice when there is an infobox or other floating element involved. They do just as this one does now (when someone has their thumbnail setting higher than the default), in that the template is pushed down to the bottom of the infobox. I say this with the navboxes in mind. Though the odds of those conflicting with an infobox is unlikely since they're at the bottom of the article. The templates (or rather, tables I guess) used for television show seasons also doesn't account for floating objects and just pushes further down the page as well. Granted, they're not intended to be next to floats, but still. I think this script should be commended for at least attempting to play nice with infoboxes/floats. – Mizery Made ^{(talk · contribs)} 17:51, 15 December 2010 (UTC)