5 ms·

I recently started moving my static jekyll website to AMP. The biggest annoyance by far is that an AMP website requires javascript, and <img> tags are no longer

by treve 10y ago

I recently started moving my static jekyll website to AMP. The biggest annoyance by far is that an AMP website requires javascript, and <img> tags are no longer valid. <amp-img> is required. This means I now have to choose between blog posts that are valid AMP and valid (and rendering) in an atom news reader. I sort of get why this is done on a technical level, but I prefer my HTML to follow HTML best practices. HTML will outlive AMP. Please just allow this and fix this in your AMP caching systems to automatically transform this.

ohstopitu 10y ago
I'm more annoyed about inline CSS (which I understand is supposed to be better....but with Jekyll it gets complicated really fast to import my SCSS to CSS inline).
- tangue 10y ago
  Did you have a look at email inliners (the premailer gem should be enough considering the AMP spec). You'll need to add a gulp or grunt task before publishing, though.
  - ohstopitu 10y ago
    I was hoping to do it without any other gems (I'm not a Ruby dev, but I really like Jekyll because of it's support). I followed the tutorial here[0], however, the issue is, my SCSS is stored into a seperate dir, and in order to inline it...I'd be forced to either 1. modify my entire project dir setup - something I don't want to do 2. start from scratch and create my own css inline. Thanks to the above, my theme been stuck in limbo (AMP and Facebook Pages being a key feature I had created my theme for) [0]http://www.kevinsweet.com/inline-scss-jekyll-github-pages http://www.kevinsweet.com/inline-scss-jekyll-github-pages
onli 10y ago
That's exactly it for me as well. Several times I got prompted by articles like this to evaluate AMP, because I like the core idea – a defined subset of HTML tags for static content that can then be cached. And then I have to realize that this is not the core idea at all. Replacement of HTMl-Tags with AMP-tags, converting a static site to a site only working with javascript, javascript that can't be self-hosted – that is just an ugly and bad solution far from the claimed core idea. How AMP should be: Define a subset of allowed HTML and best practices fit for static pages. Verify and cache the result. If doing crazy js-hacks, do that on the cache-layer as an add-on, like the image resizing.
- callahad 10y ago
  Side project idea: a browser add-on that de-AMPs (dAMPs?) content back into standard HTML...
  - onli 10y ago
    As extension to scripts like Noscript. Would be useful.
detaro 10y ago
Curious, why did you want to move your site over? For small-ish sites with clean code I don't see any benefit of using AMP right now.
- callahad 10y ago
  AMP sites get preferential treatment in Google search results: https://search.googleblog.com/2016/09/search-results-are-officially-ampd.html https://search.googleblog.com/2016/09/search-results-are-off... Specifically, they're eligible for placement in the "Top Stories" header, and they get a special "️(!) AMP" flag alongside their entry in the search results.
  - detaro 10y ago
    I thought the "top stories" was only for "proper" news sites? It would be interesting to see if the AMP marker has an effect on browsing behavior, it seems awfully technical to me.
- deleted 10y ago
  [deleted]
- ahoy 10y ago
  Google gives preferential placement to AMP pages over non-AMP pages in mobile searches.
- treve 10y ago
  Experimentation. I use my blog to get experience with various technologies.
andybak 10y ago
Surely it's a fairly simple technical problem to solve? Middleware or a build step in your static site generator could easily produce AMP and non-AMP-but-fast content from the same data and templates?
- lucideer 10y ago
  Why would you generate both? At what endpoints would you serve which? Which would you serve as the canonical version, and how would people reach the alternative? If you're intending to content-negotiate for Googlebot I suspect you'll run into trouble.
  - detaro 10y ago
    AMP is designed to be served at alternative endpoints. The canonical HTML version gets a rel=amphtml header and the AMP page a rel=canonical. https://www.ampproject.org/docs/get_started/create/prepare_for_discovery https://www.ampproject.org/docs/get_started/create/prepare_f...
    - lucideer 10y ago
      This I was completely unaware of. I'd read the majority of the docs, so this isn't really emphasised. Tbh, if this had been front-and-centre when I started implementing AMP, I might have actually finished the job without balking at the hard Google dependency and abandoning the effort. I'm still wary of it given the Google-hosting of AMPed pages accessed via SERPs, but this does make it slightly less awful I guess.
what_ever 10y ago
You can create an AMP version of the page for each page and include that as the amp canonical tag on your normal pages. In that case people visiting from Google get AMP version. The normal site should still exist and it should continue to link to normal pages.
Manishearth 10y ago
There's a lot of "reinventing HTML/JS" that goes on which irks me. Folks reinvent `<select>` in JS all the time. This stops type-to-search and mobile sites from working. The same goes for password fields (for password managers and "click to show" on mobile). The same goes for reimplementing scrolling in JS and text zoom. The same goes for onclick links (like twitter) and breaking ctrl-click and other linky things. The same goes for a million different features of the web and screen readers. And like you said, the same goes for img and feeds. If you're going to reimplement something, bear in mind that it may have far more functionality than that for your primary use case.

