HTML

Mobiles

AMP - Le Web pour mobile vient de grossir...

Au diable la sémantique, les attributs HTML servent de prétexte, oublier le CSS3, c’est maintenant l’AMP, plus simple... Ce qui est vraiment intéressant avec cette nouvelle heu... coup d’État, c’est qu’on peut étudier encore davantage les petits secrets de Google, en pratique, ça manière de réfléchir! Même que Google nous assure un meilleur positionnement avec l’AMP. Et ça, c’est intéressant, car c’est quand même le boss! À première vue oui, je suis le premier à dénoncer les absurdités des langages de programmation. Et l’AMP simplifie vraiment le caractère adaptatif et singulier des résolutions en réutilisant les meilleurs éléments du CSS3 et du HTML5 justement. C’est juste plate qu’on doive passer par un moteur supplémentaire. Au fond on est capable d’être simpliste nous aussi! En passant directement par le CSS3 , HTML5 et JavaScript 6...

Dire qu’on arrivait à peine à se passer de jQuery. J’imagine que Google à prévu le coup! Mais cette foi avec une emprise décuplée!

Google à 5 problèmes majeurs

Outre son moteur et filtre de recherche, au demeurant, plutôt efficace si votre sujet est sérieusement traité par les sites populaires en vedette chez Google. Et on pourrait joindre au mot Google ceux des majors, comme les Washingtonpost de ce monde :

1. Il n’aime pas la compétition et surtout les freelances. Il n’a certainement pas aimé les cadriciels de Yahoo, Boostrap ou Fundation. Bien sûr le projet AMP n’est pas la même chose, il est avant tout un outils pour Google. Mais c’est aussi un genre de framework.
2. Le besoin grandissant de publicité. Et les outils AMP sont tout à fait faits pour ce palier à ce besoin.
3. Le besoin de monétisation des sites web. Bon, pas sûr que l’AMP soi vraiment utile bien que Google le prétend. Et on peu certainement dire que Google n’est pas le seul a souffrir de ce mal historique.
4. Il a besoin de gestion de cross-domaine pour étendre son hégémonie tout en bloquant les autres. De là l’AMP...
5. Incompatible avec les navigateurs « Internet Explorer 12 » et moins! Même le navigateur de mon Android 4.2.2 ne fonctionne pas!

Pensez-s’y une seconde, avec un Bootstrap 4 ou Fundation 6, une bonne éthique de programmation et le merveilleux CSS3. Et surtout comme sur les Trucsweb.com, sans script pour Google analytic? À quoi peut bien servir Google? À envoyer un sitemap? Non Google a compris le pouvoir des cadriciels et veux sa part du gâteau, c’est-à-dire celle d’Obélix! Et n’aller pas croire que mon commentaire est celui d’un frustré! Oui ça me frustre, mais je suis aussi capable d’admirer les véritables avancés développé par Google, comme les images WebP.

Enfin Google nous dit : Le projet Open Source « The Accelerated Mobile Pages (AMP) » vous permet de créer facilement du contenu optimisé pour les mobiles et de le charger instantanément sur toutes les plateformes. Grâce au chargement de page ultrarapide, vous améliorez l’expérience utilisateur des mobinautes (y manque juste un « r »). Vous développez le trafic sur les mobiles et vous optimisez sa monétisation(!).

C’est curieux de constater le niveau technologique, de gadget et glign glign de la confrérie, confinée dans ces appartements. Versus le peu de mots pour décrire ce projet AMP. Google parle d’un sous-ensemble du HTML pour la création de documents Web, comme des articles de presse, de manière à garantir un seuil de performance ! Jusque là tout baigne. Il enchaine en parlant de restriction sur l’ensemble des balises et fonctionnalité du HTML sans pour autant devoir développer un nouveau « moteur de rendu » engin. Eh oui, votre vieux navigateur fera l’affaire.

