Talk:Performances
Items links
I'm wondering whether the "[… items]" links shouldn't say "[view … items]" instead, to make it more clear at-a-glance that you need to click on them to see more information. - dcljr (talk) 17:02, 14 August 2025 (UTC)
- I don't know: That would add a lot of dead text, but is a hint any user only needs to see once. It would cause more clutter, and on mobiles more lines to break. The blue color was chosen to represent a link, so I'd expect that most users would get that without further help. I did try different versions back then, also with added +/- signs in closed/open status, but in my mind that all made it look worse. How about adding a sentence of explanation in the introduction section instead? Like "The data rows are shown after clicking/touching the number of items indications."? Also, I consider to add an option that small tables, like the setlist in the [Christmas tour 2017] article, could by default be expanded. Observing those open tables could act as a further hint that these header lines top collapsed sections. -Most2dot0 (talk) 19:35, 14 August 2025 (UTC)
Case in article titles
As you can see in this edit, I've started to change the event names in Data:Performances.json to sentence case, as opposed to title case, since those are being used as article titles in the tables, and the convention is to use sentence case for that (and section headings, too, BTW). Even though technically any title (within technical limitations) can be redirected to a preferred version, we might as well keep them as close to acceptable page titles as possible in the data itself. - dcljr (talk) 00:16, 15 August 2025 (UTC)
Repeated 'id's
The way ids are being formed in the tables is resulting in multiple instances of many of them. For example, id="Allsang_på_Grensen" appears 5 times on the rendered page (the HTML), once in the first table and 4 times in the "Events by year" table. This is not valid HTML. (There's also a blank table row in the first table, with id="". I'm pretty sure this isn't kosher, either. This is apparently being caused by char_limit1 not being specified.) Perhaps we should abandon the idea of having these three tables all on the same page, and instead put only "By event" and "By song" tables here (with the first formatted like the current first table but not limited to events that span multiple years, and the second exactly like the current third table — these can stay interlinked but with only a single target for each linked song title or event name). Then we can put tables like "Events by year" or "Songs by year", or whatever, on different pages, with the relevant sub-table links targeted to articles instead of anchors within the same page. Opinions? - dcljr (talk) 01:39, 15 August 2025 (UTC)
