Template talk:Longdash

ndash

The link to ndash leads to nowhere. Tromaster (talk) 23:45, 31 August 2016 (UTC)

Use correct character?

This template is currently using a box-drawing character. It might look like a long dash, but it's not. It's also not supported by all devices. There are other more appropriate characters to choose from, such as the Horizontal Bar: U+2015 ―. However, as the purpose of this template is to indicate abbreviation by use of a very long dash, I'd suggest following the guidelines at Wikipedia:Dash#Redaction and using two em dashes, or maybe the {{bar|2}} (——) template. Any thoughts? Sam Wilson 01:22, 2 November 2016 (UTC)

It's also commonly used to indicate speech left hanging by an interruption; e.g. two such uses on Page:The Soft Side (New York, The Macmillan Company, 1900).djvu/11. It's important to me that the template yield something that looks like a single long dash, and in every font. As long as that criterion is met, then I don't mind what characters are used. Hesperian 05:28, 2 November 2016 (UTC)

Good point. But actually the reason that I've noticed this is that the box-building character currently in use doesn't display correctly on Kobo ereaders. Whereas the double-dash hack of {{bar|2}} does work (although it has a slight variation of height along its length due to the strike-through having a different weight to the dash itself). I'm not bothered enough to change it, especially if there's any disagreement, but I think it's something to be aware of. Sam Wilson 05:38, 2 November 2016 (UTC)

(e/c) I use {{bar|2}} for the interrupted speech dash, and a longer one for things like "Lord M———y was robbed the other day." I haven't found any browser or font issues with it across several devices. Because of my use of it I know that other editors are also doing so, so I recommend that this template use it as well—for consistency at least. Beeswaxcandle (talk) 05:41, 2 November 2016 (UTC)

@Beeswaxcandle: Yes, that's my approach too. In addition, wrapping the associated parts of word in {{nowrap}}, e.g. "Lord {{nowrap|M{{bar|3}}y}} was robbed". Sam Wilson 05:55, 2 November 2016 (UTC)

There is actually a unicode character called the "THREE-EM DASH". Cool, hey! And here it is: ⸻. I bet London to a brick it didn't display for you.

What would be super is if we could use this character, but specify a fallback substitution, such as three em-dashes, if the intended character is unsupported by any of the reader's installed browser fonts. Unicode does in fact support character fallback substitutions, but they're hard-coded, there's no defined substitution for the THREE-EM DASH, and there doesn't seem to be a way for us to define one. Damn!

Hesperian 06:18, 2 November 2016 (UTC)

How about this, stolen from en.wikipedia's {{long dash}}: ———

The code is

<span style="letter-spacing:-.25em;">———</span>

Hesperian 06:33, 2 November 2016 (UTC)

That sounds like a good idea. I've had a play on Template:Bar/sandbox; have a look at Template:Bar/testcases. —Sam Wilson 06:57, 7 November 2016 (UTC)

I implemented it but took the last dash out of the span so that any succeeding character isn't affected by the letter spacing. It's the difference between

What the f———?

and

What the f———?

Hesperian 01:27, 8 November 2016 (UTC)

That's a great idea. Thanks for fixing. :-) I think I'll swich to using this now, instead of {{bar|2}}. Sam Wilson 04:34, 8 November 2016 (UTC)

According to Unicode 6.1+ (see w:Supplemental Punctuation), "⸺" "2M" U+2E3A "TWO-EM DASH" is the "omission dash" and "⸻" "3M" U+2E3B "THREE-EM DASH" is for use in bibliographies to replace repeated instances of an authors name. According to w:Template:Long dash (Template:Long dash (Q25969656)), it is to be used for bibliographies and thus should be the "THREE-EM DASH", however here s:Template:Longdash (Template:Longdash (Q30525777) ) it is to be used as an omission dash and thus should be "TWO-EM DASH". I am considering whether I shouldn't just ignore these templates and instead modify {{--}} (Template:Em dash (Q6582719)) to take a parameter and use a #switch to render either U+2014, U+2E3A, or U+2E3B. —Uzume (talk) 07:15, 11 May 2023 (UTC)

Parameters

