Template talk:Glossary link internal

Two sets of tooltips
This template is producing weird formatting that results in two sets of tooltips, which is counter-intuitive, confusing and difficult to use. Please see the discussion at Wikipedia talk:Manual of Style. —sroc &#x1F4AC; 11:22, 8 December 2013 (UTC)
 * it appears this has been fixed? Frietjes (talk) 20:18, 11 December 2013 (UTC)
 * I think I fixed it, unless I did something horribly wrong. —sroc &#x1F4AC; 22:07, 11 December 2013 (UTC)
 * Not pointing a personal finger, but something horribly wrong has certainly been done; see my comments at Template talk:Glossary_link.  — SMcCandlish ☺ ☏ ¢ ⚞(Ʌⱷ҅̆⚲͜ⱷ^)≼  15:54, 24 March 2014 (UTC)

Faint underline
This version of the template (as distinct from needs a light underline.  Someone, in the course of debugging an unrelated double-tooltip issue, removed the original underline without discussion, resulting in the glossaries being barely usable. It was impossible to see which terms were in-glossary links without randomly hovering over words and hoping to get lucky.  Anyway, this version uses a dashed instead of dotted line (to distinguish it from the underlining done by  (or its  wrapper), and it is a light blue color, to suggest a link (but light to be unobtrusive): — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:56, 25 August 2015 (UTC)
 * Template:Glossary link (used between articles):
 * Template:Glossary link internal (used inside same article):
 * Template:Abbr (unrelated to glossaries): WMF

Cut article size by using Template:gli shortcut
Some well-linked glossaries are getting quite long, and much of their bulk is actually made up of long-winded calls to over and over again; using  saved tens of thousands of characters at Glossary of cue sports alone, and should have a positive impact on other glossaries after it propagates to them. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  18:29, 25 August 2015 (UTC)

Reverted recent major changes
I've reverted a number of undiscussed changes (the result of random experiementation with a live template with thousands of transclusions), and returned to the long-stable version of this template, because: Ping:. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  01:44, 29 September 2017 (UTC)
 * A subtle underline color was chosen on purpose. People complained bitterly about a "robust" one, and even wanted to kill the template entirely, they hated that so much.
 * A  was used on purpose, not   because:
 * the latter is a severe readability problem in many browsers, with the underline fused to the letters;
 * the latter needs a  hack;
 * the latter also needs a  change, which is apt to have other, unintended effects;
 * all of that is just code bloat, which actually matters in a template that may be transcluded hundreds of times on the same page;
 * other code may do a "regular" underline here; if you use or the  element, the only way to tell the content has both kinds of markup is to use different underline styles that do not overlap:
 * WP virtually never uses  color markup – most editors don't understand it (thus easily break it due to more complicated syntax), it's not needed, and it's unnecessarily lengthy.
 * Using the  element instead of is a terrible idea. At a well-linked glossary like Glossary of cue sports terms, doing that made the text nearly unreadable, with almost everything italicized; and
 * this directly interfered with intentional and more contextually important, meaningful uses of italics, e.g. for non-English terms, for in-sentence discussion of "words as words", for book titles, for hatnotes and other cross-references (which glossaries may use quite extensivesly), and for actual semantic emphasis with  or .

— SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  23:03, 5 October 2017 (UTC) Update, re:  and  : Yeah, the best way to do this is with  ; sandboxed and implemented. Now it won't matter what skin people are using, even a weird custom one. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  23:08, 5 October 2017 (UTC) That actually failed; I didn't sandbox enough. What does work is. Now it won't matter what skin people are using, even a weird custom one  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  23:40, 5 October 2017 (UTC)
 * Here's what I have to say on the matter:
 * While this template may have "thousands" of transclusions, it's only used on 7 individual articles&mdash;all of which are glossaries that you'd expect to have a high number of transclusions, and all of which I looked at when I made the changes. They were certainly not "random". (I was editing Glossary of graph theory terms at the time.)
 * These changes have been live for almost a year, and no one has raised any objections.
 * I explained the reason for each change I made in my edit summaries. In particular:
 *  was used for glossary terms because that is precisely what it is designed for, per the HTML specification:
 * The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts.
 * was used to match the color used for the  class at the time, so that the term did not stand out too much from the regular body text. (It seems that perhaps this color has since changed to  .) Your use of pure black was in fact not subtle.
 * merely allows the element to be styled as if it were a block element. It doesn't have any unintended effects. (And if it did, they would be readily apparent on a page that has hundreds or thousands of transclusions.)
 * The three statements  go together: The first two are for backwards compatibility with older browsers that don't support the third syntax, which is the real intended style (a dotted underline matching the color of the body text).
 * That said, I agree with your note about and : This is an abbrev. example of overlapping style.
 * &mdash;Gordon P. Hemsley&rarr; &#x2709; 15:45, 30 September 2017 (UTC)
 * Thanks for the response. To cover these in the same order:
 * I didn't mean the article or template selection were random; the changes were random experimentation done to the live template instead of in a sandbox, as demonstrated in your edit history on the template, trying out this then trying out that.
 * I saw the explanations, and they clearly meant well, but they don't counter the objections to these changes nor the rationales for the template being done the way it was done in the first place.
 * I've raised an objection and reverted the changes (WP:BRD; this is the "D" part now). This affects few enough articles that others weren't likely to raise objections any time soon.  However, some of what you did either a) has been objected to before, as I indicated (e.g. the dark underline color), or b) doesn't comport with MoS and other rules here (e.g. the over-italicization); on the latter, whether anyone objected in this particular instance is irrelevant. (This is a general principle; e.g., it's not okay to violate BLP just because no one notices and objects to the violation. The existence of a rule about it is a "pre-objection".)  While you might not have been aware of the issues before, you are now.
 * You're misunderstanding WHATWG on the element. It does not suggest using that style for  occurrence of a technical term, etc. (If we misused it that way, any article on a technical subject would be virtually unreadable due to every other word being italicized just for being technical).  It means when a term of art is used in a words as words manner to introduce the term and/or to distinguish from another that it's being compared to.  Example of both at once: "In archaeology the term provenience has a distinct meaning from the art-history term provenance; the two are not synonymous.  A provenience is ...".  Whether such a stylization applies in a given circumstance is a case-by-case judgement call, and WP's MoS has specific advice on when to use it (including to use quotation marks instead sometimes, and usually neither stylization after the term has already been introduced and used once).  You're trying to hard-code a style that violates our style guide in multiple ways most of the time (especially in  in particular, which is not for the defining instance of the term on the page). WP follows its own style guide, not the loose and vague recommendations of WHATWG. Long digression on why else to not take WHATWG seriously: WHATWG's style and intent recommendations [and that's all they are] are sometimes flat-out wrong, conflicting not only with off-WP major style guides but also with W3C's HTML5 and CSS specs, which have way more buy-in and are what people actually validate against. WHATWG is a consortium of three browser makers, and its spec is what those three agree on as the default behavior of their products (and is notably missing Microsoft and Google). It does not dictate usage here.  And any time WHATWG conflicts with W3C, we follow W3C, because it's intended for authors/publishers not user-agent developers, and has the buy-in of hundreds of organizations, not just three. Incidentally, all three are in W3C, too; any time WHATWG conflicts with W3C on HTML or CSS, it's those three companies contradicting themselves because they can't read specs properly, just don't care, or have some kind of "the left hand doesn't know what the right hand is doing" internal office politics problem going on. I'm on WHATWG's mailings list and I see these issues unfold first-hand and real-time.  Sometimes it's just facepalm ridiculous, and frequently also involves a lot of "me and my buddies got mad at someone at W3C in 2005, so screw them and everyone who likes their spec" posturing. I've directly encountered this multiple times in trying to resolve some of WHATWG's boneheaded "PoV forks" from W3C. One obvious example of this is WHATWG trying to force italics on the content of  and "requiring" the element to only be used for titles, when it's intended for any citation data (as long as it contains at least one of: a title, author, or URL. Even if W3C were to go along with WHATWG's attempt to limit the scope (they actually tried that for a while in the early days of HTML5, and the real-world developer reaction was overwhelmingly negative), the forced italics would still be wrong, because only the titles of major works are italicized; minor works' and sub-works' titles go in italics, and some works get neither, e.g. utility software like Microsoft Word (italics  used for digital "creative works" like video games and e-books), religious doctrines like the Bible and the Q'ran, works without a real title that are named after their first few words (their incipit), e.g. untitled poems like so many by Emily Dickinson, and untitled works given some conventional name that scholars have arrived at, e.g. the Dead Sea Scrolls and Bach's Sanctus in D major (a.k.a. BWV 238). [End huge digression.]
 * Good point on  (while I don't see the difference with my eyes on my monitor, the difference might be marked on others). I implemented that, though it needs to be checked that this doesn't vary on a skin-by-skin basis, at last when it comes to the official skins. We might need to set it to a class; requires some digging around in the system-wide stylesheets. [Resolved that question below.]
 * I know what  does; I'm a professional Web developer, among other things.  There is no need for that code when we don't use markup that requires it.  Using it can also have side-effects relating to the CSS box model.  It's a "weird thing" – a "pretend this isn't what it really is" effect – that shouldn't be used when not needed to work around a specific, intractable problem. If you spend any time at WP's own CSS interface pages' talk pages, you'll find out quickly that the consensus is strongly against doing anything to elements that defies their expected behavior, if we can avoid going in that direction. No one wants a span that behaves like a div (or whatever) if this can be avoided.  In over a decade of template and style work here, the only time I can recall feeling  to use   is for the recent  system, because the effect is well-documented to require it, and in a bunch of direct testing I was not able to find another way to get the desired output.
 * Yes, I know. We don't need any of the "edge case" support code if we use the template's original design intent instead of replacing this with, and I already said this above.  Wasn't broke, don't "fix" it.  :-)
 * Right. IIRC, I actually original did this with a "real" underline (probably in before the split) and we noticed the  problem quickly, in the "testbed" article at Glossary of cue sports terms.  Someone else pointed it out; I don't think I caught that one.  Anyway, as the doc says, the intended style is dashed. In some browsers and on high-resolution monitors (small text), a dotted line is almost indistinguishable from a solid underline.
 * Sorry that's a bit long, but I'm trying to cover these things adequately. Templates with CSS in them fairly often attract well-intended but side-effect-inducing tweaks from people with particular preferences regarding what is "best" with CSS or HTML.  I get bitten in the butt by this, too, sometimes; we do have a lot of templates with clumsy code in them and I clean them up when I come across them, but once in a while get reverted because something was done in a highly particular way on purpose, and I wasn't aware of it.  D'oh!  HTML comments help.

