jeffb wrote:

I'm not sure if this suggestion is calling for an editable text box for
references, or just a static display. I would be happy with a static display
of references at the bottom of every edit preview, so that you preview the
text between your <ref></ref> tags even if the section you are editing does
not include the <references/> tag.

snoutwood wrote:

(in response to comment #1): I can only really imagine it working for a static
display. It could be set so that when one previews their edit, below the preview
for the page would be a references section showing the refs within the
section/page they're editing.

scot wrote:

The intent is for a window in which to edit the references. What this means
depends upon the supported annotations. For <ref> it might mean edits would
also alter the reference's hidden text within the article. For Wikicite
database-type citations it might mean an interface with the collection of source
publications.

• Bug 19739 has been marked as a duplicate of this bug. ***

Can we have a static display of <references/> first?

An editable version is a nice idea, and could be linked to directly from <references/> and {{reflist}}, but it can wait.

<ref> is Extension:Cite, moving bug

A suggestion made by an IP on [[WP:VPIL]]:

"Isn't a workaround extremely easy to implement? If find in string text being previewed does not include {{reflist... make the code print a {{reflist... right before displaying the wikiEditor div."

Seems a bit inefficient in my mind. But a thought, at least.

These seem redundant or overlapping:
Bug 2745 - Have References text edit window on Edit pages
Bug 30777 - In-place editing of citations
Bug 31672 - Add JS popup citation creator

Does VisualEditor fill the requirements?

In T4745#70681, @Gadget850 wrote:

These seem redundant or overlapping:
Bug 2745 - Have References text edit window on Edit pages
Bug 30777 - In-place editing of citations
Bug 31672 - Add JS popup citation creator

Does VisualEditor fill the requirements?

Having closed the other two due to VE catching those requirements, I'm not quite seeing the case here that VE does the job. Part of that, I think, is that the problem description is kind of lacking--what's the root reason the editor needs to see both things at the same time?