5 ms·

The problem is that the AMP standard is just generally poorly-thought-out, no matter who hosts it. Instead of a subset of HTML, it's a weird mishmash of everyth

The problem is that the AMP standard is just generally poorly-thought-out, no matter who hosts it. Instead of a subset of HTML, it's a weird mishmash of everything that requires magic incantations to make things work for the browsers of the time it was invented. It's like NaCl/PNaCl - a good idea in theory, but created by a team that didn't do a great job at speccing something that could be long lived and satisfy other players than Google+Chrome.

cromwellian 8y ago
Isn’t it a subset by definition? It runs in html5 browsers. Other sunsets of HTML failed magnificently like XHTML basic and it’s siblings.
- tyingq 8y ago
  Technically perhaps. But with things like <amp-img> instead of <img>, so yes, it "runs".
  - cromwellian 8y ago
    Web-components are HTML. Registering a new element (e.g. <amp-img>) that wraps <img> with some additional restrictions, is pretty much making a subset facade that restricts you to the subset. It's like complaining that BibTeX, LaTeX, AMSTeX et al aren't "TeX". In the original incarnation of SGML, the whole point of the DTD and DSSSL was to be able to define new elements, and specify how they are handled. This seems perfectly legitimate and part of the HTML standard. There may be other problems with AMP, but creating new high level elements that resolve to standard HTML elements, doesn't seem to be one of them, and arguing over whether something is named 'amp-img', or 'img' + some detailed validator that throws errors if you try to do anything with <img> off the rails, seems to be bike-shedding over naming, and if anything, I'd argue giving new names to a function to limit its inputs is more clear and readable, then adding precondition checks only.
    - deleted 8y ago
      [deleted]
    - tyingq 8y ago
      Well those new elements aren't functional unless you specifically include a Google controlled/hosted piece of JavaScript in your AMP page. If it's a standard, shouldn't there be some way for those elements to work without including someone else's JavaScript?
      - cromwellian 8y ago
        Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet"? If your objection is that the ampjs has to be loaded from Google's CDN, well, the whole point of Signed Exchanges/Web packaging is to move to a world where AMP caches are federated and you can host this stuff elsewhere. The only real objection that has merit IMHO is that Google Search should rank these things based on performance, not on amp validation alone, so if you authored your own AMP-like framework, it could be similarly ranked.
        tyingq 8y ago
        "Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet" The important part isn't "this", it's "somebody else's". AMP is very specific not about what the JS is, but rather where it is, and that you must include it using their mandated url, not your local copy. I'm just not comfortable with the idea that "you must include this opaque thing that we might change" be advertised as a standards-based movement. I have no issue with Google pushing something like AMP. I just don't like the charade that it's some sort of open movement.
        cromwellian 8y ago
        I agree with what you're saying, but AFAIK, AMP forced this hosting for very specific reasons in the browser protocol stack, and that Web Packaging/Signed Exchanges are designed to address. That is, forcing a single opaque resource location is a hack/polyfill for what should have been some kind of native browser support for these mechanisms in the first place. To me, there's been a lot of false starts in the Browser platform, a lot of hacks, and 'worse is better', until we finally get something good. Remember AppCache/Application Manifests? It was horrible. Now we have Service Workers. Or the gazillion variations of <link> prefetch/subresource/prerender/etc I think eventually we'll end up at a good place that doesn't have a centralized requirement. And I don't (being a Google employee), see these designs as deliberate attempts to arrogate power and control, but more like expediency. AMP was a reaction to Apple News and Facebook Instant putting publishers in non-Web silos. You could argue the proper thing to do would have been for the W3C/WHATWG to design something by committee, then wait a year or two for all browsers to ship, and then get the publishers on board. What AMP essentially did was ship a polyfill fix for something on existing web technologies to get publishers to do something they could have done on their own, but didn't, with the eventual real fix coming later. For whatever reason, publishers seemed unwilling to fix their mobile performance using standard practices, and invited a takeover of native mobile silos. I see AMP as a kind of holding action to preserve federated mobile web publishing, until something better came along. You have to ask yourself, what's worse, using HTML Web Components and a JS framework library, or having major publishers choosing Apple News or Facebook Instant as their primary publishing mechanism on mobile?