Forced lowercase
The forced lower case breaks a lot of links to entries with a first capital letter. Using a first-lowercase anchor is a workaround, but there should be a better way to handle this. --Paul_012 (talk) 10:33, 19 April 2018 (UTC)
 * Yeah, the first letter in the anchor link is always lower case when using this template, which shouldn’t be the case. Inter qwark talk  contribs 19:14, 13 June 2018 (UTC)
 * Yes, this is a problem. It took me some time to work out why some links were not working. I can't quite work out what is happening, but it has something to do with case of the first letter. Can it be fixed or is there a workaround that should be in the documentation? Please ping with reply. &middot; &middot; &middot; Peter Southwood (talk): 18:38, 29 April 2021 (UTC)
 * I'm having the same problem on glossary of cricket terms. Most of the gli links work fine, but I can't get to work, even after playing with the capitalisation, adding extra anchors etc. <b style="font-family: Times New Roman; color: maroon;">Modest Genius</b> talk 11:31, 28 October 2021 (UTC)
 * Can we just delete the lcfirst call in this template? Or will that break something else? <b style="font-family: Times New Roman; color: maroon;">Modest Genius</b> talk 14:52, 24 January 2022 (UTC)
 * It'll definitely break something else (namely, almost every use of this template at the start of a sentence). Almost all glossary entries should be lower-case (unless they are proper names).  The usual use-case for this template is for terms, not names, and the case stuff is to account for sentence-initial position: " rules apply when ...", to link to an entry #foo.  For a proper name, use  . An alternative would be to have a #udrs anchor for short, and use  which is marginally shorter: .  Someone could probably make something more robust with a Lua module, but I can't Lua my way out of a paper bag.  — SMcCandlish ☏ ¢ 😼  18:33, 24 January 2022 (UTC)
 * Now I'm even more confused. Again looking at the cricket glossary, the entry for 'action' uses to redirect readers, with the target entry being  i.e. lower case redirecting to capitalised. That link works just fine. Meanwhile the entry for 'Chinese cut' says  and the target is  i.e. both are capitalised, which also works correctly. So I don't understand what this has to do with the start of sentences. The links only seem to break when a second word in the entry is capitalised e.g.  (a proper noun). I just tried your suggestion of using a bare , but that doesn't work either (and has a different appearance), so I reverted. Perhaps this is a problem with term rather than gli? <b style="font-family: Times New Roman; color: maroon;">Modest Genius</b> talk 18:30, 27 January 2022 (UTC)
 * The problem appears to have been a change, somehow, from the call in  to a  call in . I'm not sure why/how that happened, but if you try to do something like, it looks for a "aBC" instead of "abc". The template is not even documented this way, and says explicitly that it's going to look for a target of "abc" and that the target page needs lower-case anchors (these are automatically provided by , but if you're doing some manually wikicoded   and   list, then it would need manually added anchors. I can probably fix both the wrongheaded mismatch between what  and  are doing with case, and also add a switch to override lowercasing, like no.  — SMcCandlish ☏ ¢ 😼  02:03, 20 December 2023 (UTC)
 * Thanks for looking into this. It's a problem even without manual coding: just using gli and term breaks if there are multiple capitalised words in the term. <b style="font-family: Times New Roman; color: maroon;">Modest Genius</b> talk 13:41, 21 December 2023 (UTC)
 * It now lower-cases the entire string the same way the parent template does, and both templates now support as no for cases where a lower-case anchor isn't sensible/desirable, typically a proper name like "Hermansky–Pudlak syndrome" (I would still create them for an acronym like "VRAM" and "CMOS" since some people write them lower-case; e.g., if we were gli'ing from a quotation that used a lower case one, it would be more convenient to do than  just because a lower-case anchor was missing. Again, this doesn't affect template-structured glossaries anyway, in which  automatically creates lower-cased anchors.  — SMcCandlish ☏ ¢ 😼  01:51, 23 December 2023 (UTC)