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.
[1] https://amp.dev/ru/documentation/guides-and-tutorials/learn/...
> 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-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>
https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/
It's not 2010 HTML, that's for sure, but so what? Are you complaining about AMP, or about HTML5?
[1]: Spec: https://developer.mozilla.org/en-US/docs/Web/Web_Components/...
[2]: Examples: https://www.webcomponents.org/
HTML has always tolerated out-of-spec tags, because it was originally designed as an application of SGML (defined by an SGML DTD). Since then, new tags were regularly added (and generally tolerated by older browsers), but the practice of defining new tags in a DTD has gradually stopped happening. Web Components accomplish a similar role but replace the use of the declarative language in a DTD with a requirement to run a Turing complete langrage. Making the definition of new tags undecidable is a powerful way to tightly couple browser implementations under Google's control.
[1] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
An html compliant browser would apply the custom elements spec and render the custom element. If the user isn't using JavaScript, then you fall back, as defined in the spec.
Note that custom elements are themselves a standard, there is no "extending" here. There is just applying the web elements spec in a way some people dislike.
Other sunsets of HTML failed magnificently like XHTML basic and it’s siblings.
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.
If it's a standard, shouldn't there be some way for those elements to work without including someone else's JavaScript?
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.
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.
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?
Not the crypto library https://nacl.cr.yp.to/
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.