Image handling (for AMP etc.)

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:

  1. Supports all of the template languages
  2. Supports all (or most of) the rendering engines (Blackfriday, MMark, AsciiDoc etc.)
  3. Is speedy
  4. 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:

  1. Getting the img vs amp-img correct
  2. Adding missing width and height tags

Doing the above in the markdown engines would:

  1. Only be possible for a couple of them (Blackfriday (see https://github.com/russross/blackfriday/blob/master/html.go#L515), MMark).
  2. Would mean content rendered for each of the alternate formats.
  3. Would not handle inline HTML (aka the img shortcode etc.)
  4. …

The other alternative is to render one version of the content (like today) and then do transformations of the rendered content.

This would:

  1. Handle all rendering engines.
  2. Would render content only once.
  3. Would handle inline HTML
  4. Could be hooked into the existing transformer parser, so should be speedy.

Hey @bep, thank you and other contributors for a great implementation of AMPs and other output formats! Really good and nonintrusive implementation.

Just ran into the img-issue you describe above while using the figure shortcode in markdown. Do we have a solution for this?

EDIT: Just found this and this

The “shortcode issue” will solve the amp issue, I think. But I get to … get to it. It’s not a trivial one, but I think I should put in on priority once I get some time.

Just to make it clear what issue I’m talking about:

https://github.com/spf13/hugo/issues/3220

1 Like

Thanks @bep, appreciate it!

Just so I’m with you @bep. We’re not “quite there yet” when it comes to automatically loading an alternate shortcode template (e.g. images.html / images.amp.html), right?

We’ve not even started the long walk.

Men vandra ska vi :grin:

But I even found a fairly simple solution to a hard problem related to this issue on my walk home today. Fresh air is good for thinking.

1 Like

Agreed, fresh air and away-time from the keyboard usually works wonders

1 Like