Un contenu SVG est un document, et canvas est un outil. SVG possède un contenu. Canvas n'a qu'une apparence, résultant de l'execution d'un script. SVG peut donc être lu, comme tout document. Son utilisation et intégration est donc parfaitement adapté dans un contexte site web.

Canvas est par contre déstiné aux applications web. C'est à dire que son utilisation est tout indiquée dans un "truc" qu'on utilise, et non pas qu'on "lit". Aussi je pense que canvas n'a strictement rien à faire dans (X)HTML car sa présence dans un document est totalement inadéquate. Il n'a aucune valeur semantique, et n'est absolument pas accessible.

Je pense qu'on fait de plus en plus fausse route. On vampirise le HTML pour réaliser des applications web. Certes, on le fait depuis longtemps faute de mieux, mais de nouvelles technologies émergent. Il serait peut être temps alors d'arreter d'utiliser HTML pour tout et n'importe quoi, et de l'utiliser uniquement ce pourquoi il a été conçu : le document. Il serait peut être temps d'utiliser autre chose pour les applis web, comme le XUL, pour avoir de vraies interfaces utilisateurs.

Parce que franchement, les interfaces à la google mail et yahoo mail, c'est super pour l'utilisateur "normal", mais il faut voir pour les autres le cauchemar, que ce soit coté accessibilité ou développement. En effet les développeurs s'arrachent les cheveux à mettre des balises, des images, des feuilles de styles dans tous les sens, sans compter les nombreux scripts pour faire que l'interface utilisateur ressemble à une interface utilisateur classique comme on trouve dans n'importe quel logiciel, que le fonctionnement d'un onglet ressemble à un vrai onglet, qu'une liste arborescente ressemble à une liste arborescente comme dans l'explorateur. Alors qu'avec un langage de type XUL, ça se fait avec quelques balises. Le développeur n'a qu'à se concentrer sur les traitements déclenchées par l'interface et non se concentrer sur le fonctionnement intrinsec de son interface.

Accessibilité ? Les interfaces utilisateurs HTML utilisant des scripts de partout pour faire des onglets, des trees etc ne sont pas accessibles. Les développeurs web font-ils ce qu'il faut pour intégrer les mécanismes d'accessibilité inhérents à l'usage d'une interface utilisateur ? Assurément pas. Ils ne peuvent pas vraiment. Au mieux, ils font ce qu'il connaisse en accessibilité d'un document, en HTML. Mais malheureusement, un document n'est pas une interface utilisateur. La problèmatique est tout autre. Je vais prendre un exemple simple : le bouton.

Imaginons par exemple qu'il n'y ait pas de bouton en HTML. Le développeur décide alors d'utiliser un span pour réaliser un bouton. Il va donc falloir d'abord conçevoir l'habillage pour que ça ressemble à un bouton. Premier problème : il sera forcément en totale opposition avec les recommendations de tels ou tels environnements graphique. Si il fait un bouton type "windows", celui-ci ne sera pas cohérent dans un environnement KDE, ou GNOME, ou MAC OS X. Et vice versa. Ce genre de problèmatique fait parti de l'aspect accessibilité.

Le développeur va devoir ensuite réaliser le comportement du bouton : gérer les clics, le focus, l'activation, la désactivation et tout autre action sur son faux bouton (si il a du temps..). C'est un boulot monstrueux par rapport à ce qu'on fait quand on réalise un logiciel classique. Dans n'importe quel langage, déclarer un bouton dans une interface de logiciel, c'est 3 lignes de code à tout casser. En XUL, une balise. En HTML/javascript : 150 lignes de code. Pour arriver à un résultat pas forcément à la hauteur. Et le lecteur vocal d'écran, la plage braille et tout autre dispositif non visuel, y compris le clavier (la fameuse touche tab pour passer le focus d'un element à un autre), lui ne verra qu'un span. Pas un bouton. Et par conséquent, sera certainement ignoré parmis les actions possibles sur "l'écran" (à moins de mettre des attributs title, alt ou que sais-je, mais ce n'est franchement pas ce qu'il y a de mieux). Canvas, c'est pire, parce qu'il n'a aucun contenu. Avec du SVG, il y a du contenu. Un système de lecteur vocal peut dire, là il y a un cercle, là un rectangle, par ce que c'est écrit dans le document. Au niveau du canvas, c'est le blanc complet.

Je vous laisse imaginer le cauchemar pour rendre accessible un faux onglet, une fausse liste arborescente en HTML, un menu déroulant etc, bien plus compliqué qu'un bouton. Certes, il existe certainement des scripts et bouts de code tout fait, qui accélèrent le développement, mais je doute fortement qu'ils aient les qualités requises en matière d'accessibilité. Sans compter les conséquences au niveau téléchargement.

En passant, les fameux widgets DashBoard sous MacOs X, réalisés en HTML, et utilisant canvas, doivent être une horreur coté accessibilité à cause des raisons que je viens d'évoquer. (quelqu'un pour confirmer ?)

Il n'y a en principe pas ce problème d'accessibilité avec un langage comme XUL, car ce n'est pas le développeur qui construit le bouton, mais le système. Le navigateur demande à l'environnement graphique de lui créer un bouton lorsqu'il voit qu'il faut créer un bouton (c'est ce qu'il fait pour un <input type="button"/> en html, mais bien sûr, pas pour d'autres élements "simulés" en html). De ce fait, l'élement a donc nativement toutes les propriétés et comportements que l'utilisateur attend. Et que n'importe quel système d'accéssibilité attend. Le lecteur vocal écran est informé que ceci ou cela est un bouton ou une liste arborescente, ou un menu déroulant. Il est informé de toutes les caractéristiques intrinsec du widget. Il sait quoi faire. La réaction va donc être tout à fait adaptée. L'utilisateur aura le bon "stimulis" qui lui fera prendre conscience de la nature de l'objet qui a le focus. Les raccourcis claviers dont a l'habitude l'utilisateur dans son environnement graphique fonctionneront (alt+lettre pour ouvrir la barre de menu par exemple). Etc.

Pour en revenir au canvas, tout comme le html n'est pas adapté pour réaliser une interface utilisateur, canvas n'est pas adapté aux documents du web (en particulier HTML) pour reproduire un dessin accessible. Le SVG, si.

Il faut utiliser les technologies adaptées aux besoins. Alors certes, à cause du manque d'un langage XUL-like standardisé, on va continuer à mélanger les deux genres. Quand on sait qu'il a fallu 5 à 7 ans pour avoir une implémentation de CSS2 plus ou moins bonne dans tous les navigateurs, j'ai bien peur qu'il faille attendre tout autant (sinon plus, voire jamais?) pour un XUL like standard adopté par tout le monde.

On peut noter l'initiative du whatwg, qui est en train de mettre au point une évolution du HTML, avec des formulaires plus complet et plus riche, des balises documentaires plus nombreuses. Mais pas vraiment grand chose pour faire facilement une interface utilisateur sérieuse, ce qui réserve ce HTML aux documents, et donc avec quelques incohérences dans leurs spécifications (toujours en cours de rédaction), comme cette balise canvas qu'ils proposent, qui, pour moi, n'a pas sa place dans un document. J'éspère qu'ils n'iront pas trop loin et que cela n'aboutira pas à un mélange de sémantique documentaire et de sémantique interface utilisateur. Car alors j'ai bien peur que cela ajoute des incohérences et surtout, fasse surgir des mauvaises utilisations.