Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Regular Markdown images are incorrectly recognized as figures #1291

Closed
flobernd opened this issue Jun 6, 2024 · 8 comments · Fixed by #1292
Closed

[BUG] Regular Markdown images are incorrectly recognized as figures #1291

flobernd opened this issue Jun 6, 2024 · 8 comments · Fixed by #1292
Labels
bug Something isn't working

Comments

@flobernd
Copy link
Contributor

flobernd commented Jun 6, 2024

Describe the bug 描述你遇到的错误

Hi @HEIGE-PCloud, sorry to bother you again 🙂 I found another bug that is currently blocking me from migrating my blog to the DoIt theme.

In one of my blog posts, I'm using the following markdown content with the LoveIt theme:

- ![red](pin_red.png) +12V
- ![white](pin_white.png) Locked Rotor Signal
- ![black](pin_black.png) Ground (GND)

Note

The images do not specify a figure description. E.g. just ![red](pin_red.png) but not ![red](pin_red.png "Figure Description").

This generates the following output:
432-206-max

The images are correclty inlined and can't be clicked. They as well do not appear in the lightbox image selection:
1913-217-max

After migrating to the DoIt theme, the images are incorrectly recognized as figures which messes up the layout:
860-371-max

They are as well showing in the lightbox image selection:
3502-177-max

Expected behavior 期待的行为

Markdown images without a figure description should be inline and not recognized as figure.

Screenshots 屏幕截图

No response

Build Environment 构建环境

  • hugo v0.125.1-68c5ad638c2072969e47262926b912e80fd71a77+extended linux/amd64 on Docker
  • latest DoIt commit

Preview Environment 预览环境

Firefox on Windows 11

Additional Information 补充信息

No response

@flobernd flobernd added the bug Something isn't working label Jun 6, 2024
@HEIGE-PCloud HEIGE-PCloud linked a pull request Jun 6, 2024 that will close this issue
@flobernd
Copy link
Contributor Author

flobernd commented Jun 8, 2024

Thank you for the fix 🙂

@evilpan
Copy link
Contributor

evilpan commented Jun 20, 2024

Oh... this cause a lot of images broken like ![text](https://exapmle.com/image.png), since many markdown documents just use text as caption and not the Figure Description part, and even some markdown engine doest not support figure description well. So what about just treat raw images without both text and caption like ![](https://example.com/image.png) as non-figure? There's a lot of user that meets the same issue, for example dillonzq/LoveIt#213 dillonzq/LoveIt#238 dillonzq/LoveIt#490 and dillonzq/LoveIt#522 .

What do you think, @HEIGE-PCloud ?

@flobernd
Copy link
Contributor Author

flobernd commented Jun 20, 2024

If you ask me, the current (and original LoveIt behavior) is the most correct one. Standard markdown does not know about figures. Standard markdown just inlines images, like LoveIt/DoIt as well does now after the fix. The additional figure description text is ignored by most markdown engines (and if the engine complains, this is actually correct as it is not standard markdown 😋).

I don't see a benefit in changing the standard markdown behavior to something non-standard.

When I paste an existing markdown document in a blog, I expect it to look exactly like it is displayed in other markdown engines. Figures are exclusive to this kind of blog so in my opinion they should be enabled explicitly (by adding the figure description to the markdown image).

@evilpan
Copy link
Contributor

evilpan commented Jun 20, 2024

You are right, @flobernd. The standard markdown does not handle the the additional figure description text, thus most of markdown writers does not add it when inserting images to the document.

The question is, while rendering the markdown document, the default behavior of the image rendering shoud be add to gallary, click to enlarge or open the image in new tab. Which is what the most of markdown supported blog system do, even github's image will open in new tab when clicked.

Anyway, this is a preference matter. If someone is using [img](link) to insert images and want to make it show on gallary, she would need to add additional figure description text in EVERY previous image, which is quite annoying, I think.

@flobernd
Copy link
Contributor Author

flobernd commented Jun 20, 2024

the default behavior of the image rendering shoud be add to gallary

I disagree here for the above stated reasons. In standard markdown, these images (red) are inlined and not rendered as a figure. I personally would not like to have them in some kind of gallery. If you look at my original bug report, they create a lot of noise in the gallery.

or open the image in new tab

This would be fine for me, but I still don't see the added benefit here as one could simply add the figure description.

thus most of markdown writers does not add it when inserting images to the document

If someone is using [img](link) to insert images and want to make it show on gallary, she would need to add additional figure description text in EVERY previous image, which is quite annoying, I think.

Most markdown writers use images to decorate their texts. They expect that to result in a specific layout (which is inlined images in this case). If we would automatically display them as figures, that would mess with the intended layout.

I see writing a blog article as a dedicated workflow. It's different than writing a regular markdown paper. Maybe I'm missing something here, but does it really happen that often that somebody converts an existing markdown document to a blog article?

@HEIGE-PCloud
Copy link
Owner

HEIGE-PCloud commented Jun 20, 2024

I remember the image behavior being a long standing controversial topic. People have conflicing opinions about what the correct behavior should be, and I think they all have vaild reasons for their specific use cases.

I'll just provide one of my observations here. I think sometimes blog authors care about the gallary feature more than the readers. As a reader, I can simply zoom in if I want to see a picture at a larger form factor. I also rarely find listing all images in a blog post in a row useful, since most images in a blog post are supplementary to the main text. I imagine many other text based content focused websites (like news websites) don't provide a "gallary" feature for a similar reason.

@evilpan
Copy link
Contributor

evilpan commented Jun 21, 2024

@HEIGE-PCloud

As a reader, I can simply zoom in if I want to see a picture at a larger form factor

That's what I mean. In DoIt the only feature to achive this behavior is light gallery (AFAIK). Currently the default behavior is to make images inline, and readers cannot simply zoom in when click the image.

@flobernd

If you look at my original bug report, they create a lot of noise in the gallery.

I agree, personally I'm not a fan of this gallery feature.

Most markdown writers use images to decorate their texts. They expect that to result in a specific layout (which is inlined images in this case).

Does people use inline image frequently when writing markdown? at least for me, I rarely use inline image, since images are either too wide or too high to be correctly inlined into text lines. So most of images is put in a single new line. In your use case, I prefer emoji for it: 🔴🟥/🟢🟩

but does it really happen that often that somebody converts an existing markdown document to a blog article?

The scenario is people may migrate from one static blog generator to another, e.x. from Jekyll/Hexo to hugo, or from one theme to another. For example: #693 (PS: this update also break that issue)

As I said, this is just a matter of preference, maybe we need a poll here. Or there's another solution, like making inline image clickable to zoom without gallery.

@flobernd
Copy link
Contributor Author

The scenario is people may migrate from one static blog generator to another, e.x. from Jekyll/Hexo to hugo, or from one theme to another.

Interesting! It's indeed annoying that different themes handle standard markdown behavior in different ways.

I still think DoIt is doing a great job here as it follows the standard mardown as close as possible while still allowing extended syntax on top. This minimizes surprises for users that are used to standard markdown while still offering a lot of extra options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants