Template talk:Track listing/Archive 12

Archive 5

←

Archive 10

Archive 11

Archive 12

Archive 13

Archive 14

Archive 15

Option to hide track length

I've proposed this a couple times before, but it never seemed to go anywhere. I really think there should be an option to hide the track length column in the template. This would mainly be used for concert films where track times are not relevant. It could also be useful for albums that have not been released yet and their track times are currently unknown. –Dream out loud (talk) 19:43, 26 November 2013 (UTC)

I don't see a point to this. There's nothing wrong with displaying track times for concert films, so I don't know why you would want to hide those times, and for albums with no track times listed, the column is simply blank until someone fills in those times. MrMoustacheMM (talk) 20:06, 26 November 2013 (UTC)

Displaying track times for concert films doesn't make any sense. I've never seen any concert video release include the track times in its liner notes. Why? Because a concert film is not 100% music. There's usually an introduction, intermittent segments, band members talking to the crowd, interviews, end credits, etc. So a 60 minute concert film may only have 52 minutes of music, for example. Additionally, how does one go about getting the exact length for each song? Should someone watch the film and manually time how long a song goes from start to finish? What about for concert films that have only been released to theaters and aren't available on home video? For concert film articles that I've worked on, I just did a numbered list, simply because there's no option to hide the extra column. There's no reason not to add an extra option to hide the length column for concert films. –Dream out loud (talk) 23:36, 2 December 2013 (UTC)

In the cases that you describe, using a numbered list is the correct option, per WP:MOSALBUM#Track listing. The track listing template should not be used in such cases. MrMoustacheMM (talk) 01:46, 3 December 2013 (UTC)

Total length

Since when has this field been lumped together with the top-most fields? I remember it being one of the latter-most fields, but I could be wrong on this. For the past four years I've always put it after the length field of the final track, and it seems logical to do so since "total length" is shown after the final track outside of the editor as well. I know it doesn't matter all that much, but I'm still keen to know the background behind it. Mac Dreamstate (talk) 16:33, 15 January 2014 (UTC)

You can put it anywhere. Whether it's at the top, bottom, or 3/7ths of the way down, it will still appear in the same place in the final rendered template. MrMoustacheMM (talk) 17:40, 15 January 2014 (UTC)

Help, pls: Defeating 'collapsed' when wikilink-navigating to the inside of one

I want to wikilink from Sa_Dingding#Biography → to → Tales_of_Us#Thea (feat. Sa Dingding) (an {{Template:Anchor}} within a collapsed Template:Track_listing).

It don't seem to work as intuitively obvious (auto-opens), which is slightly WP:EASTEREGGish (as would be the lack of such a feature). Is there some knack, pls?   Ian, DjScrawl (talk) 22:30, 4 January 2014 (UTC)

There's an old vaudeville joke that basically goes

Patient: "Doctor, doctor. It hurts when I do this." (moves arm to indicate the motion).

Doctor: "Then don't that."

In other words, if you are not achieving what you want, put the anchor outside of the template. I believe that they don't take-up any horizontal space, so that should be OK. Walter Görlitz (talk) 00:55, 5 January 2014 (UTC)

The template behaviour would have to change based on what link brought you to the page. I don't think that's possible, and at a glance {{anchor}} is not meant to be used within tables. According to Help:Table#Section link or map link to a row anchor there's another method to link to specific rows of tables, but I don't know if that will un-collapse a template - I don't expect it will. Huon (talk) 00:57, 5 January 2014 (UTC)

It won't. If a link target is within a collapsed portion of a page (whether that be a table or something else), the browser will not uncollapse, and won't even take you to the top of the collapsed content - it'll take you to the top of the page.

There is nothing to prevent {{anchor}} from being used in tables, but you need to be careful where you put it. This is because {{anchor|Foo}} resolves to <span id="Foo"></span>, and the span element is valid anywhere that ordinary text is permitted, which includes the caption and cells of a table, but not those portions of a table that are outside the caption and cells. So, you can put it on a line that begins |+ (caption), and the following forms of cell are valid:

!{{tlx|anchor|Foo1}} A header cell
!style="background:white;" |{{tlx|anchor|Foo2}} A header cell with styling
|{{tlx|anchor|Foo3}} A data cell
|rowspan=2 |{{tlx|anchor|Foo4}} A data cell spanning two rows

You need to ensure that the {{anchor}} is not in that portion of the markup where we place the classes, styles etc. Thus, you can't put the {{anchor}} anywhere on lines that begin with {| (start of table) or |- (new row), and the following forms of cell are not valid:

!{{tlx|anchor|Foo1}} |A header cell
!style="background:white;" {{tlx|anchor|Foo2}} |A header cell with styling
|{{tlx|anchor|Foo3}} |A data cell
|rowspan=2 {{tlx|anchor|Foo4}} |A data cell spanning two rows

But you can do the same thing without {{anchor}}. Recall that {{anchor|Foo}} resolves to <span id="Foo"></span> - as it happens, the id= attribute is valid in any HTML element, so what we want to achieve is a cell constructed as <th id="Foo"> or <td id="Foo">. All we need to do is place the id= attribute (without using {{anchor}}) in that portion of the markup where the classes, styles etc. may be used, as follows:

{| id=FooX
|- id=FooY
!id=Foo1 |A header cell
!style="background:white;" id=Foo2 |A header cell with styling
|id=Foo3 |A data cell
|rowspan=2 id=Foo4 |A data cell spanning two rows

Anchors are indeed zero-width; but if placed on a line of their own, and are followed by a blank line, they may well have height. --Redrose64 (talk) 19:20, 5 January 2014 (UTC)

• Thanks everyone! I notice the #Collapsibility vote has gone for removal. Given the conclusions there, this was to become my vote there, or moving for some MOS that discourages collapsing with wikilinks within (or some such).   – Ian, DjScrawl (talk) 01:37, 20 January 2014 (UTC)