Use of <span class=hidden></span> to hide citation definitions

Question

Wiki text can be hard to read and edit if, when in edit mode, the text is broken up by lots of lengthy in-line citations. To address that problem, recent versions of the MediaWiki software (which provides the software that powers Wikipedia and lots of other wikis (including, I think, WikiTree)) allow grouping all the full references together at the end of the profile, giving each a name, just using the short name in the in-line text, and wrapping the block of full references with <references></references>. See https://www.mediawiki.org/wiki/Help:Cite#Separating_references_from_text WikiTree, however, does not yet support the use of <references></references>. As a work around, some of us have been using basically the same approach endorsed by MediaWiki, but, since <references></references> are not yet supported by WikiTree, instead surrounding the block of full references with <span class=hidden></span> to suppress the footnote flags that would otherwise appear at the end of the profile where the block of full references are. No use of <span> tags of any type is officially "not recommended", but their use is very clearly not forbidden. There are thousands of well-developed profiles on WikiTree that use this approach. As an example, see the profile for Aquila Chase.

Recently, a new Suggestion was added that identifies as an error all uses of <span class=> and <span style=>, which suggests that the work around described above is an error that needs to be "fixed" - eg by moving all the full references back into the text, thus recreating the problem that the approach solved.

I would like to propose that, until WikiTree adds support for <references></references> tags, the new Suggestion be modified so that it does not flag <span class=hidden> usages. (I note that Suggestions already only flags certain uses of <span> tags even though, since September 2021, WikiTree does not recommend the use of ANY <span> tags.)

I would also like to encourage WikiTree members to NOT "fix" the use of <span class=hidden> by moving the full citations into the text where they are used. If and when WikiTree adds support for <references></references> tags, the correct fix will be to replace <span class=hidden></span> with <references></references> tags and to move the whole references block under == Sources ==. Until then, I think the use of <span class=hidden></span> as a work-around for the fact that WikiTree does not yet support <references></references> tags, should be viewed as an acceptable (even if not recommended) use of <span> tags.

I would like to encourage WikiTree to add support for both <references></references> tags AND <ref extends=> tags as soon as possible. The latter tag is MediaWiki's solution for dealing with references to multiple different pages of the same source, a problem that has also encouraged people to use <span> tags as a workaround (in that case, <span id=> tags). See https://www.mediawiki.org/wiki/Help:Cite#Citing_different_parts_of_the_same_source

Comments

THANX, Edison - I had not taken the trouble to look up the version numbers or their release dates, instead depending on my defense of practically any mistakes I make by the claim that, being a girl, what do I know from numbers?

---

Yeahsure, Gaile. Uh huh. Right. And, after all, Albert Einstein was just a patent clerk.  

---

It's all relative. I'll show myself out.

---

A big round of applause, folks! Jonathan will be here through next Wednesday. Two shows a night except on Monday. And please be sure to tip your waitstaff!

---

Gaile, you said above (in addition to an earlier similar remark):

Currently the Style Guide directs us to place the container set of <ref name="something"> citation goes here </ref> at the first instance of use of that source and can only use the <ref name="something" /> empty tag at later places in the biography.

Those are statements that the order of ref tags matters. (Where exactly does the Style Guide say that, incidentally?)

Also it seems to me that Chase's proposal to allow <span class="hidden"> is only as a temporary stopgap; his ultimate request is for <references> ... </references>.

It is well known that WikiTree is unlikely to upgrade from MediaWiki v1.11. That version was apparently extensively modified to suit WikiTree (the modifications are a major reason why an upgrade would be difficult).

Since it's been modified already, it could be modified again; in other words, WikiTree could retake control on an ad hoc basis, instead of upgrading. A potential new modification would be to allow reference definitions to be gathered from between tags <references> and </references> (where they would be hidden). Chase indicated here that Aleš is looking into a possibility along these lines.

Edited to add: See also a more recent answer from Aleš.

---

Jim, on this page, under the heading "Advanced Sources", it says:

Here's how to use the same source citation multiple times. The first time you use it, include a "name" inside the ref tag, like this:

<ref name="birth certificate">Birth Certificate of George Russell Beebe, Registration 398-5554-428 (1920), Missouri Department of Health and Senior Services - Bureau of Vital Records, Personal copy in the files of [[Beebe-655|Barbara Beebe]]</ref>

