Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Why break HTML spec with AMP when it's possible to implement AMP in HTML compliant way? #1245
Any particular reason why AMP decided to go with:
or even, the horrible, charset dependent lightning bolt:
Rather than the more standards compliant:
<html> <meta name="amp" content="amp">
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?
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.
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?
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 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):
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.
Know this issue is closed, but in case anyone else stumbles on this later: