review attrib.js

[pkra]

It looks a bit like label, cf. #452.

[pkra]

I think downstream actually needs something sooner rather than later (to identify attrib output, e.g., in book prefaces).

[pkra]

It looks a bit like label, cf. #452.

To clarify: attrib.js currently has 3 cases

• general: span in the parent
• if parent is disp-quote, we create a footer, then span in the footer
• if parent is figure, span in the figcaption (with the assumption there always is one)

I think downstream actually needs something sooner rather than later (to identify attrib output, e.g., in book prefaces).

This refers to the fact that the general case doesn't really deserve that name.

To step back: we only have 466 occurrences of attrib across all publications right now.

Of those, 245 are case 3 (figures with photo credits) in 2 older books (mbk103, clrm067, which were both pretty special cases in themselves).

The second case (disp-quote) occurs 163 times, almost always via \epigraph.

So the "general" case is just 58 cases. One is a hack for a verse (in an MCL) and the rest seems to come down to \aufm, cf. https://github.com/AmerMathSoc/texml/blob/5b62cf9ad9171063a843345cc99e82bfa36b3046/lib/perl/TeX/Interpreter/LaTeX/Class/amsclass.pm#L1122

Now as mentioned earlier, \aufm macro shows up pretty consistently at the end of book prefaces as well as some articles (NOTI letter-likes). (Doing this research brings up some questions around aufm output which I'll file on the texml end.)

---

Regarding the OP, I still agree that this is similar to the label.js situation. Ideally, attrib.js would just create a span (and importantly: add a data attribute which is currently missing). Then we'd need a good pattern to smoothly handle the other cases. The latter seems like the main challenge.

[pkra]

(Doing this research brings up some questions around aufm output which I'll file on the texml end.)

I could answer them myself. Older books have markup where aufm creates an attrib after a paragraph without opening a new paragraph. But texml does that nowadays (see the link above).

[pkra]

Then we'd need a good pattern to smoothly handle the other cases. The latter seems like the main challenge.

first idea:

    recurseTheDomRedirected = (htmlParentNode, xmlnode) => {
        this.recurseTheDom(htmlParentNode, xmlnode);
        xmlnode.remove();
    };

[pkra]

Initial refactoring looks good but extending this pattern to label is proving more complex. To be continued.