Template talk:Track listing/Archive 5

src: upload.wikimedia.org

Video Template talk:Track listing/Archive 5

Tools for your convenience

Text file with fields for 1-99 listed:

Google Docs format
Plain text format (downloadable)

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

Google Docs format
Excel 2003 format (downloadable, recommended)

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

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

Maps Template talk:Track listing/Archive 5

Recent change: width

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

src: blog.close.io

Proposal to auto-narrow width

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

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

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

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

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

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

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

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

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

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

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

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

--TheDJ (talk o contribs) 21:49, 2 May 2010 (UTC)

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

Templates Archives - inFlow Inventory Blog

src: www.inflowinventory.com

Automatic Track Listing Converter

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

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

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

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

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

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

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

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

{{Track listing

| title1 = Razor

| length1 = 6:48

| title2 = Over and Out

| length2 = 5:56

}}

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

Please try it out and get back to me.

It can be found here...

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

Cheers, Foofighter1337

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

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

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

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

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

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

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

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

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

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

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

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

Top 5 Marketing Mistakes You Need to Stop Making Now

src: www.behindtheshutter.com

hAudio microformat

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

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

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

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

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

src: hw1.thisamericanlife.org

Proposal to redesign table width to fit longer titles

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

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

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

See subtopics below:

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

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

Cause of over-wide tables

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

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

Those were fixed, as follows:

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

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

Impact of auto-widened tables

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

Customizing auto-widened tables

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

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

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

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

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

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

Examples of /sandbox2 to auto-widen

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

Current revision:

Proposed /sandbox2:

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

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

Firefox 3.6.4 comparison wide narrow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Migration plan for auto-widened tables

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

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

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

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

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

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

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

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

New parameter endnotes & endnotes_color

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

The endnotes (above), in markup language, spans 3 lines, as follows:

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

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

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

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

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

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

New parameter addtotal=yes

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

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

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

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

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

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

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

Proposal for limited use of 2nd Template:Tracklist_custom

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

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

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

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

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

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

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

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

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

Source of the article : Wikipedia

Senin, 12 Februari 2018