next steps for ref-

[pkra]

As expected, #3 is not good enough for all of m522.

As a first complication, there's a ref- pointing to the cantor set figure - not a theorem, thus no label to be found.

[pkra]

Some other scenarios that likely fail

• ref- pointing to equation tag, sectioning, or random ids (i.e., some fallback behavior)
• ref- before its target - will probably cause a timing problem (a target theorem probably hasn't been upgraded by then so the label will be missing) -- could be solved by mutation observer

[pkra]

We could also try to reverse things - have targets update ref-.

[pkra]

And of course it doesn't help to have mismatch between ID and ref's target. I fixed a few I must have mucked up when setting up the HTML.

[pkra]

Here's a random idea: attribute for different types/markup scenarios.

E.g., <ref- thm=thmid> for refs to theorems. Then the code for ref- could more easily be organized into different use cases - and authors could subclass to add more methods for their use cases.

[pkra]

On second thought, that shouldn't be necessary -- the ID points to an element and we can simply organize by tagName.

[pkra]

Even better: since we probably want to DRY things, we could have the base class (statement right now) do a this.isStatement = true in its constructor -- then ref- can check against that to decide its code path.

[pkra]

I'm starting to like the idea that an element is responsible for its ref's.

This would make ref- unnecessary -- we could just just anchors.