I don't think we should be passing this as options. buildExpression has generated the elements, why not update them here? I worry that passing options will result in descendent elements also getting these data attributes.

I can definitely take a look at this and see what makes sense. In my basic testing buildExpression was returning SymbolNodes which don’t have attribute support by default so that would still need to be added. I also want to make sure things like fraction bars and other visible elements get the appropriate attributes. But assuming I can get that working it does make sense to have this layer handle all of the data attributes so it’s less tangled into the general code base.

I've tried this out and it's close, but I end up with two options, neither works for our scenarios:

1. We iterate through elements and their children, applying the attributes. This gets our attributes applied to all children but also applies them to non-visual DOM elements used for spacing and alignment which is not good for us since it makes those invisible elements considered part of the interactive DOM.
2. We iterate through elements without looking at children and apply the attributes. This solves the above problem but then naturally means for things like \data{modelid=1}{\frac{3}{4}} we don't get our attribute applied to the 3, 4, or the fraction bar which is something we want so that we can tie all three of those visual elements back to our single model ID.

Without writing a series of special cases in the data function handler (e.g. apply the attribute to elements that have .text or one of a set of special class names), I'm unsure of a way to have it implement this logic without using Options. I can make the Options object have a more generic attributes instead of dataAttributes and wire it through the existing attribute handling code, but that's the only way I've found to get the full behavior we need for interactivity.

Why don't spaces get the data attributes?

You know, I wasn't totally sure but it wasn't something that we needed (or that really made sense). Our primary use case is attaching a "model ID" to DOM elements so we can do things like selection and interaction, and we didn't need to mark up white space. It also isn't clear which data attributes the space should get, for example in \data{a=1}{3}\data{a=2}{+}\data{a=3}{4} the spaces between the 3, +, and 4 don't really make sense to have any particular value for data-a since the LaTeX doesn't really define the spacing.