Développer avec l’Open Web Platform

par birnou · 16 octobre 2009

Le terme, et surtout l’ensemble qu’il engendre, est né d’une multitude de contextes, de situations, et de besoins. Il a évolué et devient de plus en plus récurrent dans la presse et la littérature web, sous la forme d’Open Web Platform. Le w3c l’a complètement et définitivement mis en lumière, lors d’une de ses dernières publications, W3C Highlights – August 2013.

L’OWP, comme on le nomme de manière courte, regroupe sous cette appellation un ensemble de standards et de technologies du web, que ceux-ci soient issus du travail du w3c, ou de tout autre organisme de standardisation. Que faut-il comprendre ? suivre ? Nous allons essayer de mettre tout cela à plat au cours de cet article.

Rappel sur les standards

Depuis sa version 4.01 html n’avait plus évolué et les orientations vers xhtml, tels qu’ils étaient entrepris, risquaient d’amener le web vers une rupture de compatibilité descendante. Cependant, aujourd’hui le web se devait d’être applicatif et quitter définitivement son rôle consultatif, ou systématiquement associé à des RIA Flash. Il est vrai que depuis la révolution du web 2.0, les internautes interagissent de plus en plus avec le système et contribuent largement à ce type de besoins, ainsi qu’à l’élargissement des contenus.

N’oublions pas que sans standard, toute alternative se verrait rapidement vouée à l’échec, ou limiterait drastiquement sa propre pérennité et son évolution. Il n’y a qu’à se retourner et regarder l’avenir qu’ont eu les diverses solutions propriétaires en la matière…

Dans un tout autre domaine, reprenons l’exemple des magnétoscopes et des cassettes vidéo. Durant les années 80, les magnétoscopes sont devenus des objets de consommation larges, et chaque foyer s’équipait d’un tel appareillage. Seulement voilà, il y avait alors quatre principales technologies : VCR, V2000, Betamax et VHS, et aucun standard n’était défini.

Chaque grande marque s’était rapprochée d’une technologie et proposait sa solution ‘innovante’. Le problème vint alors des vidéos clubs qui, eux, ne proposaient pas les films pour chacun de ces formats… L’essor n’a pu prendre son réel envol que lorsqu’un standard a été défini, en l’occurrence le VHS, mettant ainsi tout le monde au même diapason : constructeurs, diffuseurs de films, vidéo clubs et bien sûr utilisateurs, et ce pour le meilleur confort de ces derniers.

Le web se devait de rester dans cette optique, s’appuyer sur un standard, avec une nouvelle mouture du html qui devait venir remplacer l’ancienne, sans pour autant casser la compatibilité descendante. L’enjeu étant d’apporter de vraies solutions au problème du besoin applicatif des contenus, d’une sémantique renforcée au niveau des user-agents et d’une extensibilité permanente.

Poursuivant sa vision du web, un groupe détaché du w3c, le WHATWG (Web Hypertext Application Technology Worging Group) a alors commencé, en 2004, à réfléchir à cette problématique et surtout, à proposer une réelle solution alternative au xHtml 2. Ce travail a finalement été reconnu et accepté par le w3c en 2009, « XHTML 2 Working Group Expected to Stop Work End of 2009, W3C to Increase Resources on HTML 5 ».

html5, cœur de l’open web platform

Fondé sur une base de Web Forms 2.0 et de Web Applications 1.0, html5 est donc devenu le cœur de cette nouvelle approche de développement de pages web, orientées application. Mais html5 en soi, n’est rien. Ce qui importe, c’est toute la philosophie qu’il engendre auprès des développeurs et l’approche qu’adopte sa mise en place et son développement. Répondre aux attentes des utilisateurs et non leur imposer un choix.

Ensuite, un standard structurel c’est bien, mais ce n’est pas assez. Il faut également que toutes les technologies qui gravitent autour, deviennent à leur tour des standards en leurs domaines. En effet, nous avions l’habitude d’entendre par html, un langage structurel à balises… mais, là, avec html5, il faut également entendre tout ce qui va autour… c’est-à-dire :