Si je traduis bien, je dirais que le nouveau langage AMP, n’ayons pas peur des mots, est essentiellement une énième couche de traitement pour un meilleur support des mobiles. Un peu comme l’HTML5 Shiv est au HTML5. Le mérite est de se débarrasser de plusieurs couches! Peut-être, mais l’idée est justement de se libérer de toutes les couches non? (surtout celle de l’évasion fiscale) Sans farce, on ajoute même des balises et des éléments HTML. Et on voudrait me faire ajouter un traitement AMP, apprendre un nouveau vocable, et même développer bénévolement pour Google? On n’a même pas réussi encore à se débarrasser de la main mise de Microsoft batince! Va falloir de bons arguments, où est la carotte ? Une chose sur, oublier votre cadriciel préféré, oublier le jQuery, il faut tout mettre à la poubelle pour utiliser exclusivement le nouveau « langage » et les outils Google AMP...

Car la voici la carotte :

Now when you search for a story or topic on Google from a mobile device, webpages created using AMP will appear when relevant in the Top Stories section of the search results page. Any story you choose to read will load blazingly fast-and it’s easy to scroll through the article without it taking forever to load or jumping all around as you read. It’s also easy to quickly flip through the search results just by swiping from one full-page AMP story to the next. - Google

En d’autres mots, vous n’utilisez pas Google AMP et vous vous retrouverez en fin de peloton! Ni plus ni moins! On y note aussi le 3 secondes, Google n’envisage même pas (une seconde) que c’est sa recherche qui puisse aussi en arracher, à force d’avoir trop de « Top Stories » discutable justement ; -) C’est tout à fait Google de détourner le problème à son avantage, ça s’appelle du marketing. Une des solutions prisées par l’industrie est d’ailleurs un leurre. L’asynchrone! On charge le contenu après la page de façon asynchrone. On a donc une belle page qui se charge effectivement rapidement, mais certaines fonctionnalités comme les boutons ne fonctionnent pas tant que le Ajax n’a pas fini son travail... Je ne suis pas ici pour dénoncer le puissant Ajax encore une fois, fort utile à bon escient. Mais ça reste un leurre pour un problème qui a d’autres solutions plus appropriées.

Pire, il suffit de regarder le code des pages AMP de Google pour trouver du codes inutiles! Il faut dire, à la défense de Google, que le tout a été créé en seulement 4 mois! La meilleurs défense c’est l’attaque n’est-ce pas, même s’il faut se précipiter! Regarder par exemple le code du « Washingtonpost » pour s’en rendre compte. Bouré de iFrame, pour la pub certes, mais pour un simple vidéo! Un bloc de navigation dans un bouton(!). Un paragraphe à l’intérieur d’un paragraphe (il aurait suffi d’un div)... À croire que les développeurs ne connaissent pas le HTML!

En théorie

Bon, on n’est pas au bord de la guerre civile. Ça reste un leurre. Le CSS/Javascript reste le seul maitre d’œuvre derrière le AMP. Un document HTML AMP peut être déposé sur le serveur et poussé exactement comme une page Web. Ok on avait compris! Le reste de l’introduction parle d’un AMP qui permet tout ce que le HTML fait et rien de plus que ce que le JavaScript permet déjà. C’est-à-dire à appliquer des transformations au document pour de meilleures performances (lire compatibilité(!)).

Comme les optimisations suivantes :

• Remplacer les références des images par des références à des images calibrées à la fenêtre du « viewport ».
• Les images inline qui est visible au-dessus de la ligne de flottaison (lire les images visiblent à l’ouverture).
• Les variables Inline CSS.
• Préchargement étendu des composants.
• « Minify » ou conpression HTML et CSS.

Effectivement, so what, quant on s’appelle Google, Twitter ou The New York Times, c’est le navigateur qui fait la job! Et le Ajax, beaucoup d’Ajax. C’est la recette miracle derrière le AMP et la rapidité d’affichage. Et tout un moteur avec un débogueur digne des plus grosse plate-forme de développement. Bon le CSS est encore valide, @font-face, @keyframes, @media, @supports par exemple. Mais pas le contraire, c’est-à-dire que le sélecteur hover ne peut être appliqué à la balise AMP amp-img.

Qu’est-ce qu’on a fait depuis 20 ans?

« For many, reading on the mobile web is a slow, clunky and frustrating experience ». Il suffit de lire un peu pour se rendre compte qu’on parle d’échec! Comme si l’autre industrie s’était égarée des années durant! Avec des téléphones intelligents plutôt bêtes?

