Template talk:EB1911 Fine Print

Font-size

@DivermanAU: @Billinghurst: I am thinking of changing the setting of font-size to "smaller" rather than "90%". On some platforms, "90%" may be approximated by "100%". In any case, I don't think we are looking to make things look the same as in EB1911, but analagous, so people can easily differentiate the regular from the fine-print passages, and I think the "smaller" setting is more likely to do this reliably. I don't think the "line-height" setting is effective anymore. Setting "display: inline-block" may be needed, but this can result in linefeeds between adjacent invocations of this template, which is undesirable. So I don't think the display setting should be used in this context. Library Guy (talk) 17:19, 29 October 2015 (UTC)

Hi @Library Guy: and @Billinghurst:, thanks for creating a discussion on this. My thoughts are that the current 90% is small enough, (I measured the actual size of Fine Print to about 92% on a scanned image of the EB1911). If it's smaller than 90%, the text can become hard to read, particularly with subscripts etc. which is not uncommon in the References in Fine Print at end of article (I've included XVII^le in the samples below - which is the French method displaying 17^th which I've seen a few times in Fine Print. I recently saw “part 2^a” in Fine Print on Page:EB1911 - Volume 05.djvu/303.

This is a test line of text - The quick brown fox jumps over the lazy dog. XVII^le part 2^a - standard size

This is a test line of text - The quick brown fox jumps over the lazy dog. XVII^le part 2^a - ⁠ Fine Print size (currently 90%)

This is a test line of text - The quick brown fox jumps over the lazy dog. XVII^le part 2^a - ⁠ smaller size

My vote would be to keep the Fine Print size as it currently stands; I feel if it's any smaller it is harder to read (particularly for the ever-increasing ageing population) and becomes too different from the printed version. — DivermanAU (talk) 02:13, 30 October 2015 (UTC)

It would be my opinion that the word font size chosen should align with the templates (fine/smaller/x-smaller/larger) and the same variations with line height in (smaller/larger/... block) as these are what the community has chosen through experimentation/discussion, see the results at template:smaller/doc. Consistency is important. — billinghurst sDrewth 03:56, 30 October 2015 (UTC)

@DivermanAU: @Billinghurst: The discussion at {{smaller}} was helpful. So I think we could align this with the "fine" setting at 92%. It seems we could just redirect this template to {{fine}}. Library Guy (talk) 15:59, 30 October 2015 (UTC)

Wondering whether {{fine block}} may be more appropriate as it has line space, and it is for a div. OR we can just get a bot to go through and to replace. — billinghurst sDrewth 22:41, 30 October 2015 (UTC)

As a further point of reference the DNB project uses {{smaller block}} at the end of articles, eg. Darwin, Charles Robert (DNB00) 22:52, 30 October 2015 (UTC)

There is no EB1911 fine print/c

For text which is split across two pages, the template documentation recommends using {{EB1911 Fine Print/s}} and {{EB1911 Fine Print/e}}. But without a corresponding {{EB1911 Fine Print/c}}, how do I use them? --Siddhant (talk) 04:06, 11 April 2016 (UTC)

Should this be a block template

This is a span-based template, which means it:

• Can't change the line height as advertised
• Should not contain any block-based content, including other block-formatting templates like {{block center}} or paragraph breaks, which is not documented (except incorrectly to say you can "sometimes" run paragraph together in one template call: this throws linter errors, though it does at least render out, edit: for now, this will break when the parser changes)

The /s and /e variants are block-based (they use divs) and they do change the line height as advertised. It seems a bit strange that this is the case as /s/e variants generally don't have different rendering to the "plain" variant.

Is there any use of this template in-line? I've only seen pages where it is applied to a whole paragraph, where a div can be used. I'm not quite sure how to check, short of downloading the wikitext for each page it's used on and making sure this template is at a line start. Inductiveload—talk/contribs 23:33, 21 January 2018 (UTC)

I agree. If this template is really needed, I would create a div based version and substitute it, as I guess it is mostly used with paragraph breaks. And if cases are found where this is really needed, they can be handled as they happen. — Mpaa (talk) 20:53, 25 February 2018 (UTC)

There appear to be a few places where this template is used in a non-block way:

