Template talk:Infobox album

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Albums (Rated Template-class)
WikiProject icon This template is within the scope of WikiProject Albums, an attempt at building a useful resource on recordings from a variety of genres. If you would like to participate, visit the project page, where you can join the project and/or contribute to the discussion.
 Template  This template does not require a rating on the project's quality scale.
 

is there a standardized place to put a link to the relevant musical artist's discography?[edit]

I always thought a good place to a link to the discography article for the musical artist in question would be in the little album chronology header. right now, that is just an additional link to the musical artist's article. what do you guys think? link to the discography article? wouldn't that be helpful? Tangy 303 Mamet Sauce (talk) 22:21, 29 January 2016 (UTC)

I could support that. Walter Görlitz (talk) 07:19, 31 January 2016 (UTC)

Studio parameter, take #2[edit]

I would like clarification on the format of this field, and for it to be included in the MOS for this template. Since 2008, albeit before the separate Recorded field was introduced, I have used this format:

1 January – 8 April 2014 at [Studio name] in New York City

However, recently I've been seeing something like this in the Studio field:

[Studio name], Toronto, Ontario

... or even <small> text being used for the studio. What's the deal there, and all the commas? To me it looks very awkward if the [Studio], [City], [State] format is used, rather than [Studio] in [City], [State]. Mac Dreamstate (talk) 00:55, 12 February 2016 (UTC)

Date is to go in recorded parameter. Studio should go in the studio parameter.
I have seen small setting off the city, state/province.
I have been removing if only the city, state/province is listed without a studio name. Walter Görlitz (talk) 06:19, 12 February 2016 (UTC)
Doesn't appear this question was resolved. So should it be

Abbey Road Studios, London

or

Abbey Road Studios in London?

I'm accustomed to seeing it with a comma on most album covers. As for text size, <small> should not be used where the text is already small, such as in infoboxes. Piriczki (talk) 18:31, 15 July 2016 (UTC)
Comment: Piriczki and other interested parties, there has been a discussion at Wikipedia talk:WikiProject Songs#Widespread usage of inaccessible text regarding the use of small text in infoboxes (there seems to be general agreement with you that it should not be used), and a proposal to create a bot to remove it from all affected articles. it has developed into a further discussion about what should be included in infoboxes anyway. Richard3120 (talk) 19:04, 15 July 2016 (UTC)
I've always used [Studio name], [city], [(add state or country if city not well-known)], [date]. Template:Infobox single and Template:Infobox song only have a "Recorded =" field, so it all goes on the same line. The three should be harmonized. —Ojorojo (talk) 23:22, 15 July 2016 (UTC)

You do realize that Studio = is its own parameter now, right? For live recordings, it's Venue =. The only thing that should be in the Recorded = parameter, is the recording dates. Also for the record, there's no guidance around adding the provenance of the studio or venue, so it's fair to add it. Linking should be within the WP:OVERLINK guideline. In other words, if the city is well-known, such as Los Angeles, New York, London, Paris, Berlin, etc., don't even link the city name. Linking the province or state is probably not required per that guideline. If the country is listed, don't link it at all. If three or more entries are to be used, use a list template. Based on the example, I would use

Abbey Road Studios, London

(backlinks broken for example here) and not "in London".

And for the record, if the editors at infobox song want to get with the programme, they could add the parameters, and harmonize their list requirements with this template all at the same time. Walter Görlitz (talk) 03:30, 18 July 2016 (UTC)

