New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why break HTML spec with AMP when it's possible to implement AMP in HTML compliant way? #1245

bazzadp opened this Issue Dec 24, 2015 · 5 comments


None yet
3 participants
Copy link

bazzadp commented Dec 24, 2015

Any particular reason why AMP decided to go with:

<html amp>

or even, the horrible, charset dependent lightning bolt:

<html >

Rather than the more standards compliant:

<html itemprop="amp">

Or even:

 <meta name="amp" content="amp">

Similarly <amp-img> could have been implemented as <img itemprop="amp-img"> or similar.

Presume the AMP code could have coped with any of these implementations so it seems a shame that AMP has decided to break existing HTML validators so an AMP page is not an HTML page, nor vice versa, but they are two distinct entities.

While I'm sure the HTML standard (and HTML validators) will catch up it just seems a needless extra bit of work.

Were there any reasons to go with this implementation?

Any chance AMP will support HTML-compliant versions as well so developers are free to choose which to implement if they want to keep existing HTML validators?


This comment has been minimized.

Copy link

cramforce commented Dec 24, 2015

Custom elements are part of HTML. It is time for validators to catch up. Custom properties are also a reality of the web. Namespacing everything is tedious and unidiomatic.

<img itemprop="amp-img"> wouldn't be the right way to go <img is="amp-img"> would. This article explains why AMP does not use the is attribute: (It doesn't even mention the harm that this would bring to Safari users, due to the preload scanner being wrong and double loading images with w modifiers in their srcset.

Most validators provide a way to add custom rules to make certain things they consider invalid by default to succeed. Would you be interested in creating such a custom ruleset for your favorite validator, so others don't have to?

@cramforce cramforce added the Question label Dec 24, 2015


This comment has been minimized.

Copy link

bazzadp commented Dec 26, 2015

Thanks for the answer and interesting post on not preloading images.

For the moment, while the AMP project is in a state of flux, and while it has it's own validator, it's probably best to leave AMP out of other HTML validators.


This comment has been minimized.

Copy link

dvoytenko commented Dec 28, 2015

AMP is indeed is being in active development. That being said, HTML Custom Elements are fairly stable and AFAIK either already implemented or being actively implemented in all major browsers.


This comment has been minimized.

Copy link

bazzadp commented Dec 29, 2015

My issue is not really with the use of custom elements and the validation issues they currently cause. It's the fact that that an AMP page is no longer a HTML page - in that it cannot be read without executing the AMP javascript.

This means non-Javascript browsers, or even browsers that are too old (given that AMP has stated that they will only guarantee support for the latest two major versions of browser), won't be guaranteed to load key components of the page like media since there are no fall backs to standard HTML. While that's a decision people have to make for complex applications, it's not one that IMHO should need to be made for simple articles - which are the pages AMP is aimed at.

I could not see a reason for this and the preloading issue is a good reason, so I'm glad that was explained to me. Though I'm still not convinced it could not be implemented in a different way.

For example adding a new "do-not-preload-media" meta to the top of the page, or a new img attribute for same - though obviously I realise either would require browser support to be added before it would be effective whereas AMP can be used now with no browser changes. On the plus side it would benefit the whole of the web and not just AMP pages.

Alternatively the sites that will use AMP pages (Google, Twitter...etc), as opposed to those that will create AMP pages (publishers), could have implemented something on their side with Javascript to pre-fetch the HTML page only and load it into the cache (though no pre-render, but is that such a big deal for simple pages).

Alternatively if insistent on using custom amp tags then fallbacks would also be fairly simple to implement with code like this (though admittedly not sure whether pre-loader would incorrectly pick up the fallback and download the image when it didn't need to):

<amp-img src="img.png" alt="text" height="165" width="700">
<noscript><img src="img.png" alt="text" height="165" width="700"></noscript>

Those are just a few thoughts that spring to my mind, but am sure much cleverer people than me could have come up with even better ways. Creating a completely separate HTML-like page that is in fact not HTML seems like a poor solution to me and requires two versions of every page (I don't buy that the AMP version can be the only version for the reasons given above - that it is not HTML).

I personally think web developers would be much happier if they could make a few changes to their code, and benefit fro a project like AMP, without having to create completely separate pages for this.

Anyway that's just my opinion. And I've since found out this discussion was had before (#472) and closed off without any real resolution (I'm obviously with @JohannesEH in this), so will similarly close this issue.

Thanks for taking the time to explain your reasoning to me.

@bazzadp bazzadp closed this Dec 29, 2015


This comment has been minimized.

Copy link

bazzadp commented Feb 14, 2016

Know this issue is closed, but in case anyone else stumbles on this later:

Looks like noscript now is allowed in amp documents meaning you can implement fall backs for media items (img, video and audio) for non-javascript browsers. See this issue for more information: #1279. This makes me a little happier now :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment