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#Dotted underline. — sroc 💬 11:22, 8 December 2013 (UTC)
This version of the template (as distinct from {{
Glossary link}}
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 <abbr>...</abbr>
(or its {{
abbr}}
wrapper), and it is a light blue color, to suggest a link (but light to be unobtrusive):
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:56, 25 August 2015 (UTC)
Some well-linked glossaries are getting quite long, and much of their bulk is actually made up of long-winded calls to {{
Glossary link internal}}
over and over again; using {{
Gli}}
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)
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:
border-bottom
was used on purpose, not text-decoration: underline
because:
-webkit-text-decoration: underline
hack;display: inline-block
change, which is apt to have other, unintended effects;{{
abbr}}
or the <abbr>...</abbr>
element, the only way to tell the content has both kinds of markup is to use different underline styles that do not overlap:
snrklwsl.rgb(x, y, z)
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.<i>...</i>
element instead of <span>...</span>
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
{{
em}}
or <em>...</em>
.Ping: GPHemsley. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:44, 29 September 2017 (UTC)
<i>...</i>
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.
rgb(37, 37, 37)
was used to match the color used for the mw-body
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 #222222
.) Your use of pure black was in fact not subtle.display: inline-block
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.)text-decoration: underline; -webkit-text-decoration: underline dotted rgb(37, 37, 37); text-decoration: underline dotted rgb(37, 37, 37);
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).{{
abbr}}
and <abbr>...</abbr>
: This is an
abbrev. example of overlapping style.<i>
element. It does not suggest using that style for every 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 {{
gli}}
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 <cite>
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 are 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.]
#222222
(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.]display: inline-block
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 required to use display: inline-block
is for the recent {{
Gallery layout}}
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.text-decoration: underline ...
, and I already said this above. Wasn't broke, don't "fix" it. :-){{
Glossary link}}
before the split) and we noticed the <abbr>
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.Update, re: #222222
and rgb(37, 37, 37)
: Yeah, the best way to do this is with —
SMcCandlish
☏
¢ >ʌⱷ҅ᴥⱷʌ<
23:08, 5 October 2017 (UTC)class=plainlinks
; sandboxed and implemented. Now it won't matter what skin people are using, even a weird custom one.
That actually failed; I didn't sandbox enough. What does work is color: initial
. Now it actually won't matter what skin people are using, even a weird custom one —
SMcCandlish
☏
¢ >ʌⱷ҅ᴥⱷʌ<
23:40, 5 October 2017 (UTC)
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)
[[#Umpire Decision Review System|Umpire Decision Review System]]
. An alternative would be to have a #udrs anchor for short, and use {{
gli|udrs|Umpire Decision Review System}}
which is marginally shorter:
Umpire Decision Review System. 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)
{{
gli|bowling action}}
to redirect readers, with the target entry being {{
term|term=Bowling action}}
i.e. lower case redirecting to capitalised. That link works just fine. Meanwhile the entry for 'Chinese cut' says {{
gli|French cut}}
and the target is {{
term|term=French cut}}
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. {{
gli|One Day International}}
(a proper noun). I just
tried your suggestion of using a bare [[#Umpire Decision Review System|Umpire Decision Review System]]
, but that doesn't work either (and has a different appearance), so I reverted. Perhaps this is a problem with {{
term}} rather than {{
gli}}?
Modest Genius
talk
18:30, 27 January 2022 (UTC){{
lc}}
call in {{
glossary link}}
to a {{
lcfirst}}
call in {{
glossary link internal}}
. I'm not sure why/how that happened, but if you try to do something like {{
gli|ABC}}
, 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 {{
term}}
, 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 {{
glossary link}}
and {{
glossary link internal}}
are doing with case, and also add a switch to override lowercasing, like |lc=no
. —
SMcCandlish
☏
¢ 😼
02:03, 20 December 2023 (UTC)
|lc=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 {{
gli|cmos}}
than {{
gli|CMOS|cmos}}
just because a lower-case anchor was missing. Again, this doesn't affect template-structured glossaries anyway, in which {{
term}}
automatically creates lower-cased anchors. —
SMcCandlish
☏
¢ 😼
01:51, 23 December 2023 (UTC)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#Dotted underline. — sroc 💬 11:22, 8 December 2013 (UTC)
This version of the template (as distinct from {{
Glossary link}}
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 <abbr>...</abbr>
(or its {{
abbr}}
wrapper), and it is a light blue color, to suggest a link (but light to be unobtrusive):
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 08:56, 25 August 2015 (UTC)
Some well-linked glossaries are getting quite long, and much of their bulk is actually made up of long-winded calls to {{
Glossary link internal}}
over and over again; using {{
Gli}}
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)
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:
border-bottom
was used on purpose, not text-decoration: underline
because:
-webkit-text-decoration: underline
hack;display: inline-block
change, which is apt to have other, unintended effects;{{
abbr}}
or the <abbr>...</abbr>
element, the only way to tell the content has both kinds of markup is to use different underline styles that do not overlap:
snrklwsl.rgb(x, y, z)
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.<i>...</i>
element instead of <span>...</span>
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
{{
em}}
or <em>...</em>
.Ping: GPHemsley. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:44, 29 September 2017 (UTC)
<i>...</i>
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.
rgb(37, 37, 37)
was used to match the color used for the mw-body
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 #222222
.) Your use of pure black was in fact not subtle.display: inline-block
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.)text-decoration: underline; -webkit-text-decoration: underline dotted rgb(37, 37, 37); text-decoration: underline dotted rgb(37, 37, 37);
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).{{
abbr}}
and <abbr>...</abbr>
: This is an
abbrev. example of overlapping style.<i>
element. It does not suggest using that style for every 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 {{
gli}}
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 <cite>
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 are 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.]
#222222
(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.]display: inline-block
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 required to use display: inline-block
is for the recent {{
Gallery layout}}
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.text-decoration: underline ...
, and I already said this above. Wasn't broke, don't "fix" it. :-){{
Glossary link}}
before the split) and we noticed the <abbr>
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.Update, re: #222222
and rgb(37, 37, 37)
: Yeah, the best way to do this is with —
SMcCandlish
☏
¢ >ʌⱷ҅ᴥⱷʌ<
23:08, 5 October 2017 (UTC)class=plainlinks
; sandboxed and implemented. Now it won't matter what skin people are using, even a weird custom one.
That actually failed; I didn't sandbox enough. What does work is color: initial
. Now it actually won't matter what skin people are using, even a weird custom one —
SMcCandlish
☏
¢ >ʌⱷ҅ᴥⱷʌ<
23:40, 5 October 2017 (UTC)
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)
[[#Umpire Decision Review System|Umpire Decision Review System]]
. An alternative would be to have a #udrs anchor for short, and use {{
gli|udrs|Umpire Decision Review System}}
which is marginally shorter:
Umpire Decision Review System. 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)
{{
gli|bowling action}}
to redirect readers, with the target entry being {{
term|term=Bowling action}}
i.e. lower case redirecting to capitalised. That link works just fine. Meanwhile the entry for 'Chinese cut' says {{
gli|French cut}}
and the target is {{
term|term=French cut}}
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. {{
gli|One Day International}}
(a proper noun). I just
tried your suggestion of using a bare [[#Umpire Decision Review System|Umpire Decision Review System]]
, but that doesn't work either (and has a different appearance), so I reverted. Perhaps this is a problem with {{
term}} rather than {{
gli}}?
Modest Genius
talk
18:30, 27 January 2022 (UTC){{
lc}}
call in {{
glossary link}}
to a {{
lcfirst}}
call in {{
glossary link internal}}
. I'm not sure why/how that happened, but if you try to do something like {{
gli|ABC}}
, 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 {{
term}}
, 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 {{
glossary link}}
and {{
glossary link internal}}
are doing with case, and also add a switch to override lowercasing, like |lc=no
. —
SMcCandlish
☏
¢ 😼
02:03, 20 December 2023 (UTC)
|lc=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 {{
gli|cmos}}
than {{
gli|CMOS|cmos}}
just because a lower-case anchor was missing. Again, this doesn't affect template-structured glossaries anyway, in which {{
term}}
automatically creates lower-cased anchors. —
SMcCandlish
☏
¢ 😼
01:51, 23 December 2023 (UTC)