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
figure element #48
Comments
You can already avoid paragraph tags for images like this: this is
{::nomarkdown}
<img test="test" />
{:/}
this is results in <p>this is </p>
<img test="test" />
<p>this is</p> And you can already use
gives you <figure>
<figcaption>
test
</figcaption>
<p><img src="img.jpg" alt="test" /></p>
</figure> I have currently no intention to provide extra syntax HTML5 specific tags like |
I'm probably late to this, but I like a lot how Pandoc handles this: if an image is in a paragraph on its own, it becomes a figure, and its alt-text is used as caption. |
Any chance having syntax for Figure? Something like using the Thank You. |
I can imagine providing a new option for changing the behaviour of how paragraphs with only an image are converted, similar to how the LaTeX converter currently does it - see https://github.com/gettalong/kramdown/blob/master/lib/kramdown/converter/latex.rb#L71 @9peppe / @RoyiAvital What should the output for the following kramdown fragment should be if the option to convert standalone images is activated? This is a para with an .
 Note that the alternative text of the image cannot contain markup, it is just text. |
I'd say
|
3 Remarks (Though I'm not sure they are doable):
|
@9peppe If the image had an ID assigned, should it then be on the ad 1) No. If the new option to process a paragraph with a single item being an image is activated, the output is changed. The only way this would be doable would be via the option value itself. ad 2) The parser is not touched, only the output is changed. ad 3) I don't know what you mean. If you set an id on the image, you can use that id later. |
I don't know. I think it will depend on individual use cases. But if we apply it to |
That's what I was thinking, i.e. class and id attributes are transferred to the |
@gettalong ,
Thank You. |
@RoyiAvital I'm against changing the kramdown parser. Therefore the way to specify how a paragraph with only an image should be rendered is via the new option that changes how the converter works. E.g. if the option's value is "figure", then a figure tag is rendered, if it is "image" than just the image without enclosing paragraph tags is rendered. |
I see. |
I don't really know Github Pages nor use it, but since it is based on Jekyll I guess it provides the ability to define kramdown options and through this facility one could also set the new option. |
In pandoc, when its implicit figure extension is enabled, you can append a newline to mark individual images as non-figures. About where to put the class and id, there's an issue open about that. |
So, to sum up:
will be rendered into <figure id="id" class="class">
<img alt="standalone image" src="some.jpg" />
<figcaption>standalone image</figcaption>
</figure> iff the new option 'standalone_image' is true. If it is not (the default value for the option), then the current behaviour doesn't change. @9peppe @RoyiAvital Any comments? |
@gettalong , 2 edge cases I thought about
Could we have:
Or even farther, for:
Having:
|
@gettalong , |
I'm rather busy right now, so this change together with a new release will probably be in August. |
@RoyiAvital I have implemented this now with a slight change of functionality: If you want to have a standalone image, use the special
|
@gettalong Any commit to reference in order to track this feature's availability? |
Will be pushed shortly! |
I don't understand this. Why are we introducing a behavior not seen in any markdown parser? (a big part of my initial request had to do with using the same source with multiple parsers, even if I did not make that clear) |
To make it possible to have both worlds. This new functionality is backwards compatible, so no problem. And if you use another library that supports kramdown, it will also just work, using the default output of that library. |
Yeah, but it does not make sense. |
Actually, Now, with these changes one can choose how a standalone image is shown: either as a paragraph with an image (default) or as a figure element. This has nothing to do with a doctype. |
Actually, img was an inline element, now it's replaced content and shown inline by default. But I don't want to fight over this. Doctype matters because there is no figure element before html5. So the best option would imho be |
The doctype is not known by kramdown. It just outputs valid HTML. With the current implementation, the user can choose how to display standalone images regardless of the doctype, on a case-by-case basis. |
So either you use the global |
There is no global |
@gettalong Was this ever released? {:standalone} |
For some reason I was on Jekyll 3.8.6. |
@pmpinto , I think you can also do something similar using the This is a temporary solution. For instance, GitHub Pages still uses Jekyll 3.85 and kramdown |
A more flexible solution would be better, in my opinion. When |
True, but flexibility is not the point of markdown, human-readability is. I guess the way to address your concern would be to just leave For flexibility, there's always raw html :/ |
Well...sort of. It addresses the double-content issue. But actually both sets of content have different purposes, and this is would simply eliminate the possibility of people who can't see the graphic (whether due to vision issues or a poor Internet connection) from understanding what it shows. (And if you include such descriptions in captions, well, that becomes its own double-content issue. A picture's worth a thousand words sometimes, and people who can see the image won't want those specific thousand words.) Indeed, we currently use raw HTML in this case, which certainly makes it less readable. I wonder if there could be a special attribute in this case, to allow for separate setting of |
Also realize that |
This is the way forward. There does need to be a clear distinction between the alternate text for the image and figcaption if they are different for accessibilty reasons. This is a quote from a blind user which goes against the current behaviour:
And as @AvverbioPronome said:
If the point of human readability extends to its appearance on a webpage, then this issue I think needs looking at again @gettalong. |
I’ve been trying to write lately with kramdown's markdown parser and I’ve come across two problems that seem to unsolvable in the current release.
One is that there seems to be no way to stop kramdown from wrapping image links in
tags. This is often fine but when paired with something like
the results are less than happy, images inherit unwanted text stylings and go all over the shop.
Markdown is smart enough not to add tags to existing block level elements, could the same method be used to allow specifying of stand-alone images?
If this is unfeasible or undesirable, could it be possible to allow it via an option ( say :image_block => true )
The second problem is attempting to use html5's new
and elements. According to can I use it all major browsers now support them and they’re certainly a great help in writing articles with images that need citations or have direct references to text.Looking through google to see if anyone has attempted it I found https://github.com/michelf/php-markdown/wiki/HTML5-update which seems to have a pretty useful starting point for working out a syntax to use them.
Would either of these problems be something we might be able to do something about?
The text was updated successfully, but these errors were encountered: