Replies: 2 comments 4 replies
-
|
For what it's worth, GitLab appears to be adding this now: https://gitlab.com/gitlab-org/gitlab/-/issues/15697#note_1188752984 |
Beta Was this translation helpful? Give feedback.
-
|
You probably can implement an extension like https://github.com/mdigger/goldmark-attributes for images. |
Beta Was this translation helpful? Give feedback.
-
|
I wouldn't know whether an extension would also do the job, I guess only the Gitea devs could answer that. I'm guessing yes? Nevertheless, it would be a nice feature to have in some capacity, extension or not, especially now that GitLab is also adding it (and the popular pandoc already has it, apparently). |
Beta Was this translation helpful? Give feedback.
-
|
@yuin I'm slightly confused. You mention in the README that you support attributes in the core, but that it's currently limited to headers, possibly due to no clearly defined syntax. It's true that the CommonMark community hasn't settled on an exact syntax. However @jgm has built-out a pretty good spec for use in commonmark-hs. This is the syntax GitLab is going to coalesce around. Do you think you'll be supporting or enhancing the core attribute support, or will it need to be fully implemented in an extension? |
Beta Was this translation helpful? Give feedback.
-
It will need to be fully implemented in an extension If attributes are not defined in OFFICIAL CommonMark spec, otherwise not. Heading and fenced code block attribute CAN NOT be implemented as an extension. These attributes are defined INSIDE of the element. But other attributes seem to be defined NEXT to the element. So these attributes probably be implemented as an extension. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the clarification 👍 |
Beta Was this translation helpful? Give feedback.
-
(Forwarded from go-gitea/gitea#21473 )
I would suggest to add in a simple way to specify image sizes in markdown. This is needed when using High-DPI images in documentation without making tons of low DPI manually scaled copies which kind of goes against the spirit of easy markdown documentation (which IMHO is to not spend hours in some other programs making a complicated baked altered layouted document with duplicated baked images, but just writing a simple semantic document with minimal markup and done).
Most common syntax (To be added to GitLab, Pandoc extension, ...):
{width=200}{width=200px height=200px}It's specified here: https://pandoc.org/MANUAL.html#extension-link_attributes and proposed by CommonMark community members in a discussion here: https://talk.commonmark.org/t/support-for-image-dimensions/148/45
Second most common syntax (found in discussions etc.):
What currently works:
This works on Gitea right now, the above stuff doesn't:
<img src="https://try.gitea.io/assets/img/logo.svg" width=100px/>(can even be nested into markdown links:
[<img src="https://try.gitea.io/assets/img/logo.svg" width=100px/>](https://gitea.io))However, this is not particularly intuitive and just sticks out terribly.
How to support it?
I think best would be to support both the most common and 2nd most common way as an optional switch. This way the library users who don't want it can opt out, hopefully nobody will complain about "polluting the standard", and it's available for those who want to give their users a nicer experience.
The main use case I really see in documentation. Inline HTML is just so clumsy, and markdown for documentation is otherwise just so perfectly clean and simple. And while I understand layouting and sizes and other presentation concerns are usually kept out of markdown, for images that's not really possible (due to the DPI issues) so it'd be nice to have a clean solution to specify the proper size without those HTML hacks.
Beta Was this translation helpful? Give feedback.
All reactions