Le 16 mars 2011 a eu lien au centre de conférences Microsoft un workshop sur HTML5 / CSS3 / SVG 1.1
Cette conférence a eu pour but de faire un état des lieux actuel du HTML5, de son implémentation dans les dernières versions des principaux navigateurs, des bonnes pratiques offertes par des frameworks pour faire du progressive enhancement et du fallback, sur la plateforme ASP.NET.
Le but de cet article est de vous faire un résumé rapide, et de ce que j'ai retenu de plus intéressant. Il faut souligner que cet évènement a eu lieu tout de suite après la sortie en version finale d'
Internet Explorer 9. Il est aussi un prolongement d'une session des TechDays 2011 sur le même sujet.
Une norme en cours de construction
D'abord, la spécification actuelle du HTML5 par le consortium W3C est au statut "working draft" jusqu'en mai 2011. Ce n'est qu'à cette date que l'en-cours des spécifications sera en version finale, et donnera le coup d'envoi de l'adoption officielle du standard. Au départ dans la roadmap du W3C, il était prévu de livrer la version finale du HTML5 en 2022 ! C'est pourquoi en parallèle s'est constitué un groupe de travail (le WHATWG) qui rassemble des pointures de l'internet (Apple, Google, Mozilla, ... mais pas Microsoft).
Le but est de faire évoluer la norme HTML et de faire pression sur le W3C pour accélérer la roadmap et de lui faire adopter certaines fonctionnalités en standard. Le WHATWG va plus loin en prônant un HTML non versionné et évolutif. De son côté, le W3C a donc annoncé une version finale du HTML5 en 2014.
La guéguerre des navigateurs
Les spécifications en cours du HTML5 sont l'occasion d'une compétition entre les navigateurs (Safari, Chrome, Internet Explorer, Firefox), pour imposer des éléments non encore dans la norme HTML5. A ce titre, le navigateur qui respecte le plus la norme actuelle du W3C est Internet Explorer 9 (eh oui !), s'agissant des tests effectués. En fait, Chrome et Safari (basés sur le moteur Webkit) implémentent des fonctionnalités qui ne sont pas standardisés. Le but étant de faire adopter celles-ci par le consortium, bref d'imposer des éléments actuellement propriétaires (certains se souviennent de l'époque IE6 / Netscape 4.7).
Actuellement, le risque est grand pour les développeurs de devoir re-développer des fonctionnalités basés sur des techniques dont l'évolution est instable.
Un exemple sont les WebSockets permettant la notification entre le serveur et le client ; actuellement le protocole comporte une faille de sécurité, et il n'est pas sûr que les WebSockets soient conservées sous sa forme actuelle.
Quelques nouveautés du HTML5
Plus de balises sémantiques
Le HTML5 a pour but d'offrir des nouvelles balises sémantiques, adaptées à la structure des pages web : <header>, <footer>, <nav>, <article>, <section>, <aside>, <video>, <audio>, plutôt que d'avoir des <div id="header">, <div id="nav">, etc.
La page doit comporter le doctype : <!DOCTYPE html> (Une page HTML doit toujours avoir un doctype, sinon le navigateur passe en mode Quirks !)
Les balises <audio> et <video> permettent de s'affranchir des plugins de lecture. Par contre, le codec n'est pas standardisé. De plus, la balise <video> ne supporte pas les DRM et le smooth streaming.
Pour <audio>, les codecs sont MP3, Vorbis (.ogg), AAC.
| |
MP3
|
Vorbis
|
AAC
|
|
IE9
|
X
|
|
si extension .m4a ou .aac
|
|
Firefox 3.6
|
|
X
|
|
|
Chrome
|
X
|
X
|
si extension .m4a
|
Pour <video>, les codecs sont H264 (.mp4), WebM, Theora (.ogg).
| |
H264
|
WebM
|
Theora
|
|
IE9
|
X
|
X*
|
|
|
Firefox 4
|
|
X
|
X
|
|
Chrome
|
|
X
|
X
|
|
Safari 5
|
X
|
|
|
|
Opera 11
|
|
X
|
X
|
* : téléchargement requis du codec
Les codecs ne sont pas pris en charge par tous les navigateurs. Par exemple, Firefox ne supporte pas H264 car il n'est pas ouvert (royalty free). Et Chrome prévoit de ne plus le supporter au profit de WebM. Bref, une guerre des codecs en perspective !
Pour le développeur, cela oblige à proposer à l'internaute un triple encodage de la vidéo et à faire du fallback.
Par exemple au sein de la balise <video>, on peut avoir une balise <object> pour charger un .xap (Silverlight), si le codec n'est pas pris en charge.
Exemple :
<video id="myVideo" controls autoplay>
<source src="video.mp4" type="video/mp4; codecs='avc1.4201E,mp4a.40.2'" />
<source src="video.ogg" type="video/ogg; codecs='theora,vorbis'" />
<!-- insertion <object> silverlight -->
<!-- insertion <object> flash -->
</video>
Un exemple plus poussé est donné sur le blog de Niall Kennedy, avec une détection JavaScript.
La balise <canvas> est une zone de dessin, manipulable avec des librairies JavaScript et les primitives, en initiant des contexts (méthode getContext()). Cette balise soulève un problème d'accessibilité car c'est une boite noire, et peut être très couteuse en terme de CPU. Il faut tirer parti de l'accélération matérielle que peut permettre le hardware de la machine (puce de la carte graphique). IE9 offre cette possibilité (voir le site Test Drive).
Les HTML5Forms (ou WebForms)
Attention, c'est toujours en working draft, et à ne pas confondre avec les webforms d'ASP.NET.
Les HTML5Forms ont été proposés par Opera, cela concerne des nouveaux types et attributs de la balise <input> afin de les rendre accessibles. Tous ces éléments ne sont pas tous pris en charge par les navigateurs. En fait, ces nouveautés existent déjà depuis quelques années (avec le web 2.0) en fallbacks avec des librairies AJAX, ou la librairie AjaxControlToolkit d'ASP.NET (gauge bar, calendar, etc.).
- Attribut placeholder
Il permet d'avoir un texte alternatif dans l'input lorsque celui-ci est vide et qu'il n'a pas le focus. Si le navigateur ne le prends en compte nativement, des fallbacks existent en jQuery, et plus anciennement avec le contrôle TextBoxWatermark de la librairie AjaxControlToolkit.
- Attribut autofocus
Permet d'avoir automatiquement le focus sur un input.
- Et 13 nouveaux types (date, email, number, ..., etc.)
Quelques nouveautés du CSS3
On peut citer notamment, border-radius pour faire des coins arrondis, et box-shadow pour faire des ombres portées. background peut contenir un fichier *.svg. (un tag HTML ayant un box-shadow par dessus un background en SVG est supporté par IE9).
Des fallbacks existent si le navigateur ne les supporte pas, via des libraires JavaScript, ou en préfixant les instructions CSS en fonction des navigateurs (instructions propriétaires) :
<style type="text/css">
.rounded
{
-moz-border-radius-topleft:3px; /* firefox */
-moz-border-radius-topright:3px;
-webkit-border-top-left-radius:3px; /* safari */
-webkit-border-top-right-radius:3px;
-khtml-border-top-left-radius:3px; /* konqueror*/
-khtml-border-top-right-radius:3px;
border-top-left-radius:3px; /* standard*/
border-top-right-radius:3px;
}
</style>
Les Media Queries
Une fonctionnalité intéressante sont les Media Queries. Ils permettent d'adapter la résolution du client en fonction du poste client ou du device (smartphone, notebook, tablette), en chargeant des images plus petites. Ce qui évite l'implémentation d'un code JavaScript discriminant. La discrimination (ou device filtering) peut également se faire au chargement des fichiers CSS.
Exemple :
<link href="mobile.css" rel="Stylesheet" type="text/css" media="screen and (max-width:480px)" />
<link href="netbook.css" rel="Stylesheet" type="text/css" media="screen and (min-width:481px) and (max-width:1024px)" />
<link href="laptop.css" rel="Stylesheet" type="text/css" media="screen and (min-width:1025px)" />
On peut citer également les CSS3 animations, les CSS3 transitions mais sont pour l'instant en working draft et donc instables.
WOFF
Web Open Font Format est un wrapper des fonts au format True Type et Open Type. Il permet de télécharger des polices depuis le serveur (via CSS), de manière compressée (téléchargement plus rapide). Le WOFF est en cours de standardisation par le W3C et est soutenu par Microsoft, Mozilla, Opera. Il semble qu'il soit supporté par les dernières versions des navigateurs (sauf Safari actuellement).
SVG 1.1
Scalable Vector Graphics est un langage XML affichant des graphiques vectoriels (donc redimensionnables). Il est stylable par CSS, et est manipulable par JavaScript. SVG a l'avantage de l'accessibilité grâce aux propriétés aria ; mais a aussi l'inconvénient d'être très verbeux (c'est du XML) et peut être très lourd à charger si la page contient beaucoup de graphiques.
Typiquement, SVG est utilisé pour faire du charting. Un bon exemple est la librairie Highcharts JS. C'est une librairie JavaScript qui manipule des graphiques SVG et les rends interactifs.
WebGL
Est basé sur OpenGL, a pour but d'afficher de la 3D dans les pages web. Cette technologie est expérimentale et n'est pas pour l'instant un standard W3C.
Tests de conformité HTML5
Pour vérifier la conformité des pages web sur HTML5, il y a le validateur online du W3C. Le validateur vient d'intégrer dans son moteur le support du HTML5. Après avoir saisi l'URL d'un site, un rapport de test est généré affichant des erreurs et warnings :
En parallèle du test des pages web, il y a le test du navigateur pour vérifier si celui-ci intègre les fonctionnalités actuellement en standard, celles expérimentales (et celles propriétaires). Citons ACID3 (émanation du Web Standard Project) qui fait suite aux tests ACID2 et ACID1 ; et HTML5test. Mais ces tests font débat parmi les éditeurs et la communauté des développeurs, dans le contexte de compétition entre les navigateurs.
HTML5 sous Visual Studio
Des add-ons HTML5
La venue d'HTML5 a poussé la communauté ASP.NET à proposer des add-ons pour Visual Studio 2008/2010, mais pour l'instant c'est du ASP.NET MVC. D'ailleurs, MVC est "HTML compliant" et se prête bien à ça. Il n'est pas encore prévu d'avoir des WebControls ou HtmlControls encapsulant les nouvelles balises sur l'ASP.NET classique.
Ces add-ons sont visibles sur codeplex :
Il est possible également de créer un template pour Visual Studio, dans lequel les pages aspx générées auraient un squelette de code HTML5, mais cela mériterait un article sur ce sujet ;-)
Validation HTML5
Le SP1 de Visual Studio 2010 permet maintenant d'avoir un schéma de validation HTML5/XHTML5. Les nouvelles balises sont affichées avec l'intellisense. En revanche, la validation CSS3 n'est pas encore proposée.
Pour Visual Studio 2008, John Dyer a publié en 2009 un schéma de validation permettant d'avoir également l'intellisense.
Device filtering en ASP.NET classique
Une fonctionnalité bien pratique (et à mon avis peu conne) est de mettre en place des fichiers *.browser, dans le but de discriminer du code ou du contenu. Ce qui est affiché au end user est alors filtré en fonction de son navigateur client et/ou de son device (PC, smartphone, pocket PC). Au lieu de faire du test conditionnel en code behind via la propriété Request.Browser.Id, il est possible de le faire en déclaratif dans la page *.aspx.
Exemple de filtrage natif d'Internet Explorer et Firefox
Le device filtering peut s'effectuer sur des propriétés de contrôles HtmlControl ou WebControl, ou contrôles templatisés, ici en préfixant avec "ie" et "mozilla" :
<!-- Propriétés préfixées par ie ou mozilla -->
<asp:Label runat="server" ID="labelText"
ie:Text="This is IE text"
mozilla:Text="This is Firefox text"
Text="This is general text"
/>
<br />
<asp:Button runat="server" ID="buttonText"
ie:Text="IE Button"
ie:OnClientClick="javascript:alert('Hello IE!');"
mozilla:Text="FF Button"
mozilla:OnClientClick="javascript:alert('Hello Firefox!');"
Text="General Button"
OnClientClick="javascript:alert('Hello everyone else!');"
/>
<br />
<asp:Menu runat="server" id="myMenu">
<ie:Items>
<asp:MenuItem Text="IE Item" />
</ie:Items>
<mozilla:Items>
<asp:MenuItem Text="Firefox Item" />
</mozilla:Items>
<Items>
<asp:MenuItem Text="Other Item" />
</Items>
</asp:Menu>
Cela peut être très utile lorsque on veut référencer une masterpage :
<%@ Page Language="C#"
ie:MasterPageFile="~/MasterPageIE.master"
mozilla:MasterPageFile="~/MasterPageFirefox.master"
MasterPageFile="~/MasterPageGeneric.master"
%>
Comment cela fonctionne ?
Le filtrage en natif est basé sur des fichiers *.browser situés dans le répertoire C:\Windows\Microsoft.NET\Framework\<n° de version du fk>\Config\Browsers
Ce filtrage de base peut être surchargé par l'ajout d'un nouveau fichier *.browser dans une application ASP.NET.
Configurer le filtrage pour IE9, IE8, Firefox dans une application ASP.NET
A l'heure actuelle, le fichier ie.browser (situé dans C:\Windows\Microsoft.NET\Framework\<n° de version du fk>\Config\Browsers) ne contient pas (encore) de définition pour Internet Explorer 9. Il faut donc l'ajouter. Pour cela, il suffit d'ajouter à la racine de votre projet web un répertoire App_Browser (un répertoire réservé d'ASP.NET), lequel contiendra un nouveau fichier que vous nommerez ie9.browser.
Structure du fichier i9.browser :
<!--
You can find existing browser definitions at
<windir>\Microsoft.NET\Framework\<ver>\CONFIG\Browsers
-->
<browsers>
<browser id="IE9" parentID="IE6to9">
<identification>
<capability name="majorversion" match="9" />
</identification>
<capabilities>
<capability name="jscriptversion" value="9.0" />
</capabilities>
</browser>
</browsers>
La valeur de l'attribut parentID est une valeur existante dans le fichier ie.browser. La version du JScript pour IE9 a été reprise à partir des commentaires conditionnels (code côté client servant à discriminer la version d'Internet Explorer).
Pour illustrer le filtrage, nous allons mettre le code suivant dans la page Default.aspx :
<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="DeviceFiltering._Default" %>
<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
<style type="text/css">
label{ margin:0 1em 0 0; }
</style>
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
<h2>Browser filtering in ASP.NET</h2>
<!-- filtrage réalisé en code behind -->
<div id="divIE9" runat="server">
<asp:Label id="lblIE9" runat="server" AssociatedControlID="txtNameIE9">Votre nom (sous IE9)</asp:Label>
<input id="txtNameIE9" runat="server" type="text" />
</div>
<div id="divIE8" runat="server">
<asp:Label id="lblIE8" runat="server" AssociatedControlID="txtNameIE8">Votre nom (sous IE8)</asp:Label>
<input id="txtNameIE8" runat="server" type="text" />
</div>
<div id="divFF" runat="server">
<asp:Label id="lblFF" runat="server" AssociatedControlID="txtNameFF">Votre nom (sous Firefox)</asp:Label>
<input id="txtNameFF" runat="server" type="text" autofocus="true" placeholder="Entrez votre nom" />
</div>
<div id="divBrowser" runat="server">
<asp:Label id="Label1" runat="server" AssociatedControlID="txtName">Votre nom</asp:Label>
<input id="txtName" runat="server" type="text" />
</div>
<!-- filtrage réalisé en déclaratif -->
<p>
<asp:Button ID="btnTest" runat="server"
ie9:OnClientClick="javascript:alert('IE9 button!')"
ie8:OnClientClick="javascript:alert('IE8 button!')"
firefox35:OnClientClick="javascript:alert('Firefox button!')"
ie9:Text="I'm a button for IE9"
ie8:Text="I'm a button for IE8"
firefox35:Text="I'm a button for Firefox" />
</p>
</asp:Content>
Et le code suivant dans la page Default.aspx.cs :
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
namespace DeviceFiltering
{
public partial class _Default : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{
if (!this.IsPostBack)
{
divIE8.Visible = false;
divIE9.Visible = false;
divFF.Visible = false;
divBrowser.Visible = false;
switch (Request.Browser.Id)
{
case "ie8":
divIE8.Visible = true;
break;
case "ie9":
divIE9.Visible = true;
break;
case "firefox35":
divFF.Visible = true;
break;
default:
divBrowser.Visible = true;
break;
}
}
}
}
}
Résultat sous IE9 :
Résultat sous IE9 en mode IE8 :
Résultat sous Firefox :
On peut donc remarquer que l'affichage du bouton se fait de manière déclarative, en préfixant un ID de browser sur un attribut et c'est fini ! :)
Conclusion
Le HTML5 est d'ores et déjà un progrès concernant la sémantique et l'accessibilité des pages web. Ses spécifications auront l'avantage de rendre natives des fonctionnalités telles que les webforms (actuellement rendues avec des librairies AJAX/JavaScript).
Mais attention au buzz marketing effectué autour, et à la dépendance des navigateurs. Car ceux-ci ne l'implémentent pas de la même manière, les performances peuvent être assez différentes d'un device à l'autre. Le HTML5 n'est absolument pas pour l'instant synonyme de développement unique !
Par ailleurs, d'autres briques du HTML5 n'ont pas été évoquées dans ce workshop. Citons le Web Storage (stockage de données dans le navigateur, cache d'application), le Web SQL Database (basé sur SQLite), les Web Workers (scripts JS tournant en tâche de fond), la géolocalisation (via une API JavaScript), les microdata (amélioration du référencement naturel par ajout de données dans les balises, lues uniquement par les robots).
A l'heure de l'expansion imminente du HTML5 sur les sites web et mobile, gageons que les futurs add-ons ou CTP d'ASP.NET apporteront leur lot de nouveauté !
Pour aller plus loin
Souscrire