Feature request: Option to hide <ref> tag content in edit mode

+11 votes
364 views
A well-developed profile can have dozens of in-line references, each of which can be quite lengthy. This can result in the text of the bio being difficult to read and edit when viewed in edit mode. This problem has resulted in some people using a number of workarounds that are either not approved or are complicated - eg, putting all the full references at the bottom of the bio and then hiding them with a <span class=hidden> tag.

In order to improve the readability of bio text in edit mode without having to resort to a workaround, I would like to request an edit mode option to have the editor not display closing </ref> tags and the text between the opening <ref> and <ref name=x> tags and closing </ref> tags. Ideally, when the option is selected, clicking on a particular <ref> or <ref name=x> tag would toggle between showing and not showing the hidden text/tag.
in WikiTree Tech by Chase Ashley G2G6 Pilot (318k points)
edited by Chase Ashley

2 Answers

+7 votes

I think that's a terrific idea Chase!  yes

by Living Tardy G2G6 Pilot (773k points)
+6 votes
Isn't some of that addressed by the Enhanced Editor?
by Living Kelts G2G6 Pilot (557k points)
My thought also. It would be nice if the enhance editor could be enhanced to have an expand/contract option for the contents of the ref tags (i.e. a + or - symbol) that hides or shows the contents.
The Enhanced Editor highlights the inline references, making it easier to find where they begin and end, but it doesn't get them out of the way.  The Preview gets them out of the way, but on a long profile that leads to loads of tedious scrolling between the edit and preview panes.  I do like Rob's idea of incorporating Chase's improvement into the Enhanced Editor.  Seems like a natural extension.

So it would be something like?

This is a sentence. <ref name="source1">+ This is another sentence ...

And if you clicked on the "+" it would show

This is a sentence. <ref name="source1">This is the text inside the inline reference.</ref>- This is another sentence ...

Something like this should be an optional opt-in, as with the enhanced editor being opt-in.
It might be hard to implement in the enhanced editor unless CodeMirror (the underlying tech) supports it. I had a quick look here: https://codemirror.net/doc/manual.html#addon_foldcode

There is some support for "folding" in an addon.

The way Visual Studio Code (vscode) does it is with a symbol in a column or gutter to the left of the text. It has a "V" (down arrow) symbol in the gutter if a line can be folded and a ">" symbol if the line has been folded and can be unfolded. The "V" symbols only show up if you hover over the gutter.

That seems to be how code mirror does folding too. See demo here: https://codemirror.net/demo/folding.html

More info on the concept of code folding here: https://en.wikipedia.org/wiki/Code_folding

The WikiTree case is a bit different because there do not have to be any newlines in a paragraph with many inline refs. So it is not simply a matter of folding based on lines.

What Jamie suggested makes sense to me. But I think it might be hard to implement using the code mirror tech.
Is it easy to implement not in the enhanced editor?
I'm afraid I don't see the need, because I find the preview adequate. But if there is a change please make it optional, for example controlled by a setting. It's important that the full text of the biography box be available for copying, modifying offline or programmatically, and repasting. Also hovering as mentioned above doesn't work on tablets and other mobile devices.
Jim ... this request is not for the preview.  This is for the edit box.
Yes, Tommy, I know, but I find viewing the preview adequate as a method for separating out the inline references, so I don't myself see the need for a change to the way the edit box works, and I fear that such a change might have unwanted side effects. If other people do see a need then fine, as long as there is an option to retain the status quo.
I, too, find the preview view sufficient.  It is also handy for highlighting missed end-ref tags, or the lack of <references /> after Sources.
I think the preview is for testing your edits before you click the save button, so that you don't have to come back and edit the profile again and save again.

The preview does nothing for separating out the inline citations while in edit mode editing the text. I, for one, find the inline citations to be a clutter while editing a profile.  Also, I don't won't to spend my time scrolling through multiple lines of table code for multiple census records, as well as, any other inline citation that I can now include a table for.

I look forward to the day that the inline citations can be collapsible.  If, I am not mistaken, I think I mentioned this already in a previous post. Perhaps someone can find it.