La gestion de l’affichage (CSS),
La prise en charge des multi-média (audio, vidéos…),
Le graphisme bitmap et vectoriel (canvas, SVG),
L’animation (transition, transformation, animation… 2d et 3d),
Les protocoles de communication (xmlHttpRequest),
Les API de navigateurs et les API d’appareils mobile,
La nomenclature des méta données (schema.org)…

Bref, tout ce qui contribue à la mise en place et au développement d’une application.

Recommandations modulaires

Pour être reconnus en tant que tels, les standards doivent être, d’une part validés et d’autre part recommandés. Le travail sur l’ensemble des points reste une gigantesque entreprise, mais son découpage modulaire permet des recommandations progressives, et jouables dans le temps. Donc, dès aujourd’hui, il est possible d’utiliser ces technologies avec une garantie de finalisation et d’implémentation, au cœur de l’ensemble des user-agents.

Tous les acteurs majeurs du web sont présents à la table de la conception et de cette évolution, ce qui garantit la non-propriétarisation de quelque fonctionnalité que ce soit. Qu’il s’agisse d’éditeurs ou de concepteurs d’applications, Mozilla, Apple, Adobe, IBM, HP, Microsoft, … , tous sont actifs, et tous ont compris que seule la mise en place et l’appui sur de véritables standards, peuvent garantir l’évolution et la pérennité du web.

Les besoins de nos applications s’étendent et se précisent de jour en jour. De ce fait, un grand nombre de réponses se profilent, et se peaufinent.
Cependant, il est parfois déroutant de suivre l’implémentation en fonction des plateformes, des navigateurs et de leurs versions. En ce sens, nous avons accès à divers sites qui nous proposent de nous aider à suivre cela de manière très souple, ergonomique et parfaitement intégrée :

Ceci étant, il ne s’agit là principalement, que du classique tandem html / css ! Et l’Open Web Platform s’étend bien au-delà…

Alors, quelles sont les branches de cet arbre tentaculaire ?

Bien qu’il en soit le déclencheur, html5 n’est pas seul sur le coup… et loin s’en faut. Reprenons chacun des éléments vu précédemment et détaillons leurs rôles, leurs implications et les sources web qui peuvent nous aider à mieux les appréhender.

hmlt5

Html est un langage à balises qui permet de structurer le contenu d’une page web, en découpant de manière sémantique l’ensemble du document. Ce langage est relativement simple, mais son utilisation fait l’objet de certaines notions et règles, qu’il est bon d’employer. Voir l’article Les bases du langage HTML.

Avec cette mouture, à l’opposé de la version antérieure, il est vrai que le langage sort de ses gonds et s’enrichit de balises, de fonctionnalités et d’options, qui permettent de s’attaquer confortablement au développement de réelles applications web. Bien que vous puissiez en avoir un résumé succin dans l’article « html5 », nous pouvons déjà dresser la liste des nombreuses avancées ;

Recommandations modulaires et progressives
Éléments de structure à forte sémantique
Microdatas, et documentation
Attributs data-personnalisables
Champs de formulaires enrichis et adaptés
Éléments et API multimédia
API de dessin SVG et canvas
Diverses API applicatives en natif
Frameworks d’aide au déploiement
Frameworks et API pour applications mobiles

Les CSS

Le langage CSS permet de définir de manière distincte et autonome, aussi bien l’aspect visuel des balises, que la disposition du contenu des pages.

De manière synthétique, nous pourrions dire que l’ensemble des descriptions CSS se place dans un fichier TXT sous la forme de règles, les unes après les autres. Pour chacune de ces règles, un sélecteur pointe vers un élément du document en particulier et définit un bloc entre deux accolades {}, qui contient une ou plusieurs descriptions de rendu, sous la forme de paires propriétés / valeurs.