by treve 10y ago

ohstopitu 10y ago

I'm more annoyed about inline CSS (which I understand is supposed to be better....but with Jekyll it gets complicated really fast to import my SCSS to CSS inline).

tangue 10y ago
Did you have a look at email inliners (the premailer gem should be enough considering the AMP spec). You'll need to add a gulp or grunt task before publishing, though.
- ohstopitu 10y ago
  I was hoping to do it without any other gems (I'm not a Ruby dev, but I really like Jekyll because of it's support). I followed the tutorial here[0], however, the issue is, my SCSS is stored into a seperate dir, and in order to inline it...I'd be forced to either 1. modify my entire project dir setup - something I don't want to do 2. start from scratch and create my own css inline. Thanks to the above, my theme been stuck in limbo (AMP and Facebook Pages being a key feature I had created my theme for) [0]http://www.kevinsweet.com/inline-scss-jekyll-github-pages http://www.kevinsweet.com/inline-scss-jekyll-github-pages

onli 10y ago

That's exactly it for me as well. Several times I got prompted by articles like this to evaluate AMP, because I like the core idea – a defined subset of HTML tags for static content that can then be cached. And then I have to realize that this is not the core idea at all. Replacement of HTMl-Tags with AMP-tags, converting a static site to a site only working with javascript, javascript that can't be self-hosted – that is just an ugly and bad solution far from the claimed core idea. How AMP should be: Define a subset of allowed HTML and best practices fit for static pages. Verify and cache the result. If doing crazy js-hacks, do that on the cache-layer as an add-on, like the image resizing.

callahad 10y ago
Side project idea: a browser add-on that de-AMPs (dAMPs?) content back into standard HTML...
- onli 10y ago
  As extension to scripts like Noscript. Would be useful.

detaro 10y ago

Curious, why did you want to move your site over? For small-ish sites with clean code I don't see any benefit of using AMP right now.

callahad 10y ago
AMP sites get preferential treatment in Google search results: https://search.googleblog.com/2016/09/search-results-are-officially-ampd.html https://search.googleblog.com/2016/09/search-results-are-off... Specifically, they're eligible for placement in the "Top Stories" header, and they get a special "️(!) AMP" flag alongside their entry in the search results.
- detaro 10y ago
  I thought the "top stories" was only for "proper" news sites? It would be interesting to see if the AMP marker has an effect on browsing behavior, it seems awfully technical to me.
deleted 10y ago
[deleted]
ahoy 10y ago
Google gives preferential placement to AMP pages over non-AMP pages in mobile searches.
treve 10y ago
Experimentation. I use my blog to get experience with various technologies.

andybak 10y ago

Surely it's a fairly simple technical problem to solve? Middleware or a build step in your static site generator could easily produce AMP and non-AMP-but-fast content from the same data and templates?

lucideer 10y ago
Why would you generate both? At what endpoints would you serve which? Which would you serve as the canonical version, and how would people reach the alternative? If you're intending to content-negotiate for Googlebot I suspect you'll run into trouble.
- detaro 10y ago
  AMP is designed to be served at alternative endpoints. The canonical HTML version gets a rel=amphtml header and the AMP page a rel=canonical. https://www.ampproject.org/docs/get_started/create/prepare_for_discovery https://www.ampproject.org/docs/get_started/create/prepare_f...
  - lucideer 10y ago
    This I was completely unaware of. I'd read the majority of the docs, so this isn't really emphasised. Tbh, if this had been front-and-centre when I started implementing AMP, I might have actually finished the job without balking at the hard Google dependency and abandoning the effort. I'm still wary of it given the Google-hosting of AMPed pages accessed via SERPs, but this does make it slightly less awful I guess.

what_ever 10y ago

You can create an AMP version of the page for each page and include that as the amp canonical tag on your normal pages. In that case people visiting from Google get AMP version. The normal site should still exist and it should continue to link to normal pages.

Manishearth 10y ago

There's a lot of "reinventing HTML/JS" that goes on which irks me. Folks reinvent `<select>` in JS all the time. This stops type-to-search and mobile sites from working. The same goes for password fields (for password managers and "click to show" on mobile). The same goes for reimplementing scrolling in JS and text zoom. The same goes for onclick links (like twitter) and breaking ctrl-click and other linky things. The same goes for a million different features of the web and screen readers. And like you said, the same goes for img and feeds. If you're going to reimplement something, bear in mind that it may have far more functionality than that for your primary use case.