Wikipedia

Wikipedia:Templates for discussion/Log/2016 May 28

< Wikipedia:Templates for discussion‎ | Log
< May 27 May 29 >

May 28 edit

Template:American Experience episodes edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was merge and remove redlinked episodes. (non-admin closure) ~ RobTalk 04:10, 15 June 2016 (UTC)[reply]

Propose merging Template:American Experience episodes with Template:American Experience.
Navbox {{American Experience episodes}} is incredibly difficult to navigate with the hidden seasons, especially as most of the articles are redlinks. Would propose a merge to {{American Experience}}, showing only "notable" (i.e. episodes with existing articles) episodes in the result. I've already removed the narrators, directors, etc, from the target given the long standing consensus not to include cast and crew in navboxes. -- Rob Sinden (talk) 15:36, 19 May 2016 (UTC)[reply]

Keep
I've restored the content to {{American Experience}} due to a failure to seek consensus for an enormous edit. And secondly, the template was nearly deleted in it's entirety by Robsinden by his edit time stamped 11:29, 19 May 2016. Posting "Longstanding consensus not to have cast and crew in navboxes" for the edit summary with no link to the "Longstanding consensus" discussion does not establish the truthfulness for this claim.
showing only "notable" (i.e. episodes with existing articles) episodes in the result
Red links are permitted per Wikipedia:NAVBOX and Wikipedia:EXISTING. Wikipedia:NAVBOX states,
"Each link should clearly be identifiable as such to our readers. In general text colors should be consistent with Wikipedia text color defaults, so links should be blue; dead links should be red; and red and blue should not be used for other (non-link) text. However, specific navbox guidelines for color of text and background other than the defaults are available."
And Wikipedia:EXISTING states,
"Red links should normally be avoided unless they are very likely to be developed into articles. Red links can be retained in navigation templates that represent a well-defined and complete set of data (geographic divisions, annual events, filmographies, etc.), where deleting red links would leave an incomplete and misleading result. Even then, editors are encouraged to write the article first."
The purpose of those templates is to link the films to the series. This template is no different than Template:The Simpsons episodes. If you are opposed to the redlinks, than please create content. I have stated the above policies Wikipedia:NAVBOX and Wikipedia:EXISTING to Robsinden recently at the following talk pages with diffs:
  1. 12:18, 18 May 2016 for Template talk:Sade
  2. 09:59, 19 May 2016 for Template talk:Civil Rights Memorial