The Studio = and Venue = parameters were added a year and a half ago without any notice or discussion.[1] Many recent album GAs don't use them and the change wasn't picked up for the single and song infoboxes. Anyway, this type of information is better discussed in the body of the article and, like the miscellaneous parameters, inclusion in the infobox is probably unnecessary. —Ojorojo (talk) 14:16, 18 July 2016 (UTC)
Relying on feature articles to determine if something is done right is not appropriate. There is no criteria to determine if all infoboxes are used correctly according to the current documentation. This isn't miscellaneous information, the venue of a live recording is usually central to the album. Similarly, the studios can make a difference, particularly prior to the 1990s. I agree that it should be discussed in the article, summarizing it the infobox is not inappropriate. Walter Görlitz (talk) 14:24, 18 July 2016 (UTC)
Hmm, I'd wondered where that Studio parameter suddenly appeared from, a year or two back. I agree (Ojorojo) that it's been introduced incorrectly, without due discussion let alone consensus, but then that same reluctance to involve other editors has governed other changes to album- and song-related templates to various degrees, I've found. I agree with Walter on this issue, though. The studio or live venue is important enough to warrant a separate field in the infobox. In the same way, we wouldn't/don't lump a record label in with the release date – i.e. "Released = 9 June 1978, Rolling Stones Records". JG66 (talk) 02:47, 25 July 2016 (UTC)
  • Support commas — You wouldn't write that a movie was filmed at "Hollywood in California". Also, the studio/venue parameter is essential.--Ilovetopaint (talk) 16:28, 20 July 2016 (UTC)
  • Support commas, but absolutely no text for any infobox parameters. Mac Dreamstate (talk) 17:16, 20 July 2016 (UTC)
  • Support prepositions (i.e. "in", "and"), not just commas - @Ilovetopaint:, of course you wouldn't say "Hollywood in California", but you would say "The Record Plant in Hollywood, California". There shouldn't be a final word on this. Some articles would benefit from listing out several studios located in the same city and using both commas and prepositions such as "in" or "and". How can you not see where that approach might be more conducive? If we used only a comma, readers could mistake the city of a studio as a separate recording location (eg. "Quad Recording Studios, Platinum Sound Studios, New York", the latter possibly suggesting "someplace in New York"). Dan56 (talk) 14:49, 24 July 2016 (UTC)
The studio parameter calls for the name of the studio, not the city in which it was recorded. If an album was recorded at some unknown place in New York, we wouldn't use "Studio = New York City". The city named following the studio is obviously the location of the studio. I don't see anywhere else where prose is necessary or used in an infobox summary. Piriczki (talk) 18:39, 24 July 2016 (UTC)
Perhaps it's obvious if the city is New York. But what if it's "Caribbean Sound Basin" (which is a studio, but you could see how it could be mistaken for another kind of location, right??) Also, the name of a studio constitutes "prose", so what you're really proposing is banning the use of prepositions, which I don't see the harm of using in an infobox. If commas are being used to separate studios in a list, it's confusing when the last item will be the name of a city; you're putting the burden on the reader to make the connection, that it's not another item in the list but the location for all listed studios. I really don't see the harm in allowing what minimal use of prepositions like "in" or "and" would be warranted by this parameter. Studio names, city names, two-letter prepositions... these are all words. Is there some benefit of reader accessibility regarding commas I'm overlooking? Dan56 (talk) 23:20, 24 July 2016 (UTC)
There is no article for "Caribbean Sound Basin" and only five articles mention it. Are we to add "in" to every album infobox based on that? And wouldn't "Studio = Caribbean Sound Basin, Trinidad" suffice in those articles? Piriczki (talk) 23:54, 24 July 2016 (UTC)
You're being awfully reductive. That was just an example. And no one's forcing you or anyone else to add anything you don't want, but if I want to at an article I'm contributing to, I will exercise this preference, whose harm or disadvantage you have yet to explain. Dan56 (talk) 00:49, 25 July 2016 (UTC)
  • Support prepositions. Scratch my earlier vote—I've been swayed back to my original preference of "[Studio] in [City]", or "[Studio] and [Studio] in [Same city]; [Studio] in [Different city]". No need for country or state, and I have some weird aversion (or even revulsion) towards consecutive commas. Mac Dreamstate (talk) 00:57, 25 July 2016 (UTC)
  • Support commas (and other forms of punctuation if necessary). I agree that one-size-fits-all won't work, and anyway it's about presenting details on a specific album (or song) clearly and correctly. I think all infobox text should be concise, abrupt, just like items presented in a table. For albums recorded in several locations, I'd go for something like: Island Studio, London; Musicland Studios, Munich; Sound Recording Studios, Los Angeles – introducing semicolons to clarify the location of each studio, as one would in prose in main text to differentiate between items in a list. If there are a number of studios in the same city, then: Studio Olympic Sound Studios, Island Studio, Morgan Studios (all London); Musicland Studios, Munich; Sound Recording Studios, Los Angeles. I appreciate that the dots in the list templates would probably remove the need for semicolons in those examples, although I'm really not familiar with the templates. JG66 (talk) 03:27, 25 July 2016 (UTC)