{{editprotected}} It would be good to have parameters for this, to avoid having to use {{nowrap}} separately, and to allow a different number of em dashes, to match the original source (I've come across quite a few works which use two em dashes rather than three). So for example:

• {{longdash|B|."}} would be the same as {{nowrap|B{{longdash}}."}}
• {{longdash|B|."|2}} would be the same as the above, but would be two em dashes, rather than three

As there aren't any parameters at the moment, this wouldn't break any existing uses. If no one objects I'll make a sandbox version. --Yodin^T 03:32, 26 March 2024 (UTC)

That's a good idea, I think that something like this would be enough.

Edit: other version with longer code but no useless nowraps there — Alien333 (what I did & why I did it wrong) 09:31, 5 May 2024 (UTC)

Thanks! I've added your version to Template:Longdash/sandbox, and tested it out at Template:Longdash/testcases; and it's working just as expected. I'm still not completely sure about the order of parameters though; do you think the number of dashes should be the first parameter or last? --Yodin^T 11:32, 5 May 2024 (UTC)

For the order of the parameters, it depends on the relation of this to {{bar}}. Once we do a variable-length horizontal bar, it's more or less the same. This template would even be better in some aspects^[1].

If we assume that this is replacing it and will often be used with variable length, I'd put it first, but else I'd put it last with an alias, like length (that's what I did in my version).

Anyhow, we'll get a third opinion anyway if we want to change it as it's protected.

1. differences:

   • this has nowrap
   • code is cleaner
   • behaviour with unexpected inputs, bar gives nothing for 0 and errors for negatives, this gives one emdash both for 0 and negatives.

— Alien333 (what I did & why I did it wrong) 12:07, 5 May 2024 (UTC)

That makes sense! I've added an edit request now. --Yodin^T 16:01, 5 May 2024 (UTC)

I am extremely sceptical of making this template more complicated, and adding logic like this in template code (in particular, {{#expr:…}} is a strike and {{loop}} is an automatic fail; {{loop}} will be deprecated and deleted as soon as I can possibly manage it). But I'm open to being persuaded of the error of my ways, so perhaps you could sketch out what the problem we are trying to solve is (links to concrete example pages is always good), and expand a bit on the {{longdash}} vs. {{bar}} picture? Xover (talk) 10:32, 6 May 2024 (UTC)

That was just a draft, and there are probably cleaner ways to do it that I'm not aware of. {{loop}} is just a String.rep wrapped anyway (and {{bar}} uses that), but I've directly changed it to invoke if you prefer. I also changed the structure a bit, removing the {{#expr: and adjusting the last space with a quarter em space (U+2005).

Regarding whether it is a good idea, the point of this was I think was primarily to avoid having to use nodash separately.

The problem with {{bar}} is that in links, such as there, the strike-through approach leads to a dashed line.

This template, on the other hand, manages to make a continuous line.

That is why variable length would be useful, because it happens to have a non-3em bar in a link, especially in TOCs. — Alien333 (what I did & why I did it wrong) 11:56, 6 May 2024 (UTC)

@Xover: this template is mostly used when part of a word is replaced by a continuous dash, but you've still got the first letter or two, and sometimes a few letters at the end of the word too, while {{bar}} is for when it's not part of a word. This template is currently fixed at 3 em dashes, but in practice, these dashes are often 2em, and sometimes even vary within a work (e.g. this recent example, where I've been using {{bar}} as this template's fixed 3em dashes don't match the text). Because it's part of a word, you need to wrap the word and the dash in {{nw}} every time, which seems weird, as the template could just add the nowrap itself, which would make the page markup more streamlined. But in order to do that, we'd need to add parameters for the first/last letters of the word (as implemented here). In practice, this could be merged with {{bar}}, but as Alien333 says, there might be some other cases, such as in hyperlinks, where {{bar}}'s approach doesn't work, and this could be used instead. --Yodin^T 14:03, 6 May 2024 (UTC)

Hmm. Ok, I'm on board with there being a need for nowrap and (some level of) variable length, which need an implementation like described above might meet. But here be dragons I'm afraid.

First things first, {{bar}} and {{longdash}} would seem to be no-brainers to merge; they do the exact same thing in the exact same contexts, just with different implementations. Big picture we don't need or want two templates for spitting out a horizontal line. {{bar}} breaks inside wikilinks because it uses TemplateStyles which are currently broken inside wikilinks (a fact of which I have just griped at the devs for, again).

But in any case, the path here is, I think, to investigate some sane way to merge these two, and clean up the implementation while we're at it. I'm not overjoyed by the "add more overlapping em-dashes" approach, but I can't off the top of my head think of any way to add a horizontal line with CSS that will behave like the currently active font (the strikethrough is text decoration and you have limited control over things like line width). For calling convention {{sp}} and {{lsp}} are probably the pattern (it's essentially tackling the same problem just for a different aspect), but I'd need to dig deeper into the issue first. Xover (talk) 06:11, 10 May 2024 (UTC)

Thanks 👍 Merging the two templates makes sense, and from my perspective this isn't urgent, so it could wait until the TemplateStyles issue is resolved if that makes life easier? --Yodin^T 19:56, 11 May 2024 (UTC)

I've been fidgeting a bit more with this, since as of now it overlaps very much, so I reduced the spacing (still in sandbox) from .25 to .115. That appears to still work with or without serif, italics and bold. There's still a few-pixel overlap, but it's much less (compare ——— and ———). — Alien333 (what I did & why I did it wrong) 15:17, 5 June 2024 (UTC)

Unicode character

What is the reason for this template to use a three em dash workaround instead of a proper Unicode character like two-em dash ("⸺" U+2E3A) or three-em dash ("⸻" U+2E3B)? Inter-rede (talk) 02:01, 30 July 2024 (UTC)

Per Hesperian (see discussion on top), the problem with the pre-made unicode characters is that often they don't display well on e-readers. — Alien333 (what I did & why I did it wrong) 08:43, 30 July 2024 (UTC)

character

@CalendulaAsteraceae: it was discussed before (see above), and it was stated (maybe false now?) that the three-em dash character was not supported by all common fonts, and thus could cause an exporting issues. — Alien  3
3 3 09:08, 1 December 2024 (UTC)

Good catch, thanks! —CalendulaAsteraceae (talk • contribs) 09:19, 1 December 2024 (UTC)

Slightly reduce letter spacing

Replace letter-spacing:-.25em; by letter-spacing:-.115em;

Reason: We (currently) don't have a better alternative than overlapping dashes, but we can make them overlap less. Reducing the letter spacing from .25 to .115 still works with and without italic, bold, or serifs. There's still a few-pixed overlap, but it's much less (compare ——— and ———). — Alien  3
3 3 16:49, 1 December 2024 (UTC)