Actually, WP:NAVBOX is a guideline, and WP:EXISTING is an essay, neither are policies. You're cherry-picking though by quoting the bit which says what colour links are to be if they are included, when actually the pertinent part of WP:NAVBOX is "a grouping of links used in multiple related articles to facilitate navigation between those articles". Although not specifically precluded, redlinks do not point to articles. A sea of redlinks hinders the reader from finding the articles they want to find. And with the switch function of this navbox, they are only finding a couple of active links each time, which is frustrating for anyone.
As far as consensus regarding cast and crew go, see Wikipedia:Templates for discussion/Log/2015 March 16#Template:James Bond film crew and related discussions. The other entries (TV network, theme song, etc) were just too tangential for inclusion. The fact is, as it stands {{American Experience episodes}} is unusable. You have to select the seasons one by one, only to find the majority of links are redlinks. This works with {{The Simpsons episodes}} where nearly every episode has a blue link, but this is not the case here. By combining the two navboxes and only including links with target articles, you help the reader navigate to existing articles, rather than a complicated navigation system that hinders the reader finding the articles. --Rob Sinden (talk) 07:54, 20 May 2016 (UTC)[reply]
@Robsinden:
You're cherry-picking though by quoting the bit
What do you call it when you do it? Everything in that Wikipedia policy is pertinent. Not only the parts you like at the exclusion of the parts you dislike.
As far as consensus regarding cast and crew go
That is a link to Template:James Bond film crew. A template dedicated solely to the film crew of James Bond. That is not a comparable comparison to this template. Nor does it reflect a consensus discussion. It's a nomination you started with two supporting deletes. You're going to need something more substantial to prove this claim.
How about I create a list article for directors and narrators? My examples are List of directors of The Simpsons and List of The Simpsons writers.
other entries (TV network, theme song, etc) were just too tangential for inclusion
The creator, executive producers, theme music composers, and related articles are too tangential for inclusion? Was there a discussion that appointed you to determine which articles are pertinent or redundant to a template? No editor makes that determination by themselves.
redlinks
I've addressed this issue numerous times as stated above. Ignoring this aspect of the policy is a personal choice.
Mitchumch (talk) 17:26, 20 May 2016 (UTC)[reply]
Yes, by all means, create a list of directors and narrators. I don't know if they would pass notability guidelines though... --Rob Sinden (talk) 09:01, 23 May 2016 (UTC)[reply]
Oh, the directors are all listed at List of American Experience episodes. That's sufficient. --Rob Sinden (talk) 09:08, 23 May 2016 (UTC)[reply]
As far as the theme song goes, this would be suitable for inclusion if it was composed for the TV series, as it is intrinsically linked to the show. However, take a look at Time Has Come Today#In other media and see how many other TV series it has been used in. And it is against standard practice to link the TV network, you can look at any other TV series navbox for this (although it might be appropriate to include the show in {{PBSTV}}). --Rob Sinden (talk) 09:07, 23 May 2016 (UTC)[reply]
Relisted to generate a more thorough discussion and clearer consensus.
Please add new comments below this notice. Thanks, ~ RobTalk 17:34, 28 May 2016 (UTC)[reply]
  • Merge per the nominator and his continued discussion with Mitchumch. Trim out the red links as the majority are unlikely ever to have an article and which certainly aren't being used to create new articles. --Izno (talk) 13:22, 31 May 2016 (UTC)[reply]
    • @Izno: Are you saying redlinks of films are unlikely to have articles? Mitchumch (talk) 15:02, 5 June 2016 (UTC)[reply]
      • No, not so broadly. I am saying these redlinks are unlikely ever to have articles, and I find it additionally likely that if someone were to create them, they would likely be merged to a list. I am also saying that the list in this navbox is not being used for article generation (at least not quickly). Rob's suggestion below is better, and I have some concerns with it from a readability standpoint, but it's on the right track. --Izno (talk) 11:37, 6 June 2016 (UTC)[reply]
  • THIS is something how it should look. --Rob Sinden (talk) 08:54, 1 June 2016 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:Paragraph break edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was Keep. This kept open to encourage discussion (and a pretty great one!) I think it's safe to close this now. ~3 days without further posts. (non-admin closure) — Andy W. (talk · ctb) 16:10, 4 June 2016 (UTC)[reply]

An unhelpful template that inserts a styled HTML div rather than a paragraph break. I last saw it used in talk-page list items; not, as claimed, in footnotes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 17 May 2016 (UTC)[reply]

  • Comment Wow, this template has been changed a lot since I created it in 2012. I'm okay with its removal if its uses can be subst'ed with something that produces the same amount of space.  — Scott • talk 17:48, 17 May 2016 (UTC)[reply]
    • Keep For the longest time I thought that I was the only one using this. That's clearly no longer the case, and good arguments are being made for its utility.  — Scott • talk 09:15, 18 May 2016 (UTC)[reply]
  • Keep I use this all the time, it's very helpful since "p" has been deprecated. I don;t see a valid argument for deleting it. BMK (talk) 19:03, 17 May 2016 (UTC)[reply]
    • "p" has been deprecated What do you mean? --Izno (talk) 20:28, 17 May 2016 (UTC)[reply]
  • Keep It avoids the use of <p> where that tag would cause an accessibility issue, see Template:Paragraph break#Purpose, also User talk:Magioladitis/Archive 21#FGM. --Redrose64 (talk) 19:22, 17 May 2016 (UTC)[reply]
    • If screen readers cannot act on paragraph markup within list items, that's honestly their problem--paragraphs from an HTML specification standpoint are allowed within list elements and should consequently be expected. --Izno (talk) 20:28, 17 May 2016 (UTC)[reply]
    • There is nothing about accessibility in Template:Paragraph break#Purpose. See also below. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 17 May 2016 (UTC)[reply]
      • What part of "can cause problems for navigation with screen readers" is not about accessibility? --Redrose64 (talk) 23:15, 17 May 2016 (UTC)[reply]
  • Keep This sounds like it could solve the accessibility issue at Supergirl (TV series)#Cast and characters and other articles following that layout. nyuszika7h (talk) 19:40, 17 May 2016 (UTC)[reply]
  • Comment: Template:Paragraph break#Purpose says "it is not possible to introduce paragraph breaks using newlines alone. For example, within a list item...."

    That's bunkum. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:10, 17 May 2016 (UTC)[reply]
    I assume your post is intended as a demonstration of "paragraph breaks using newlines alone" - but you have not used newlines, alone or otherwise; you have used two <br /> tags, which are not the same thing at all. This →