• Places like 1911 Encyclopædia Britannica/Homer, where it is used in section titles. This is not how the original work is formatted anyway.
• A few pages like Page:EB1911 - Volume 08.djvu/181, where it is a continuation of the last page, which should be done with the /s/e templates anyway.

I'm trying to generate a list of these usages, but it's a bit of a faff! Inductiveload—talk/contribs 11:48, 17 April 2018 (UTC)

Here is a first shot at such a list, taken from nearly 20000 just over 15000 template usages, there are only about 250 "suspicious" usages, mostly from titles and page-continuations: User:Inductiveload/Maintenance/Suspicious EB911 Fine Print usages. It's still not clear to me that there are any valid uses of this template as a span, though there are certainly places where, due to template misuse, converting to div will break things currently. Fixing usages in these pages should make it possible to replace with a div-based one. Inductiveload—talk/contribs 13:14, 17 April 2018 (UTC)

Please change span to div

This template is used with paragraph breaks and note that once Tidy is replaced with RemexHtml by end of June, the styling will no longer apply to anything beyond the first paragraph and your rendering will break. You can see this here. On the left, you see the current rendering. On the right, you see the new rendering.

To address this, you should replace the span tag with a div tag. I would have done this myself but I see that User:JustinCB's edits to do this were reverted by User:EncycloPetey. SSastry (WMF) (talk) 19:24, 16 April 2018 (UTC)

See discussion in previous section on this issue. --EncycloPetey (talk) 19:27, 16 April 2018 (UTC)

I see. Looks like you don't want editors to use this template where multiple paragraphs are involved. Anyway, I suppose when Tidy is removed and the rendering breaks, editors will fix those uses? But, Special:LintErrors/html5-mesnesting gives you the list of pages affected. There are a fair number of entries against this and against Template:Fine which is affected similarly. SSastry (WMF) (talk) 19:50, 16 April 2018 (UTC)

The template {{fine}} is supposed to be a span template, and does not need to be fixed. We have {{fine block}} which is a div template. --EncycloPetey (talk) 20:03, 16 April 2018 (UTC)

Got it. I am mostly pointing out that there are several pages which seem to be using these templates incorrectly and will need to be fixed - otherwise their rendering will be different than intended once Tidy is replaced. SSastry (WMF) (talk) 03:52, 17 April 2018 (UTC)

