Why does MathLive use Unicode spaces for spacing rules?

What was the reason for implementing the TeX spacing rules with Unicode spaces? Do they match the exact "CSS translations" in em units as all the TeX spacings?

Also, how does this current approach compare to using margins/paddings to achieve the spacing?

And: why do some characters (including \pi, I believe) have some margin correction instead of using Unicode spaces?

[arnog]

The idea was to have more compact markup, i.e. a single character instead of "margin-right: 0.1667em". However, it turns out that browser are unfortunately not consistent in their rendering of these spacing characters (see #505). So, I'll be reverting to using margin in all cases.
As to why some character combinations are still using margins today, it can happen if the required margin (which is part of the font info) for this character does not match an existing spacing character width.

Different idea: would it make sense to implement glue divs as in TeX to represent the spacings? I am thinking about doing this in my fork and would first of all love to hear your opinion on this and secondly maybe this could be a good approach in general for MathLive itself, but I'm not sure. I think it would actually allow for maximum control over how everything is rendered. What do you think? 🤔

[arnog]

It's a possibility, but a potential downside is that it would create additional DOM elements (and possibly a lot of them). It would have to provide a clear benefit, but I'm not really seeing it right now.

That is, instead of:

<span style="margin-right:0.1667em">x</span><span>=</span>

(two DOM elements)

You would have
<span>x</span><span style="min-width:0.1667em"></span><span>=</span>

(three DOM elements)

The benefits I think of mostly have to do with simply having more clear control in some way over what is actually happening. One thing one could imagine as far as I see, for example, would be animations/transitions from display to text style that act directly on the glue divs (although this is not part of MathLive core but would provide a very solid basis for it).

Another plus would be to more easily catch UI events on the right DOM elements. At the moment, the divs are unproportionally shifted to the left, since the spacing is only applied to one side (although this would not be a problem anymore with margins). If you wanted to catch UI events on the spacings itself, for example, (which is theoretical but could be the case) it would basically be impossible or at least really hard and cumbersome to do so. I kind of feel like a glue implementation would be the most intuitive thing to do in some way, if that makes sense. It feels more 'complete' and maybe less prone to errors, since, imo, it is more straightforward to think about.

If you actually chose to do it this way, I would be very keen on helping to implement it or even implement it by myself completely and doing a pull request, if you don't have the time. Since I need to do this for my fork anyway, it would be great since I could hear your opinion on how to implement things.

[arnog]

As per #505, MathLive no longer uses Unicode characters for spacing but uses explicit margin adjustments.

So the proposal is rejected? 😢

[arnog]

At this time, I don't believe that using extra DOM elements to represent glue is the best course of action. As I've mentioned it would significantly increase the number of DOM elements created, and the number of DOM elements in a page have a significant impact on the performance of the rendering of a page (and the memory it consumes). Browsers have to do a lot of extra work for each DOM element in terms of layout calculations, styling calculations and rendering.

The potential benefits you mention might be more relevant in your fork, but they don't really seem to apply to MathLive. For example, the glue is not an addressable element: it is not represented by an atom, nor by a Latex fragment. A user could not select it and delete it. Furthermore, if it were separate DOM elements, some extra logic would have to be added to properly route the UI elements: when a click happen on one of those "glue" divs, some logic would have to be implemented to associate it to the correct atom. I'm afraid this would make things more complicated, not simpler.

I do appreciate the suggestion, though. It's always good to consider alternatives.

Well, that's fair. Thanks for the consideration anyway :) one question, though: what would your intuitive way of implementing this be? Would you implement glue as an elementary atom? And also, where in the MathLive source are the spacings handled/defined?

[arnog]

You could modify the markup generated to introduce additional DOM elements.

The code to do this is in Span.toMarkup(). The first argument of the function, hskip, is the quantity of the glue in mu (1/18 of an em).

The code section that begins with if (this.children) implements the inter-atom spacing as per the Latex rules.

The code section that begins with if (hskip) renders the glue accordingly.