À l’époque c’était des sites en quelques lignes, avec des bitmaps, fallait faire avec! Du Wap, du WML (Wireless Markup Langage) ou du HDML. Ensuite en XHTML, des versions distinctes optimisées pour mobile « m.monsite.com » généralement avec une largeur en pourcentage « % ». C’était déjà pas mal. Mais depuis les iPads et iPhones on a le HTML5, le Javascript 6 et surtout le CSS3.

Il faut laisser l’industrie s’adapter, lui donner du temps! Ça va tellement vite, c’est à peine si on trouve la balise figure dans la plupart des gestionnaires et cadriciels! Si la technologie évolue à une vitesse sans précédent, c’est tout le contraire avec les normes internationales. Et que dire des navigateurs! À part Opera, ils n’ont certainement pas donné l’exemple. Le HTML/CSS fait déjà le gros du travail. D’ailleurs Google a même participé à l’élaboration du dernier HTML5.1 sous l’égide du WHATWG avec la W3C! On peut à la limite s’aider d’une remise à zéro avec un bon cadriciel (framework). Mais avec une bonne technique, une bonne philosophie, je suis sur qu’on peut faire une page Web aussi simple sans la mauvaise expérience du « slow, clunky and frustrating »! Il ne s’agit qu’une d’une news en fin de compte. Google ne parle pas d’application complexe, il parle de recette, de galerie d’image, de photos et de paragraphe!

Programmation responsable

Ce n’est pas surtout AMP qu’il nous faut, c’est un peu de bons sens! Je suis tombé aujourd’hui sur une page web très simple. Une animation certes, un glissement sans plus, mais en fait il charge une quantité impressionnante de composantes externes. À peu près tout ce qui se trouve sur le Web était chargé inutilement. Le problème n’est pas tant l’optimiser, pour les pauvres mobiles incompétents. C’est d’en mettre trop. Il fut une époque où le moindre octet en mémoire était compté, ou la programmation devait être avant toute chose ...nécessaire. Aujourd’hui on programme au cas où! Sauf pour une exception, l’UTF-8 mais ça, c’est une autre histoire...

Base du document HTML AMP

Enfin, laissons de côté la littérature et cette culture pour se poser la vraie question. La W3C est de plus en plus à la remorque des majors comme Google, a t’ont vraiment le choix! Il faut passer au HTML AMP, pour une seule et bonne raison, c’est Google!

Ah oui, j’avais oublié de vous dire. La couche supplémentaire pousse le ridicule jusqu’à se créer ses propres balises. Par chance on a droit à un <amp> et non pas un <google>, quoique ce dernier parle davantage(!) :

<!doctype html>
<html ⚡>
  <head>
    <meta charset="utf-8">
    <link rel="canonical" href="allo_le_monde.html" >
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <style amp-custom>
      /* Styles maison */
      h1 {color: red}
    </style>
    <script type="application/ld+json">
    // Exemple de microdonnées JSON
    {
      "@context": "http://schema.org",
      "@type": "NewsArticle",
      "headline": "Allo le monde!",
      "image": [
        "image.png"
      ],
      "datePublished": "2016-03-08T08:00:00+05:00"
    }
    </script>
    <!-- Autres librairies AMP -->
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
  </head>
  <body>
    Allô le monde!
    <amp-img src=image.png width=300 height=300></amp-img>
  </body>
</html>

Obligatoire (en rouge) : Le document AMP doit absolument contenir :

