1105227 - Create consistent vertical line spacing for templates and images in a numbered list

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task, P4)

Description

[Ton [:Tonnes]]

Attachment: Screenshots

For a while now, it has been clear that using hashes and colons or semicolons before images in Sumo articles results in inconsistent and too little line spacing when images are preceded or succeeded by text.

For clearness and possibly as a (unwritten) rule, any text line followed by an image in support articles should have exactly the same spacing as 2 text lines written on a new line, preventing text to “lie on top of images” or “stick to the bottom of a preceding image” and hence causing bad visibility of the text lines to users, especially in between two images. It should not matter if a hard return (i.e. an images placed on a separate line separated by empty lines - as is very common in TB articles at the moment), hashes or colons or semicolons were used. Currently, editors and localizers may apply tricks like adding <br><br> after a preceding text or before an image or a <br> in between a (semi)colon and an [[image...]] tag when hashes and colons or semicolon are included, creating enough (but a little too much) whitespace in order to create proper spacing between text and images. The same applies to text after an image - this should always be one line automatically regardless of what follows, so no <br>s should be needed in order to separate an image from succeeding text. And of course, issues like these should not be resolved by including whitespace in the images themselves, as is sometimes the case.

Note that when using {for} markup, spacing is affected and may sometimes be OK, though by possible coincidence.

See the attached example screenshots of text-image-text occurrences when using #:, #; and hard returns (only line feeds as separator) respectively. Using either # OR ;/: causes too little space in both cases.

1 #; - spacing before and after image is too litlle
2 #: - spacing before and after image is too litlle
3 hard returns only OR leaving out the hashes (#) - spacing before and after image is OK.

Comment 1

[Joni Chan]

Thanks, Ton. I'm moving this to the KB software component for SUMO Dev to address. "KB Content" is for article requests.

Comment 2

[Ton [:Tonnes]]

A nice example of what degrades when adding # is shown by a recent change to the How to download and install Firefox on Windows article.

Compare the content views of these revisions (images in steps 3 and 4):
https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-windows/revision/87578
https://support.mozilla.org/en-US/kb/how-download-and-install-firefox-windows/revision/87791

Comment 3

[Ton [:Tonnes]]

Is this likely to get fixed some day? There are quite some edits happening lately where images are moved to "block level" (by one user in particular ;-) ), causing more and more images to get squeezed in between text sections, unless #;<br>[[image]] is used as a workaround.

Long story short:

# This is text.
                             (empty line)
[[image]]
                             (empty line)
# This is another text.

… currently is the only proper way of creating fine (one line) distances between text and images, both before and after them (as currently is the case in most TB articles). Starting / indenting images with #, #; or #: and without the empty lines should display exactly similar - i.e. with an identical text line distance, for the benefit of proper reading (and to prevent bottoms and tops of button texts getting cut by images IIRC.)

Comment 4

[Michael Cooper [:mythmon]]

I have no idea how you got the idea of doing "#;" or "#:". Those are abuses of the syntax, as a leading # is supposed to create a numbered list. Why it doesn't for images, I don't know. Abusing syntax such as adding leading # before images is not something we can support.

As you pointed out, the only proper way of adding images in block-flow (as opposed to inline for small icons) is to leave a blank line between the image and the preceding/following text. This creates paragraphs. Why are you doing anything else?

Comment 5

[Lan Glad [:upwinxp]]

# This is text.
                          (empty line)
[[image]]
                          (empty line)
# This is another text.

and

# This is text.
[[image]]
# This is another text.

seem to do the same.

