HTML, JSX Ligatures

[stevemolitor]

I'd like to request ligatures for these HTML and JSX/TSX expressions:

• </
• />
• </>

The 0xProto web site has an image that seems to indicate that they are supported, but I'm not seeing that. I see the ligature for <> but not for the others.

Here is what they look like in Fira Code, as I toggle the feature on and off:

In 0xProto only the <> is ligaturized:

To be clear, I'm not asking for ligatures that deform shape, just ligatures that move the characters closer together.

[msaktype]

<> had been provided as a ligature for Haskell's concatenation operator and SQL and Pascal's inequality comparison operators.

From the perspective of JSX, it does seem inconsistent, but personally, I don't think ligatures for </ or /> are necessary.

[stevemolitor]

<> had been provided as a ligature for Haskell's concatenation operator and SQL and Pascal's inequality comparison operators.

From the perspective of JSX, it does seem inconsistent, but personally, I don't think ligatures for </ or /> are necessary.

I agree, they're not necessary. I think grouping the characters </ and /> together helps though, as it hints that they are not two discrete characters but rather a single "closing tag" indicator.

Having a <> without a corresponding </> ligature does look odd when using JSX fragments:

The closing </> looks much bigger than the opening <>, and I would argue the </ and /> also look out of place compared to the more compact <>.

Perhaps these ligatures could be added behind a feature that users could optionally turn on?

[msaktype]

The closing </> looks much bigger than the opening <>

Exactly.

and I would argue the </ and /> also look out of place compared to the more compact <>.

But, if we do the same thing here, using the HTML in the attached image as an example, the spacing between i and </ seems unnatural compared to > and h. I found that it depends on how I design these ligatures.
Considering the above, if you want to add a ligature, </> may be the best option.

Perhaps these ligatures could be added behind a feature that users could optionally turn on?

You mean, is it possible to enable specific ligatures optionally? If so, the answer is yes.

For example, GitHub's monaspace allows users to select the ligatures they want to enable.
However, to get a bit technical, these are not ligatures as defined in the OpenType specification, but rather implemented as stylistic sets.
Therefore, when configuring ligatures in VS Code, you need to specify them as:

“editor.fontLigatures”: “‘calt’, ‘ss01’, ‘ss02’, ‘ss03’, ‘ss04’, ‘ss05’, ‘ss06’, ‘ss07’, 'ss08', 'ss09', 'liga'”

and they may not work in applications that do not support stylistic sets.

I believe that providing the ligature functionality under the name “ligature” (technically liga or calt) would be less confusing and better than giving users options.

[stevemolitor]

But, if we do the same thing here, using the HTML in the attached image as an example, the spacing between i and </ seems unnatural compared to > and h.

That's a good point. I think it's important that opening < always line up:

  <div>
  </div>

It would look weird if the second < were shifted to the right, because then it wouldn't line up with the < on the line above.

That means the / has to shift to the left, which means there will be more space than usual between the / and the d. You can see that in Fira code gif I pasted above. I can live with that, but it is a little weird.

I found that it depends on how I design these ligatures.

Unless you found a solution to that issue?

EDIT:

Oh I see, you could extend the bottom or top arms of < and >. JetBrains Mono looks like this:

I like that, others may not. Does that "deform the shape" of the characters, and thus not in keeping with 0xProto's approach to ligatures? It's kind of borderline I guess.

You mean, is it possible to enable specific ligatures optionally?

I was suggesting putting these new ligatures in a stylistic set, but it sounds like you are suggesting that might be too complicated for users. I use Emacs and have to use external software to turn on stylistic sets, so I definitely see the appeal of just baking it all in via liga!

So just to make sure I'm following, the idea is to:

• add a </> ligature, to be consistent with <>
• do not add </ or /> ligatures? Or do add them a la JetBrains?
• add the new ligature globally via liga or calt.

I hope I'm understanding correctly, and thanks again for a great font!

[msaktype]

Does that "deform the shape" of the characters, and thus not in keeping with 0xProto's approach to ligatures? It's kind of borderline I guess.

As mentioned in the README, “deform the shape” refers to changing characters like != to ≠, which is a common way to handle ligatures. However, in 0xProto, we define the range where characters appear to be connected, such as <> or ->.
Therefore, even if I were to implement ligatures for </>, </, or />, I would only adjust them to bring the characters slightly closer together.

do not add </ or /> ligatures? Or do add them a la JetBrains?

I will try to add both, and also </> too!

[msaktype]

By the way, this is beyond the scope of the discussion in this issue, but what do you think about the idea of removing ligatures that only shorten the distance between characters other than arrows (such as -> or =>)?

For example, -> is not just about reducing the distance between - (hyphen) and > (greater), but also about making it look like an arrow. Therefore, I believe that keeping these ligatures is meaningful because they make it easier to convey the intended meaning in the input text. However, I am starting to question the significance of ligatures like ??, .., or ! =, which simply reduce the distance (by a very small amount), I am beginning to question the significance of their existence.

[stevemolitor]

I will try to add both, and also </> too!

Great! That's probably the most consistent approach, given that the <> ligature already exists.

Therefore, even if I were to implement ligatures for </>, </, or />, I would only adjust them to bring the characters slightly closer together.

I noticed that Fira Code does extend the bottom and top bars of the < and > characters slightly, but that was not apparent to me at first glance. It's subtle, though, and doesn't look "deformed" to me. So there might be a compromise approach.

[stevemolitor]

but what do you think about the idea of removing ligatures that only shorten the distance between characters other than arrows (such as -> or =>)?

I am starting to question the significance of ligatures like ??, .., or ! =, which simply reduce the distance (by a very small amount)

I love these ligatures! I requested a .. ligature (which you added, thanks!), actually.

I think by grouping characters like == or || closer together, it helps signal that they are a single semantic unit, a single operator. Syntax highlighting has a similar effect, and I think the ligatures complement it. When reading code, it helps to chunk things up, so that it doesn't look like just a stream of line noise.

Plus, it would be inconsistent if certain two-character operators were ligatures and others were not, IMHO.

But I'm sure you'll get lots of opinions on this - it is subjective!

[msaktype]

I think by grouping characters like == or || closer together, it helps signal that they are a single semantic unit, a single operator. Syntax highlighting has a similar effect, and I think the ligatures complement it. When reading code, it helps to chunk things up, so that it doesn't look like just a stream of line noise.

It makes sense 👍 I have also found from experience that when writing code, even if only slightly, visual feedback during text input through ligatures is helpful.
I'll leave all the ligatures as they are.

[msaktype]

Sorry for the delay. I've released v2.501, which includes the proposal from this issue.