W3C home > Mailing lists > Public > public-digipub-ig@w3.org > March 2016

RE: An interesting take on AMP versus PWP

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Wed, 30 Mar 2016 14:04:13 +0000
To: Nick Ruffilo <nickruffilo@gmail.com>, Alan Stearns <stearns@adobe.com>
CC: "public-digipub-ig@w3.org" <public-digipub-ig@w3.org>
Message-ID: <CY1PR0601MB1422D250C0D4DDE98F1FBF53DF980@CY1PR0601MB1422.namprd06.prod.outlook.com>
This is also an example of the common confusion between "document" and "publication." Simply recognizing the issues around a "publication" as distinct from a simple "document" immediately reveals that AMP and PWP are apples and banquets. ;) AMP is basically a profile of HTML, mainly a subsetting. I don't see any reason why a content document in a PWP couldn't conform to AMP and thereby load and render faster. There is no conflict here, imo.—Bill Kasdorf

From: Nick Ruffilo [mailto:nickruffilo@gmail.com]
Sent: Tuesday, March 29, 2016 8:57 PM
To: Alan Stearns
Cc: public-digipub-ig@w3.org
Subject: Re: An interesting take on AMP versus PWP

I think it's worth noting that AMP could be considered a portable document format for sorts but by NO MEANS is it a complete or fully functional document that we hope to scope out with PWP.

It would be interesting for us to look at how AMP solves a few issues - but I really don't think it answers much - it just limits functionality to ensure high-performance (speed).

There are some interesting overviews and resources on AMP (https://www.ampproject.org/) but I personally disagree very strongly with Baldur's last paragraph (which sadly seems to be a theme - i like most of what Baldur says and then in his last paragraph he jumps the shark in a way that leaves me blinking...)


On Tue, Mar 29, 2016 at 6:39 PM, Alan Stearns <stearns@adobe.com<mailto:stearns@adobe.com>> wrote:
I don’t know enough about AMP to evaluate this, but thought I should pass it on.



(an attempt to quote twitter in email)


Baldur Bjarnason

> An interesting side-effect of AMP's basic model is
> that anybody can run an AMP CDN and, because behaviour
> is well-defined, customise it
> If you have an app/platform & would like to control
> the performance or representation of AMP pages linked
> from it, you could do your own CDN
> That includes anything from aggressively pre-loading
> linked AMP pages to tweaking how its custom elements
> behave.
> By sub-setting HTML and limiting JS behaviour to a
> strictly defined set of custom elements, Google has
> effectively created portable web docs
> Which basically makes most of what the W3C's Digital
> Publishing Interest Group is working on, a modern
> XHTML2 to Google AMP's HTML5

- Nick Ruffilo
Aer.io<http://Aer.io> an INGRAM company

Received on Wednesday, 30 March 2016 14:04:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:41 UTC