dfabulich 8y ago
This new thing substantially improves the design. What design problems do you see in the new thing?
- mmastrac 8y ago
  The whole spec is still a giant mess [1] of HTML and HTML-like-but-not-quite-really, with a boatload of ceremony that does nothing but glue it into an existing ecosystem. Hosting it on someone else's site doesn't fix that. [1] https://amp.dev/ru/documentation/guides-and-tutorials/learn/spec/amphtml?referrer=ampproject.org https://amp.dev/ru/documentation/guides-and-tutorials/learn/...
  - themacguffinman 8y ago
    I honestly don't see the mess that you're referring to. Can you be a bit more specific? AFAIK, Amp is 100% valid HTML because it's a HTML subset, it is not "HTML-like-but-not-really".
    - pdkl95 8y ago
      That is patently not true. From mmastrac's [1]: > Resources such as images, videos, audio files or ads must be included into an AMP HTML file through custom elements such as <amp-img> From: https://github.com/ampproject/amphtml/blob/master/spec/amp-tag-addendum.md#amp-specific-tags https://github.com/ampproject/amphtml/blob/master/spec/amp-t... Amp Specific Tags <amp-img> <amp-video> <amp-ad> <amp-fit-text> <amp-font> <amp-carousel> <amp-anim> <amp-youtube> <amp-twitter> <amp-vine> <amp-instagram> <amp-iframe> <amp-pixel> <amp-audio> <amp-lightbox> <amp-image-lightbox> None of that is "100% valid HTML".
      - themacguffinman 8y ago
        Custom elements are 100% valid and standards-compliant HTML. https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/ https://www.w3.org/TR/custom-elements/
throwawaymath 8y ago
What's wrong with NaCl?
- dfabulich 8y ago
  I believe the gp was referring to NaCl the Native Client https://developer.chrome.com/native-client https://developer.chrome.com/native-client Not the crypto library https://nacl.cr.yp.to/ https://nacl.cr.yp.to/
- mmastrac 8y ago
  NaCl was an interesting tech demo, but it was a complex set of rules built on the x86 house of cards and it took a lot of work to port it between platforms (I think it was demoed on ARM but never took off). PNaCl was a "lazy" attempt at making this cross-platform by leveraging LLVM's intermediate format which was never designed to be a "format" like that. WebAssembly is 10x better than either of those formats and you can see the benefits of having multiple players design something to work for a long-term horizon.

cromwellian 8y ago

Isn’t it a subset by definition? It runs in html5 browsers. Other sunsets of HTML failed magnificently like XHTML basic and it’s siblings.

tyingq 8y ago
Technically perhaps. But with things like <amp-img> instead of <img>, so yes, it "runs".
- cromwellian 8y ago
  Web-components are HTML. Registering a new element (e.g. <amp-img>) that wraps <img> with some additional restrictions, is pretty much making a subset facade that restricts you to the subset. It's like complaining that BibTeX, LaTeX, AMSTeX et al aren't "TeX". In the original incarnation of SGML, the whole point of the DTD and DSSSL was to be able to define new elements, and specify how they are handled. This seems perfectly legitimate and part of the HTML standard. There may be other problems with AMP, but creating new high level elements that resolve to standard HTML elements, doesn't seem to be one of them, and arguing over whether something is named 'amp-img', or 'img' + some detailed validator that throws errors if you try to do anything with <img> off the rails, seems to be bike-shedding over naming, and if anything, I'd argue giving new names to a function to limit its inputs is more clear and readable, then adding precondition checks only.
  - deleted 8y ago
    [deleted]
  - tyingq 8y ago
    Well those new elements aren't functional unless you specifically include a Google controlled/hosted piece of JavaScript in your AMP page. If it's a standard, shouldn't there be some way for those elements to work without including someone else's JavaScript?
    - cromwellian 8y ago
      Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet"? If your objection is that the ampjs has to be loaded from Google's CDN, well, the whole point of Signed Exchanges/Web packaging is to move to a world where AMP caches are federated and you can host this stuff elsewhere. The only real objection that has merit IMHO is that Google Search should rank these things based on performance, not on amp validation alone, so if you authored your own AMP-like framework, it could be similarly ranked.
      - tyingq 8y ago
        "Isn't that like saying "This page doesn't render without including this CSS or Font or XSL Stylesheet" The important part isn't "this", it's "somebody else's". AMP is very specific not about what the JS is, but rather where it is, and that you must include it using their mandated url, not your local copy. I'm just not comfortable with the idea that "you must include this opaque thing that we might change" be advertised as a standards-based movement. I have no issue with Google pushing something like AMP. I just don't like the charade that it's some sort of open movement.
        cromwellian 8y ago
        I agree with what you're saying, but AFAIK, AMP forced this hosting for very specific reasons in the browser protocol stack, and that Web Packaging/Signed Exchanges are designed to address. That is, forcing a single opaque resource location is a hack/polyfill for what should have been some kind of native browser support for these mechanisms in the first place. To me, there's been a lot of false starts in the Browser platform, a lot of hacks, and 'worse is better', until we finally get something good. Remember AppCache/Application Manifests? It was horrible. Now we have Service Workers. Or the gazillion variations of <link> prefetch/subresource/prerender/etc I think eventually we'll end up at a good place that doesn't have a centralized requirement. And I don't (being a Google employee), see these designs as deliberate attempts to arrogate power and control, but more like expediency. AMP was a reaction to Apple News and Facebook Instant putting publishers in non-Web silos. You could argue the proper thing to do would have been for the W3C/WHATWG to design something by committee, then wait a year or two for all browsers to ship, and then get the publishers on board. What AMP essentially did was ship a polyfill fix for something on existing web technologies to get publishers to do something they could have done on their own, but didn't, with the eventual real fix coming later. For whatever reason, publishers seemed unwilling to fix their mobile performance using standard practices, and invited a takeover of native mobile silos. I see AMP as a kind of holding action to preserve federated mobile web publishing, until something better came along. You have to ask yourself, what's worse, using HTML Web Components and a JS framework library, or having major publishers choosing Apple News or Facebook Instant as their primary publishing mechanism on mobile?

dfabulich 8y ago

This new thing substantially improves the design. What design problems do you see in the new thing?

mmastrac 8y ago
The whole spec is still a giant mess [1] of HTML and HTML-like-but-not-quite-really, with a boatload of ceremony that does nothing but glue it into an existing ecosystem. Hosting it on someone else's site doesn't fix that. [1] https://amp.dev/ru/documentation/guides-and-tutorials/learn/spec/amphtml?referrer=ampproject.org https://amp.dev/ru/documentation/guides-and-tutorials/learn/...
- themacguffinman 8y ago
  I honestly don't see the mess that you're referring to. Can you be a bit more specific? AFAIK, Amp is 100% valid HTML because it's a HTML subset, it is not "HTML-like-but-not-really".
  - pdkl95 8y ago
    That is patently not true. From mmastrac's [1]: > Resources such as images, videos, audio files or ads must be included into an AMP HTML file through custom elements such as <amp-img> From: https://github.com/ampproject/amphtml/blob/master/spec/amp-tag-addendum.md#amp-specific-tags https://github.com/ampproject/amphtml/blob/master/spec/amp-t... Amp Specific Tags <amp-img> <amp-video> <amp-ad> <amp-fit-text> <amp-font> <amp-carousel> <amp-anim> <amp-youtube> <amp-twitter> <amp-vine> <amp-instagram> <amp-iframe> <amp-pixel> <amp-audio> <amp-lightbox> <amp-image-lightbox> None of that is "100% valid HTML".
    - themacguffinman 8y ago
      Custom elements are 100% valid and standards-compliant HTML. https://html.spec.whatwg.org/multipage/custom-elements.html https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/ https://www.w3.org/TR/custom-elements/

throwawaymath 8y ago

What's wrong with NaCl?

dfabulich 8y ago
I believe the gp was referring to NaCl the Native Client https://developer.chrome.com/native-client https://developer.chrome.com/native-client Not the crypto library https://nacl.cr.yp.to/ https://nacl.cr.yp.to/
mmastrac 8y ago
NaCl was an interesting tech demo, but it was a complex set of rules built on the x86 house of cards and it took a lot of work to port it between platforms (I think it was demoed on ARM but never took off). PNaCl was a "lazy" attempt at making this cross-platform by leveraging LLVM's intermediate format which was never designed to be a "format" like that. WebAssembly is 10x better than either of those formats and you can see the benefits of having multiple players design something to work for a long-term horizon.