Depuis 2001, la version 2.1 des CSS s’est démocratisée auprès des développeurs et leur utilisation a permis de confirmer la pure séparation, entre contenu et affichage. Seulement voilà, vu le besoin d’afficher des visuels de plus en plus raffinés et disponibles sur un parc de navigateurs de plus en plus en large, cette version ne pouvait pas satisfaire complètement les attentes des développeurs et des utilisateurs. Une version 3 devait donc être mise en place. Les premiers travaux débutèrent bien avant le patch 2.1 et leur aspect modulaire, a permis un avancement cohérent et continu.

La vision de l’utilisation des CSS n’a pas toujours été partagée par l’ensemble des navigateurs, qui ont toujours plus ou moins essayé de tirer la couverture au lieu de s’appuyer sur les standards… Bien que cela s’améliore de version en version, il n’y a qu’à voir l’attitude de chacun face au rendu par défaut des balises en html4 et html5 : du côté de Firefox, du couple webkit avec Safari et Chrome, l’excellentissime Opera, et sans oublier Internet Explorer… On y accède également de manière plus ou moins globalisée, ou actualisée, depuis le site iecss.com.
En ce sens, il est toujours bon d’avoir recours à une feuille de style de réinitialisation. Le choix est large, CSS Reset | 2012’s most common CSS Resets.

L’article Aborder les CSS3, permet de couvrir bien des questions sur l’usage des CSS, et notamment leur version 3, au sein de nos développements. Un article plus didactique sur la prise en main des CSS est en cours d’écriture, de même, un autre article orienté mise en page avec la gestion multi-colonnes, les flexbox, le mode grille, est également en cours de finalisation… n’hésitez pas à nous demander de presser le clavier et la souris si besoin était. Sinon, vous pouvez toujours vous rapprocher de la formation Comprendre et utiliser les CSS chez video2brain, ou du paquetage Maîtrise des CSS chez Pearson.

Les media Queries et Responsive Web Design

Les CSS seules ne seraient qu’à moitié efficaces et utiles, si elles ne pouvaient pas s’adapter aux périphériques de lecture du contenu de la page web. En effet, jusqu’à l’ajout des recommandations, en 2012, rien, au niveau des standards, ne permettait de distinguer un nokia 6600 d’un iPhone, même ancien.

Les média queries sont donc un mécanisme standard, un module CSS3, qui permet d’adapter les feuilles de styles liées à divers paramètres, comme le type de périphérique en cours d’utilisation, ou à des propriétés d’affichage, comme la largeur d’écran, la fenêtre d’affichage, les couleurs utilisées, la résolution disponible…. Toutes ces propriétés pouvant, bien entendu, être cumulées.

Cette technicité a donné naissance à une approche du développement d’interfaces, connu sous le nom de Responsive Web Design. Conjointement à l’utilisation de grilles, il est possible de préserver la proportionnalité d’occupation de l’espace d’affichage et de l’adapter à un téléphone, comme à un écran d’ordinateur. Cette flexibilité se partage entre deux notions, la mise en page adaptative (web design fixe) prôné par Mark Boulton, ou le web réactif (web design fluide) démocratisé par Ethan Marcotte.

Attention à ne pas confondre les deux, Jeffrey Zeldman le détaille bien dans son article, Responsive Design. I don’t think that word means what you think it means.

Pour explorer plus en avant l’univers des média queries, du Responsive Web Design et de l’utilisation des grilles, rapprochez-vous de l’article Responsive Web Design, mais encore ?

Metadatas

Afin de pouvoir apporter le maximum d’informations à certaines descriptions ou aspects du contenu, et permettre ainsi aux tierces applications de pouvoir communiquer ou échanger des données, nous devons avoir recours à l’usage de métads données, les metadayas. Nous pouvons donc employer aussi bien des microformats, que des données de type Dublin Core.

Par contre, même en cumulant ces deux sortes de standard, la couverture reste insuffisante et par ailleurs peu souvent employée.

De ce fait, lorsque le WhatWg a travaillé sur les recommandations du html5, le groupe a établi un ensemble de spécifications relatives justement à ces métas donnés et a permis ainsi, d’une part d’élargir le spectre d’action, et d’autre part, de le renforcer sur un grand nombre de couvertures manquantes.

