5 ms·

On AMP for Email

skybrian 9y ago
Re: "Amp for Email uses that language instead of HTML and CSS." Is this correct? Looking at the example in the spec [1], it seems to be a subset of HTML. [1] https://github.com/ampproject/amphtml/issues/13457 https://github.com/ampproject/amphtml/issues/13457
- gregable 9y ago
  It is just a subset of HTML (as is amp). Most email providers that accept HTML formats already only accept a subset of HTML. This is just a different, more formally defined, subset.
  - nixpulvis 9y ago
    I mean, HTML is just XML... these subsets are in many ways their own language.
    - seabrookmx 9y ago
      It's not, technically. XHTML was a formally defined HTML subset of XML but it died.
      - nixpulvis 9y ago
        Fair enough, my point stands though.
    - dingaling 9y ago
      HTML is an application of SGML / ISO8879. It defines its own domain and that's the scope of it. It's a leaf. XML is a subset of SGML and can have further subsets and implementing applications I.e. it is a branch. As noted above, XHTML was a leaf on this branch. So they are related but not equivalent.
- iza 9y ago
  Except you have to use <amp-img> tags instead of <img>. Same for video, audio, and iframe. https://www.ampproject.org/docs/reference/spec#html-tags https://www.ampproject.org/docs/reference/spec#html-tags
  - magicalist 9y ago
    > Except you have to use <amp-img> tags instead of <img> Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html
    - skybrian 9y ago
      Hmm, custom elements are an interesting loophole. If you define your own set of tags and provide JavaScript implementations for them, I guess it would run in a browser, but is it really the same language anymore, and does it matter? I'm reminded of: #define BEGIN { #define END }
      - magicalist 9y ago
        > is it really the same language anymore Yes? The analogy would be more like defining custom functions or classes not in the standard library. It's just encapsulation that can then be used by name. They can't be inserted arbitrarily regardless of syntax like a macro can be.
eveningcoffee 9y ago
AMP for Email is another Googles attempt to grab more dominance by abusing their market share.
ronnier 9y ago
I really don’t care about amp for email. But I’m very worried about amp for the web because it means we give up control of our content and features and will need to live by googles rules.
- nixpulvis 9y ago
  Do you just not use email much then?
  - criddell 9y ago
    It's just a client-side thing then, right? I can send email to a GMail user from a non-AMP client and I can receive email from a GMail user. I don't think there are any mail system interoperability concerns, are there?
    - nixpulvis 9y ago
      I assume sending will always work as expected (they aren't about to start demanding things be AMP formatted), but who knows what your client might render an AMP email looking like.
- skybrian 9y ago
  I know what you mean, but at a certain level of abstraction, isn't that what web programming is all about? You already live by Chrome+Firefox+Safari+IE rules. I mean sure, there's a complicated political process, but it's still rules made by other people working for large organizations that the average web programmer just accepts. It's not like we all had a vote about Flash. Or JavaScript, for that matter. There's a lot you can do while working within the rules, though.
aidenn0 9y ago
Enough people are coming out saying it's a terrible idea that the contrarian in me thinks is't likely to catch on now.
- patrickaljord 9y ago
  Being able to do tasks without leaving your email client is actually great, specially on mobile. Answering Doodles, filling ticket forms etc. Users are going to love this. Should we not improve the email experience just for the sake of abstract concepts such as Web Standards? Not to mention that AMP is an open spec that could be implemented by anyone and be included in web standards.
  - iamdave 9y ago
    Filling out web forms in emails sounds like a dream come true for phishing shops.
  - nixpulvis 9y ago
    It's sad that we've gotten so jaded that you think Web Standards are abstract concepts that get in the way of improvement. Standards are what have gotten us as far as we are (in general). P.S. WTF is a doodle?
    - patrickaljord 9y ago
      You're aware that most web standards originate from proprietary tech that went crazy popular and were then standardized? Doodle is super popular in Europe but not so in the US https://doodle.com/ https://doodle.com/
- EpicEng 9y ago
  >Enough people are coming out saying it's a terrible idea... In the tech sphere, posting on blogs linked to by sites like HN. The fact is that 99% of gmails users will never see the push back and have no clue what AMP is. Unless the actual experience is just terrible, most users will be probably enjoy the added functionality without thinking about the concerns we have.
superkuh 9y ago
The problem with AMP is centralization. The problem with centralization is deciding who gets to talk about what subjects. Centralization provides perverse incentives to restrict this. That email operates as a significantly decentralized, federated set of privately run servers cuts the gordian knot of having to decide what is allowed. AMP is a step backwards for everyone in order to make up for the terrible performance of mobile networks and smart phones.
- bonaldi 9y ago
  Mobile networks and smart phones have incredible performance. AMP is about making up for the race-to-the-bottom behaviour of sites that can’t resist using 6mb and a boatful of JS just to render an article(+analytics+ads)
  - regularhackerer 9y ago
    Could do that without centralization.
  - superkuh 9y ago
    Do you really believe that? They can't even hold a TCP connection open without running out of battery or terrible latency. And $diety forbid trying to host or use ports.
    - bonaldi 9y ago
      I have a device that fits in my trouser pocket that allows me to stream and watch HD video for multiple hours over a cell network while being powered by a battery roughly the volume of a matchbox. Yes, I think that's incredible. Does it have TCP characteristics similar to an Ethernet-equipped desktop? No, probably not -- but that's got nothing to do with the characteristics that led to the creation of AMP. Mobile networks and phones are powerful enough for video, so they're powerful enough to download and render a web page. If they're slow at web pages, it's very likely the fault of the page creator, not the network or device. AMP is an attempt to force the hands of the page creators out there, since they apparently can't self-regulate.
cromwellian 9y ago
I don't know why people keep getting this wrong, but AMP does not introduce proprietary browser extensions or syntax. It's a custom element framework, not much different than say, React and JSX, or Vue, Ember, or tools such as LESS/SASS. In fact, its even more 'webby' than those because at least some browsers don't need polyfills for Web Components, and the declarative nature is more transparent than a virtual dom app with embedded data. Web Components was created so that browsers could use custom elements, like say <pay-with-bitcoin-button/> or <x-video codec="daala" src="foo.daala"/> AMPHTML is an implementation of that. Everyday like clockwork, new frameworks appear on HN that introduce yet another way to create web content that eschews the vanilla approach, AMP is about as close to vanilla as you can get. There's a separate issue if your concern is Google SERP giving preference to AMP or the way it is being rendered in a carousel, but that's a political argument around the deployment, it's not a technical argument against having a simple subset that unsophisticated developers can use to create fast loading apps, like Twitter bootstrap helped many devs create proper HTML5 content. Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement, and CloudFlare already provides a competing implementation. I get why people have legitimate gripes over AMP: URL/bookmarking/canonical linking behavior, scrolling behavior on Safari, the way its rendered in Google.com, perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored, etc. I think those are all legitimate concerns, but the hyperbole over the syntax seems very misplaced: AMP isn't Flash or ActiveX, it runs on open web browsers without modification on top of standard specs. Over and over again, people say "but you don't need AMP, you can make fast mobile sites by hand!" That's like saying "You don't need Web frameworks, you can make great apps with VanillaJS and HTML", the only problem is, history has shown that most web developers can't, and absent some framework codifying good behaviors, badness accumulates overtime until things get so bad that users turn away from the web altogether to native apps. You'll find years later complaining about how Apple News killed the mobile web and why you're forced to get your content approved by gated native News apps, because of overly optimistic beliefs that the wild wild west of news publisher web jockeys would all create optimal, consistent mobile browser experiences without assistance or any industry effort to standardize some best practices. BTW, we've been down this road before. Remember XHTML Mobile?
- 9y ago

Re: "Amp for Email uses that language instead of HTML and CSS." Is this correct? Looking at the example in the spec [1], it seems to be a subset of HTML. [1] https://github.com/ampproject/amphtml/issues/13457 https://github.com/ampproject/amphtml/issues/13457

gregable 9y ago
It is just a subset of HTML (as is amp). Most email providers that accept HTML formats already only accept a subset of HTML. This is just a different, more formally defined, subset.
- nixpulvis 9y ago
  I mean, HTML is just XML... these subsets are in many ways their own language.
  - seabrookmx 9y ago
    It's not, technically. XHTML was a formally defined HTML subset of XML but it died.
    - nixpulvis 9y ago
      Fair enough, my point stands though.
  - dingaling 9y ago
    HTML is an application of SGML / ISO8879. It defines its own domain and that's the scope of it. It's a leaf. XML is a subset of SGML and can have further subsets and implementing applications I.e. it is a branch. As noted above, XHTML was a leaf on this branch. So they are related but not equivalent.
iza 9y ago
Except you have to use <amp-img> tags instead of <img>. Same for video, audio, and iframe. https://www.ampproject.org/docs/reference/spec#html-tags https://www.ampproject.org/docs/reference/spec#html-tags
- magicalist 9y ago
  > Except you have to use <amp-img> tags instead of <img> Those are just custom elements: https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html
  - skybrian 9y ago
    Hmm, custom elements are an interesting loophole. If you define your own set of tags and provide JavaScript implementations for them, I guess it would run in a browser, but is it really the same language anymore, and does it matter? I'm reminded of: #define BEGIN { #define END }
    - magicalist 9y ago
      > is it really the same language anymore Yes? The analogy would be more like defining custom functions or classes not in the standard library. It's just encapsulation that can then be used by name. They can't be inserted arbitrarily regardless of syntax like a macro can be.

eveningcoffee 9y ago

AMP for Email is another Googles attempt to grab more dominance by abusing their market share.

ronnier 9y ago

I really don’t care about amp for email. But I’m very worried about amp for the web because it means we give up control of our content and features and will need to live by googles rules.

nixpulvis 9y ago
Do you just not use email much then?
- criddell 9y ago
  It's just a client-side thing then, right? I can send email to a GMail user from a non-AMP client and I can receive email from a GMail user. I don't think there are any mail system interoperability concerns, are there?
  - nixpulvis 9y ago
    I assume sending will always work as expected (they aren't about to start demanding things be AMP formatted), but who knows what your client might render an AMP email looking like.
skybrian 9y ago
I know what you mean, but at a certain level of abstraction, isn't that what web programming is all about? You already live by Chrome+Firefox+Safari+IE rules. I mean sure, there's a complicated political process, but it's still rules made by other people working for large organizations that the average web programmer just accepts. It's not like we all had a vote about Flash. Or JavaScript, for that matter. There's a lot you can do while working within the rules, though.

aidenn0 9y ago

Enough people are coming out saying it's a terrible idea that the contrarian in me thinks is't likely to catch on now.

patrickaljord 9y ago
Being able to do tasks without leaving your email client is actually great, specially on mobile. Answering Doodles, filling ticket forms etc. Users are going to love this. Should we not improve the email experience just for the sake of abstract concepts such as Web Standards? Not to mention that AMP is an open spec that could be implemented by anyone and be included in web standards.
- iamdave 9y ago
  Filling out web forms in emails sounds like a dream come true for phishing shops.
- nixpulvis 9y ago
  It's sad that we've gotten so jaded that you think Web Standards are abstract concepts that get in the way of improvement. Standards are what have gotten us as far as we are (in general). P.S. WTF is a doodle?
  - patrickaljord 9y ago
    You're aware that most web standards originate from proprietary tech that went crazy popular and were then standardized? Doodle is super popular in Europe but not so in the US https://doodle.com/ https://doodle.com/
EpicEng 9y ago
>Enough people are coming out saying it's a terrible idea... In the tech sphere, posting on blogs linked to by sites like HN. The fact is that 99% of gmails users will never see the push back and have no clue what AMP is. Unless the actual experience is just terrible, most users will be probably enjoy the added functionality without thinking about the concerns we have.

superkuh 9y ago

The problem with AMP is centralization. The problem with centralization is deciding who gets to talk about what subjects. Centralization provides perverse incentives to restrict this. That email operates as a significantly decentralized, federated set of privately run servers cuts the gordian knot of having to decide what is allowed. AMP is a step backwards for everyone in order to make up for the terrible performance of mobile networks and smart phones.

bonaldi 9y ago
Mobile networks and smart phones have incredible performance. AMP is about making up for the race-to-the-bottom behaviour of sites that can’t resist using 6mb and a boatful of JS just to render an article(+analytics+ads)
- regularhackerer 9y ago
  Could do that without centralization.
- superkuh 9y ago
  Do you really believe that? They can't even hold a TCP connection open without running out of battery or terrible latency. And $diety forbid trying to host or use ports.
  - bonaldi 9y ago
    I have a device that fits in my trouser pocket that allows me to stream and watch HD video for multiple hours over a cell network while being powered by a battery roughly the volume of a matchbox. Yes, I think that's incredible. Does it have TCP characteristics similar to an Ethernet-equipped desktop? No, probably not -- but that's got nothing to do with the characteristics that led to the creation of AMP. Mobile networks and phones are powerful enough for video, so they're powerful enough to download and render a web page. If they're slow at web pages, it's very likely the fault of the page creator, not the network or device. AMP is an attempt to force the hands of the page creators out there, since they apparently can't self-regulate.

cromwellian 9y ago

I don't know why people keep getting this wrong, but AMP does not introduce proprietary browser extensions or syntax. It's a custom element framework, not much different than say, React and JSX, or Vue, Ember, or tools such as LESS/SASS. In fact, its even more 'webby' than those because at least some browsers don't need polyfills for Web Components, and the declarative nature is more transparent than a virtual dom app with embedded data. Web Components was created so that browsers could use custom elements, like say <pay-with-bitcoin-button/> or <x-video codec="daala" src="foo.daala"/> AMPHTML is an implementation of that. Everyday like clockwork, new frameworks appear on HN that introduce yet another way to create web content that eschews the vanilla approach, AMP is about as close to vanilla as you can get. There's a separate issue if your concern is Google SERP giving preference to AMP or the way it is being rendered in a carousel, but that's a political argument around the deployment, it's not a technical argument against having a simple subset that unsophisticated developers can use to create fast loading apps, like Twitter bootstrap helped many devs create proper HTML5 content. Otherwise common inaccurate statements are that AMP Cache is Google-only, when in fact, it's a spec others can implement, and CloudFlare already provides a competing implementation. I get why people have legitimate gripes over AMP: URL/bookmarking/canonical linking behavior, scrolling behavior on Safari, the way its rendered in Google.com, perceptions that if you create a fast site that is AMP-like, but doesn't use AMP, you don't know how it's going to be scored, etc. I think those are all legitimate concerns, but the hyperbole over the syntax seems very misplaced: AMP isn't Flash or ActiveX, it runs on open web browsers without modification on top of standard specs. Over and over again, people say "but you don't need AMP, you can make fast mobile sites by hand!" That's like saying "You don't need Web frameworks, you can make great apps with VanillaJS and HTML", the only problem is, history has shown that most web developers can't, and absent some framework codifying good behaviors, badness accumulates overtime until things get so bad that users turn away from the web altogether to native apps. You'll find years later complaining about how Apple News killed the mobile web and why you're forced to get your content approved by gated native News apps, because of overly optimistic beliefs that the wild wild west of news publisher web jockeys would all create optimal, consistent mobile browser experiences without assistance or any industry effort to standardize some best practices. BTW, we've been down this road before. Remember XHTML Mobile?

9y ago