Re: Canonical content and AMP

--001a1130ce582b712f0530d970e5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I didn=E2=80=99t think much about AMP until I read this Search Engine Watch=
 article
<https://searchenginewatch.com/2016/02/22/what-will-googles-accelerated-mob=
ile-pages-amp-mean-for-marketers/>
in February. This is the phrase that caused a pang: =E2=80=9CSimply put,
Accelerated Mobile Pages is a stripped-down version of the mobile web which
runs on a reinvented version of the language used to create web pages:
HTML.=E2=80=9D

The article describes AMP as =E2=80=9CGoogle=E2=80=99s answer to Facebook=
=E2=80=99s Instant
Articles and Apple News.=E2=80=9D

I can only agree with Andrew=E2=80=A6 technologies like AMP promote duplica=
tion of
content in multiple formats in different locations on the web, and that=E2=
=80=99s a
bad thing. Especially in those situations (all of the above) where the
architectural sleight of hand helps continue to centralize the action.

And I can=E2=80=99t see there=E2=80=99s much we can do about it. Directly t=
hat is. It=E2=80=99s a
classic case of what the hi:project team has come to call
short-term-gain-long-term-pain. And just look at all those publishing
companies signing up for that short-term-gain =E2=80=93 market and technolo=
gical
forces leave them no option imho.


On 19 April 2016 at 15:48, Travis Leithead <[email protected]>
wrote:

> My initial reaction is that AMP, while good intentioned and helpful for
> performance, is similar to the =E2=80=9Cmobile web=E2=80=9D XHTML subset =
or the TV
> subsetting that we discussed. The difference is that AMP is opt-in by the
> developer community, so it=E2=80=99s not device- or browser-makers buildi=
ng it in=E2=80=A6
>
>
>
> *From:* Andrew Betts [mailto:[email protected]]
> *Sent:* Tuesday, April 19, 2016 1:31 AM
> *To:* [email protected]
> *Subject:* Canonical content and AMP
>
>
>
> At the F2F in March I was concerned that the best progressive web apps
> were generally mobile-only, and I=E2=80=99m getting a similar feeling abo=
ut AMP.
>
>
>
> I=E2=80=99m wondering whether TAG have a view on the use of `m.` sites.  =
>From an
> architectural perspective `m.` is a bad thing, surely.  But I can=E2=80=
=99t build
> my desktop webpages using AMP - because I would lose essential features
> like reader comments, so I'm stuck serving (at least) two copies of the
> same document.
>
>
>
> HTML sandbox / Content Performance Policy seems like a better approach,
> but I=E2=80=99m wondering whether I=E2=80=99m alone in thinking that a) t=
echnologies like
> AMP can promote duplication of content in multiple formats in different
> locations on the web, and 2) that=E2=80=99s a bad thing.
>
>
>
> Seems to me that we've spent the last few years gradually moving away fro=
m
> m., and we're now heading back towards that territory.  Is this a conscio=
us
> recognition that One-Responsive-To-Rule-Them-All was a bad idea?
>

--001a1130ce582b712f0530d970e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I didn=E2=80=99t think much about AMP until I read <a href=
=3D"https://searchenginewatch.com/2016/02/22/what-will-googles-accelerated-=
mobile-pages-amp-mean-for-marketers/">this Search Engine Watch article</a> =
in February. This is the phrase that caused a pang: =E2=80=9CSimply put, Ac=
celerated Mobile Pages is a stripped-down version of the mobile web which r=
uns on a reinvented version of the language used to create web pages: HTML.=
=E2=80=9D<br><br>The article describes AMP as =E2=80=9CGoogle=E2=80=99s ans=
wer to Facebook=E2=80=99s Instant Articles and Apple News.=E2=80=9D<br><br>=
I can only agree with Andrew=E2=80=A6 technologies like AMP promote duplica=
tion of content in multiple formats in different locations on the web, and =
that=E2=80=99s a bad thing. Especially in those situations (all of the abov=
e) where the architectural sleight of hand helps continue to centralize the=
 action.<br><br>And I can=E2=80=99t see there=E2=80=99s much we can do abou=
t it. Directly that is. It=E2=80=99s a classic case of what the hi:project =
team has come to call short-term-gain-long-term-pain. And just look at all =
those publishing companies signing up for that short-term-gain =E2=80=93 ma=
rket and technological forces leave them no option imho.<br><br><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On 19 April 2016 at 15:48, =
Travis Leithead <span dir=3D"ltr">&lt;<a href=3D"mailto:travis.leithead@mic=
rosoft.com" target=3D"_blank">[email protected]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">





<div link=3D"#0563C1" vlink=3D"#954F72" lang=3D"EN-US">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,sans-serif">My initial reaction is that AMP, while good intenti=
oned and helpful for performance, is similar to the =E2=80=9Cmobile web=E2=
=80=9D XHTML subset or the TV subsetting that we discussed. The
 difference is that AMP is opt-in by the developer community, so it=E2=80=
=99s not device- or browser-makers building it in=E2=80=A6<u></u><u></u></s=
pan></p>
<p class=3D"MsoNormal"><a name=3D"m_4277471640375102476__MailEndCompose"><s=
pan style=3D"font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"><=
u></u>=C2=A0<u></u></span></a></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,sans-serif">From:</span></b><span style=3D"font-size:11.0pt;=
font-family:&quot;Calibri&quot;,sans-serif"> Andrew Betts [mailto:<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
</a>]
<br>
<b>Sent:</b> Tuesday, April 19, 2016 1:31 AM<br>
<b>To:</b> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]=
rg</a><br>
<b>Subject:</b> Canonical content and AMP<u></u><u></u></span></p><div><div=
 class=3D"h5">
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal">At the F2F in March I was concerned that the best pr=
ogressive web apps were generally mobile-only, and I=E2=80=99m getting a si=
milar feeling about AMP.<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">I=E2=80=99m wondering whether TAG have a view on the=
 use of `m.` sites.=C2=A0 From an architectural perspective `m.` is a bad t=
hing, surely.=C2=A0 But I can=E2=80=99t build my desktop webpages using AMP=
 - because I would lose essential features like reader comments,
 so I&#39;m stuck serving (at least) two copies of the same document.<u></u=
><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">HTML sandbox / Content Performance Policy seems like=
 a better approach, but I=E2=80=99m wondering whether I=E2=80=99m alone in =
thinking that a) technologies like AMP can promote duplication of content i=
n multiple formats in different locations on the web,
 and 2) that=E2=80=99s a bad thing.<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">Seems to me that we&#39;ve spent the last few years =
gradually moving away from m., and we&#39;re now heading back towards that =
territory.=C2=A0 Is this a conscious recognition that One-Responsive-To-Rul=
e-Them-All was a bad idea?<u></u><u></u></p>
</div>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div>

--001a1130ce582b712f0530d970e5--