3 ms·
> 1. <figure> and <figcaption> Pandoc will generate html code using these elements when you use implicit_figures feature: https://pandoc.org/MANUAL.html#exten
by marbu 3y ago
> 1. <figure> and <figcaption>
Pandoc will generate html code using these elements when you use implicit_figures feature:
https://pandoc.org/MANUAL.html#extension-implicit_figures https://pandoc.org/MANUAL.html#extension-implicit_figures
And it seems to be well supported in web browsers:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fi...
You can see an example how it looks like in this post from my blog, there are no css tweaks for figure or it's caption (I use static site generator based on pandoc):
https://blog.marbu.eu/posts/2023-04-29-the-first-web-browser/ https://blog.marbu.eu/posts/2023-04-29-the-first-web-browser...
And personally I find that better compared to alternative solution consisting of multiple div elements.
- AlienRobot 3y agoI'm sorry for what I'm going to tell you, but this is exactly the sort of wrong use of the <figure> tag I mentioned about. In fact, your blog contains the PERFECT example of WRONG use of the <figure> tag, which illustrates why <figure> semantics are a lost game at this point. The spec explicitly notes:[1] >When a figure is referred to from the main content of the document by identifying it by its caption (e.g., by figure number), it enables such content to be easily moved away from that primary content, e.g., to the side of the page, to dedicated pages, or to an appendix, without affecting the flow of the document. > >If a figure element is referenced by its relative position, e.g., "in the photograph above" or "as the next figure shows", then moving the figure would disrupt the page's meaning. Authors are encouraged to consider using labels to refer to figures, rather than using such relative references, so that the page can easily be restyled without affecting the page's meaning. The point of <figure> is that the element can be REMOVED from the document and moved elsewhere without changing the meaning of the document. I assume the intention is that you say "see figure 3" like a textbook. If you write something like: >I was familiar with it’s interface from few screenshots like the one shown below There's no way to move the <figure> containing the screenshot to a sidebar for example, because then what you wrote wouldn't make any sense. If <figure> was being used the way it was meant to be used, it would be trivial to write a browser plugin that hid all figures and listed them in a sidebar. But nobody is following the spec. Everyone in the planet is using <figure> as if it was just a container for an image with a tag for the image caption (pandadoc, wordpress, etc., are all doing this!), so that's in practice what it is now. This is what makes it so hard to understand who would even consume these tags for something useful. It seems every time they're widely used, they're widely used with semantics that don't match the spec, so if you wrote a markup-based tool, you would have to go against the spec, which means there is no point in having a common HTML spec in first place, just make your own API like microdata. I'd even say the only reason that browsers work at all is that authors are forced to see their websites through a browser so the markup has to at least work in the browser. For every tool that authors don't all use (such as a browser plugin that hides figures), there's no way to guarantee the author used the markup correctly, so it's not something that can be relied on. [1] https://html.spec.whatwg.org/multipage/grouping-content.html#the-figure-element https://html.spec.whatwg.org/multipage/grouping-content.html...
- marbu 3y agoOh, you are indeed right about the figure element! Sorry for missing your point at first. I would not blame this on pandoc though, it's my mistake of missing what the intended purpose of figure element is, because I haven't studied the spec and browsers doesn't do anything useful with it (as you pointed out). That said if I used pandoc to generate pdf via latex, I would have noticed that, since the figures are repositioned as expected in such case. And while I agree that in the current state, it's kind of pointless for browsers to try to take advantage of this element when most of the real code is against the spec, I believe that it didn't help that browsers didn't do that in the beginning when nobody was using it yet. But since the spec is not explicitly asking for anything, browsers did the bare minimum. While I can imagine 2 use cases already: i) better layout of printed page (eg. when I try to print my blog post, firefox will happily cut a figure in half if I select print on a5 paper even though it could try to reorganize it bit smarter ...) ii) similar to what you describe, an ability to show the figures in a separate window so that you can see the text and figures at the same time (this is actually similar to a picture-in-picture like feature for images what I describe in the blog, and to be honest I would still find that kind of useful)