L’ensemble des descriptions parues est centralisé sur le site schema.org.

Tout simplement en se basant sur les divers schémas (ou vocabulaires) mis à disposition et leurs exemples d’illustration, il est possible de rapidement les prendre en main. L’ensemble des balises HTML peut être affiné par des attributs de ‘description’. En fonction de la sntaxe retenue (Microdatas ou RDFa Lite), ces attributs sont d’abord basés sur la couverture des données décrites par un itemscope. Puis ils s’appuient sur un type de métas données, au travers de itemtype et enfin, chaque donnée peut s’illustrer par la propriété itemprop.

Tous les types de description sont cumulables. De ce fait, une organisation peut se coupler avec une personne en tant que représentant et une adresse… Il est possible ainsi de rapidement décrire quasiment tout, ou presque.

<footer itemscope itemtype="http://schema.org/Organization">
	<span itemprop="name">Puce et Média</span>,
	<div itemprop="address" itemscope itemtype="http://schema.org/PostalAddress">
		<span itemprop="streetAddress">1, impasse de la pie</span>
		<span itemprop="postalCode">13 490</span>
		<span itemprop="addressLocality">Jouques, France</span>
	</div>
</footer>

<footer vocab="http://schema.org/" typeof="Organization">
	<span  property ="name">Puce et Média</span>,
	<div  property="address" vocab="http://schema.org/" typeof="PostalAddress">
		<span  property ="streetAddress">1, impasse de la pie</span>
		<span  property ="postalCode">13 490</span>
		<span  property ="addressLocality">Jouques, France</span>
	</div>
</footer>

WAI-ARIA

L’usage conjoint de diverses technologies dynamiques et notamment celles permettant de générer des interfaces riches (RIA), peut rapidement devenir difficilement accessible, sans pour autant avoir à décrire des fiches comme le feraient les métadonnées. Cette barrière d’accès peut apparaître autant au niveau des internautes qui utilisent des écrans d’aide à la navigation ou encore des lecteurs d’écran, qu’au niveau des moteurs de recherche ou autres parseurs de contenu.

Certains types d’éléments d’interface ne sont pas suffisamment explicites sur leur nature. Par exemple, les composants tels que calendrier, menus ou autre boite de dialogue, ou encore la granularité des menus de navigation (menus, sous-menus, primaire, secondaire, contextuel…) et bien d’autres… bref, avec la mise en place d’une application web, ce ne sont pas les situations qui manquent.

En réponse et anticipation à cette problématique, le w3c a donc mis en place un groupe de travail pour plancher sur les spécifications du WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications). L’objectif premier est de rendre le web applicatif, et son interface d’utilisation, accessible.

Ce travail s’est donc principalement attaché à décrire le rôle de ces divers éléments de page qui peuvent être verbeux en balises HTML et qui ne possèdent pas de sémantique appropriée.
Le résultat propose donc une catégorisation des rôles en quatre segments ;

Abstract Roles (permet de définir la nature de l’ensemble englobant)
Widget Roles (définit les types de composants)
Document Structure Roles (définit l’organisation du contenu)
Landmark Roles (définit les diverses régions de la page)

Certains peuvent même trouver résonance auprès de certaines balises html5
header	banner
aside	complementary
footer	contentinfo

Il est donc important de prendre le temps de venir compléter ses pages web, surtout si celles-ci sont à vocation applicatives, et de se poser les bonnes questions sur le rôle de chaque élément de l’interface. De même, sur le thème de l’accessibilité, il faut prendre en compte que ARIA ne concerne que la sous-partie applicative du WAI (Web Accessibility Initiative). Il peut être également intéressant de se rapprocher des Règles pour l’accessibilité des contenus Web (WCAG 2.0), et de lire l’excellente Introduction à WAI ARIA paru chez les intégristes.net.

SVG

SVG est un format d’image basé sur une grammaire XML. SVG supporte autant l’interactivité que l’animation et autorise l’emploi de CSS. Tous les navigateurs modernes, et les versions Internet Explorer supérieure à 8, supportent ce format.

