Hugo: Add AMP (Accelerated Mobile Pages) output

[S--Minecraft]

Google has started to support AMP.
So It would be better if I can make AMP pages with hugo.

Thanks

AMPProject

[dingtianran]

🖖
Agree

[nikolay]

:+1:

[bep]

OK, I read about and it looks interesting. It got some pretty powerful companies behind it, so I guess it's gonna stay.

If I understand this correctly

• From Hugo's point of view, this is another output representation, lets name it _amp_
• _amp_ and others can have their own templates (they normally would), so:
  
  
  
  • if /index-amp.html exists, that template will be used for the amp output for the home page (etc.).
  
  
• The alternative output will be placed in a subfolder of the main representation, so "/my-post/index.html" and "/my-post/amp/index.html"
• Alternative outputs should be a list in site config (["amp", "???"] and adding one will double the page output (including paginator pages)
• We might have to think about URL refs
• The user is responsible for adding link rel="amphtml" and the other way around in the templates

Does the above make sense?

/cc @spf13

[itwars]

Hi,

We need it! It seems there's already something for jekyll https://github.com/juusaw/amp-jekyll as well as for wordpress https://wordpress.org/plugins/amp/
BR

[bep]

hugo should really support AMP asap.

This is open source. ASAP is as soon as you want.

that you need to add also a canonical tag with the html version of the page, and from the html version a rel=amphtml link to the amp versions URL.

This is in my list as a "end user responsibility" (simply add it in the templates)

[kennylevinsen]

Is there a need for this, rather than just applying AMP on the site in general? This way, hugo doesn't have to know about AMP. An argument for this could be the ability to have AMP content _and_ AMP-violating content simultanously, but I suspect that one in this case should consider just abiding by AMP.

The ability to render all content in multiple layout sounds like a bit of an overhead, but doable. The solution should definitely not know what AMP is, and any AMP-ness should be completely user-defined. (AMP is not a magic bullet, and slows down some sites considerably - I also do not approve of the supertracking features it was designed to have).

@bep: index-{name}.html would not work with non-ugly-urls. What about rendering the entire thing to a subfolder, /{name}, with pages the normal places, /{name}/posts/wee? This would mean that you could not have a section with the same name as an additional layout, but might be a bit cleaner, and would make linking more logical. This could also be used to have things like /beta/ for a new layout.

This can already be done with hugo using two runs of hugo:

hugo --theme normal  --baseURL https://something.com/
hugo --theme amp --baseURL https://something.com/amp/ --destination public/amp

[spf13]

My take on this is that there's a lot of unknowns around AMP and what the best way to implement it is which makes sense since it's so new. For example, the wordpress plugin mentioned appends /amp/ to the end of urls (and doesn't support all pages yet), where the Jekyll one does something entirely different.

I believe that ideally Hugo would support AMP in an integrated way and have support for it integrated into the theme system. Ideally a user would be able to have their content, download a AMPable theme and it would just work. The user wouldn't need to know anything about AMP.

There are a few dependencies to adding full AMP support including adding image processing to satisfy the "amp-img components, like all externally fetched AMP resources, must be given an explicit size (as in width / height) in advance, so that the aspect ratio can be known without fetching the image." requirement.

Really what needs to happen is for someone to take the initiative and come up with a proposal for how to add AMP support into Hugo.

[kennylevinsen]

I thought a bit about getting the appropriate width/height on images, and thought of 3 possible solutions that made sense:

1. Having this be a post-process step on the HTML output. Possible, but really ugly.
2. Mangle markdown processors to have runtime-replaceable export mechanisms that default to their current state. A bit intrusive in other projects, but not too bad. This would allow hugo to look up the image dimensions if necessary, and for hugo to change a tag if a layout asks for it.
3. A new command for inserting an image that allowed manual input of the dimensions, or automatic fetching if hugo felt like it. This could be done without messing around with the markdown processors.

I think 2 is the neatest, with 3 being the quickest.

I really hope that we could reach AMP compatibility _without_ amp-awareness in hugo. Dimensions on image tags are helpful to all layouts, not just mobile or AMP, as it avoids jumpy content and wasted clock-cycles on recalculated styles.

I vote for a mechanism where a layout can be a "group" of layouts that should all be run for all content, with each sub-layout having some local settings for the export (dimensions on images, what tag to use, ...) and their own destination sub-folder. That would allow for themes to both have normal and AMP in one package, while being more generic, and allowing some of the features to be applied to normal themes (dimensions on images). It would allow us to be more flexible in case of changes to the AMP spec as hugo doesn't care, and would also allow someone to make a Facebook Instant Articles variant of their layout, or whatever other custom layout they'd want to make.

[gam-phon]

This theme is for Jekyll that support AMP. It is very popular. Their approach is:

Google AMP has it's own set of special html tags for including content. You should use these instead of normal Markdown or HTML tags.

I don't think this is a good approach.

Solution 2 that proposed from @joushou is a good solution and makes changing between themes easy. It does not require you to change the contents to change between themes.

[itwars]

In addition, markdown processor need to be update to allow :

Inline-style:

![alt text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 1")

and

Reference-style:

![alt text][logo]

[logo]: https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 2"

To be transform in :

<amp-img src="" alt="" height="400" width="800"></amp-img>

We need image size detection.

And CSS inlining.

BR

[kennylevinsen]

I do not believe that CSS inlining is in any way a required feature. That's just a matter of inlining the stylesheet manually for an AMP-specific layout.

The ability to output amp tags, as well as detecting image sizes (which I would like to be separate, so that regular sites can benefit from properly sized img tags as well), has already been mentioned. There are 3 different approaches to the implementation in my previous comment.

[tanzaho]

Did anyone started to work on this topic ?

[bep]

This issue has been automatically marked as stale because it has not been commented on for at least four months.

The resources of the Hugo team are limited, and so we are asking for your help.

If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still valuable, please open a proposal at https://discuss.gohugo.io/.

This issue will automatically be closed in four months if no further activity occurs. Thank you for all your contributions.

[bep]

Note/Update: This issue is marked as stale, and I may have said something earlier about "opening a thread on the discussion forum". Please don't.

If this is a bug and you can still reproduce this error on the latest release or the master branch, please reply with all of the information you have about it in order to keep the issue open.

If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.

[bep]

This will be covered by Hugo 0.20 + https://github.com/spf13/hugo/issues/3220