Tommy, I think you are seeing a disagreement where there is not one.  I believe that what Jim and I are saying is "if this proposal would work for some people, please let it be optional for those of us who do not wish it, or for whom it will not work".

The enhanced editor — which is useful for some, but which not everyone chooses to use (I am one) — is optional.

That's all we are asking.  The option to choose it, or to not choose it.  (Presuming it is something that can be implemented at all.)

All you need to do is write your edit page like this:

John Smith was born in 1830 in Leicester, Leicestershire, England, United Kingdom.
< ref >
Birth registration source
< /ref >
He was the son of John Smith and his wife, Margaret Jones.

It is easy to see the sources and text and you can check that it still displays as a proper paragraph when you view the preview.
The problem with that method is you get a space before and after the reference number.

Fact one. [1] Fact two. [2]

I prefer the following:

Fact one.[1] Fact two.[2]
Those spaces can be helpful to those who experience vision difficulties.

Tommy, I solve that problem by putting the <ref> tag immediately following the text and using a new line for the citation and another new line for the </ref> tag.

... but I only do that on profiles that I do not manage.  For the ones I manage, I name all <ref> tags.  I used to put all the <ref name="something"> citation here </ref> immediately under the Sources heading, with the <references /> tag immediately under the last citation.  I found this worked very well, completely eliminating the bloat in the biography and it was also very helpful to have all the citations in one place.  

I used to use the span tag to suppress the line of numbered links this produces, until WikiTree changed the rule to make it a no-no to use span tags for this purpose.  I then had to go through all the profiles I created to remove the span tags.  The line of number links that are displayed immediately below the Sources heading on the view page actually serves as a sort of TOC for the sources that immediately follow it, although I would prefer not to have it visible.

Then WikiTree changed the rules so that, for reasons I cannot fathom, they require the <references /> tag to be on the line immediately beneath the Sources heading and also require that the <ref name="something"> citation </ref> must be used in the first instance, after which the <ref name="something" /> can be used.  

These arbitrary new rules, not at all needed to comply with any language constraints, create a monumental amount of work for me to have to again re-format all the profiles I created, but I found a solution that still keeps all the citations in one place and out of the biography text flow on the edit page, plus has them as the first instance before using the <ref name="something" /> to invoke them.  

I am gradually moving all my <ref> ... </ref> citation sets to the top of the profile, where I make the line of numbers linking to the citations look purposeful by preceding them by the line <sup>''source index:''</sup> (the 2 apostrophes are the code for italics, not a quote mark).  This is also less desirable (in my opinion) than having the citations on the edit page actually appear under the Sources heading, similarly to how they appear on the view page.

This is a very long and tedious job (although, for those who set store by such things, it greatly increases my contribution count) and is only made more so when some well-intentioned member decides to change the format of a profile I have not yet gotten to by removing all the <ref> citation </ref> tags and inserting them in the body of the biography.  More often than not, when they do this, they foul the format by either not putting a citation at the first instance of it in the biography, adding it to the <ref name="something" /> tag instead of replacing it (causing the same number link to appear twice at the same place), or fouling the formatting completely by an error like omitting a closing </ref> tag.  They don't usually contact me about it at all, but occasionally someone will write me a long message in which they go to great lengths to gently explain to me all about how what I did is not the way code works.

EDITED TO ADD:  See my father's profile for an example.

Gaile's method of sourcing is non-standard and not recommended. Not-recommended is not the same as forbidden so you don't have to rush through and make edits to profiles that use it, but please don't change profiles to this format.

One option for people who really want to be able to fold/collapse the inline references is to copy the biography text into another editor to edit it.

vscode is free and if you set the language to HTML it will allow you collapse this:

In the 1901 census Ralph was living in St Pancras, London, England. Relation to Head: Son.<ref>
'''1901 Census''':
"1901 England Census"<br/>
Class: RG13; Piece: 157; Folio: 47; Page: 38<br/>
{{Ancestry Sharing|24274440|95cf5c}} - {{Ancestry Record|7814|2229789}} (accessed 12 October 2021)<br/>
Ralph E Pavey (9) son in household of Hanry Alf Pavey (59) in St Pancras registration district. Born in London, England.
</ref>