In all following references you can just use this:

<ref name="birth certificate" />

I don't see that saying that the order of the ref tags matters - it only says that's the way they want WikiTree profiles to be.  The language does not require the container with the full citation has to be used before the empty tag with the same name attribute can be used.  The only language requirement for ordering tags related to sourcing is that <ref> or <ref /> tags must all be located earlier in the document than the <references /> tag.

As I understand Jim's request, it's temporary nature is until the <references> tag becomes available, which will happen if and when WikiTree updates to a newer wikimedia version.  

There happens to be an even easier fix than using the id attribute of the span tag.  If WikiTree added a class to its main CSS file, it would take only 2 or 3 lines of code there to suppress display of anything between the Sources heading and the <references /> tag.  Modifying a CSS file is not the same as modifying programming code - it is a fast and easy edit to do without need for extensive testing to ensure that it does not induce any adverse impacts to anything else.

---

Ok, Gaile, I guess it comes down to the meaning of "matters".

I would interpret what the Style Guide says as a pedagogical simplification, not a policy requirement that definition precede use.

What you say about CSS is appealing, but might be dangerous, because there are probably many existing cases where contrary to rule there is desirable material between the Sources heading and the <references /> line. Would it be possible to distinguish between <references /> and </references>, displaying in the first case but hiding in the second?

---

Please do consider that sourcing (or whatever you prefer to call it) is already difficult enough for some people.  Please let us not get so overly complicated we end up with even more unsourced profiles, or badly sourced, or complaints that "someone messed up my sources because. . ." when some well-meaning Wikitreer adds a new source and doesn't understand your "sources can be between the tags here, but not here".

Having a simple, working method allows for fuller collaboration than everyone having a different "style".  I have gone to edit some profiles to correct a "suggestion", or to add a source, or a biological item, and I just click away without doing anything because I simply do not understand the "style" used by that particular profile's manager.  This is not collaboration; it is control by use of non-conformity.  There's a good reason to not have anything between the Sources header and the <references /> tag - and that is that it's an easy method to follow.

---

Jim, it is certainly possible - and easy, too - to define a CSS class that would include exactly what you want to include and exclude everything else.  The only thing is that we start out here with a problem - that a few years ago a change was made to the Style Guide that prohibits us from putting anything at all between the Sources heading and the <references /> line, so what we've been talking about is not in keeping with the Style Guide as it now stands.