← is a newline: observe how it breaks the list structure. --Redrose64 (talk) 23:15, 17 May 2016 (UTC)[reply]

The W3C defines <br /> as "a line break". I take that to be synonymous with "newline". On the other hand, the HTML markup emitted by your comment is not a newline, but </dd></dl></li></ul><p>. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:07, 18 May 2016 (UTC)[reply]

  • The <br /> element is not necessarily synonymous in rendered effect with a newline character. See the note at [1]. MediaWiki produces different output for both, so they should be considered different in this context.  — Scott • talk 15:54, 18 May 2016 (UTC)[reply]
  • The W3C states (n.b. not "defines") "The br element represents a line break.", that is, a line break in the page as rendered by the browser. But the direction at Template:Paragraph break#Purpose is not talking about <br /> tags, but newline characters, U+000A; and moreover those that are in the Wikicode, not those in the rendered page. To demonstrate that, I put a newline U+000A into the Wikicode of my previous post, between the two arrows, in order to deliberately break the list structure. Your analysis of the emitted HTML shows that such breakage did occur: the whole list was closed. --Redrose64 (talk) 19:48, 18 May 2016 (UTC)[reply]
  • Keep. I use this a lot, after being told to stop using <p> for paragraph breaks in bundled references. By the way, on the Village Pump this discussion has caused my use of the template (in this post) to show up as "see TfD". Can someone fix that, please? SarahSV (talk) 00:44, 18 May 2016 (UTC)[reply]
    Fixed it myself. [2] SarahSV (talk) 01:24, 18 May 2016 (UTC)[reply]
    Why are you unable to use <br /> in such cases? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:09, 18 May 2016 (UTC)[reply]
    It doesn't produce the same effect. I always used <p> tags in bundled refs to produce a new line that respected the structure of the reference, but I kept being told off by a small number of technical editors who persuaded me to use {{pb}} instead. The best solution would be to fix whatever problem the <p> tag apparently causes for screenreaders. SarahSV (talk) 05:21, 19 May 2016 (UTC)[reply]
    That is not something that we can address: we have no control over how screen reader software interprets HTML tags, nor any other aspect of how they are written. --Redrose64 (talk) 12:13, 19 May 2016 (UTC)[reply]
    But it's something those who write the screenreaders can address, and they should address it. I'm sick and tired of being told we have to twist this and that backwards and upside down because some broken screenreader never gets fixed. I've been hearing such nonsense for literally years. Fix it or live with it. EEng 20:42, 22 May 2016 (UTC)[reply]
    Accessibility is not something that we can opt out of. This includes ensuring that the semantics of lists are appropriate. Nor can we direct screenreader aoftware vendors to "fix it". Please see MOS:ACCESS; WCAG; and these: Authoring Tool Accessibility Guidelines (ATAG) 2.0; Accessible Rich Internet Applications (WAI-ARIA) 1.0; WAI-ARIA 1.0 User Agent Implementation Guide; Role Attribute 1.0; Web Content Accessibility Guidelines (WCAG) 2.0; User Agent Accessibility Guidelines 1.0; Authoring Tool Accessibility Guidelines 1.0; Web Content Accessibility Guidelines 1.0. --Redrose64 (talk) 21:42, 22 May 2016 (UTC)[reply]
    No one's suggesting opting out of accessibility, nor "directing" anyone to do anything. I'm suggesting that if those who use screenreaders want to be able, well, use them, then they need to "direct" those who produce the software they're paying for to make it do whatever it needs to deal with the world the way it is. I don't care what esoteric coding goes inside the template, or its effect on lists and stuff -- if that needs to be fixed to achieve what you think accessibility demands, then you fix it -- just so long as I can code {{paragraph break}} and get a paragraph break. Or are you arguing that paragraph breaks are somehow impossible to create accessibly? EEng 00:08, 23 May 2016 (UTC)[reply]
    Nothing of the sort: my post of 12:13, 19 May 2016 was a reply to the request "fix whatever problem the <p> tag apparently causes for screenreaders". --Redrose64 (talk) 08:06, 23 May 2016 (UTC)[reply]
    Right. We can't do anything to change the way screen readers are implemented. As they're what people with visual impairments rely upon, we're obliged to build things that work with them. EEng, if you have a problem with their implementations, you need to take it up with the people that make them. It's out of our hands. And frankly, we're in a position of huge privilege here compared to those with visual impairments. So we have to fiddle with our markup a bit? Big deal. Imagine being blind and trying to read Wikipedia. That's what we're working to enable.  — Scott • talk 09:48, 23 May 2016 (UTC)[reply]
    "we're obliged to build things that work with them" -- Let's see. Suppose screenreaders were only able to read words in Basic English. Would you insist that articles restrict themselves to Basic English? If we are committed to meeting certain standards, then we should meet them, and (working from the other end) screenreaders should do the same. I'm hearing that this or that about the internals of this template cause some problem; fine, change the internals of the template to do whatever's needed. Deleting the template on accessibility grounds would make sense only if there's no way to implement a paragraph break accessibly, which is a ridiculous proposition.
    Redrose64, if you don't know by now that you can't reference a post by pasting in the timestamp you happen to see on your screen (everyone else sees different timestamps, because their timezones are different) then I'm skeptical of your competence to comment on highly technical matters. EEng 11:32, 23 May 2016 (UTC)[reply]
    "Suppose screenreaders were only able to..." They're not. "...screenreaders should do the same..." They should. Like I said, if you want that to happen, go talk to them. Until then, we work with what we've got.  — Scott • talk 11:47, 23 May 2016 (UTC)[reply]
    What the heck are you talking about? Timestamps in signatures are plain text; moreover, they have timezones, and that timezone is always UTC, because that is the server time for this project. Consider, that my most recent post here ends with "08:06, 23 May 2016 (UTC)"; the one before that "21:42, 22 May 2016 (UTC)", and so on back to "19:22, 17 May 2016 (UTC)". Here comes another timestamp, and don't tell me it's not in UTC when it plainly is: --Redrose64 (talk) 18:45, 23 May 2016 (UTC)[reply]
    Redrose64, see WP:Comments_in_Local_Time. Timestamps in signatures may be in some sense "plain text", but then so are template invocations and everything else in wikitext -- but software understands them and fiddles with them. So the post displayed to you as 12:13, 19 May 2016 is displayed to me as 8:13 am, 19 May 2016. (If you copy and paste a timestamp just right, in fact the software will convert both the original timestamp, and your reference to it, so that they match in both places it appears, but there are many ways for that to go wrong -- as it did in your attempt to refer to a timestamp -- and it's a bad idea -- the only safe way to refer to an earlier post is either via a diff or just a few keywords.) You may be unaware of this because your preferences are set for UTC, but nonetheless this shows you're willing to hold forth at length about things you really know nothing about; I'm thus skeptical of your pronouncements about standards adherence and screenreaders and so on. EEng 06:10, 25 May 2016 (UTC)[reply]
    You're blathering at length about something completely irrelevant to this discussion and insulting Redrose64 because he didn't psychically know that you're using a nonstandard gadget. You should stop talking now.  — Scott • talk 08:07, 25 May 2016 (UTC)[reply]
    Knowing how basic technical stuff (whether everyone uses it or not) works isn't paranormal, and is relevant to a discussion in which technical claims are being made on a "because I just keep saying it over and over" basis. EEng 08:29, 25 May 2016 (UTC)[reply]
    That gadget does not touch the wikitext, so when editing a page (whether you have the gadget enabled or not), the timestamp is in UTC. Knowing anything at all about what I know, other than what I have already stated, is paranormal. Don't question my intelligence, otherwise it's WP:NPA time. --Redrose64 (talk) 09:18, 25 May 2016 (UTC)[reply]
    Template expansion doesn't touch the wikitext either, so that has nothing to do with it. People wouldn't open the page for editing when reading and attempting to interpret your post, thus we're talking about what the reader sees on the rendered page. What you know is on display in this very discussion; I'm not questioning your intelligence, but you technical knowledge, which is patchy. You go ahead and have the last word now, and anyone who understands these things already sees what's going on. EEng 13:28, 25 May 2016 (UTC)[reply]
    Time for somebody uninvolved to hat this digression.  — Scott • talk 11:53, 25 May 2016 (UTC)[reply]
    As indeed someone should close this whole wrongheaded nomination. EEng 13:28, 25 May 2016 (UTC)[reply]
    It would be a good idea if the Foundation or some of the volunteer developers could contact the people who write the screenreader software and let them know about this problem. It does cause trouble on Wikipedia, yet the number of people reading references with screenreaders is likely to be very small, so it makes sense for the screenreader developers to fix the issue, rather than us trying to find ways around it. SarahSV (talk) 19:02, 23 May 2016 (UTC)[reply]
    Exactly. EEng 06:10, 25 May 2016 (UTC)[reply]
  • Proposed close: Kept. Per consensus. No plan offered for what to do with the 2271 transclusions. All deletion arguments have been addressed (though perhaps some are disputed), so it seems that it's not deprecated because it shouldn't be. Unnecessarily disruptive. --Elvey(t•c) 17:20, 19 May 2016 (UTC)[reply]
    There's no harm in letting this run, especially given the useful discussion on accessibility. If a few editors learn something about accessibility on the project from this discussion, then it will have been very productive. ~ RobTalk 20:00, 19 May 2016 (UTC)[reply]
  • Keep Very useful in addressing accessibility problems. Moreover, will all these html changes lately changing the code in a template is easier than changing html tags. I am in favour of keeping any similar template around. -- Magioladitis (talk) 20:24, 25 May 2016 (UTC)[reply]
Arbitrary break 1 edit
  • @Graham87: I wonder if you could help us out here. Do actual paragraph breaks (HTML 'p' elements) inside list items pose an issue for screen readers, and does replacing paragraph breaks with HTML 'div' elements help in that respect? Izkala (talk) 21:14, 25 May 2016 (UTC)[reply]
    • @Izkala: Yes, they do; a relatively minor one, but an issue: JAWS runs the text together if it's part of a list item and it's separated by paragraph breaks. The template under discussion fixes that, but so does the solution I proposed in my comment here. Graham87 02:19, 26 May 2016 (UTC)[reply]
      • @Graham87: Hold on, so an opening 'p' tag alone does not introduce a paragraph break, but the empty 'div' does? That sounds contrary to the template documentation, that says the aim is to prevent screen readers from jumping to paragraphs within footnotes. Izkala (talk) 09:54, 26 May 2016 (UTC)[reply]
@Graham87:, when you are using your screen reader, what difference do you experience between these two lines of text (the first with pb the second with p)?
  1. John Smith, Book Title, Publisher, 2015, p. 1.{{pb}}Susan Jones, Book Title, Publisher, 2016, p. 2.
  2. John Smith, Book Title, Publisher, 2015, p. 1.<p>Susan Jones, Book Title, Publisher, 2016, p. 2.

SarahSV (talk) 15:42, 26 May 2016 (UTC)[reply]

@SlimVirgin: I would expect not much, because you're not including the markup under discussion. Graham87, try these:
  1. John Smith, Book Title, Publisher, 2015, p. 1.
    Susan Jones, Book Title, Publisher, 2016, p. 2.
  2. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

--Redrose64 (talk) 17:10, 26 May 2016 (UTC)[reply]
Thank you for fixing that, Redrose, but I wrote it that way deliberately so that everyone is very clear about what difference is being discussed. SarahSV (talk) 17:22, 26 May 2016 (UTC)[reply]
@SlimVirgin and Redrose64: In the first set, there is indeed no real difference between the two examples; in the second one, there's an appropriate separation between the items in the first example while there is not in the second. Graham87 02:39, 27 May 2016 (UTC)[reply]
@Graham87: sorry to keep asking for clarification, but could you say what you mean by "appropriate separation between the items"? That is, what is the difference that you hear? SarahSV (talk) 04:20, 27 May 2016 (UTC)[reply]
@SlimVirgin: No problem. In the first example in the second set, I hear the first line, then I can arrow down to hear the second one (as is expected with two regular paragraphs). In the second example, all the text in both lines runs together. Graham87 07:43, 27 May 2016 (UTC)[reply]
@Graham87: Sorry to keep badgering you Graham, but can you confirm there's no difference between the following two?
  1. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

  2. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

Izkala (talk) 09:28, 27 May 2016 (UTC)[reply]

@Izkala: With the first one, the text is run together; with the second one, it isn't. However the p tags should probably be closed. Graham87 09:40, 27 May 2016 (UTC)[reply]
@Graham87: Thanks, that clears it up for me. The template is probably easier for non-technical people to use, so I remain ambivalent about deletion. Izkala (talk) 09:45, 27 May 2016 (UTC)[reply]

@Graham87: One more from me, and in this case focus both on whether the third item is noted as being numbered and whether the paragraphs are explicit:

  1. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

  2. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

  3. John Smith, Book Title, Publisher, 2015, p. 1.

--Izno (talk) 11:03, 27 May 2016 (UTC)[reply]

@Izno: Yes, the third item is numbered, and the paragraphs in the second item are explicit. Graham87 13:02, 27 May 2016 (UTC)[reply]
So the p tag works as expected? SarahSV (talk) 15:19, 27 May 2016 (UTC)[reply]

@Graham87: do you hear any difference between the following three?

  1. John Smith, Book Title, Publisher, 2015, p. 1.

    Susan Jones, Book Title, Publisher, 2016, p. 2.

  2. John Smith, Book Title, Publisher, 2015, p. 1. Susan Jones, Book Title, Publisher, 2016, p. 2.
  3. John Smith, Book Title, Publisher, 2015, p. 1; Susan Jones, Book Title, Publisher, 2016, p. 2.

SarahSV (talk) 15:22, 27 May 2016 (UTC)[reply]

@SlimVirgin: Nope, the text is run together in all three of your examples. Graham87 03:15, 28 May 2016 (UTC)[reply]
Thanks, Graham87. That suggests that it works as intended. I use it to replace the semi-colon that I add between shorter references, such as "Smith 2015; Jones 2016." I add <p> between longer references only to provide a visual break so that the footnote doesn't look cluttered. SarahSV (talk) 14:36, 28 May 2016 (UTC)[reply]
@SlimVirgin: A p tag only works if there is a p tag starting the list item, as in my item 2 above and Izkala's "badgering" item 2. In other words, a source of the form <li><p>Content<p>More content vice <li>Content<p>More content. This is why Izkala stated "probably easier for non-technical people"--her presumable belief is that requiring editors to insert not one but two "breaks" of some sort is in some way less intuitive. I'm not sure I agree with the rationale, but I obviously haven't !voted either. --Izno (talk) 15:32, 27 May 2016 (UTC)[reply]
Izno, I'm confused about what is meant by "works". I use p tags within bundled references to create a visual break only. Note: visual. It does not signal that one paragraph has ended and another begun, because these are not paragraphs. It does not signal that one reference has ended and another begun; that is done by the full stop. The intention is only to make the references easier to see, because with long references adding them all to the same line looks crowded.
If a screen reader is not affected by the p tag – if a screen reader reads out the two references on one line – that is okay, unless it is confusing for some other reason. SarahSV (talk) 15:47, 27 May 2016 (UTC)[reply]
OK, but the issue with that is that you're abusing ('abusing' in the technical sense of the word) an error in the logic of one (popular) screen reader. You wanna have a visual break and have it be semantically void, but neither the 'p' nor the 'div' element fulfil both of those criteria. The 'br' element is the closest you'll get without having to fool the MediaWiki parser (e.g. by inserting a non-breaking space inside a 'span' element), methinks. Izkala (talk) 16:09, 27 May 2016 (UTC)[reply]
But it is semantically void in these examples, is it not? SarahSV (talk) 16:14, 27 May 2016 (UTC)[reply]
That does appear to be the case in JAWS, the screen reader Graham is using. Izkala (talk) 16:16, 27 May 2016 (UTC)[reply]
I'm confused about your point, in that case. You wrote: "You wanna have a visual break and have it be semantically void, but neither the 'p' nor the 'div' element fulfil both of those criteria." But the p tag does fulfill both these criteria. SarahSV (talk) 16:18, 27 May 2016 (UTC)[reply]
Standards-wise, it doesn't. The software Graham is using does not recognise the 'p' element in that particular context, most likely due to a bug. In fact, per the HTML standard, <li>John Smith, ''Book Title'', Publisher, 2015, p. 1.<p>Susan Jones, ''Book Title'', Publisher, 2016, p. 2.</p></li> contains not one, but two paragraphs. Izkala (talk) 16:30, 27 May 2016 (UTC)[reply]
Standards-wise aside, the meaning is clear, namely "Reference one. Reference two." At some point common sense has to kick in. A lot of volunteer time has been spent on this issue in various places for a couple of years. It affects a very small number of readers who both use screen readers and who read through the references. Now we find that it makes no actual difference to those readers.
Imagine if we were to spend as much time correcting people's grammar. Every time I see the simple past tense used when the present perfect or past perfect is needed, I cringe. But we would grind to a halt if we were to go around systematically correcting things like that. SarahSV (talk) 16:53, 27 May 2016 (UTC)[reply]
Rather, imagine if we spent so much time correcting people's grammar while we had no knowledge of language... Because I remain unconvinced most people here and in past threads have any real appreciation of the accessibility implications - and that includes me. Izkala (talk) 17:36, 27 May 2016 (UTC)[reply]
Izkala, we had a similar situation with alt text. A small number of people insisted that detailed alt text be added to featured-article candidates, so for about a year several of us struggled to do that. It was horrible to have to write it after you were already exhausted from preparing the article for the other FAC criteria. Then we heard back from Wikimania that people using screen readers were complaining about the alt text being too long. What they wanted was an alt attribute (which can be "alt = "), not detailed text, so all that time, and all the arguing about it, had been wasted. SarahSV (talk) 17:49, 27 May 2016 (UTC)[reply]
There's still no plan offered for what to do with the ~2271 transclusions. SV, it seems you have a point. Are you saying/thinking we should replace them with <p> and and say any problem is with JAWS?--Elvey(t•c) 17:44, 27 May 2016 (UTC)[reply]
I think we should keep this template but let editors choose whether to use it or the p tag. SarahSV (talk) 17:53, 27 May 2016 (UTC)[reply]
  • Keep for as long as the problem persists. gidonb (talk) 22:27, 27 May 2016 (UTC)[reply]
  • Keep for now. Not to say the template is perfect. Marking up the previous paragraph implicitly, whether it's a <br>, <div>, or <p> tag after it, but no <p> start tag before, may validate, but good luck writing a CSS or jQuery selector for it. Today's screen readers also don't recognize implicit paragraphs, per Graham87's tests (thanks!). Still, an incomplete solution is better than no solution at all. Matt Fitzpatrick (talk) 13:09, 28 May 2016 (UTC)[reply]
@Matt Fitzpatrick: The first isn't actually an issue that's solved by this template. And, evidently, JAWS does recognise implicit paragraphs separated by an empty 'div'. Nobody's suggesting there be no solution, the obvious alternative being to also wrap the first paragraph inside a 'p' element. If we're dead-set on not using 'bare' HTML elements, this could equally be achieved by a set of three templates:

Izkala (talk) 14:55, 28 May 2016 (UTC)[reply]

Relisted to generate a more thorough discussion and clearer consensus.
Relisting comment: It's obvious this template will be kept, but this is templates for discussion and a useful discussion is ongoing, so I'm going to leave this open for another week.
Please add new comments below this notice. Thanks, ~ RobTalk 15:16, 28 May 2016 (UTC)[reply]
Arbitrary break 2 edit
  • Izkala, I'm still confused about what you want to achieve with the tag. I use <p> to create a visual break in bundled references. See my post above:
"I use it to replace the semi-colon that I add between shorter references, such as 'Smith 2015; Jones 2016.' I add <p> between longer references only to provide a visual break so that the footnote doesn't look cluttered."
Someone on a screen reader doesn't need a visual break. They will hear the two citations on one line. That's not a problem. I think the claim that <p> creates an accessibility issue is not correct, or at least it's not correct when it comes to bundled references. SarahSV (talk) 15:24, 28 May 2016 (UTC)[reply]
    • I'm talking about when paragraphs are actually needed, e.g. in lists in the main article prose. Izkala (talk) 16:15, 28 May 2016 (UTC)[reply]
  • Can you give an example of when <p> would be used in "lists in the main article prose." I can't think what is meant by that. SarahSV (talk) 16:39, 28 May 2016 (UTC)[reply]
  • Thanks. Are you saying you want to be able to use <p> in those circumstances? SarahSV (talk) 17:10, 28 May 2016 (UTC)[reply]
  • It would seem sensible. Izkala (talk) 17:12, 28 May 2016 (UTC)[reply]
So, my understanding of things is as follows. I may - of course - be wide of the mark, but I think there's three separate ways to deal with things paragraph-y:
  • Purely visual breaks for list-like enumerations that wouldn't benefit from being coded as HTML lists - perhaps best handled by 'br' tags?
  • Paragraphs within lists in prose - these should be properly marked up as paragraphs
  • Paragraphs within footnotes and references - I'm thinking some people don't want these being picked up as paragraphs by JAWS (ctrl + up/down arrow) for different reasons, which is why {{paragraph break}} has to come be used in those places

Graham87, Frietjes, do you have any thoughts? Izkala (talk) 18:39, 28 May 2016 (UTC)[reply]

Iskala, <p> does not cause a problem when it is used to create purely visual breaks in citations, as opposed to when producing real paragraphs within prose. In citations, it is equivalent, for a screen reader, to a semi-colon, as we discovered above. I am glad we finally established that, which is why I keep repeating it in case it gets overlooked again. SarahSV (talk) 19:14, 28 May 2016 (UTC)[reply]
Yes, but like I said, that's only by accident. A future update to JAWS (we've only established this to be the case in JAWS) could reverse this behaviour. Izkala (talk) 20:32, 28 May 2016 (UTC)[reply]
@SlimVirgin and Izkala: Not really a semicolon; more like nothing. But otherwise, this summary sounds good. Graham87 04:56, 29 May 2016 (UTC)[reply]
  • Keep as per Scott. Because <p> is deprecated, there is still a big use for the paragraph break template. ☞Henry☜ 18:25, 29 May 2016 (UTC)[reply]
    • Err, 'p' is deprecated? Perhaps somebody should let W3C know. Izkala (talk) 18:40, 29 May 2016 (UTC)[reply]
  • Strong Keep - Whatever issue(s) this template had seem to have been fixed. Good accessibility wise and generally convenient.—Godsy(TALKCONT) 09:39, 1 June 2016 (UTC)[reply]
The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

Template:MonasticHouses NonChristian London England edit

The following discussion is an archived debate of the proposed deletion of the template below. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).

The result of the discussion was delete. Plastikspork ―Œ(talk) 01:25, 6 June 2016 (UTC)[reply]

Unused. The information in it is covered on the page London Buddhist Vihara. The template's creator has not replied since I asked him about it a year ago on his user page. – Fayenatic London 12:10, 28 May 2016 (UTC)[reply]

The above discussion is preserved as an archive of the debate. Please do not modify it. Subsequent comments should be made on the appropriate discussion page (such as the template's talk page or in a deletion review).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Templates_for_discussion/Log/2016_May_28&oldid=1086982350"