to this:

In the 1901 census Ralph was living in St Pancras, London, England. Relation to Head: Son.<ref>...
</ref>

It does not allow collapsing of tables though.
Gaile/Jamie - I have been using the same technique of putting the full citations at the end of the profile, naming them, using only the short-form name in the text, and hiding the footnote flags at the bottom of the profile with <span class=hidden>. My request for an option to make ref tags collapsible in edit mode is so I can revert to putting the full citations in the text without the text being hard to read due to large blocks of citations breaking it up.

A more complete solution would address the issue as part of an upgrade to the editor that makes formatting citations easier for novices and allow people to do in-line citations without knowing anything about ref tags or spans - eg, (1) have an edit-mode side panel or floating window that would list all citations already in the profile and let you enter new ones, (2) have the ability to drag and drop a citation from the list into the text, resulting in the addition of a properly formatted in-line citation, (3) the in-line citations could either appear in edit mode as wiktree markup - ie with collapsible ref tags - or, preferably, as just footnote flags which if clicked would cause the related source to be highlighted in the citation list. But I'd settle for collapsible ref tags.
Jamie - If the use of <span class=hidden> tags to hide the footnote flags is only "not recommended" but is not forbidden, why is it being flagged as an error in the Suggestions list? I have >800 profiles for which I am a PM that now have this "error" message. This is going to cause Data Doctors to go around trying to "fix" perfectly fine profiles, which is (IMHO) just busy work and in many cases is just going to result in something getting messed up. Can we at least downgrade it to a Hint or a Warning?
The <span> tag is what is on the not recommended list, and just using a span tag won't cause an error to appear. But using "class" (and "style", I believe) in the tag throw errors. The errors are determined by the Data Doctors Project so you might want to discuss this with them.
Rob - Don't you only get collapse tags in VS code if the beginning and end tags are at the start different lines? In any event, except perhaps for a few coders, I don't think most people would find doing editing in a code editor a convenient solution.
VS code works if the <ref> is not at the start of the line.

The problem we are discussing is basically the same as what editors on Wikipedia face.

I think the *ideal* solution would be if WikiTree had a Visual Editor like the one on Wikipedia. Apparently most people editing on Wikipedia still use the basic text editor (like we do) but a sizable percentage now use the VisualEditor which is an extension from WikiMedia.

If you want to try that out go to this page and press the "Edit" tab at top right: https://www.mediawiki.org/wiki/VisualEditor:Test
Rob - Any chance you could come up with a Chrome extension to make <ref> tag text "foldable" in edit mode? I was thinking of trying, but have never done a Chrome extension before.
Ales is looking at https://www.mediawiki.org/wiki/Help:Cite#Separating_references_from_text as a possible solution to the problem of in-line full references making the text difficult to read/edit. Rather than making in-line references collapsible, it essentially duplicates the approach of putting all the full references down at the bottom of the bio, using only the short defined reference terms in the in-line text, and suppressing the extraneous footnote flags where the full references are defined. If support for this <references></references> approach was added to WT, I'd be very happy and would never be tempted to use <span class=hidden> again (although collapsible <ref> tagged text would still be nice for working on profiles that already have the full references in the body of the text).

Related questions

+5 votes
3 answers
+9 votes
1 answer
+4 votes
1 answer
252 views asked Jan 17, 2023 in WikiTree Tech by M. Lohmeyer G2G6 Mach 1 (13.4k points)
+20 votes
4 answers
+5 votes
1 answer
208 views asked May 1, 2023 in WikiTree Help by Siegfried Keim G2G6 Mach 6 (68.1k points)
+4 votes
2 answers
164 views asked Jan 27, 2023 in WikiTree Tech by Michelle Detwiler G2G6 Mach 2 (21.8k points)
+6 votes
1 answer
231 views asked May 25, 2021 in The Tree House by Pip Sheppard G2G Astronaut (2.8m points)
+2 votes
0 answers
+3 votes
2 answers

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright

...