Hacker News Reader

Comment by dfabulich | Hacker News Reader

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

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/...

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".

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-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".

Custom elements are 100% valid and standards-compliant HTML.

https://html.spec.whatwg.org/multipage/custom-elements.html https://www.w3.org/TR/custom-elements/

Are you familiar with HTML5 and Custom Elements[1][2] (often aka WebComponents). <legit-whatever-i-want> is a valid HTML component.

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/

So what happens when an HTML-compliant browser renders a document with <amp-img>? It won't be what the author of the document intended, because the browser will skip the <amp-img> tag. The document is only interoperable if all browsers load and execute Google's Javascript that defines those tags. This type of technically-valid with obviously functionally incompatible is a perfect example of the Extend phase of the EEE[1] strategy.

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...

This is an application of the W3C's Extensible Web Manifesto (https://www.w3.org/community/nextweb/2013/06/11/the-extensib...)

What?

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.

Reply on news.ycombinator.com