Cliquez sur l’image ci-contre et vous en aurez l’illustration. Une fois la fenêtre ouverte, cliquez sur les icônes de la légende, en bas à droite et profitez-en également pour explorer le code source…

Bien qu’il soit possible de créer l’ensemble du contenu SVG depuis une simple page blanche et de tout réaliser en code, l’idée de l’utilisation de ce format, reste essentiellement de démarrer depuis une application tierce pour créer le document SVG (Inkscape, Illustrator, Fireworks…).

Ensuite, nous pouvons éventuellement y apporter tous les aspects dynamiques et interactifs depuis l’interface du navigateur, en s’appuyant sur CSS et Javascript.

SVG s’emploie de diverses manières au sein d’une page HTML :

En insertion de la balise Image <img src= »fichier.svg » />
En liaison sur une balise Object ou Embed <object data= »fichier.svg » /> <embed src= »fichier.svg » />
En utilisant directement la nouvelle balise SVG, au sein du contenu HTML <svg><defs>…</defs><g>…</g></svg>

Un chapitre entier de la formation Open Web Platform avec HTML5, CSS3, Responsive Web Design, parue chez video2brain, est consacré à l’approche SVG et à sa mise en place.

WOFF

Le WOFF (Web Open Font Format) est un conteneur standard émergeant, qui permet de distribuer, de manière compressée, des fontes personnelles (TrueType et OpenType) pour illustrer le contenu de nos pages. L’ensemble des navigateurs modernes prennent en compte ce format, à l’exception d’Internet Explorer, qui ne le fait qu’à partir de sa version 9. Pour les versions antérieures on lui préférera donc le format EOT (Embedded OpenType).

L’idée d’un format de fonte global est importante afin de n’avoir qu’un seul format à livrer. Cependant, il est également intéressant de voir que des périphériques comme iPad, ou iPhone interprètent les fontes au format SVG.

Un chapitre complet de la formation Open Web Platform avec HTML5, CSS3, Responsive Web Design, parue chez video2brain, est consacré à l’approche de la typographie sur le web.

ECMAScript

Bien que certains navigateurs puissent utiliser leur propre langage, comme JScript pour Internet Explorer, l’interaction utilisateur au sein des navigateurs, est principalement assurée par le Javascript. Ce langage, né au milieu des années 90, entrait directement en compétition avec d’autres langages de script côté client, qui voulait le remplacer. Pour cela, Netscape qui le développait, l’a soumis à ECMA International, en vue de sa standardisation.

La spécification ECMA-262 a donc donnée naissance à l’ECMAScript, qui n’est ni plus ni moins que la version standardisé de Javascript.

Aujourd’hui, en version 1.8.5, compatible ECMAScript 5, Javascript est un langage objet à prototypes, extrêmement puissant, qui permet bien des manipulations au niveau des contenus web ;

Intervenir sur le DOM (Document Object Model)
Récupérer des données en ligne (XMLHttpRequest)
Agir sur l’interface utilisateur (palettes, composants d’interface…)
Mettre en place des animations
Ajouter divers niveaux d’interactions complexes
Améliorer considérablement l’expérience utilisateur
Contrôler l’environnement de présentation (navigateur, …)
Écouter les périphériques (souris, clavier, écran…)
Étendre ses capacités en utilisant des librairies (également en Javascript)

Un article plus orienté sur les bonnes pratiques et l’aspect objet de Javascript est en cours d’écriture… n’hésitez pas à nous demander de presser le clavier et la souris si besoin était.

Les APIs du HTML5

L’Open Web Platform couvre également un certain nombre d’API natives qui viennent, ou viendront, renforcer considérablement les capacités natives de nos navigateurs. Beaucoup d’API n’ont pas encore de standard recommandé afin de garantir leur inter-opérabilité. Mais tous disposent déjà d’un cadre, en version brouillon, pouvant définir avec précision leur champ de manœuvre et leurs recommandations ;

