The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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).
Redundant template with self links. The template contains links for promo articles about the non notable books. Those articles have already been merged or redirected to the author's article by multiple editors. The template is only used on the author's page and now serves no purpose, as it is simply a list of redirects. Walrus Ji (talk) 20:44, 19 December 2020 (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).
The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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. If someone needs the content to add it to the 1977 template or for other use, please ping me. Primefac (talk) 02:01, 28 December 2020 (UTC)[reply]
No accompanying article with coverage that 'Test match double' is a significant achievement and is exclusive. The criteria is too inclusive if we expand it to all test-playing nations. No navigational value. Störm(talk)19:01, 19 December 2020 (UTC)[reply]
Comment There is an existing navbox for all countries, but it stops in 1977 for some unexplained reason: {{Test cricket doubles to 1977}}. There is Double (cricket) which could be expanded to cover this, but it currently deals just with domestic single season efforts rather than international career ones. This could be better dealt with by a category than a navbox. As it is, many of the players listed are bowlers who have played long enough to reach 1000 runs, rather than being all-rounders of note. Spike 'em (talk) 21:07, 19 December 2020 (UTC)[reply]
Delete Not sufficiently important to need a navbox. Content should be in a Test Record article if it is sufficiently important. Doesn't seem to exist for other test countries. Nigej (talk) 22:13, 23 December 2020 (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).
The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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 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).
The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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 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).
The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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 mergetoTemplate:Tooltip. Note that once this is complete, there is no prejudice against revisiting the question of whether to even have this as a single template; there were multiple opinions here that indicated it should simply be deleted outright. Primefac (talk) 12:31, 10 January 2021 (UTC)[reply]
Some time ago, Template:Tooltip was "merged" and redirected [1]toTemplate:Abbr. This was an outright mistake in several ways (and undertaken over a decade ago when we cared much less about HTML specs). First, it was not actually merged: the correct use of <span>, for non-abbreviation uses, was lost; {{Abbr}} imposes <abbr> in every case. This is an HTML standards compliance failure on a pretty massive scale. That element is only for abbreviations (including acronyms and initialisms). Despite the redirect from {{Tooltip}} being deprecated, for that very reason, a few years ago [2], the deprecation was simply ignored by the community in actual practice. There are tens of thousands of calls to {{Tooltip}} (directly, not to {{Abbr}}), and a large proportion of them are not abbreviation cases. Then we also ended up with {{Hover title}}, which did the exact same thing {{Tooltip}} did, just with backwards parameters (plus some extra options).
I have merged the additional features of {{Hover title}} into a new (non-redirect) {{Tooltip}}. It appears that the vast majority of instances of calls to {{Tooltip}} and to {{Hover title}} (a name that doesn't mean much of anything to anyone) are due to their use in infoboxes and other templates. If 1) instances of the former in such templates are tracked down and sorted properly into uses of {{Abbr}} for input that is explicitly abbreviation/acronym/initialism, with the rest remaining as {{Tooltip}} calls (which is fine for input that is sometimes abbreviations and sometimes not – <abbr> is an entirely optional semantic markup element); and 2) instances of {{Hover title}} are changed in templates to reverse the 1 and 2 parameters and to use {{Tooltip}} instead; then 3) this should leave only a comparatively small number of manual insertions of {{Hover title}} to clean up as {{Tooltip}} instances (probably an easy bot task). Then some /doc updates, of course. (PS: I have not TfD-tagged the templates in a way that's visible when transcluded, since these are so frequently used in mainspace that it might be too visually disruptive to even use the small, inline version of the TfM tag. And our readers don't care about template mergers anyway.) — SMcCandlish☏¢ 😼 23:46, 3 December 2020 (UTC)[reply]
Note: WP:Village pump (technical) has been notified of this discussion. Also notified participants in the two old discussions, and talk pages of project pages (e.g. WT:HTML5, WT:LINT) where people congregate who probably care and also have ideas for how to do this cleanup expeditiously. — SMcCandlish☏¢ 😼 23:56, 3 December 2020 (UTC); updated: 00:31, 4 December 2020 (UTC)[reply]
Merge. It looks like it should be pretty easy to make one of them into a wrapper for the other until a bot comes along to fix the existing usage. – Jonesey95 (talk) 00:37, 4 December 2020 (UTC)[reply]
Delete both. I'm not a fan of this out-of-process restoration of the template. We have a guideline at MOS:NOTOOLTIPS which states not to use tooltips at all. We have a community consensus at Wikipedia:Redirects_for_discussion/Log/2018_May_9#Template:Tooltip which state that appropriate uses should be converted to use {{Abbr}}; Any non-abbreviations should be removed or replaced with footnotes.. The real issue was that someone at some point removed Tooltip from the /holding cell for whatever reason. --Gonnym (talk) 11:40, 5 December 2020 (UTC)[reply]
@Izno: Okay, so I seemed to have misunderstood something pretty critical which is that our tooltips are currently not accessible to keyboard-only nor mobile users. I looked into the relevant guidelines there, and it seems that we are improperly relying on the title attribute. However, could this not be fixed to make it W3C compliant? –MJL‐Talk‐☖06:03, 6 December 2020 (UTC)[reply]
The point of this template is to produce the hover/tooltip effect with <span>, so I'm not sure what can be done.... (<abbr>'s title has slightly different semantics; title is required in that context and it is the expansion of the particular abbreviation. {{abbr}} covers this case already, of course.) There might be a way combined with Template:sronly to get the content into view of the screenreader. We would still have issues with devices that are neither screenreaders nor desktop (namely, almost all mobile) with a media query for mobile. It is likely that most people on those devices would not want the content (as it is often parenthetical in nature, or not necessary for full understanding if you already have the context), but I don't think I would want to have such a radical deviation for three different kinds of devices from the casual editor's authoring perspective, which is almost always desktop only, and unlikely to consider the impacts. Graham87, any thoughts? --Izno (talk) 18:04, 6 December 2020 (UTC)[reply]
All that said to MJL about possible ways to make the content of a title attribute accessible, I definitely tend toward agreement with both Gonnym and Nardog. Probably all uses of these templates (and abbr) need scrubbing/work/verification. --Izno (talk) 18:04, 6 December 2020 (UTC)[reply]
Updated, more accessible implementation tests: As for {{sronly}}, that looks like it could easily be used to make the tooltip content available accessibly anyway, perhaps as a square-bracketed note. Just feed it the same {{{2}}} or whatever, as feeds the tooltip itself. I've already test-cased this at Template:Tooltip/testcases, and it seems to be working with everything I throw at it. @Graham87:, I hope the test cases are clear enough. I've tested various linking scenarios, and each example presents the code to test, then example output of the sandbox version of the template, and finally sample output of the current "live" version of the template (useless right now for this, since it lacks any sronly code). — SMcCandlish☏¢ 😼 09:46, 14 December 2020 (UTC)[reply]
Reality-check comments: Aside from the fix being tested above, I have to point out that we know several relevant things by now from direct experience:
Telling people not to abuse the <abbr> element and its {{abbr}} template wrapper is simply going to be ignored if there is no alternative that does not abuse that element for non-abbreviations.
There are limits to what can be done to make WP or any other website accessible in every imaginable way; the technology simply doesn't exist to do much. And even when it does, makers of screen readers, mobile browsers, etc., often simply refuse to implement such features, and even when they are implemented, users of those things often refuse to turn those features on.
WP has made various decisions to permit features that are not 100% accessible to everyone (collapsing navboxes, etc.), because they provide useful features for a majority of users, and they do not harm the actual content of the encyclopedia for users who depend on less capable software (be they screen readers for the visually impaired, or just mobile web browsers for limited-capability devices).
This is the same kind of trade-off; if the template (and MoS material about it) is documented properly, to not use it to effectively "hide" key content, but only add navigational and other features that are secondary, there is not an actual problem for us to solve from an encyclopedia-production perspective (cf. WP:GREATWRONGS – it is not our job to find solutions for every web-accessibility problem ever recognized).
We already use, for many years now, title= tooltips for all kinds of things, including rendering |reason= values of numerous inline cleanup/dispute templates, e.g.: [needs update]
With the accessibility fix being tested above, that should take care of much of this. I don't think we can care that the mobile-but-sighted version may lack some features. That's a usability not accessibility matter, and the mobile version lacks all sorts of features that the desktop site has. It has to, because it's a stripped-down version for small, handheld devices.
Finally, an old RfC and an apparent consensus to make a blanket statement in one page doesn't mean much if it had little input and if the community itself doesn't want to comply. The guidelines exist to document practice not to try to force a change in it. Nor is such a limited consensus unchangeable. When is the last time this was even examined from a MOS:ACCESS point of view, and can anyone actually identify a real problem (e.g., an instance of use that harms the encyclopedic experience for a subset of users, rather than simply provides a side feature not all of them can use)?
Another example of harmless use is Template:Glossary link (a meta-template), and its progeny. They use the HTML title= feature to let people know they are going to a glossary entry if they click on the link. It in no way breaks the links, nor interferes with identification of the link URL (usually done in the browser-window footer, though this varies by user agent), nor hiding the actual content that is marked up by the template, nor anything else bad. — SMcCandlish☏¢ 😼 09:46, 14 December 2020 (UTC)[reply]
@SMcCandlish: Thanks for this. Yes, it does work well with screen readers, though I would put an initial space before the left bracket in the screen reader output. This would be nice to have if the tooltip/etc. templates were used ideally almost 100% of the time, but as you said that's not always the case. Also, the technical village pump does get occasional complaints about weird glitches when this method is used, most notably in {{sfrac}}, the latest being this one about Google results. On a scale of importance from 1 to 10, I'd rate the importance of having these always read out for screen reader users as about a 3 or a 4 ... but then again I may or may not know what I'm missing. Graham8711:58, 14 December 2020 (UTC)[reply]
@Graham87: Strange; I actually did put a space there (encoded as   to force it). If that somehow didn't work, I can try some other replacement like . I put that version in the sandbox just now, so the test cases should have nbsp in them. If we're sure it's going to mostly work, it shouldn't be hard to propagate this sort of sronly tweak to other templates that use tooltips (especially since most of the inline cleanup/dispute ones use a meta-template). The real cleanup operation over the long haul would be undoing misuse of {{abbr}} for non-abbreviations (which brings us full circle to why this TfM is open. Does the title= attribute of the <abbr> element work properly in screen readers already? I think you were indicating it's handled differently because it's mandatory in that element, a special case. If not, I suppose this {{sronly}} tweak can be done to the {{abbr}} template as well. On the Google glitch: I would hope that wouldn't matter much for this particular sort of use case, since the material in these tooltips is basically trivial, parenthetical annotation. I can see the math-markup substitution being a more important and problematic case, since it's actual encyclopedia content, not metadata. PS: There is actually a very technical HTML 5 compliance nitpick with the sronly template (at all, not just in this particular kind use of it); something it is doing needs an extra attribute on an element; I forget the details, just something I saw when I ran its output through W3C's validator. I'll try to remember to bring that up at Template talk:Sronly. — SMcCandlish☏¢ 😼 13:09, 14 December 2020 (UTC)[reply]
@SMcCandlish: The non-breaking space works fine. Re the title attribute in abbr, it does work, but screen reader users generally have to specify that they want to hear it because the abbreviation expansion isn't spoken by default. Graham8714:27, 14 December 2020 (UTC)[reply]
Is this something people know about and choose? Using this trick to force reading-out of the title content is a bit different from alt text, in being add-on material rather than a replacement. And if someone has the <abbr>-reading feature on, then they would get the material twice. I've asked at Template talk:Sronly about a "nosr" approach. — SMcCandlish☏¢ 😼 04:15, 15 December 2020 (UTC)[reply]
Question: I notice that, {{tooltip}}, unlike {{abbr}}, does not change the cursor to a pointer with a quetion mark when one hovers over it (at least on my browser). I like the changed cursor; is that something we could retained at {{Tooltip}}?{{u|Sdkb}}talk00:00, 26 December 2020 (UTC)[reply]
Not that I know of; that appears to be a function that your browser does with the <abbr> element specifically. There might be a way to do something like it with JavaScript, but it's a bit out-of-scope for this, at this time. Better discussed post-RfM at Template talk:Tooltip. — SMcCandlish☏¢ 😼 21:01, 31 December 2020 (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).
The following discussion is an archived debate of the proposed deletion of the template(s) or module(s) 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).
Added two categories to this nomination, as these two categories are solely populated by the templates that are going to be deleted. Techie3 (talk) 06:44, 21 December 2020 (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).
