refactor label.js out of existence

[pkra]

From #451 (comment)

Looking more at label.js, I think I'd rather get rid of that entirely and move its logic into the various parent pieces -- label and title are just too messy.

• case: fn 40f8899
• case: ref b5aebe2
• case: fig etc fe5bde5
• case: disp-formula-group
• case: statement
• complex cases

[pkra]

Random thought: this might end up somewhat differently - label and title could just create spans with respective data-ams-doc and parents create wrappers and recurse title and label with those.

[pkra]

fn is somewhat of a wrench - it injects a sup element inside the "typical" label span. This will make the idea from the previous comment a bit harder - unless we move sup-creation downstream (or even upstream).

[pkra]

For the record, the tags of label parents:

toc-entry
sec
book-app-group => sec
book-app => sec
app
disp-formula-group
fn
statement
fig
fig-group => fig
table-wrap => fig
table-wrap-group => fig
ref
secheading

[pkra]

disp-formula doesn't really need a figcaption wrapper around the label (or a figure for that matter).

[pkra]

To quote #457 (comment)

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.

Similarly, ideally, we'd have label and title just create spans with their respective data attributes and find a smooth pattern to handle any re-organization in the parents.

[pkra]

Similarly, ideally, we'd have label and title just create spans with their respective data attributes and find a smooth pattern to handle any re-organization in the parents.

On a related note, in fig.js, we map label to strong (via passthrough); that's really not necessary, semantically speaking but it would be a breaking change. (A generic label mapping would still need to be moved/redirected to the figcaption.)

[pkra]

After too much additional research, it's tempting to "just" reduce this to the case where we generate the heading. But that would be lazy - I'd prefer to reflect the complexity of the content here so there are no fewer surprises down the line.

Just to recap the parent elements

// fig-likes are already done
'fig',
'fig-group',
'table-wrap-group',
'table-wrap',

// overlap with fig-likes?
'statement',
'disp-formula-group',

// "just a label/title"
'fn',
'toc-entry',
'ref',

// tricky b/c pass-through - metadata and sometimes in sec-likes
'title-group',

// sec-likes where we want headings.
'sec',
'ref-list',
'book-app',
'notes',
'secheading',
'abstract',
'named-book-part-body',
'app',
'book-app-group',
'ack',

[pkra]

An update

• statement and disp-formula group were fairly straight forward, based on fig.js .
• fn, toc-entry, and ref already handle label/title on their own (but might benefit from refactoring once we have reduced label.js to just generating the label/title span)
• 'named-book-part-body' is only in an ancient book - the title should nowadays be in a book-part-meta title-group

This leaves

• sec, ref-list, notes, secheading, abstract and app seem fairly straight forward (just re-using what's in label.js right now)
• title-group seems tricky. It is passed-through right now. Outside metadata (which is handled) and toc (which is easy) it shows up in book-part-meta (another pass-through).