I see some high altitude discussions about getting AMP support into Hugo.
In my head it is a fairly complex problem that should be split into smaller parts.
The alternate rendering of AMP (and other types) / template handling / theme etc. are fairly straight forward and out of scope in this discussion.
The hardest part is the handling of AMP tags in content files, most notable the AMP image tag (and maybe also the video tag).
The AMP HTML spec is here:
AMP adds some custom attributes:
layout, width, height, media, placeholder, fallback
In layout files I would say that this is “up to the user / theme creator” to get right. In content files, we will have to do some magic.
But we should aim for a solution that:
- Supports all of the template languages
- Supports all (or most of) the rendering engines (Blackfriday, MMark, AsciiDoc etc.)
- Is speedy
- Is possible to implement in a fair amount of time
To take Blackfriday as an example: Blackfriday produces HTML. It is possible to hook into, say, the image tag and create something else. But that would be for Black friday only and only for markdown (not for inline HTML, from shortcodes etc.)
So given the image tag, this is how I see it:
If target is AMP, all image tags should be amp-img, add width and height if not present and figure a way for the user to add layout etc.
(and maybe: If target is HTML, add width and height if not present.) (this would be a nice to have-bonus)
(thumbnail creation etc. is related to this, but let’s leave that out for now)
If we concentrate on:
- Getting the img vs amp-img correct
- Adding missing width and height tags
Doing the above in the markdown engines would:
- Only be possible for a couple of them (Blackfriday (see https://github.com/russross/blackfriday/blob/master/html.go#L515), MMark).
- Would mean content rendered for each of the alternate formats.
- Would not handle inline HTML (aka the img shortcode etc.)
The other alternative is to render one version of the content (like today) and then do transformations of the rendered content.
- Handle all rendering engines.
- Would render content only once.
- Would handle inline HTML
- Could be hooked into the existing transformer parser, so should be speedy.