Bulleted flatlist for multiple studios/locations sounds good to me. It's already in place for genres. Mac Dreamstate (talk) 13:51, 25 July 2016 (UTC)
JG66 sums it up well and using {{flatlist}} lessens the need for extra punctuation. However, listing all studios where there are several overwhelms other infobox fields. In some cases, "various locations" may present a more balanced appearance. —Ojorojo (talk) 14:55, 25 July 2016 (UTC)
Wow, that's quite a list at Led Zeppelin II (10 studios for 9 songs!). I struggle with the idea of "various locations", though; I've seen it used in one or two articles, but it's (by definition) so noncommittal – I mean, it's non-information. If the length is an issue, I'd be looking to remove the word "Studio" and lessen the load that way. So, taking the examples I gave above, "Studio = Olympic, Island and Morgan studios, London; …" might be the way to go. JG66 (talk) 02:04, 26 July 2016 (UTC)
I'm confused. Template:Infobox album#Genre still says to delineate genres using commas, which I personally would prefer to bullets, since you don't usually see bullets used to separate items in a list. Dan56 (talk) 00:23, 26 July 2016 (UTC)
I think I saw a guideline somewhere else (maybe one of the general MOS'es) which essentially read like it was designed to "override" the usage of that parameter. There's a fair amount of seemingly outdated stuff in there, though; e.g., the part about linking producers doesn't adhere to WP:OVERLINK. Mac Dreamstate (talk) 00:38, 26 July 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Back to the original question, is it "Abbey Road Studios, London" or "Abbey Road Studios in London"? I count five editors in favor of commas (Walter Gorlitz, Piriczki, Ilovetopaint, JG66, Ojorojo) and two opposed (MacDreamstate, Dan56). Is there consensus or not? Piriczki (talk) 19:10, 26 July 2016 (UTC)

Why don't you just open an RfC at the article you really want some so-called "consensus" to put our edit war to rest? ([2], [3], [4], [5]) Dan56 (talk) 10:13, 27 July 2016 (UTC)
Piriczki: well yes, the numbers certainly tell that story, but it might be an idea to invite more editors here than the few of us who have weighed in so far. My suggestion would be to open an RfC on this page and post a notification at WP Albums. (I mean, the issue's hardly related to one album article – which is why the discussion started here, surely.) JG66 (talk) 07:13, 2 August 2016 (UTC)
@JG66:, my point was there shouldn't be an overarching rule on this but something that can be decided case-by-case; I don't believe "[studio], [city]" would benefit every single article (or that outlawing the use of prepositions such as "in" or "and" makes sense), and the use of commas conflicts with what's being discussed below. Dan56 (talk) 00:51, 5 August 2016 (UTC)
Jeez, Dan. You're sounding reasonable enough there, but in practice, letting things "be decided case-by-case" just means you'll get your way every time. Simply because you refuse to budge an inch on any issue or let other editors' judgement hold sway! (I'm not trying to have a go at you – it's a very unfortunate situation for everyone, I find.) If consensus was with your view on this, you'd be pushing to have it set in stone in the guidelines/documentation, and policing it rigorously across the encyclopaedia no doubt. Instead, you're wanting things left nice and loose.
On the point of "in": most people here disagree, and it's not unreasonable to think that the purpose of these discussions is to gain consensus on, at least, a general, consistent approach. As the only other respondent as that Parallel Lines RfC, Martin de la Iglesia, implies, doesn't this discussion provide the answer to the RfC there … Even given what you say about "[studio], [city]" not being used for every single article, I struggle with your rationale in that first link above, to Piriczki, that a reader might mistake "Record Plant, New York City" for "Record Plant and somewhere in New York". Because: a) if the latter were the intended meaning, then surely the text would read "Record Plant, undisclosed New York studio" (or something similar); and b) if anyone misreads "Record Plant, New York City" as you say they might, well, they probably won't have a prayer with anything in the article, in which case they'd best quit altogether. You made a similar change in a Who album article I watch: do you really think "in" is needed there when (quite rightly, imo) you've used semicolons to separate the three city locations? I mean, without the "in"s, no one's going to parse that information as "IBC Studios, Pye Studios, De Lane Lea Studios, CBS Studios, Kingsway Studios, somewhere [else] in London; Talentmasters Studios, somewhere [else] in New York; Gold Star Studios, somewhere [else] in Los Angeles". JG66 (talk) 05:08, 5 August 2016 (UTC)

