@awight: Assuming this task is about Cite, hence adding project tag so others can find this task when searching for tasks under that project or looking at that project workboard. Wondering how this task is related to T151305: More edge case handling for "extends" parameter? Duplicate? Dependency?

During story time we found one scenario that concerns us: What if users are so used to certain errors shown where they are shown now, that moving the error will break their workflow?

We think we need more input fro UX people to find a good answer and a way forward.

From yesterdays story time about this ticket:

• We had a look at all the different ways Cite is reporting errors. There are 3 or 4 different places an error message can show up. Often the context is entirely lost. E.g. a bad dir="x" results in the <ref> not being rendered at all, like it does not exist, resulting in many more confusing errors that have nothing to do with the bad dir.
• We might start working on this in 3 steps:
  1. Check if it's possible to move some of the existing error messages down to the <references> section. Note this is only possible for error messages that do not make the code ditch the erroneous <ref>. It might be there are none of these.
  2. Make the code not ditch erroneous <ref>, but render a [1] footnote marker instead. Render these in the <references> section with the error message appended to the text if there was any, otherwise only the error message. Note: This should be done one error message at a time to keep patches and possible impact small.
  3. Make the erroneous [1] footnote markers stick out by coloring them red, or add a red exclamation mark icon. Ask WMDE-Design for a design. Note this last step is optional and should only be done if we can invest the resources.

#2 would be great since most errors at the end of the day do end up there
today.