4 ms·

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 th

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?

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?