@JG66:, if you cant see how there would be cases where prepositions would be more useful than strictly punctuation, then you clearly lack imagination. Dan56 (talk) 20:15, 7 August 2016 (UTC)

  • Support commas – Seems the most logical for me. For multiple studios, I would use {{plainlist}} rather than {{flatlist}}, so it's one per line. They are usually already long enough to almost take up a line, unlike something like genres. nyuszika7h (talk) 08:55, 5 August 2016 (UTC)

Consistency with recording dates?[edit]

@Nyuszika7h:, @Piriczki:, @Walter Görlitz:, @Ojorojo:, should prepositions also be avoided when listing several recording dates? Think of cases where punctuation and prepositions would benefit the layout in infobox parameters like "Recorded": September 1, 2, and 5, 1971 at Electric Lady Studios in New York; October 5, 1973, and January 1, 1974, at the Record Plant in Los Angeles (for example). This isn't uncommon, and it's ridiculous to limit editors to punctuation. Consider Big Fun (Miles Davis album): "Columbia Studios B and E, New York" (emphasis added). Should "and" be removed and the line be rewritten as "Columbia Studio B, Columbia Studio E, New York"? Furthermore, New York isn't a studio, yet it's being listed like one. This effort to ban prepositions strikes me as misguided minimalism; they can only help. Dan56 (talk) 20:23, 7 August 2016 (UTC)

Doesn't anyone think seeing three or four studios listed consecutively, and then the name of a major city, would throw readers off a bit? The preposition "in" would only make it less jarring. Dan56 (talk) 21:53, 7 August 2016 (UTC)
Prepositions should not be used at all in relation to a recording studio. The studio should be listed, with the city next to each recording studio.
-- Walter Görlitz (talk) 22:26, 7 August 2016 (UTC)
You completely sidestepped what I had written. Dan56 (talk) 02:27, 8 August 2016 (UTC)
No I didn't. I said that my opinion is that they should not be used at all. Ever. Nothing you can say will change my mind that a preposition will make summarizing studios in an infobox necessary. If something is needed to make it less jarring in the way of additional prose, it should be in the prose section not the infobox. Walter Görlitz (talk) 14:15, 11 August 2016 (UTC)
When you don't engage someone's argument and just spout declamatory statements about what should be, then you sidestep what I wrote. Furthermore, I don't see anything at MOS:IBOX about infoboxes needing to be devoid of prepositions. Dan56 (talk) 02:39, 27 August 2016 (UTC)