Géolocation API qui a largement été modélisé par Google, est une interface qui permet de récupérer, et interagir avec les informations de géolocalisation du dispositif de lecture, côté client (smartphone, tablette, ordinateur, appareil connecté…)
Web Worker qui permet de dispatcher les scripts chronophages vers des threads différents afin que ceux-ci ne soient pas interrompus par d’autres scripts nécessaires à la gestion de l’interface utilisateur. Leur emploi nécessite cependant un navigateur moderne ou Internet Explorer depuis la version 10.
WebSocket est un protocole qui s’appuie sur http lors de la connexion, sous la forme d’un Upgrade header, et qui permet ensuite un dialogue direct entre le poste client et une application web. Le serveur peut également envoyer des messages… améliorant ainsi la communication sur des aspects temps réels et échange en continu. Le recours à ce protocole nécessite un navigateur moderne ou la version 10 d’Internet Explorer.
Web Storage qui va permettre de gérer le stockage d’informations sur le navigateur (localStorage, sessionStorage) et ainsi pouvoir souvent remplacer et largement améliorer, l’usage des cookies. L’utilisation de ces variables est possible sur tous les navigateurs modernes et sur Internet Explorer, à partir de la version 8.
WebGL qui permet, aux navigateurs compatibles de restituer un environnement graphique 2D ou 3D sans avoir recours à une technologie complémentaire. L’intérêt majeur vient du fait que les objets WebGL font partie du DOM et peuvent en ce sens être combinés avec les autres éléments HTML de la page. Les navigateurs modernes supportent WebGL, mais pour Internet Explorer il existe une version expérimentale sur la version 11 (sans usage de plug in).
DOM events (level 3) qui permettra entre autre, d’intégrer l’ensemble des écouteurs événements de manière standard et ce, quel que soit le navigateur, ainsi que l’ajout d’un ensemble d’évènements adaptés à l’écoute du clavier.

Comme dit précédemment, toutes les API ne sont pas encore recommandées par le w3c. Il en existe un grand nombre en parallèle de celles listées ci-dessus. À terme, l’idée est que l’ensemble des navigateurs, et des user agent, puissent prendre en charge l’ensemble de ces fonctionnalités de manière native. Sur son Blog, Erik Wilde a listé ces API, HTML5 Landscape Overview, et donne un accès vers chaque proposition de recommandations sur le site du w3c.

XMLHttpRequest

Cette API aurait pu être citée dans le chapitre précédent, aux côtés des autres exemples et bien qu’elle ne fasse pas réellement partie de la mouvance occasionnée par HTML5, il est vrai qu’il serait difficile d’envisager une application web ne faisant pas usage d’AJAX. Déjà présente, depuis longtemps, dans nos outils de développement, nous pouvons quand même dédier un chapitre spécifique à cette fonctionnalité et l’inclure dans la liste des technos propres à l’Open Web Platform.

La révolution du web 2.0 a apporté une interaction continue avec le contenu de la page. En ce sens, un grand nombre de données peuvent être échangées, entre le client et le serveur, sans que la page soit rechargée dans son intégralité. XMLHttpRequest permettait ce genre d’échanges, mais possédait quelques limitations, comme par exemple, le support des données binaires ou l’échange entre deux domaines distincts.

XMLHttpRequest 2 encore en cours de recommandations, est là pour solutionner ce type de manque.
Si vous souhaitez explorer et mettre en application ce type de technologie, rapprochez-vous de l’article XMLHttpRequest et le formatage des données.

Et ensuite…

Bien que nous ayons été par le passé, habitués à attendre les recommandations avant d’employer une technologie, avec HTML5 bien au contraire, il est conseillé de les utiliser tout en restant vigilant sur leur implémentation et leur diffusion sur l’ensemble des navigateurs… Quelques sites peuvent nous guider en ce sens Can I use… ou HTML5 test score.

De même, il est bon de voir qui fait partie intégrante de HTML5 ou de sa mouvance, des recommandations brouillons, candidates etc… Le graphique HTML5 APIs and related technologies by Sergey Mavrody peut nous aider.
Quelques sites peuvent également nous tenir informé comme :