Perhaps it should have "display:inline-block;" added to the style="", though, so it could still change the line height(but still it wouldn't work across paragraphs). JustinCB (talk) 14:48, 17 April 2018 (UTC)

I'm not going to make that change though because I got a real stern warning about changing templates. JustinCB (talk) 14:50, 17 April 2018 (UTC)

@SSastry (WMF): What do you think about making it inline-block ? JustinCB (talk) 17:54, 25 April 2018 (UTC)

@JustinCB: User:EncycloPetey is suggesting that all those individual pages that use these templates incorrectly should be fixed instead to use the right block-based template. So, either a bot or editors would have to do that fix. Or, this will happen post-June after Tidy is replaced everywhere and editors see the change in rendering. SSastry (WMF) (talk) 18:38, 25 April 2018 (UTC)

Broken at the moment

So, was this edit to change it from span to div formatting responsible for the fact that all the transcluded articles using this template are now broken? It's creating breaks at every new page instead of carrying over into the next as a single paragraph. See, e.g., the broken small paragraphs at "Money" in the EB9. That didn't used to happen at all.

I mean, yeah, we can "fix" the problem by moving all the text in small paragraphs to a single page, but it seems like a lot of needless work if there's an easy way to repair the template. — LlywelynII 06:42, 1 March 2019 (UTC)

Bug: Invisible newlines can become paragraph breaks

In Wikimedia markup, as in HTML, a single newline within text is treated as a space or a word-break. In Wikipedia, this creates a minor nuisance, by enabling ambiguous of "semi-split paragraphs", where it is not clear whether the previous editor(s) intended a single newline between sentences to start a new paragraph or to continue the open paragraph. But in Wikisource, the invisible newline in markup is a resource, in that the lines of the markup can be kept in synch with the scanned image, for easier proofreading.

Currently, these templates can violate that convention. If the contained text contains single linebreaks, the template can fail to render it as a single paragraph.

With {EB1911 fine print/s}text{EB1911 fine print/e}, the last line gets treated as its own paragraph, UNLESS the contained text is followed by a newline.

With {EB1911 fine print|text}, the first line gets treated as its own paragraph AND the last line gets treated as its own paragraph, UNLESS the contained text is preceded by a newline and followed by a newline.

Sometime the extra newline needs to be added to the noinclude header or noinclude footer to make the text render correctly.

(The HTML comments here are not necessary for correct function, but they are necessary as a safeguard against breakage by subsequent editors who don't now the unwritten rules.)

(To see the codes, edit this section.)

Once-broken, using {EB1911 fine print/s}text{EB1911 fine print/e}:

First first first first first first first first first first middle1 middle1 middle1 middle1 middle1 middle1 middle1 middle2 middle2 middle2 middle2 middle2 middle2 middle2 middle3 middle3 middle3 middle3 middle3 middle3 middle3

last last last last last last last last last last last last.

Worked around, using {EB1911 fine print/s}text{EB1911 fine print/e}:

First first first first first first first first first first middle1 middle1 middle1 middle1 middle1 middle1 middle1 middle2 middle2 middle2 middle2 middle2 middle2 middle2 middle3 middle3 middle3 middle3 middle3 middle3 middle3 last last last last last last last last last last last last.

Twice-broken, using {EB1911 fine print|text}:

First first first first first first first first first first middle1 middle1 middle1 middle1 middle1 middle1 middle1 middle2 middle2 middle2 middle2 middle2 middle2 middle2 middle3 middle3 middle3 middle3 middle3 middle3 middle3 last last last last last last last last last last last last.

Worked around, using {EB1911 fine print|text}:

First first first first first first first first first first middle1 middle1 middle1 middle1 middle1 middle1 middle1 middle2 middle2 middle2 middle2 middle2 middle2 middle2 middle3 middle3 middle3 middle3 middle3 middle3 middle3 last last last last last last last last last last last last.

Move

Don't, unless you're also fixing all the redirects here so we don't end up with hundreds of broken pages. — LlywelynII 09:27, 10 March 2019 (UTC)

At least you stated that the move caused an actual problem. I am sorry for not catching it. (I would have worked around it by promptly undoing it.) (I am glad someone undid it.)

Renaming a page does not break links on other pages, because every move leaves a redirect page. The referring pages never need editing because of a move. (Wikipedia 101.) Renaming a template does not break pages that invoke it – at least not on Wikipedia, where ten-thousands of pages invoke templates by their prior names. (This is not universal – renaming an image on Commons (only via move-request) triggers bot action to necessarily adjust every invoking page.)

"My" template-move here broke some/many/all invoking pages. (D'oh!) I have to believe there is [yet another] bug or incorrect setting here. (Wikisource is not Wikipedia?)

I had good reason to rename this page to {EB1911 fine print} (as it should have been named originally): Most names use sentence case; Title Case Is Inappropriate. Also for consistency with {EB1911 fine print/s} and {EB1911 fine print/e}, which are named correctly and share the same /doc in spite of different casing.

{EB1911 fine print} always worked (and still works), despite its different casing. It appears to redirect without an actual redirect page - MediaWiki said it moved over redirect, but it might actually create a micro-redirect instead. After "my" move, I looked for an actual redirect page, and there was none. The search box redirected to the new page name, but when I edited the URL to the former name, I got "page not found". (Maybe it avoids leaving a redirect page when only the case is changed; maybe never leaves a redirect page.) Not leaving an actual redirect page might be part of the mess I caused – it is the kind of thing that could confuse the caching of pre-assembled pages.

After my move, I loaded a random page that uses the template, and it displayed correctly.

I saw one strange sign that I should not have shrugged off. After the move, a recently-edited page that uses {EB1911 fine print} and was displaying correctly displayed as if the template (now with the exact case-matched name) did not exist. I did a "null edit" on that page, and it displayed normally. That specifically suggests that there is a caching problem.

If the move broke any other pages, every broken page would be fixed by a "null edit" (not that I'd suggest it). When renaming a page that only changes case, apparently MediaWiki should either cache-void every page that includes the renamed page, OR leave an actual redirect until the caches expire. It's a bug.

In the interim, moving the template back was the sensible work-around (ignore the invalid edit-note given). -A876 (talk) 21:03, 11 March 2019 (UTC)