Harmonization with other music templates[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

  • Closing discussion The consensus is Support for harmonizing the templates. The guideline already used in Template:Infobox musical artist will be added to the relevant music templates:

[Entries in field] should be separated by using commas, {{flatlist}} or {{hlist}}.[1]

[1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

Whether commas should be eliminated altogether or class = be added is not part of this proposal and needs to be discussed separately. —Ojorojo (talk) 14:34, 8 August 2016 (UTC)

Proposal[edit]

Several music infobox templates have the same parameters, but different explanations/guidelines. For example, "Genre":

These should be harmonized, along with other common parameters including "Label", "Producer", "Format", and "Writer". (Infoboxes single and song specify {{Plainlist}} for "Recorded", probably because they don't have separate date and "Venue" and "Studio" parameters; these can be changed when added). The standard parameter guideline with explanatory footnote used in Infobox musical artist should cover all:

[Entries in field] should be separated by using commas, {{flatlist}} or {{hlist}}.[1]

[1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

Are there any objections to adding this? —Ojorojo (talk) 15:57, 26 July 2016 (UTC)

  • Oppose Have those other templates harmonize with this one as this is correct. Walter Görlitz (talk) 06:33, 27 July 2016 (UTC)
    • You do realize that Producer = allows for the optional use of {{flatlist}}, right? This was added over three years ago [6] and is consistent with MOS:HLIST. This option is used in many album GAs, including for Genre = and Label =; adding it here and harmonizing with other infobox guidelines just adopts accepted practice. One's personal preference does not make it "correct". —Ojorojo (talk) 14:16, 28 July 2016 (UTC)
      • I assume this comment was directed at me. Yes. All fields where a list could be present could use a comma separated values or list templates. Walter Görlitz (talk) 05:09, 29 July 2016 (UTC)
    • No, it is not correct, you know full well that consensus on this has gone against you in other discussions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 2 August 2016 (UTC)
      • Sorry Andy. The consensus is simply wrong. No proof that all screen readers make use of this has ever been provided. So I don't care what lies have been told in other discussions and what errors in logic have been made, the consensus here is clear. Walter Görlitz (talk) 05:23, 3 August 2016 (UTC)
      • And for the record, I comply with the misguided consensus, I can explain it as is evidenced below, but recognize that it has no empirical support and I will continue to disagree with its implementation at every turn until either I am provided with empirical evidence, until I'm dead in my grave, or all those who support it are. Walter Görlitz (talk) 05:28, 3 August 2016 (UTC)
        • It's impossible to supply empirical evidence to someone who doesn't believe the evidence presented. Nevertheless, This 2015 WebAIM survey shows the screen readers commonly used. Both Graham87 and I have told you how JAWS normally behaves when reading a list and you can read for yourself about its ability to navigate through a list item-by-item. NVDA is free and you can check for yourself or read how to navigate through a list. VoiceOver doesn't work so simply as you have to put it into 'word' mode during list navigation. Windows-Eyes uses 'S' and 'Shift-S' to go back and forth between items in a list. I'm sorry I can't provide proof that all screen readers make use of lists, but I can say with certainty that the bulk of screen readers in common use enjoy some benefit from list markup. --RexxS (talk) 14:18, 3 August 2016 (UTC)
          • Thanks. It's not impossible. I am simply asking for a survey of screen readers that shows whether or not the formatting makes a different. So you can show me all the lists of most popular tools, but all I have ever seen is a single, anecdotal report that it works better for one user who happens to use JAWS. Walter Görlitz (talk) 12:32, 4 August 2016 (UTC)
            • Thank you, Walter, that's clearer to me now. I agree I haven't found a survey of screen reader users that discusses the exact question of whether having lists marked up in list format makes a difference to the listener. What I can show you is merely that the list formatting allows all the major screen readers to navigate directly to a list (if they wish to revisit the information), and that it allows all the major screen readers to move forwards and backwards through a list (perhaps to rehearse earlier items in a longer list). What Graham87 has done is to relate that one user of a screen reader finds it improves the experience for him, not in a dramatic way, but as one of many small improvements that semantic markup makes to his everyday use of screen readers. I've no reason to suspect that Graham's experience is atypical, so I draw the conclusion that having extra abilities to find and navigate though lists is an improvement for most screen reader users. Conversely, what I've yet to see is the smallest hint of evidence that semantic markup worsens that experience for the visually impaired or even that it has no effect at all. --RexxS (talk) 17:02, 4 August 2016 (UTC)
  • Support {{flatlist}} in studio, genre and producer fields. Mac Dreamstate (talk) 14:30, 28 July 2016 (UTC)
  • Support, but also convert appropriate parameters to hlist and plainlist classes — then we won't have to bother with any templates. This has already been done (with hlist) at {{Infobox music genre}} and {{Infobox song}}. Commas can still be a valid option.--Ilovetopaint (talk) 09:48, 30 July 2016 (UTC)
  • Oppose Not a fan of "flatlists"/"bulleted lists"/whatever, believe they look grammatically foreign to most readers (as opposed to a comma), and their benefits have yet to be explained to me. Dan56 (talk) 16:14, 30 July 2016 (UTC)
    • The benefits are that they insert invisible formatting that can be used to programmatically parse the information into chunks. This makes it easier to digest for "partners" of Wikipedia to format data grabs into correct chunks. This also makes it easier for blind users who utilize screen readers—and I'm still waiting for that list of screen readers and their market penetration to confirm this—so that the items can be separated correctly. I'm not a fan of them either, but I understand how they may benefit some constituents. Walter Görlitz (talk) 19:43, 30 July 2016 (UTC)
      • That's too technical/unclear to me; "invisible formatting", "programmatically parse", "data grabs ... chunks"... I'm not even sure what screen readers are lol. Dan56 (talk) 04:51, 31 July 2016 (UTC)
        • Support A screen reader is a type of software that reads the written content of your computer screen aloud or forwards it to a braille device, so if you're blind you don't have to read it yourself but can still. Apart from the technical benefits we should have a standardised/harmonised output among related types of infoxes. De728631 (talk) 19:56, 31 July 2016 (UTC)
          • Please clarify - So if commas are used instead, the screen reader will misread the listed items? Dan56 (talk) 02:35, 2 August 2016 (UTC)
            • So programmatically parse means that a software tool can more easily interpret the information. If you were to perform an Internet search for A Night at the Opera, The Joshua Tree or The Woman in Me, you would see a summary on the right-hand side of the search. A Google employee did not spend time reading the article, a Google employee wrote a program to "read" the article and extract salient information out of the article. That information is placed into a database for quick retrieval.
            • Using the formatting provided by these lists makes it easier to correctly parse chunks of information by any program or even by a human. If the value had a comma in it, and the list were comma separated, it could be confusion. If a big, ugly bullet was placed so you could see it, the confusion would be eliminated. The programs don't see the bullets. They see special computer code. It's still not clear that all screen readers use the special HTML formatting though, but one frequent editor who uses a screen reader assures us that his does. Walter Görlitz (talk) 05:02, 2 August 2016 (UTC)
              • Interesting, @Walter Görlitz:, but then tell me, why aren't bulleted lists used elsewhere, such as in the rest of the article, in the body, the prose, etc.? Why are editors only using them in infoboxes, track listings and other templated tables? Shouldn't an article be consistent in style and use one way of separating listed items wherever items are listed ? Dan56 (talk) 22:58, 2 August 2016 (UTC)
                • I'm not Walter, but perhaps I can cast some light on the issue. Vertical bulleted lists are used commonly in article text (using * and # wikimarkup), which is suitable for longer items; but when each list item is short, the convention for prose is to display them inline with commas to separate them, as we all are used to. That's not too bad for a screen reader, but not as good as it could be. Because we are not writing a paper encyclopedia, we can now take advantage of the technology to introduce hidden markup that enhances the text. A horizontal list is an obvious example and hlist was originally conceived to improve the way that the navigational templates at the bottom of many articles were presented. They used a mid-dot (·) as a separator, but it was soon realised that screen readers read it as a single piece of text and vocalised the dots: "item one, dot, item two, dot, etc." and so we found a way of turning the horizontal list into a real list, analogous to the vertical list. In that sense it's more consistent than text with commas in it. It's understandable that some sighted readers don't like the look of the dots used in hlist (although screen readers don't see them, just as they don't see the bullets in a vertical list), so I'd suggest that you might want to lobby Mediawiki talk:Common.css to introduce a new class for horizontal lists that used a comma instead of the dot. There's an example of a class called "cslist" that does just that in my User:RexxS/common.css. --RexxS (talk) 23:55, 2 August 2016 (UTC)
        • Comment [Diary of a fence-sitter]. I've been umming and ahing about this for ages. I'm certainly pro the idea of a harmonised approach to Song, Single and Album infoboxes (not just on the issue of list formatting, but also re inclusion of the certification field and anything else we've been discussing in the thread above.) But I don't like the look of the bullets at all, either, and I think there's a tendency for editors to assume that because someone's come up with a template, it simply has to be used. If we can be sure that {{flatlist}} and {{hlist}} offer a genuine benefit to visually impaired/blind readers, though, I'll swallow my natural aversion and support this. JG66 (talk) 06:42, 2 August 2016 (UTC)
  • Comment Wikipedia:Manual of Style/Accessibility is a guideline "primarily intended to assist those with disabilities". As part of its stated attempt to comply with access standards, it includes under "Horizontal lists": "For lists running across the page, and in single rows in infoboxes and other tables, the templates {{flatlist}} and {{hlist}} ("h[orizontal]list") are available to improve accessibility" (emphasis added). Some editors here question whether this provides the intended benefit (at the expense of a normal appearance). It would be helpful to hear from those more familiar with accessibility issues, so a note has been added on the MOS:ACCESS and WP:WPACCESS talk pages about this discussion. —Ojorojo (talk) 13:15, 2 August 2016 (UTC)
    • Perfect, that's a great idea. JG66 (talk) 13:23, 2 August 2016 (UTC)
  • Comment – It's definitely possible to make an accessible list and use comma as separator instead of the bullets (personally I don't have a problem with them, but not everyone likes them). See here for a demonstration. nyuszika7h (talk) 13:53, 2 August 2016 (UTC)
  • Support the use of list templates. We've had past clarification from users of assistive software that this is beneficial to them; and it confirms with ISO standards for web accessibility (not to mention the HTML standard). We don't need to trouble the same people to confirm this for every template affected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:11, 2 August 2016 (UTC)
  • Support the use of list markup, for accessibility reasons. Whether that list is formatted using {{flatlist}} {{plainlist}} {{hlist}} etc. is largely presentational, the important thing is that lists should be semantically marked up as such. --Redrose64 (talk) 14:56, 2 August 2016 (UTC)
  • Support: Where a horizontal list has only two or three items, I don't believe a screen reader user will be too bothered that the whole list gets read out in one go. For a large list, the ability to pause after each item and even go back to the previous item with a single keystroke starts to become a useful convenience for those using the common screen readers. There is also the benefit of disambiguating between two possible readings of Producer: John Smith, Boyband, which may actually be two items, John Smith and Boyband, or which may be a single item, John Smith (i.e. the John Smith who is a member of Boyband). Semanitic markup such as hlist would indicate whether there were two items or just one. --RexxS (talk) 20:30, 2 August 2016 (UTC)
  • Possible compromise Since some editors prefer commas to dots and the benefit of list templates for two or three items is small, maybe the parameter guidance could be standardized as follows:

For two or three [field entries], use commas for separation. For four or more, use {{flatlist}} or {{hlist}}.[1]

[1] For short horizontal lists of two or three items, comma separators are acceptable, but for longer lists the use of {{flatlist}} or {{hlist}} is preferred as they offer a benefit to users of screen readers. Vertical lists should always be implemented by {{plainlist}} or {{ubl}} and never by <br /> tags for reasons of accessibility.

The majority of infobox fields would use commas (most have 3 or less items), but accessibility would still be provided for longer lists. This appears to work with "class = hlist" already used in Infobox song. Thoughts? —Ojorojo (talk) 15:10, 3 August 2016 (UTC)
I'd prefer to give editors the option - as suggested by the original poster - of either using commas or {{hlist}}, etc. in short lists. Some editors may prefer to use the same format for short lists as for longer lists and see it as a consistency issue; otherwise an infobox might end up with different formats in different fields. Does it really improve an article to have a list of three labels using commas right next to a list of four producers using {{hlist}}? --RexxS (talk) 16:30, 3 August 2016 (UTC)
I've seen it mixed, but yes, it may look odd to some. —Ojorojo (talk) 18:24, 3 August 2016 (UTC)
  • Necessity of templates Again, why do we need to bother with {{hlist}}, {{flatlist}}, {{plainlist}}, or {{ubl}}? Apply the classes and there will be no need to clarify between {{ubl}} and {{hlist}}.--Ilovetopaint (talk) 16:31, 5 August 2016 (UTC)
It needs to be clarified whether commas will work with class =, since some want the option. —Ojorojo (talk) 18:41, 5 August 2016 (UTC)
  • Agree with middots We need to use ISO standardized punctuation for list items like this. Mid-sentence, a comma is appropriate but in list-readable formats like this, use a middot (with or without a template to generate it). —Justin (koavf)TCM 18:20, 5 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Consistency with recording dates?[edit]

Should middots also be used in place of commas that are in Americanized recording dates ([month] [day] [comma] [year])? Think of cases where punctuation and prepositions would benefit the layout in infobox parameters like "Recorded" and "Studio". September 1, 2, and 5, 1971; October 5, 1973, for example. Dan56 (talk) 20:16, 7 August 2016 (UTC)

Last album and next album fields don't work[edit]

In the Last album and Next album fields, the entry in the "This album" doesn't appear on the reader's unless you specify blank entries such as "". Please sort it out. You can see my point in this edit. Jodosma (talk) 18:51, 18 May 2016 (UTC)

It's been like that for years—as long as I can remember, or 2008 to be exact. If the field for This album is the only one that applies, with no albums before or after, then I was told (many years ago, and I agreed with the editor) that the discography section becomes unnecessary until further album articles can be entered. Introducing blank entries to force This album to show up isn't the right way to go about it, as WP guidelines widely discourage hidden elements unless absolutely necessary. Mac Dreamstate (talk) 19:36, 18 May 2016 (UTC)

Why is <small> formatting allowed[edit]

It adds nothing to the presentation and many times full size is best. I had thought that <small> was deprecated – especially in infoboxes. Jodosma (talk) 18:58, 16 September 2016 (UTC)

@Jodosma: Agreed--it is bad for accessibility. —Justin (koavf)TCM 20:19, 16 September 2016 (UTC)
(edit conflict) I can't seem to find any parameter in this infobox that comes in very small script by default so I suppose you are referring to this edit? In this case I would say it does not add to the presentation and normal font size can be used. But there may be cases with long parameter entries where the font size would cause additional line breaks and make the list look cluttered, so I think there is a reason why <small><small/> is not completely ruled out. And I didn't know that it was deprecated either. De728631 (talk) 20:32, 16 September 2016 (UTC)
It's against MOS:FONTSIZE as infoboxes already have smaller font than body text by default, and using <small> will make it fall below 85%. nyuszika7h (talk) 22:38, 16 September 2016 (UTC)
<small><small/> is completely ruled out, in all circumstances: it will put the page in Category:Pages using invalid self-closed HTML tags; the correct form is <small>...</small>. As for deprecation, the HTML5 spec for the small element says thet it "represents side comments such as small print" and "Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements." The implication is that the element has a particular semantic meaning, and should not be used merely for reducing font size. --Redrose64 (talk) 08:00, 17 September 2016 (UTC)