Template talk:Track listing/Archive 3
This is an archive of past discussions about Template:Track listing. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 | → | Archive 10 |
Use in single tracklist articles, aspect
I find this template to be pretty good for multiple tracklist articles, as in does a good job of aligning everything. However, in articles with only one tracklist, I must admit I still don't really like the layout. I still find that this templates looks too much like a big block of text :(
I'm specifically thinking of this example:
- wikitable - template
I find the wikitable version to just generally look better. Without multiple tracklists, I don't think this article warrants the use of this template (or many others, as a matter of fact).
What would you think of trying to make the template look more like the wikitable (albeit a bit more compact)? This templates needs at minimum either lines in between rows, or more contrast in between row colors. Under these conditions, I wouldn't mind using it. happypal (Talk | contribs) 03:31, 6 August 2008 (UTC)
- I did leave an alternate version, with the notes in the extra column, on the talk page if that helps any? — Balthazar (T|C) 20:48, 7 August 2008 (UTC)
- While you mention that a higher contrast between the different table rows could help the overall layout/look of the template, there is an interesting [article] adressing the actual effect of this so called "Zebra striping". I guess giving the single rows more padding/line height could probably be a a typographical approach to the problem. FjtDo (talk) 20:14, 11 August 2008 (UTC)
Release types color
I think it should have the option to display the color in the headline according to the type of the release using Template:Infobox Album/color (for a single) something like this:
<table {{#ifeq: {{{collapsed}}}|yes|class="collapsible collapsed"}} cellpadding="0" style="width: 100%;border-width: 0px; border-collapse: collapse;">
{{ #if: {{{headline|}}} |
<tr>
<th colspan="10" style="text-align: left; background-color: #fff; border-width: 0;">
{{{headline}}}</th>
</tr> |
{{#ifeq: {{{collapsed}}}|yes|
<tr>
<th colspan="10" style="text-align: left; background-color: {{Infobox Album/color|single}}; border-width: 0;"> </th>
</tr>
}}
}}
<tr>
<th style="width: 20px; padding-left: 10px; padding-right: 10px; text-align: right; background-color: {{Infobox Album/color|single}};">#</th>
<th style="{{#switch: {{#expr: 0 + ({{#ifeq: {{{lyrics_credits}}}|yes|1|0}} + {{#ifeq: {{{music_credits}}}|yes|1|0}} + {{#ifeq: {{{writing_credits}}}|yes|1|0}} + {{#if: {{{extra_column|}}}|1|0}}) }} | 0 = width: 100%; | 1 = width: 60%; | 2 = width: 40%; | 3 = width: 30%; | 4 = width: 20%;}} text-align: left; background-color: {{Infobox Album/color|single}};">Title</th>{{ #ifeq: {{{lyrics_credits}}}|yes|<th style="{{#switch: {{#expr: ({{#ifeq: {{{lyrics_credits}}}|yes|1|0}} + {{#ifeq: {{{music_credits}}}|yes|1|0}} + {{#ifeq: {{{writing_credits}}}|yes|1|0}} + {{#if: {{{extra_column|}}}|1|0}}) }} | 1 = width: 40%; | 2 = width: 30%; | 3 = width: 20%; | 4 = width: 20%;}} text-align: left; background-color: {{Infobox Album/color|single}};">Lyrics</th>}}{{ #ifeq: {{{music_credits}}}|yes|<th style="{{#switch: {{#expr: ({{#ifeq: {{{lyrics_credits}}}|yes|1|0}} + {{#ifeq: {{{music_credits}}}|yes|1|0}} + {{#ifeq: {{{writing_credits}}}|yes|1|0}} + {{#if: {{{extra_column|}}}|1|0}}) }} | 1 = width: 40%; | 2 = width: 30%; | 3 = width: 20%; | 4 = width: 20%;}} text-align: left; background-color: {{Infobox Album/color|single}};">Music</th>}}{{ #ifeq: {{{writing_credits}}}|yes|<th style="{{#switch: {{#expr: ({{#ifeq: {{{lyrics_credits}}}|yes|1|0}} + {{#ifeq: {{{music_credits}}}|yes|1|0}} + {{#ifeq: {{{writing_credits}}}|yes|1|0}} + {{#if: {{{extra_column|}}}|1|0}}) }} | 1 = width: 40%; | 2 = width: 30%; | 3 = width: 20%; | 4 = width: 20%;}} text-align: left; background-color: {{Infobox Album/color|single}};">Writer(s)</th>}}{{ #if: {{{extra_column|}}}|<th style="{{#switch: {{#expr: ({{#ifeq: {{{lyrics_credits}}}|yes|1|0}} + {{#ifeq: {{{music_credits}}}|yes|1|0}} + {{#ifeq: {{{writing_credits}}}|yes|1|0}} + {{#if: {{{extra_column|}}}|1|0}}) }} | 1 = width: 40%; | 2 = width: 30%; | 3 = width: 20%; | 4 = width: 20%;}} text-align: left; background-color: {{Infobox Album/color|single}};">{{{extra_column}}}</th>}}
<th style="width: 60px; padding-right: 10px; text-align: right; background-color: {{Infobox Album/color|single}};">Length</th>
</tr>
{{Tracklist/Track|color=#fff|1|{{{title1|song}}}|}}
</table>
danBLOO (talk) 22:19, 15 August 2008 (UTC)
- Why would we require redundant color-coding of releases? – Cyrus XIII (talk) 22:16, 22 August 2008 (UTC)
- I think it's appropriate... - danBLOO (talk) 22:26, 22 August 2008 (UTC)
- If there is already a color present in the infobox, it would seem a bit excessive to spread it to other areas. That also adds a field to the template that is just ripe for error, in which case the color of the infobox and the track list will clash strongly. --Jacob Talk 01:33, 23 August 2008 (UTC)
- But it would be helpful for track listings used on artists' wikis when a single wiki for the release is not worth, or articles sharing different types of releases (like "All of Your Love" and Sanalejo - on the esWiki because I couldn't find something alike on the enWiki). --danBLOO (talk) 02:25, 23 August 2008 (UTC)
- I also see it as redundant. Most, if not all, articles do not need it and if it were an optional thing some editors would insist on having it in every article where it's not needed. = ∫tc 5th Eye 03:03, 23 August 2008 (UTC)
- Okay, it was just a suggestion... it's not up to me take the final decision... anyway, I still think it would be useful. --danBLOO (talk) 03:43, 23 August 2008 (UTC)
A few suggestions...
Here are some idea that I think should be added to the template so it can be used in more articles. I'd help make these changes myself, but the syntax just seems to complicated to me.
- Create an "Artist" column for usage on soundtracks, compilations, or other albums where multiple artists appear. I think the "extra column" is too far away from the "title" column to be used as "Artist."
- Create a parameter for parenthesis next to the title (in addition to the "info" column) for song versions, such as "Radio Edit", "Remix", "Single Version", "Live", etc. The "info" column text is too small, plus it may still be used in addition to a "version" parameter. The version of the song should not be within the song's quotes - ex: "Last Night on Earth" (Live from Mexico City), NOT "Last Night on Earth (Live from Mexico City)".
- Make the "time" column optional. This would be useful for albums whose tracklists have been released, but their times are not yet known, and its also good for usage with music film releases, such as live concerts, where the length of the track is not necessarily relevant.
–Dream out loud (talk) 02:22, 1 September 2008 (UTC)
- Your second point: That's what the "note" parameter is for, isn't it? = ∫tc 5th Eye 02:24, 1 September 2008 (UTC)
- Well it could be used for it, but that "note" parameter is used for so many other things that I think an additional column should be added. The "note" parameter is also used for alternate writing credits, the song's original album (if on a compilation), among other things, and you can't really put more than one thing in there. –Dream out loud (talk) 15:57, 1 September 2008 (UTC)
- I took the liberty of converting your bulleted list into a numbered list so it is easier for us to refer to the items; hope you don't mind. I support (1) and (3), I can see the need and what you propose sounds to me like good solutions. However I won't give an opinion on (2) as I haven't used the template enough to decide if the "info" column is sufficient. Can you think of an example where you would use both the "version" and the "info" columns at the same time? – IbLeo (talk) 16:41, 1 September 2008 (UTC)
- Yes, in the tracklisting for Miss Sarajevo, I wanted to include the text "(single edit)" along with the title, and "(featuring Luciano Pavarotti)" next to it. This is a case where both are needed - one to display the version, and another to display the guest. –Dream out loud (talk) 16:55, 1 September 2008 (UTC)
- I agree with all your suggestions. I think that the "performer(s)" column should be preceding the "title" one; another example for "note" and "version" columns would be bonus tracks, when an especial edition of an album includes a bonus track which is just a different version of a track that is already included on the standard edition of the album... --danBLOO (talk) 19:22, 1 September 2008 (UTC)
- Yes, in the tracklisting for Miss Sarajevo, I wanted to include the text "(single edit)" along with the title, and "(featuring Luciano Pavarotti)" next to it. This is a case where both are needed - one to display the version, and another to display the guest. –Dream out loud (talk) 16:55, 1 September 2008 (UTC)
- I took the liberty of converting your bulleted list into a numbered list so it is easier for us to refer to the items; hope you don't mind. I support (1) and (3), I can see the need and what you propose sounds to me like good solutions. However I won't give an opinion on (2) as I haven't used the template enough to decide if the "info" column is sufficient. Can you think of an example where you would use both the "version" and the "info" columns at the same time? – IbLeo (talk) 16:41, 1 September 2008 (UTC)
- Well it could be used for it, but that "note" parameter is used for so many other things that I think an additional column should be added. The "note" parameter is also used for alternate writing credits, the song's original album (if on a compilation), among other things, and you can't really put more than one thing in there. –Dream out loud (talk) 15:57, 1 September 2008 (UTC)
- See below; all the ways I can think to exploit this template and/or cause errors in it.
←This isn't so much exploitation as it is bad editing and in practice, this would just be vandalism. Need I make a list of all of the ways I can "exploit" a Wiki page in general? In general though, you haven't used the template to do anything improper. You've used some external code to make it look a bit odd, and you've added images and false text into the fields. I do not see what you've accomplished here, other than making an ugly table. --Jacob Talk 15:49, 2 September 2008 (UTC)
Regarding parenthesis: The stuff that goes into quotes in our track listings usually reflects what is printed on the packaging of the respective release, which may already include some information in parenthesis. That's what we are quoting, obviously. So if it says
- Great Song (single edit)
on the packaging, we list it as
- "Great Song (Single Edit)"
rather than
- "Great Song" (single edit)
As far as this template is concerned, all remaining information should probably go into note or extra fields, depending on its amount and nature. With that in mind, I have updated the Miss Sarajevo article, using the record's MusicBrainz entry as reference (which might not be entirely accurate itself, but the general idea should be clear). – Cyrus XIII (talk) 16:41, 2 September 2008 (UTC)
- I can see your point on the parenthesis, but what about making the "length" column optional, and creating an "artist" column for compilation albums? I really don't think the "extra" or "note" fields should be used for the artist on a compilation. –Dream out loud (talk) 16:29, 3 October 2008 (UTC)
- The "extra" column can be used for artists on a compilation, see the Cloverfield soundtrack for an example. :-) --Jacob Talk 16:36, 3 October 2008 (UTC)
- The know that the "extra" or "notes" parameter can be used, but I still think "artists" should have its own column. The extra column is all the way on the right with other columns in between that deter its importance, and the "notes" parameter is just too small (see The Million Dollar Hotel: Music from the Motion Picture). –Dream out loud (talk) 21:40, 3 October 2008 (UTC)
- It is important to keep in mind that a good template needs to consider common requirements first before going out of its way for less likely scenarios. An optional length column would free very little extra space while adding another option for editors to consider, while lengths are about the most common bit of information about listed songs, next to titles – not really a good candidate for an optional column. Furthermore, the space between the left margin of an article and the thought line drawn by album infoboxes remains fairly limited and in order to keep the information conveyed by a list accessible, it needs to remain at least somewhat readable, hence the number of columns has to be kept at a minimum. Right now there are columns for track numbers, titles and lengths (obviously) and we've got general and lyrics/music differentiated songwriting credits, which should already suffice for 90% of the albums on Wikipedia. For everything more specific/less common (and multi-artist compilations do fall into that category) there's the notes and the extra column. – Cyrus XIII (talk) 20:41, 8 October 2008 (UTC)
- The "extra" column can be used for artists on a compilation, see the Cloverfield soundtrack for an example. :-) --Jacob Talk 16:36, 3 October 2008 (UTC)
Does this template collapse subsequent ones?
When I use this template (which is brill, I must say!), it collapses the band navbox at the bottom of the page. See H.A.A.R.P and Age of Winters for examples. Why the hell does this happen and how do I prevent it?! Andre666 (talk) 21:17, 3 October 2008 (UTC)
- Note: I did the same for The Eminem Show and it did not happen... ?! Andre666 (talk) 21:17, 3 October 2008 (UTC)
This happens if there are two templates in an article that implement the collapsible class, like most navboxes do, as well as the tracklist template, when the "collapsed" option is used. For that reason (and reader convenience), I would not use the option to hide lists with very few entries, as it was done the first two examples you listed. – Cyrus XIII (talk) 20:41, 8 October 2008 (UTC)
- Any chance this can be changed? It sucks that it collapses other templates as it looks better to hide smaller entries like bonus tracks etc. Andre666 (talk) 21:20, 8 October 2008 (UTC)
Notes
This field is by default in small font, which, having seen it used over a month or two, worries me. We have readers whose vision is such that although they can read normal-sized text, small fonts may be tricky to them; I don't think we should force them to use screen-reading software for parts that are otherwise inaccessible, nor use their browser's zoom facility in order to do so. That makes for a difficult experience for them. I've also come across examples where this field is being used instead of the "Writers" field, which again, is not what was perhaps intended. Although I like this template, and it's somewhat new, I'd prefer the "Notes" to be full-sized font, for ease of legibility, and we still have the option of embedded footnotes and references in any field. Comments welcome. --Rodhullandemu 22:48, 28 October 2008 (UTC)
- Besides vision problems, there are some of us with old monitors which don't have great resolution, or have their monitors set to a fine pixel setting, making text normally small. WP's normal font size is already close to the minimum used on most websites.
- As for the "writers" field, if the wrong parameter is being used for no apparent reason, we should be justified in changing it.
- I have also seen "music" used in place of "writers"; apparently some editors don't realize music and lyrics go together as a set. Maybe we should make that clearer in the instructions, OR change the template to use one switch to turn both on at once (or is that being too Draconian?). --A Knight Who Says Ni (talk) 23:26, 28 October 2008 (UTC)
I appreciate your concerns, though I am not really sure if this template is a good place to start address readability problems due to the use of <small> font, seeing that some of our more widely used templates (e.g. {{Infobox Musical artist}}, {{Infobox Album}}) make use of it as well. Until a wider reaching consensus and maybe a guideline on this emerges, I'd rather not sacrifice the readability gain provided by the better distinction between titles and notes for our wider audience, as per earlier discussion on this (see the archive).
As for making the use of writern and lyricsn/musicn fields mutually exclusive, I'll look into how easy it would be to accomplish from a technical perspective and if it won't encumber any rare but valid use cases (though right off the top of my head, I can think of none). – Cyrus XIII (talk) 07:45, 3 November 2008 (UTC)
- The credit columns should now be mutually exclusive, if anyone notices any misbehavior please report it here and also give me a nudge on my talk page. Note that this update does not group lyrics and music credits into one inseparable set, as there are many bands which, for example, have a single lyricist and only differentiate their credits for the music (Marilyn Manson come to mind). But now it's "Writer(s)" OR "Lyrics"/"Music", along with a more explicit documentation, which will hopefully curb down erroneous use a bit. – Cyrus XIII (talk) 12:31, 13 November 2008 (UTC)
Automatic conversion
Is there any way to convert automatically from standard format to tracklist format? I guess a regular expression won't work because of the numbers, right? Flowerparty☀ 17:18, 9 November 2008 (UTC)
- Not that I know of. It would be insanely helpful, but the crux of the default (as per WP:ALBUMS) is, that many of the track listings out there in the wild, even the simpler ones, tend to differ from the suggested syntax, due to all kinds of irregularities, like missing quotes, wrong types of dashes or extra whitespace. And of course, it gets a lot more diverse when any notes or credits are involved, so a converter would have to juggle quite a few cases and exceptions, in order to come up with some half-decent suggestions. But I'll ask FjtDo to comment on this too, he's a lot more reg-ex savvy than I am anyway. – Cyrus XIII (talk) 07:33, 10 November 2008 (UTC)
- The problem with regular expressions is that the slightest difference in the provided pattern can mess up the whole result. And if you change it to match against even wider possibilities the results will probably take even more work to clean up than building it from scratch. So doing a small script which converts perfectly written listings from the old format to the template would be possible but making it work with slight flaws (let alone table based listings with changing columns) would probably take more effort than the actual conversion by hand. FjtDo (talk) 19:50, 14 November 2008 (UTC)
template can be too wide
I was just looking at the The Platinum Collection (Queen album) article and this template runs over the infobox. Is there a way to shrink the template so it all fits? Naufana : talk 19:18, 12 November 2008 (UTC)
- No it doesn't—must be your screen resolution. Andre666 (talk) 22:40, 12 November 2008 (UTC)
- It could be your browser or its configuration; your example looks fine in Firefox. --Rodhullandemu 23:17, 12 November 2008 (UTC)
- When I shrink the window, the box shrinks along with it, so it looks okay. What is your browser, and are you using an ordinary computer (i.e. not a handheld device)? --A Knight Who Says Ni (talk) 04:39, 14 November 2008 (UTC)
Some additional features
This template is great, accept I think that it needs to include a "featured artist(s)" category and an "Artist" category. As the "extra collumn" is way too far from the track title to include these. I would help add these in myself, but I'm not that experianced. Consideration is greatly appreciated. Narcotics (talk) 19:38, 15 November 2008 (UTC)
- I presume you want "artists" for various artists albums. What is the other column for, and would it be likely to be used on most tracks, or would it be wasted space? The template's output has a fixed width that is rather limiting, so I'm not sure there is room for more large columns. --A Knight Who Says Ni (talk) 19:56, 15 November 2008 (UTC)
- a "featured artists" category for songs that are by one specific artist, but they might have a few songs with another artist guest starring.Narcotics (talk) 20:25, 15 November 2008 (UTC)
- Considering the chart's space limitations, that kind of information might be better placed in the body of the article. --A Knight Who Says Ni (talk) 20:27, 15 November 2008 (UTC)
- My understanding is that you mean a song by one artist with another featured, for example "Broken Strings" by James Morrison featuring Nelly Furtado (see Songs for You, Truths for Me). In this situation, I always simply put the featured artist's name in the notes section, making it look like the following in my example:
- Considering the chart's space limitations, that kind of information might be better placed in the body of the article. --A Knight Who Says Ni (talk) 20:27, 15 November 2008 (UTC)
- a "featured artists" category for songs that are by one specific artist, but they might have a few songs with another artist guest starring.Narcotics (talk) 20:25, 15 November 2008 (UTC)
No. | Title | Writer(s) | Length |
---|---|---|---|
5. | "Broken Strings" (feat. Nelly Furtado) | James Morrison, Fraser T. Smith, Nina Woodford | 4:10 |
- This is fine, no? Andre666 (talk) 10:07, 16 November 2008 (UTC)
I have a good example where another column is needed. From the Screen to Your Stereo Part II. What is needed to be good: title (OK); featuring artist (using "note", OK); from the movie (using "extra_column", OK); original artist (not OK). In cover albums, the original artist is very relevant information. Therefore an exclusive column would be cool. ChancerBR (talk) 02:38, 25 January 2009 (UTC)
Started expanded but collapsible?
Based on the docs, either a tracklist generated by this can either by fully expanded with no way to collapse it, or can be collapsed with a method to expand it. It would be helpful to have a version that starts expanded but can be collapsed. --MASEM 19:39, 17 November 2008 (UTC)
- Actually that's how the template started out and the collapsible function was only later restricted, the assumption being that readers would be unlikely to hide initially expanded track listings anyway. Also, every instance of a template that uses the collapsible class triggers all subsequent templates of that kind to appear collapsed from the outset. This of course is not very desirable with regard to most artist/band navboxes. What particular use cases are you looking at, where you consider a expanded but collapsible table helpful? – Cyrus XIII (talk) 10:13, 28 November 2008 (UTC)
Discussion at WP:ALBUMS
This template is currently being discussed on the talk page of WikiProject Albums. Comments are welcome. – Cyrus XIII (talk) 10:13, 28 November 2008 (UTC)
clear: right
This template was modified recently with clear: right; in its style. I doubt this was the right choice, since this pushes the tracklists to below infoboxes, etc. resulting in a huge white space on a lot of articles. What was the intention of this edit, and would anyone object to it being changed back? Adam McMaster (talk) 16:53, 28 December 2008 (UTC)
- You should have sent a notice about this question directly to User:Happy-melon who is the one who made the edit. I've done this for you. From his edit summary and your objection, it appears that both of you are seeing problems that the other is not seeing. It would be helpful for both of you to state actual articles where the template is seen as creating a problem. --A Knight Who Says Ni (talk) 17:25, 28 December 2008 (UTC)
- Thanks for the heads-up, AKWSN. this is what I see on Vista/FF3 with the old template code. Do you see the problem? I'm surprised that it never manifested itself on your browser, since the tracklist template used an absolute margin in an attempt to 'get out of the way' of infoboxes, while the infoboxes themselves are variable-width. You are correct that it produces a lot of whitespace, but this is not, IMO, a huge problem. Firstly, the change merely moves the whitespace from the right side of the box to the top; in many cases this will have reduced the height of the table and hence removed wasted space in the article. Secondly, the extra whitespace only occurs on articles that are overly short; pages such as Master of Puppets, to use an example from the top of WhatLinksHere, have enough content to move the tracklist well below the infobox. In fact having a table not full width would have looked wierd in that article and countless others. I hope this clarifies the reasoning behind my edit. Happy‑melon 17:50, 28 December 2008 (UTC)
- I've never seen that problem before (using Safari on OS X 10.5). Here's an example (original page) of a page with excessive whitespace after this change. Might it be better to make the tracklist table have a fixed width? This way we could keep it out of the way of most infoboxes, and those which are still too wide would just push the tracklist down (in the same way that clear: right; does). Adam McMaster (talk) 18:59, 28 December 2008 (UTC)
- That sounds perfect. The example you have given looks great; why doesn't this happen on all pages? Andre666 (talk) 19:27, 28 December 2008 (UTC)
- What do you mean by 'fixed width'? Px and em will both break on low-resolution monitors and handheld devices such as iPhones, causing horizontal scrolling that is a recognised Bad ThingTM. % is no better than the current solution as far as I'm aware. The issue of whether the tracklist overlaps the infobox is largely dependent on screen resolution; what works for you on one page may not work for a different user on the same page if they have differently-configured monitors. Trying to account for all configurations is not possible. Again I'd like to point out that the old template also had significant amounts of whitespace down the right hand side, the clear:right version takes up the full width which IMO looks better everywhere; the only issues are when the article has a short amount of text around a long infobox. We have here a square peg and an L-shaped hole; it is simply not possible to fit one into the other without leaving whitespace. My contention is that by taking up the lower part of the L, the whitespace can, should be and in many cases is taken up with article prose. While I know such articles are depressingly rare, the articles of which we can be proud do not have any whitespace issues at all with this change, as the text fills all the gaps. With the old code, whitespace remains. IMO, I think the real 'solution', intangible though it is, is to improve the articles where this template is used such that the whitespace goes away :D Happy‑melon 23:02, 28 December 2008 (UTC)
- I agree that getting rid of all the stubs would be a great solution :) You're right that setting the width to some fixed value could cause horizontal scrolling for some users; I hadn't thought of that. Would it be possible to add an optional parameter to the template to turn clear:right on/off and maybe one to change the right margin to accommodate larger infoboxes? So we might have a usage like
{{tracklist | clear=None | margin=300px | ... }}
Adam McMaster (talk) 23:10, 28 December 2008 (UTC)
- I agree that getting rid of all the stubs would be a great solution :) You're right that setting the width to some fixed value could cause horizontal scrolling for some users; I hadn't thought of that. Would it be possible to add an optional parameter to the template to turn clear:right on/off and maybe one to change the right margin to accommodate larger infoboxes? So we might have a usage like
- What do you mean by 'fixed width'? Px and em will both break on low-resolution monitors and handheld devices such as iPhones, causing horizontal scrolling that is a recognised Bad ThingTM. % is no better than the current solution as far as I'm aware. The issue of whether the tracklist overlaps the infobox is largely dependent on screen resolution; what works for you on one page may not work for a different user on the same page if they have differently-configured monitors. Trying to account for all configurations is not possible. Again I'd like to point out that the old template also had significant amounts of whitespace down the right hand side, the clear:right version takes up the full width which IMO looks better everywhere; the only issues are when the article has a short amount of text around a long infobox. We have here a square peg and an L-shaped hole; it is simply not possible to fit one into the other without leaving whitespace. My contention is that by taking up the lower part of the L, the whitespace can, should be and in many cases is taken up with article prose. While I know such articles are depressingly rare, the articles of which we can be proud do not have any whitespace issues at all with this change, as the text fills all the gaps. With the old code, whitespace remains. IMO, I think the real 'solution', intangible though it is, is to improve the articles where this template is used such that the whitespace goes away :D Happy‑melon 23:02, 28 December 2008 (UTC)
- That sounds perfect. The example you have given looks great; why doesn't this happen on all pages? Andre666 (talk) 19:27, 28 December 2008 (UTC)
- I've never seen that problem before (using Safari on OS X 10.5). Here's an example (original page) of a page with excessive whitespace after this change. Might it be better to make the tracklist table have a fixed width? This way we could keep it out of the way of most infoboxes, and those which are still too wide would just push the tracklist down (in the same way that clear: right; does). Adam McMaster (talk) 18:59, 28 December 2008 (UTC)
- Thanks for the heads-up, AKWSN. this is what I see on Vista/FF3 with the old template code. Do you see the problem? I'm surprised that it never manifested itself on your browser, since the tracklist template used an absolute margin in an attempt to 'get out of the way' of infoboxes, while the infoboxes themselves are variable-width. You are correct that it produces a lot of whitespace, but this is not, IMO, a huge problem. Firstly, the change merely moves the whitespace from the right side of the box to the top; in many cases this will have reduced the height of the table and hence removed wasted space in the article. Secondly, the extra whitespace only occurs on articles that are overly short; pages such as Master of Puppets, to use an example from the top of WhatLinksHere, have enough content to move the tracklist well below the infobox. In fact having a table not full width would have looked wierd in that article and countless others. I hope this clarifies the reasoning behind my edit. Happy‑melon 17:50, 28 December 2008 (UTC)
Can we undo this? It creates horrible looking excessive white spaces on both Safari and Firefox on OS X 10.5.6 Scapler (talk) 21:03, 28 December 2008 (UTC)
- And on Vista IE7. §hep • ¡Talk to me! 02:38, 29 December 2008 (UTC)
- Same on Linux with Firefox 3.0.x. Given that the issues some were observing before Happy-melon's edit were more specific (i.e. resolution and system-based) than the very general problem with the tracklist being bumped down when in the vicinity of an infobox, I have reverted it. And while stub-expansion remains an ever-appreciated task, basing template design on the hopeful future of many of the articles at hand is hardly practical. Plus I can think of a few instances were neighboring infoboxes and tracklists are unlikely to go away, regardless of article scope (e.g. Music of The Lord of the Rings film trilogy).
- This does not mean that we should stop discussing how the spacing issue could best be addressed, but I urge all editors to preview their proposals in private sandboxes, until proper consensus has been reached here. Article stability comes first. :) – Cyrus XIII (talk) 03:29, 30 December 2008 (UTC)
- I too, am having an awful time trying to remove this exact ugly white-space problem from "an article". Though the problem does not exist when viewed with Google Chrome, it does become extremely ugly when viewed with Internet Explorer (any version I've tried) @ 1024x768 resolution. See [1] (screen-capture example (cropped)). In IE, this template does not seem to allow anything to be written to its right. Anything that is supposed to appear to the right of this template (such as an infobox), appears above the template instead. The actual tracklist table is a good size... but the template it's wrapped with, consumes 100% of the editable width.
- I could probably solve this cross-browser compatibility issue using straight HTML, but figured it would likely be wise to check here first. -- WikHead (talk) 09:08, 26 February 2009 (UTC)