Re: [Docutils-users] <img> instead of <video> tag inserted for image:: foo.mp4

[Guenter M. <mi...@us...>]

Dear Agathe,

On 2022-05-03, Agathe Porte wrote:

...

> As I dig further and further into html5_polyglot, I am sad to see that
> <video> has no first class support in reStructuredText. 

Video is a relatively new addition and only rarely used up to now.
This is also related to poor support in the target document formats 
(just HTML5, no ODF, LaTeX, or troff (manpage)).

> I did a local patch to add more attributes to the renderer, then
> another patch for allowing alternative source format, 

thank you for sharing

> but I think that a new video class should be added instead of hacking
> the image class so deeply. This has been done in a plugin for sphinx
> [2]: full support of a distinct video node that can support extra
> attributes. 

I suppose "class" here means a new document node class and maybe matching
directive? 
This is one way to do it, it would mean a change to the Docutils document
model https://docutils.sourceforge.io/docs/ref/doctree.html as well as
the reStructuredText specification
https://docutils.sourceforge.io/docs/ref/rst/restructuredtext.html.

What would be the advantage over a common <image> node for both still and
moving images?

> One quirk of using "classes" for detecting {loop,controls,autoplay} is
> that the video keeps the "loop" CSS style class, which seems not useful
> and can conflict with CSS classes.

This may be solved by popping the relevant values from the "classes" list
(as is done with "language-.." values and, in `html5_polyglot` for the
classes corresponding to semantic HTML5 tags (cf. the
`html5-text-level-tags.txt` functional test input and resulting
`standalone_rst_html5.html`).
(CSS stylesheet rules can also use the "loop" attribute as selector.)

> I was not able to see prior discussion for proper video support in 
> docutils using a search engine. Please enlighten my light if anything 
> seems wrong with this proposal. 

Alternative sources are also useful (and supported for) still images in HTML5.
cf. https://sourceforge.net/p/docutils/mailman/docutils-develop/thread/a461cd5a-6222-45bc-ac66-0be0117e6002%40Spark/#msg37264494

Another use case is providing for alternative formats in the rst source 
for different output formats (e.g. SVG for HTML, PDF for LaTeX).
Different writers would filter out non-supported formats.

Instead of the HTML "srcset" syntax, I consider adding support for
optional nested <source> nodes (similar to the ones in HTML5 <video>).
This would, IMO, give a clearer way to specify image resolution and sizes
than the "srcset" and "sizes" attributes.

We should/could start a dedicated thread in docutils-develop or
feature-enhancement ticket for this.

Thanks,

Günter