I don't know why we have to add ; or : before an image. I saw Scootergrisen's revisions (like this one https://support.mozilla.org/en-US/kb/update-mcafee-and-firewall-settings-allow-firefox-access/compare?locale=en-US&to=85300&from=77433) and I thought we have to do that in all articles. : and ; move images to the right a bit.

We have to add # before an image - numbering is incorrect if we don't.

Comment 6

[Ton [:Tonnes]]

That’s very useful info - I didn’t even know this is abusive syntax. It’s never been my decision to move them to blcok level that way either (nor did I do any such edit), it’s just what’s been happening for the past few years and triggered me to file this bug, as apparently it causes trouble.

So in order to have proper line spacing for images, we might need to change all instances in FF and other articles to hwo it’s done in TB / above, probably gradually, right? I’m not sure how this will affect the numbering though, as Marko wrote.

Comment 7

[Lan Glad [:upwinxp]]

Attachment: If there's no # before an image, numbering starts over and over again

Comment 8

[Ton [:Tonnes]]

Yes I know. A possible factor may be that TB articles hardly use any numbering at all so it remained unnoticed - or there was a need for numbering in FF articles resulting in the "abuse". The question however is how to solve this.

There is a difference when (not) using empty lines, but it may only be visible when not using # before an image. Try editing a TB article - https://support.mozilla.org/en-US/kb/automatic-account-configuration or its locale'’ copy is a good one to test with.

Comment 9

[Lan Glad [:upwinxp]]

Should we file a new bug? "Don't restart numbering when there is an image in it"

Comment 10

[Joni Chan]

I'm changing the title to Marko's suggestion in comment #9.

Comment 11

[Ton [:Tonnes]]

Joni: are you sure that’s a good title? This bug is mainly about non-similar and too narrow line spacings between text and images (before and after) when using #, #; or #:, which turned out to be abusive syntax for images and unavoidable to maintain proper numbering. Marko’s suggestion (that I kind of interpreted as a joke) was about a new bug for a separate issue, which is not really an issue IMO because separate images not following numbered list symbols (#) on new lines automatically cause new numbered lists for any new # after them, which makes sense.

Maybe this bug’s title should at least contain something about required vertical spacings similar to those between two text lines before (and after!) images, which is my main concern. Depending on what’s needed to accomplish this as well as a (new) solution for numbering along images within lists, Mike may know of a better title?

Comment 12

[Ton [:Tonnes]]

Attachment: templates_hash_diff.png

It may be a little disturbing to see many new articles created lately suffering this issue, especially the iOS articles.

Albeit abusive syntax, using #; before images reduces the space compared to ; only so obviously the # is the reason, not the ; or :, though that may be clear from the above. Attached is a screenshot to reflect this once again. Note the issue is all about d1 and d2 not being similar.

Templates that contain text on line 1 and images on line 2 not preceded by # (like tabios) display fine when viewing the templates only, but not when they’re included and numbered in articles. Including a blank line between the text line and the image in the template itself isn’t an option, since the blank line is obviously skipped when called from an article.

For images only: in the https://support.mozilla.org/en-US/kb/use-tabs-firefox-ios article for instance, leaving out the # preceding the images on current line 6 and 11 would fix the issue for these "2 step" sections, but a "3 step" section would still suffer it in the last step because of required numbering for the previous ones.

When testing, it turned out the issue is also valid when using bulleted (*) images. Joni told me it’s wrong to do so, but I only mention it here because I noticed the space below the image and before a new text line does not seem to be affected in such case, only the space above them is. However, called templates ending with images tend to leave a smaller space below the image and hence before the next text line step. This may be taken into account when working on this.

Regarding the bug title: maybe "Create consistent vertical line spacing for included numbered templates and images" would do?

Comment 13

[Ton [:Tonnes]]

A question that popped up while checking some TB articles: why is it that images do not get numbered when using #; while they do when using # only? It looks like some fix, but whatever the reason is, it requires us to use #; and hence indentation where that may not be desirable (and of course causes the issue this bug is about). For some TB articles for example, this means all images would need to be changed to use indentation when there is only one numbered list inside. Example: https://support.mozilla.org/en-US/kb/signatures.

Comment 14

[Alice Wyman]

The contributor article https://support.mozilla.org/en-US/kb/how-place-images-article says to use #; markup to place images in an ordered list.  Michel Verdi wrote that article in October 2013.

Joni, can you add your thoughts on improving that article? I have some edits pending but would really like your input.

Related discussion:
https://support.mozilla.org/en-US/kb/how-place-images-article/discuss/6559
https://support.mozilla.org/en-US/kb/adding-screenshots/discuss/6556#post-13421

Comment 15

[Joni Chan]

This is a kitsune-specific issue. I don't think it will be an issue in the new platform.

Comment 16

[Tim Casey]

Reopening as we've moved back to Kitsune for the time being.

Comment 17

[Seburo]

Closed as per https://blog.mozilla.org/sumo/2019/06/07/sumo-platform-roadmap/