• Comme un document HTML5, commencer par le « doctype » <!doctype html>.
• Une balise de niveau supérieur <html ⚡> (<html amp> est aussi accepté). (Entité HTML du symbole ⚡ (& #9889;)
• Contenir les balises <head> et <body>.
• Contenir une balise méta <meta charset="utf-8"> tout en haut de l’entête.
• Contenir une balise de relation <link rel="canonical" href="$SOME_URL" /> dans l’entête vers la version HTML régulière du document ou vers la AMP HTML elle-même si aucune version HTML n’existe.
• Contenir une balise méta <meta name="viewport" content="width=device-width,minimum-scale=1"> à l’intérieur de l’entête. C’est aussi recommandé d’inclure initial-scale=1.
• Contenir une balise de référence aux JavaScript <script async src="https://cdn.ampproject.org/v0.js"></script> à la toute fin de l’entête. (pour inclure et charger la librairie JavaScript du AMP).
• Contenir les styles suivant dans l’entête <head> : <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>

Noter que certaines plates-formes qui utilisent AMP HTML ont de nouvelles restrictions.

• Les dimensions du logo ne doit pas excéder 600x60 pixels.
• Toujours utiliser des hyperliens absolus.

On recommande en outre l’usage de métadonnées, comme Open Graph Protocol que Facebook utilise ou les nouveaux Twitter Cards, etc. Et l’usage de balisage avec schema.org/CreativeWork spécifiquement schema.org/NewsArticle ou schema.org/BlogPosting. Mais bon, c’est pas compliqué, à ajouter à votre dictionnaire personnel. Noter au passage le manque de rigueur dans l’usage des guillemets. Noter que les commentaires conditionnels HTML ne sont plus autorisé dans l’entête.

Balises HTML

Les balises HTML peuvent être utilisées telle quel en HMTL AMP. Certaines balises ont toutefois des balises personnalisées équivalentes (tel que <img> et <amp-img>) alors que d’autres sont carrément interdites :

Liste blanche des balises HTML5

Balises autorisé par les spécifications HTML5 de la section 4 Éléments du HTML.

L’Image et la composante amp-img

La composante amp-img remplace la balise HTML de façon a choisir de retarder ou d’accorder la priorité de chargement des ressources en fonction de la position du viewport, des ressources du système, de la bande passante de la connexion, ou autres facteurs.

Les composantes amp-img, comme toutes les ressources externes récupérées par le AMP, doivent avoir une taille explicite (largeur / hauteur) spécifiée à l’avance. De sorte que les proportions soient connu avant le téléchargement de l’image. Noter que le comportement de mise en page réelle est déterminée par l’attribut de « layout ».

Le CSS peut être utilisé pour donner une couleur d’arrière-plan à l’espace réservé à la ressources. Les légendes peuvent être uritilisées avec le HTML standard en utilisant les éléments figure et figcaption.

amp-img {
  background-color: grey;
}

src
Comme avec la balise , c’est le URL vers la ressources.

srcset
Comme avec la balise , et si votre navigateur le supporte, c’est les urls vers les ressources alternative selon diverse critère.

alt
Comme avec la balise , une chaine de caractère alternatif si la ressources n’est pas disponible.

attribution
Une chaîne de caractère qui indique l’attribution de l’image.

Exemple avec une vignette sa version grand format (lightbox)

Par exemple on a ici une image, avec la balise amp-img et l’attribut srcset, amp-lightbox, layout... Il s’agit d’une image figure qui contient trois références selon la résolution. Suivit d’un second bloc, cette fois pour afficher l’image en grand format, après un clic (ou un tap) on="tap:headline-img-lightbox". N’oubliez pas qu’un iPhone6 fait 1920px x 10800px !

<figure>
  <amp-img
    src="img/hero@1x.jpg"
    srcset="img/hero@1x.jpg 1x, img/hero@2x.jpg 2x"
    layout="responsive" width="360" placeholder
    alt="Curabitur convallis, urna quis pulvinar feugiat, purus diam posuere turpis, sit amet tincidunt purus justo et mi."
    height="216" on="tap:headline-img-lightbox">
  </amp-img>
</figure>
 
<amp-lightbox id="headline-img-lightbox" class="lightbox" layout="nodisplay">
  <div class="lightbox-content">
    <amp-img id="floating-headline-img"
      src="img/hero@1x.jpg"
      srcset="hero@1x.jpg 1x, img/hero@2x.jpg 2x"
      placeholder
      width="360" height="216" layout="responsive">
    </amp-img>
    <p>...</p>
  </div>
</amp-lightbox>

Héhé, c’est simple mais quel détournement! Et on note au passage un code deux fois plus volumineux!

Layout

Ce nouvel attribut AMP optionnel de mise en page permet de spécifier comment la composante doit se comporter dans la présentation du document. Les valeurs valides pour l’attribut de mise en page sont :

• Sans l’attribut : La mise en page sera déduit de la manière suivante :
  • si la hauteur est présente et la largeur est absent ou égal à l’auto, à hauteur fixe la mise en page est supposé;
  • si la largeur et la hauteur des attributs sont présents le long avec des tailles ou des hauteurs d’attribut, la mise en page en réponse est supposé;
  • si la largeur et la hauteur des attributs sont présents, la mise en page fixe est supposé;
  • si la largeur et la hauteur ne sont pas présents, contenant la mise en page est supposé.
• fixed : La largeur et les attributs de hauteur doivent être présents. Les seules exceptions sont ampli-pixel et des éléments d’ampli-audio.
• fixed-height : L’attribut de hauteur doit être présent. L’attribut de largeur ne doit pas être présent ou doit être égale à l’auto.
• responsive : La largeur et la hauteur des attributs doivent être présents et sont utilisés pour déterminer le rapport d’aspect du composant. Le composant est dimensionné de manière à la largeur de son élément de conteneur, tout en maintenant la hauteur en fonction du rapport d’aspect.
• fill : la taille Element sera déterminé par l’élément parent.
• container : Le composant est supposé ne pas avoir mise en page spécifique lui-même, mais seulement agir comme un conteneur. Ses enfants sont rendus immédiatement.
• nodisplay : Le composant prend de la place de zéro sur l’écran comme si son style d’affichage était pas. Les attributs de largeur et de hauteur ne sont pas nécessaires.

Les microdonnées, d’un article, entête, date, auteur...

Très intéressant, enfin une fois que Google ai tué les métadonnées. D’ailleurs Google place maintenant ces microdonnées JSON, dans l’entête, au dessus de sa ligne de flottaison, avec son code Google Analytic! Pincer moi!

<header>
  <h1 itemprop="headline">Lorem Ipsum</h1>
  <time class="header-time" itemprop="datePublished"
     datetime="2015-09-14 13:00">September 14, 2015</time>
   <p class="standfirst">...</p>
</header>

<div class="author">
  <amp-img src="img/sample.jpg" id="author-avatar"
    placeholder height="50" width="50">
  </amp-img>
  <div class="byline">
    <p>
      by <span itemscope itemtype="http://schema.org/Person"
        itemprop="author"><b>Lorem Ipsum</b>
        <a class="mailto" href="mailto:lorem.ipsum@">
        lorem.ipsum@</a></span>
    </p>
    <p class="brand">PublisherName News Reporter<p>
  </div>
</div>
<div class="article-body" itemprop="articleBody">
...

En conclusion, préparez-vous pour travailler pour Google, bénévolement!

Je vais faire d’autres exemples avec le temps, car celles de Google sont vraiment très simples et tellement orientés business et publicité. En fait Google a le pire défaut du développeur, il a développé toutes les exceptions inimaginables, dont la plupart me sont inutiles : statistiques, publicité, Viméo, Dailymotion, Soundcloud, carousel, Facebook, Instagram, jwPlayer, Kaltura, Pinterest, iFrame, Openx, Reach-Player, partage sociale, Springboard-player, Twitter, Vine, Youtube! Y a de la majuscule en masse! Une balise est même carrément dédiée à la publicité! La amp-ad mais attention, aucun JavaScript externe n’est autorisé sauf exception. Et l’exception c’est les majors de l’industrie de la publicité en ligne. Google se sent un peu coupable? : A9, Adblade, Adform, AdReactor, AdSense, AdTech, Criteo, Dot and Media, Doubleclick, Flite, Industrybrains, OpenX, plista, Smart AdServer, Yieldmo, Revcontent, TripleLift, Teads, I-Mobile, Webediads!

Et quand Google parle de « major browser » dont Chrome, Firefox, Edge, Safari et Opera, on note l’absence d’Internet Explorer, et donc du « Windows Phone ». Et ça, c’est Google qui le prétend. J’ai une seule tablette, et ça adonne que l’AMP ne fonctionne pas avec son navigateur par défaut Android 4.2.2! C’est dire deux documents, avec deux techniques quasi similaires, pour encore longtemps...

Enfin pour la carotte, pour l’instant elle est bien fade! D’ici à ce qu’un Google-Human s’y penche, la page nouvellement référencée par Google, avec ces microdonnées, sort avec un minimum d’information et sans aucune distinction. Faut dire que son service webmestre est en pleine mutation, lui aussi...