Before they made that change, I put all my <ref> container tags between the Sources heading and the <references /> line, but since then I have been gradually changing them to meet this new arbitrary requirement, as well as the other one requiring the <ref> container to be used the first time that source is used to support a statement in the biography.  I am now putting them all at the start of the document and, to make the undesired line of number links at the top of the page look more purposeful, I insert "source index:" just in front of it (see my father's profile for an example).  I'm hesitant to risk someone going in and editing it for me by providing an easy link to it, but will take the risk of also offering an example of how I did it before it was a no-no to put anything between the Sources heading and the <references /> tag (see this profile, which I have not yet gotten around to changing).  Note:  both ways have the line of number links visible to avoid using the "not recommended" class attribute of the <span> tag, which was then also on the no-no list but I would much rather have them not display on the view page.

---

Re not having anything between Sources and <references/> - I think one reason for this guideline is that WT's merge process automatically takes anything between Sources and <references/> and puts it below <references/>. Since <ref> tags don't work if they are below <references/>, any references that were between Sources and <references/> will be invisible in the merged profile and will need to be moved.

Answer 1

Hi Chase
I can't see that you mention clicking on the "Turn on Enhanced Editor' box, which is at the bottom of the biography section in Edit mode, as an option.

Although the inline citations are still visible, it makes it much clearer what is actual text and what is citations and other wiki mark-up.  I use that often when creating or editing biographies which use in-line citations.

I should add that I'm someone who uses and prefers 'lengthy' in-line citations for a variety of reasons.

Comments

I always use the enhanced editor, and it definitely helps, but also definitely not as good as separating out the full citations from the text.

---

Separating the ref tags on separate lines from the citation can create other issues, especially if there is too much space they read as missing ref tag issues.

Be careful using this to resolve visibility issues as that is not how WikiTree guidelines recommend the formatting.  It is best to use the Enhance Editor, not separating the tags on different lines.

Answer 2

An upvote for Chase's question. WikiTree absolutely needs a way to organize references and citations. I've also used a <span class=hidden></span> system on some of my profiles because after many years we still have no better option. And it's as much about creating proper, thorough reference lists as it is decluttering text in the biographical narrative.

As one example, see what is in production use at Wikipedia to accomplish both creation and separation of fully-qualified references from body text, as well as short, repeatable (and with different page numbers) inline citations. I've used their Harvard citation template on scores of Wikipedia pages.

Often overlooked in many G2G discussions about the subject is that there is a clear distinction, in most style systems, between a citation and a reference. Even WikiTree's own "Sources Style Guide" directly implies that we should be using both shortened, inline citations in addition to a section of fully-qualified references (note, though, that the Help page uses terminology at odds with most major style systems (e.g., Chicago Manual of Style, 17th Edition, items 14.1 through 14.67; MLA Handbook, 8th Edition, distinction between "works-cited list and in-text citations").

In scientific publications, the readers are typically expected to have the basic background knowledge necessary to understand why a work was listed in the references. In that regard, genealogy is more like a humanities publication...which is reasonable because our subject is really history. Many references are unique and require context and explanation, or in some cases a bit of transcription or interpretation. That's why Elizabeth Shown Mills in Evidence Explained--which on the WikiTree "Sources Style Guide" is stated to be the preferred method--writes that references have two purposes:

• To record the specific location of each piece of data; and
• To record details that affect the use or evaluation of that data

Accomplishing the second purpose using WikiText inline citations only is, in many instances, impractical to say the least. I even had the profile of one of my 3rd great-grandfathers edited in a complete makeover to remove my fully-qualified, detailed references and replace them with nothing but linked one-liners. The reason given by the Project Coordinator who did it was the citations were way too long and they cluttered the text in the biography. By that thinking, even a copied FamilySearch citation to a 1900 U.S. Census enumeration is too long and causes too much clutter.

Currently, without the use of correctly formed <span> tags, we have no way to create a comprehensive reference list to which shortened inline citations can link. I agree with Chase that, until WikiTree presents a solution, correctly formed <span> tags should be removed from the Suggestions list in order to help prevent exactly what occurred on the profile of that 3rd great-grandfather: a well-meaning soul deciding to "fix" what he or she deemed to be an error and undoing a lot of valid work in the attempt.

Answer 3

I am removing  <span class= hidden ></span> from this suggestion until we resolve this problem.

I did look into implementation of <references></references>, but it is not something simple. Our version of mediawiki is 10 years old and most extensions are no longer compatible. I will investigate further to see what can be done.

Comments

Thanks, Ales!

---

These suggestions are now excluded. Here are the new totals.

Suggestions	Total	0000-0000	0001-1499	1500-1699	1700-1799	1800-1899	1900-1999	2000-9999	Open	Hidden	New
Error 951: Not recommended tag SPAN CLASS=	469	4	7	55	89	232	82		433	5	2
Error 952: Not recommended tag SPAN STYLE=	5989	166	94	259	865	3436	1166	3	5657	67	17

---

Thank you, Ales.

---

You're the best, Alês!    

I wish there was some sort of temporary workaround using MediaWiki's template function--something that gives us a way to accomplish it without adding our own HTML tags--but I actually tried that a few different ways on a sandbox installation of my own a little over a year ago (on MediaWiki v1.33). The only way I found that seemed like it might work was to use a separate template instance for each reference item, and then many attempts would still fail seemingly due to MediaWiki's self-recursion controls. Seemed doable if we constrained ourselves to strict, content-type citation parameters like Wikipedia generally does with multiple different templates for different types of source media, but I think we'd reasonably need to be able to include just about every possible text and additional template combinations--like your external linking to Ancestry and Find a Grave--inside a fully-qualified reference. I also puttered around the citation-related stuff at Miraheze's Template Wiki seeing if someone had written a different solution. At one point I tinkered with creating for-purpose Scribunto Lua scripts...but abandoned that almost right away. Above my pay grade.  

---

Edison, there is a much easier way.  Just add a class to WikiTree's main CSS file, defining style of hidden for all instances of <ref> that occur after the instance of == Sources ==.