Chez Jérémie - Mot-clé - Mozilla

MDN fait peau neuve

Jeremie — Sun, 12 Aug 2012 14:56:00 +0200

Après plusieurs mois de travail intense, la plateforme technique qui supporte MDN vient de changer. Originellement basée sur la solution DekiWiki de la société MindTouch, la documentation de Mozilla vient de passer sous une solution 100% maison : Kuma. Kuma est un projet codé à l’aide de Python/Django et est directement inspiré de la plateforme qui supporte déjà SUMO (le support utilisateur de Firefox) connu sous le nom de Kitsune.

Comme tous les projets Mozilla, Kuma est 100% open source. Le code est disponible sur GitHub et vous êtes largement invité à proposer patches et fixes si vous en avez envie

Le principal intérêt pour MDN de passer sur une plateforme ouverte et développée par Mozilla est simple : Pouvoir maîtriser les évolutions à apporter à la plateforme pour garantir la meilleure expérience utilisateur possible sur MDN. En la matière, les besoins sont importants et Mozilla a de grandes ambitions pour MDN.

Quoi de neuf ?

Si la plateforme, très jeune, souffre encore de quelques bugs en cours de résolution, les premières améliorations sont déjà visibles. Les deux plus évidentes sont liées à la localisation et aux templates personnalisés.

Concernant la localisation des contenus, disons-le clairement : on ne pouvait pas faire pire que ce qu’il y avait avant. Désormais, à chaque fois que vous voulez traduire une page, vous disposerez toujours de la version anglaise d’un coté et de votre propre version de l’autre, de même les liens entre les différentes versions localisées seront automatiques et vous avez même la possibilité de localiser l’URL de chaque page comme bon vous semble. La fonctionnalité la plus intéressante est liée à la navigation : lorsque vous naviguez sur une version locale de MDN (disons, le français par exemple) et qu’un contenu n’est pas disponible dans cette langue (souvent matérialisé par un lien rouge), vous accèderez automatiquement au contenu en anglais avec un bandeau vous proposant directement de traduire ce contenu.

Concernant les templates personnalisés, l’équipe de développement a créé un langage de script entièrement basé sur JavaScript (exécuté coté serveur) qui porte le nom de KumaScript. En clair, c’est du JavaScript avec quelques extensions pour en faire un langage de gabarit autonome (précédemment, il s’agissait d’un langage basé sur Lua, peu ou pas extensible). Les API disponibles restent encore sommaires, n’hésitez donc pas à ouvrir des bugs si vous avez des besoins particuliers. Ce système de template permet de créer des automatismes et des gabarits faciles à réutiliser d’une page à l’autre et il y a beaucoup à faire en la matière.

Et après ?

Dans les prochains mois, de nouvelles fonctionnalités vont faire leur apparition. La semaine dernière, toute l’équipe MDN (rédacteurs et développeurs) ainsi que quelques contributeurs se sont réunis à Toronto pour planifier et prioriser ces améliorations, 3 jours intenses sous la direction d’Ali Spivak, la nouvelle « Product Manager » de MDN. La listes de toutes les idées que nous avons amenées est beaucoup trop longue pour tout vous mettre ici… disons simplement que l’équipe de développement a du boulot pour plusieurs années si personne ne les aide

Parmi les principales priorités, les éléments suivant sont ressortis et vont faire l’objet d’un effort particulier dans les prochaines semaines/mois :

1. Sécurité

La plateforme étant encore jeune, certaines fonctionnalités ont besoin d’êtres sérieusement passées au crible des questions de sécurité. Ainsi, des filtres vont être appliqués ou améliorés pour rendre l’édition à la fois plus souple et plus sur (en particulier pour lutter contre les attaques de type CSRF), la politique de sécurité actuelle étant de tout interdire par défaut (script, iframe, etc. ne sont pas permis, même pour des usages légitimes). De même, l’envoi de fichiers n’est pour l’instant pas permis mais tout cela va rapidement changer.

2. Exemples de codes

Un travail de fond va être réalisé pour permettre aux utilisateurs d’embarquer des exemples de code actifs et modifiables (à la jsFiddle ou dabblet), le tout dans des conditions garantissant la sécurité des utilisateurs et des contenus. C’est sans doute le plus gros chantier des mois à venir (et celui que j’attends le plus impatiemment pour pouvoir déployer des exemples dans la doc SVG ;).

3. Localisation

Les outils pour la localisation vont être très largement améliorés (oui, c’est possible). Il s’agit d’un travail qui va s’étaler sur plusieurs mois (voire plusieurs années). Une des premières améliorations va être la possibilité de choisir la langue d’origine pour réaliser une traduction (aujourd’hui, c’est forcément l’anglais). Dans le même temps les bases d’un tableau de bord vont être posées pour permettre de plus facilement prioriser et planifier les pages à traduire.

4. API d’écriture

Pour le moment, Kuma n’offre qu’une API en lecture des contenus de MDN. Afin de rétablir le fonctionnement de certains outils et permettre le développement d’outils de consultation et d’édition tiers, une API permettant d’écrire du contenu dans MDN va être mise en œuvre. L’objectif est de permettre aux personnes voulant éditer du contenu avec leur éditeur de textes préféré de le faire ou bien de permettre à certains projets utilisant d’autres systèmes de wiki (GitHub par exemple) de partager leurs contenus facilement sur MDN (c’est typiquement le cas du projet JetPack pour Firefox).

5. Présence dans les moteurs de recherche

MDN souffre encore de certains manques qui grèvent son indexation par les moteurs de recherche. Les points les plus évidents vont être rapidement améliorés : qualité des méta-données (titre et description) et ajout d’un sitemap.

6. Recherche et tableau de bord

Un travail de fond va être engagé afin d’améliorer sérieusement la qualité des recherches sur MDN (techniquement parlant, cela va passer par le déploiement d’une base de données Elastic Search) et permettre de poser les bases techniques permettant de créer un véritable système de tableau de bord pour les éditeurs. Ce tableau de bord permettra dans un premier temps aux éditeurs de suivre et filtrer les contenus qui les intéressent pour, dans un second temps se transformer en un véritable système d’échange, de communication et de coordination (mais tout ça va prendre du temps, il va falloir être patient).

Mais encore…

Tout cela n’est que le début. Bien d’autre demandes ont été émises, parmi lesquels ont été priorisées les suivantes :

Localisation complète du système de tags
Possibilité de déplacer des ensembles de pages en une fois
Améliorer les liens croisés entre documentation et démos
Mettre en base de données, automatiser et partager les tables de compatibilité navigateurs
Améliorer le bandeau de localisation des articles non-traduit pour directement choisir la langue d’affichage alternative

Et bien plus encore… Si cela vous intéresse, vous trouverez toutes les notes de la semaine de travail sur ce Pad : https://etherpad.mozilla.org/MDN-Toronto-2012

Enfin, n’hésitez pas à ouvrir des bugs si vous avez des besoins ou des fonctionnalités que vous souhaiteriez voir dans MDN. L’équipe a profité de la réunion de la semaine dernière pour revoir son système de triage et de priorisation des bugs afin que leur traitement soit plus simple et plus compréhensible par tout le monde. L’opportunité de travailler sur un redesign de MDN a également été évoqué, cela fera l’objet d’un projet à part entière dans les prochains mois.

Ce n’est certes que le début et nul ne sait comment tout ça va évoluer, mais les choses sont bien engagées et MDN est bien parti pour devenir la documentation de référence du Web ouvert en étant désormais lui-même ouvert et accessible à tous. Je profite de l’occasion pour remercier chaleureusement toute l’équipe de développement de Kuma : Luke Crouch (groovecoder), Les Orchard (lmorchard), David Walsh (darkwing) et James Bennett (ubernostrum). Ils font un travail remarquable qui mérite d’être souligné.

Bonne documentation (^_^)

Bien démarrer avec MDN

Jeremie — Tue, 24 Apr 2012 21:12:00 +0200

Depuis maintenant 2 ans environ, je contribue activement à MDN (en particulier, j’écris la doc de la partie dédiée à SVG… en anglais pour l’instant) et depuis le début de l’année, j’organise tous les mercredis une petite soirée pour ceux qui veulent découvrir et aider à compléter la documentation du web ouvert chez Mozilla. A cette occasion, il y a un certain nombre de questions qui me sont posées régulièrement. En voici la liste avec les réponses qui vont bien.

Update : This article has been translate into English

Update 2 : Esteartículo fue traducido al castellano

C’est quoi MDN ?

Ne riez pas, vous n’imaginez pas le nombre de fois où j’ai entendu cette question.

Alors pour faire simple, MDN, c’est le “Mozilla Developer Network”. C’est un site web qui regroupe la quasi totalité de la documentation liée aux produits Mozilla. On y trouve 3 grandes sortes de ressources :

Des articles et des liens vers des ressources externes pour apprendre à utiliser les technologies du web
Des démos des dernières technologies implémentées dans les navigateurs modernes (Ces démo sont issues d’un concours mensuel, le “Dev Derby” organisé par John Karahalis)
Une documentation de références (API, balises, attributs, propriétés) des technologies Mozilla mais aussi et surtout de toutes les technologies du Web ouvert (HTML, CSS, Javascript, SVG, WebGL, etc.)

Cette dernière partie, la documentation des technologies Web, est la plus importante (autant en volume qu’en qualité) et celle sur laquelle, en ce moment, Mozilla porte ses plus gros efforts. Le point le plus notable de cette documentation c’est qu’elle est multi-navigateur avec des tables de compatibilité et des notes d’implémentation pour d’autres navigateurs que Firefox.

Même si cette documentation est sans doute une des plus riches documentations généralistes qui soit sur le Web, elle est loin d’être complète et c’est là que vous pouvez intervenir pour aider à la compléter

Est-ce que c’est compliqué de participer ?

Pas du tout, au contraire, c’est affreusement simple. C’est même sans doute un des points d’entrée les plus faciles pour contribuer chez Mozilla (vous n’aurez pas besoin de vous confronter à Bugzilla :-P).

En effet, pour contribuer à MDN vous n’avez besoin que de 2 choses :

Avoir envie
Avoir un compte utilisateur sur MDN

Et c’est tout.

L’opération la plus difficile consiste à trouver le bouton “Connexion” dans la barre d’en-tête, coincé entre le champ de recherche et l’horrible onglet blanc “Mozilla”… oui, au niveau ergonomie on a fait mieux. Cliquez sur ce bouton puis fournissez une adresse e-mail et un mot de passe (le système de connexion utilise le nouveau système Persona/BrowserID). Sur la page suivante, on vous demandera un “Nom d’utilisateur” qui sera le nom affiché en face de vos contributions. Et voila, vous êtes prêt à contribuer.

De son coté, la contribution est elle aussi très simple. Fondamentalement, MDN est à 80% un wiki. Sur toutes les pages du Wiki, une fois que vous êtes identifié, vous trouverez un bouton “Editer” (en haut à droite). Cliquez dessus, le contenu de la page se chargera dans un éditeur WYSIWYG (rassurez vous, si vous préférez vous la jouer hardcore, vous pouvez repasser en édition HTML). Faites-y les modifications que vous voulez, enregistrez (via le bouton “Sauvegarder” en haut à gauche) et voilà. Vous avez fait votre première contribution à MDN et au projet Mozilla en général : pas de processus de validation à la mords-moi-le-nœud, pas de délai de publication, pas de modération à priori (mais il y en a tout de même une, assez light il est vrai, à posteriori)… trop facile

Qu’est-ce que je peux faire, par où je commence ?

La réponse courte, c’est “par ce que vous voulez”, malheureusement, l’expérience m’a montré que cette réponse n’était pas celle attendue par les nouveaux venus.

Basiquement, sur MDN, vous pouvez faire 2 choses :

Proposer des démos via le “Dev Derby” mensuel, ce qui est une excellente façon de contribuer si vous êtes plutôt codeur.
Enrichir la documentation si vous vous sentez plutôt une âme de rédacteur

La contribution à la documentation peut prendre plusieurs formes qui vont dépendre du temps que vous êtes prêt à y passer et/ou de votre degré de motivation :

Écrire de nouveaux articles
C’est sans doute la contribution qui demande le plus de temps mais qui est aussi la plus utile au plus grand nombre. Notez que l’écriture de nouveaux contenus peut parfaitement se faire dans une autre langue que l’anglais
Traduire des articles existants
Ce n’est un secret pour personne, la partie anglaise de MDN est la plus fournie. Vous pouvez donc traduire ce que bon vous chante. Si vous avez envie mais ne savez pas quoi traduire, vous pouvez jeter un coup d’œil à la liste de l’ami Goofy.
Écrire des exemples de code
La littérature, c’est bien, des exemples concrets, c’est mieux. En général, un bon exemple vaut mieux que dix paragraphes d’explications complètement absconses. Écrire des exemples de code fait partie des contributions les plus utiles (et pas forcément les plus longues à produire) et MDN en manque cruellement (en particulier sur la partie SVG… je dis ça, je dis rien, hein).
Faire de la relecture
Comme MDN est faiblement modéré et comme l’erreur est humaine, il est toujours bon d’avoir des gens qui font de la relecture. Il peut s’agir aussi bien de relecture d’orthographe que de relecture technique. N’hésitez pas si vous avez peu de temps à consacrer car cela aidera beaucoup de monde (à titre d’exemple si vous lisez cet article, vous constaterez à quel point c’est désagréable de lire un texte bourré de fautes d’orthographe :-P).
Compléter les tables de compatibilité
MDN se veut une documentation agnostique du point de vue des navigateurs. En conséquence, il existe des tables de compatibilité sur de nombreuse pages de MDN. Elles permettent de savoir pour quel navigateur, une API, une balise, un attribut ou une propriété est disponible. C’est particulièrement utile et cela prend 5 minutes pour rajouter une information de compatibilité. C’est sans doute la façon la plus facile et la plus rapide de contribuer à MDN.

Et surtout, un dernier conseil. La documentation est quelque chose d’immense, en conséquence vous n’aurez jamais le temps de tout faire tout seul. Concentrez-vous donc sur les sujets qui vous intéressent vous personnellement. Dans mon cas, c’est SVG, mais chacun aura son propre centre d’intérêt. S’il y a un sujet en particulier qui vous intéresse, sachez que MDN dispose de “Topic Leaders” qui peuvent vous aider (n’hésitez pas à les contacter, ils sont là pour ça)

Et si vous êtes francophone allergique à l’anglais, sachez que vous avez de la chance. En effet, trois de ces “responsables” sont francophones : Moi-même qui peut vous aider sur tous les sujets liés à SVG, David Bruant pour toutes les questions autour de Javascript et Jean-Yves Perrier pour CSS (Jean-Yves est aussi employé Mozilla sur MDN, n’hésitez donc vraiment pas à le contacter)… Vous noterez qu’ils ne s’occupent que de technologies au rabais :-P

Sachez également qu’il existe 2 pages sur MDN qui complètent très largement ce que je viens de résumer ici :

La page “Pour commencer”
La page “A faire” (en)

Je veux traduire une page en français, comment je fais ?

Cette question est plus compliquée qu’il n’y paraît. En effet, l’actuel moteur de Wiki qui fait tourner MDN n’est pas très bien fichu sur la question de la localisation. Heureusement, d’ici quelques semaines, la plateforme technique devrait changer (les travaux sont en cours, mais vous savez comme ça se passe chez Mozilla : « on livre quand c’est prêt. — C’est à dire ? — Quand c’est prêt. »).

D’ici là, voici les principaux points auxquels il faut prêter attention.

Localiser les URL

D’abord un petit point sur la structure des URL de MDN. Elles sont de la forme :

https://developer.mozilla.org/locale/page/sous-page/sous-sous-page

Pour toutes les pages liées à une technologie, localiser l’URL reviendra, dans 90% des cas, à changer la locale. Exemple :

Néanmoins, vous pouvez parfois vous retrouver face à ça :

Dans ce cas il y a grosso modo 2 options :

Vous avez identifié une page manquante dans la partie française de MDN
Vous avez identifié une page que vous aimeriez traduire dans une partie de MDN qui n’est pas en français.

Dans le premiers cas, vous êtes le plus souvent tombé sur un lien qui mène vers une page qui n’existe pas (ils sont stylés en rouge). Dans ce cas, le travail de localisation du lien a déjà été fait et il vous faut juste trouver la page équivalente en anglais (ou autre, selon ce que vous parlez comme langue). En général, en remontant les arborescences, vous trouverez facilement une page qui a été traduite et qui vous permettra d’explorer l’équivalent de ce que vous cherchez dans la langue de votre choix. Notez que pour passer d’une langue à l’autre, vous avez sur les pages, en haut à droite un menu “Langues” qui permet de passer d’une version à l’autre d’une même page. J’y reviens ci-après.

Dans le deuxième cas, c’est parfois un peu plus délicat car vous aller devoir faire des choix de traduction des termes de l’URL. Ici, la difficulté va être de s’assurer qu’une traduction des termes n’a pas déjà été faite sur une autre page. L’idée c’est d’arriver à être cohérents d’une traduction à l’autre… ce qui est particulièrement critique pour les URL. Ici, la meilleure façon de procéder, c’est d’aller poser la question aux localisateurs qui sont rompus à l’exercice. Pour le français, le meilleur point d’entrée c’est le canal IRC #frenchmoz sur irc.mozilla.org ou éventuellement la mailing liste de la communauté francophone des contributeurs Mozilla. Tous les détails sont disponibles sur mozfr.org

Faire des liens croisés entre les différentes localisations

La deuxième difficulté lorsqu’on localise une page, c’est de réaliser des liens croisés entre les différentes versions d’une même page. Ces liens croisés apparaissent dans le menu “Langues” en haut à droite des pages.

Le seul problème, c’est que ces liens ne sont pas générés automatiquement. Concrètement, vous devez rajouter dans chacune des pages localisées les liens vers les autres localisations. Oui, ça veut dire que s’il y a déjà 10 versions différentes d’une page, vous aller devoir toutes les éditer une par une pour rajouter manuellement le lien vers la nouvelle version que vous venez de créer.

Ce n’est pas bien compliqué (c’est un petit bout de code normalisé en bas de page), mais c’est assez fastidieux

Bref, vivement le changement de plateforme technique.

Conclusion

Voilà, après ça, vous n’avez aucune excuse pour ne pas contribuer. Les problèmes de localisation mis à part (j’essayerai d’écrire un article sur le sujet quand on aura changé de plateforme) c’est facile et peu consommateur de temps. Si vous voulez en savoir plus, n’hésitez pas à passer dire bonjour le mercredi soir (je tiens une sorte de permanence dans les bureaux de Mozilla à Paris) ou à m’écrire (faites gaffe quand même, je réponds assez lentement). Au-delà de ça, d’autres peuvent vous aider si vous avez des questions sur la documentation : j’ai déjà cité les francophones David et Jean-Yves (aka Teoli)), mais chez les anglophones, vous pouvez facilement vous adresser à Eric Shepherd (aka Sheppy) et Janet Swisher. Vous pouvez facilement retrouver tout ce petit monde sur irc.mozilla.org sur la canal #devmo ou sur la liste de diffusion dev-mdc. Á noter que Jean-Yves, Eric et Janet sont les 3 principaux employés Mozilla chargés de superviser MDN, n’ayez donc aucun scrupule à vous adresser à eux (^_^)

La documentation c’est bon, mangez-en

MAJ du 25/04: Merci à Goofy pour la relecture orthographique

Documenter le Web ouvert, pourquoi et comment

Jeremie — Mon, 02 Jan 2012 09:00:00 +0100

Cela fait quelques temps que je m’implique dans plusieurs projets visant à documenter ou à fournir du matériel pédagogique concernant les technologies du web dit ouvert (standards et technologies sous licences open-source). De mon point de vue, cet effort de documentation est nécessaire pour plusieurs raison que je vais vous détailler ici et j’espère bien convaincre quelques-uns d’entre vous de me suivre sur ce long chemin… un peu aride, il faut bien l’admettre :-P

Pourquoi ?

En temps que « vieux » du Web (je créer des sites à titre personnel depuis 1997 et à titre professionnel depuis 2000), j’ai appris le Web « à la dure » en lisant quelques livres de qualité inégale, en utilisant outrancièrement la fonction « afficher la source » de mes navigateurs et en fréquentant divers forums de discussion. J’ai fait beaucoup d’erreurs (et je continue à en faire) mais en rencontrant les bonnes personnes et en apprenant de ces erreurs j’ai réussie à progresser pour arriver ou j’en suis aujourd’hui. Certes, je ne regrette rien, mais franchement ce n’était pas simple tout les jours et s’il est possible de se simplifier la vie, autant ne pas s’en priver.

Au delà de mes considérations personnelles et de mes propre besoins et envies, il y a tout de même quelques points notables qui militent en faveur d’une documentation plus importante et plus « normé » des différentes technologies Web.

Place aux jeunes

Je vois actuellement arriver une nouvelle génération de développeurs et d’intégrateurs Web. A mon grand désarrois, peu d’entre eux sont vraiment doués. C’est quelque chose d’assez normal, tout le monde ne peut pas être un génie. Mais le problème ne se situe pas là. Le problème est souvent bien en amont au niveau de leur formation. Malheureusement, il existe encore peu de cycles d’études qui forment vraiment aux technologies et problématiques propres au Web (en France, on est encore trop dans la dichotomie : écoles d’informatique d’un coté qui ne font que survoler les technologies Web sans en voir les aspects fonctionnels ; écoles d’art et de design de l’autre coté qui survolent vaguement les aspects fonctionnels en faisant totalement l’impasse sur les aspects techniques). Ainsi, la qualité de la formation dispensée dépend donc encore trop souvent de la qualité des professeurs et formateurs. La difficulté, c’est qu’eux même ont du mal à trouver des sources d’informations leur permettant de rester à jour. L’effort de veille à faire pour qu’un formateur reste au niveau est énorme et parfois difficile si l’on cherche du matériel pédagogique dans une langue autre que l’anglais. Pire ! De trop nombreuses sources d’informations sont parfois médiocres pour ne pas dire complètement fausse et le plus souvent peu ou pas mises à jour (le cas W3School, par exemple, a donné lieu à de vives réactions).

Avec tout ça, on voit bien qu’il est finalement, aujourd’hui encore, assez difficile de se former correctement aux technologies et techniques de mise en œuvre des sites Web.

La complexification des technologies

Les standards du Web sont quelque chose qui évolue en permanence. Depuis plus de 20 ans, ces technologies gagnent en maturité, changent, s’enrichissent et s’affinent. Depuis environs 3 ans maintenant, les choses vont même en s’accélérant. HTML5 change profondément la nature du langage HTML, CSS3 enrichie considérablement le nombre de propriétés disponibles, ECMAScript vient de passer en version 5 et la 6 est en préparation, etc. Le retour d’un univers concurrentiel sur le marché des navigateurs, l’émergence du Web mobile, tout cela contribue à rendre les technologies toujours plus complexes et à rendre leur implémentation parfois très hétérogène d’un navigateur à l’autre.

Quelques chiffres bruts pour se rendre compte :

HTML4 : 91 balises et 119 attributs -> HTML5 : environ 107 balises et plus de 143 attributs
CSS2.1 : 115 propriété -> CSS3 : près de 250 propriétés (C’est une estimation car les travaux de spécification ont à peine commencé)
SVG 1.1 : 80 balises et 267 attributs
Plusieurs centaines d’interfaces DOM (je n’ai pas eu le courage de compter)

Et encore, là, il ne s’agit que du sommet de l’iceberg des différentes technologies Web. Et puis, quid des implémentations ? Quel navigateur supporte quoi ? Et avec quel degré de précision/bugs ? Ou et comment trouver des informations pertinentes et à jour sur toutes ces technologies, leur fonctionnement et leurs interactions ?

Et puis tant qu’on en est à complexifier les choses, allons jusqu’au bout. La fonctionnalité suprême des navigateurs, le fameux « afficher la sources » et en train d’en prendre un petit coup dans l’aile. En effet, les techniques d’optimisation des performances (pour ne citer qu’elles) ont un petit effets de bords, elles ont tendance à rendre les codes sources illisibles par les êtres humains. Mais même sans ça, examiner le code source d’une bibliothèque Javascript de 200Ko est très loin d’être une partie de plaisir. Aujourd’hui, n’espérez donc pas apprendre sérieusement Javascript simplement en lisant du code (ce que j’ai pourtant fait il y a plus de 10 ans).

Contrairement à une idée reçu, le Web ce n’est pas simple. Je ne sais pas pour vous, mais s’il existe des sources d’informations fiables me permettant de m’y retrouver, ce sera avec plaisir que je les accueillerai.

Comment ?

J’en arrive donc à un constat simple : ressources de qualité douteuse + complexification des technologies = il faut rentrer dans une logique de documentation un peu plus sérieuse que ce qui a été fait jusqu’à présent.

L’initiative individuel

Jusqu’à une date très récente, l’effort de documentation des technologies du Web ouvert passait par des initiatives individuelles. Chaque développeur web ayant son propre site ou blog sur lequel il note et documente ce qui l’intéresse ou lui manque (c’est typiquement ce que je fais sur ce site ). Les plus fameux à ma connaissance sont sans doute :

Position is everything qui documente tous les bugs de Internet Explorer 6 (et 7) en matière de CSS (je ne compte plus les fois ou ce site m’a sauvé la vie)
Quirks mode de Peter-Paul Koch qui détail la compatibilité des propriétés CSS d’un navigateur à l’autre (on notera en ce moment le boulot que fait PPK sur le support des navigateurs mobiles)
A list apart et ce que l’on peut considérer comme son équivalent Français : OpenWeb qui produisent des articles à la fois précis et accessible à tous.

Il en existe évidement bien d’autre et il est impossible de les citer tous. Ceci étant, pour intéressant qu’il soit, cet effort de documentation reste encore très dispersé, peu structuré et nécessite de prendre le temps de chercher ce dont on a besoin tout en requérant une bonne dose d’esprits critique pour trier le bon grain de l’ivraie.

W3C et consort.

Deuxième source historique de documentation : le W3C et autre organisme de standardisation. C’est bête à dire, mais lire les spécifications des technologies peut être une mine d’or si l’on cherche des informations techniques précises. Malheureusement, il faut bien se le dire, les spécifications ne sont pas écrite pour le commun des mortels… en tout cas pas pour les développeurs Web. En effet, les spécifications sont de la matière brute. Elles sont écrite avant tout pour les fabriquant de logiciel (navigateurs, éditeur de code, etc.) et surtout, elles ne permettent pas de savoir quelles sont les différences d’implémentation d’un logiciel à l’autre. Leur lecture est donc rarement suffisante (et parfois même inutile… par exemple, essayer de lire la spécification d’ECMAScript pour apprendre le Javascript, c’est un peu comme regarder la formule chimique du beurre pour apprendre à faire un gâteau).

Saluons tout de même l’initiative du HTML Working Group qui, dans le cadre de HTML5, produit deux documents à destination des développeurs Web :

http://www.w3.org/TR/html5-author/ Version expurgé des spécificités purement techniques liées à l’implémentation de HTML et qui se concentre sur ce qui est vraiment utile pour les créateurs de sites Web.
http://dev.w3.org/html5/markup/ La liste détaillé de toutes les balises HTML5

Les fabricants de navigateurs

Une autre source de documentation parfois méconnus mais très riche existe : la documentation officiel des fabricants de navigateur. C’est vraiment dommage qu’elles ne soient pas plus connus car on y trouve parfois des perles :

MSDN : http://msdn.microsoft.com/
Documentation officiel de Microsoft, vous y trouverez absolument tout concernant les technologies implémentées dans Internet Explorer (et tout les autres produits Microsoft). Son seul vraie problème est d’être extrêmement mal structuré quand on l’aborde de l’extérieur (comprendre, via un autre moyen que les pages d’aide des produits Microsoft). Pour la petite histoire, les technologies Web, c’est là : http://msdn.microsoft.com/en-us/library/aa155073.aspx
MDN : https://developer.mozilla.org/
Site de documentation de Mozilla. Originellement fait pour documenter les technologies propres à Firefox, il est actuellement en train d’évoluer pour proposer une documentation agnostique sur tous les standards Web. En particulier, on y trouve la documentation de référence pour Javascript. Sa principale caractéristique est d’être un wiki éditable par tout le monde, c’est donc le lieu idéal pour y trouver (et y créer) la documentation dont vous avez besoin
Dev Opera : http://dev.opera.com/
On y trouve à la fois la documentation officiel des produits Opera, des articles des équipes d’Opera (chaque employé y a un blog pro.) mais également des articles écrits par des développeurs web indépendants. En effet, n’importe qui peut ouvrir un compte utilisateur et y écrire des articles.

La seul ombre au tableau, c’est le projet Webkit qui ne dispose pas d’une documentation officielle (en tout cas, je ne l’ai pas encore trouvée). On notera tout de même que depuis un peu plus de 1 an, les équipes de Google collabore avec Mozilla au sein de MDN pour que la documentation de référence soit la plus générique possible.

Le temps de l’action

Le fait est qu’on est encore loin d’avoir des documentations dignes de ce nom et, soyons claire, on n’est finalement jamais aussi bien servi que par soit même.

Aussi, je vous invite à écrire ce que vous savez. Il n’est pas nécessaire de faire de très long articles détaillés, mais simplement, mettre le résultat de vos expérimentations (à titre d’exemple, regardez ce que font Raphael Goetter avec IE7 no more ou la Web Agency Tympanus sur son blog). Quoi que vous en pensiez, ce sera toujours utile à quelqu’un (ne serais-ce que pour vous). Ok, ce que vous découvrez à peut-être déjà été écris ailleurs… mais ça n’a pas d’importance car plus il y a d’articles sur le même sujet, plus l’information est facile à trouver. Ne soyez pas timide, écrivez

Mais ce n’est qu’un début. Pour aller plus loin, je vous invite à regarder de près l’initiative Move the web forward qui détaille tout ce qu’il est possible de faire pour contribuer (au delà de la documentation) à améliorer le Web.

Enfin, et c’est là que les choses commence à se structurer, plusieurs organisations travaillent sur la documentation du Web ouvert. On notera en particulier deux acteurs majeurs de ce travail de documentation :

Mozilla

Depuis 2 ans environ, Mozilla a entamé un travail de fond visant à transformer MDN pour en faire une source de documentation neutre. Ainsi, pour tout ce qui concerne les standards du Web, vous y trouverez une documentation de référence pour les principaux langages (HTML, CSS, SVG, MathML, Javascript, etc.). L’objectif est, pour chaque balise, propriété, API, attribut, … de fournir une explication de comment ils s’utilisent avec des exemples, des cas d’usage, tout en documentant les spécificités liées aux implémentations de chaque navigateur.

Réaliser une telle documentation prend du temps et toute les bonnes volontés sont appréciées. Si vous voulez participer, vous n’avez rien d’autre à faire que de vous créer un compte utilisateur sur MDN et à écrire (c’est un Wiki rappelons-le). Si vous ne savez pas par quel bout commencer ou si vous pensez que vous n’êtes pas à la auteur pour participer, j’organise tous les mercredi une soirée de découverte de MDN dans les bureaux de Mozilla à Paris. N’hésitez pas à venir, même si c’est juste par curiosité, il y a à boire et à manger . Plus d’information sur la soirée de mercredi prochain : https://mercredidoc.etherpad.mozilla.org/4

W3C

L’été dernier, le W3C à lancé les Community Groups et un des premiers à avoir été créé fut le Web Education Community Group. Ce groupe a été créé à l’initiative de Chris Mills de chez Opera. Chris a proposé de partager le Web Standards Curriculum d’Opera sous licence libre. Il a donc été mis sur un Wiki dédié au W3C et désormais, tout le monde peu participer à son enrichissement. De manière plus général, ce Community Group à pour vocation de créer et promouvoir du matériel pédagogique à destination des professeurs et formateurs qui enseignent la création de sites Web.

Si vous êtes formateur ou enseignant vous devriez sérieusement envisager de participer à ce groupe. Contrairement aux groupes de travail sur les spécifications, la participation aux Community Groups est gratuite. En ce qui me concerne, je prévois de participer à la traduction Française du Web Standards Curriculum. Si vous voulez aider à faire cette traduction, laisser un message sur la mailing-list du groupe, je vous recontacterai alors pour qu’on se coordonne

Conclusion

La documentation du Web ouvert est un espace à défricher. Si vous voulez bénéficier d’une documentation de qualité, pour vous ou pour les autres, c’est à vous d’agir. Soyons claire, documenter est un travail long et ingrat dont on ne retire les fruits que plusieurs mois ou année plus tard. Ceci étant, il n’y a pas de secret, les projets qui marchent ce sont les projets qui bénéficient d’une documentation de qualité. C’est également vraie du Web et de la création de site. Retenez cependant 2 choses : Quelque soit votre contribution, aussi petite soit-elle, il y aura toujours quelqu’un pour vous en remercier un jour ; Si vous devez documenter quelque chose, documentez ce dont vous avez besoin pour vous-même, d’autre auront un jour ou l’autre le même problème que vous… la documentation est sans doute le seul domaine d’activité ou une action purement égoïste est également totalement altruiste

SVG et HTML5 font bon ménage avec Firefox

Jeremie — Mon, 26 Jul 2010 15:00:00 +0200

Pour faire suite à mon précédent article sur SVG, je vous propose de partir explorer la révolution technique que représente la possibilité d'inclure du SVG directement dans un document HTML. Cette possibilité fait partie du futur standard HTML 5. C'est une fonctionnalité qui sera disponible dans Firefox 4 et Internet Explorer 9 dès leur sortie. Alors comment ça marche et qu'est-ce qu'on peut en faire ?

Les premiers seront les derniers

Une fois n'est pas coutume, on va commencer par la fin. Dans cette article je vais vous détailler comment j'ai réalisé la démo suivante qui permet de transformer n'importe quelle image ou vidéo disponible en ligne en un Puzzle jouable :

http://jeremie.patonnier.net/experiences/svg/inline/puzzle.html

Pour pouvoir voir et utiliser cette démonstration, vous avez besoin d'un navigateur qui supporte les fonctionnalités suivantes :

Le support de SVG directement au sein des documents HTML5
Le support de la balise canvas
Le support des filtres SVG
Le support des balises clipPath et foreignObject de la norme SVG
Le support de l'API localStorage et de JSON (ça, c'est un peu la cerise sur le gâteau)

Au moment où j'écris ces lignes, le seul navigateur qui réunisse ces conditions nativement est Firefox 4 beta 2. C'est avec lui que j'ai fait tous mes tests.

Vous pouvez aussi tester cette démo avec Firefox 3.6. Néanmoins, pour cela, vous devez activer le support du parser HTML5. C'est possible en vous rendant à l'adresse about:config, en y cherchant le paramètre html5.enable et en lui donnant la valeur true. Attention, il s'agit d'une version expérimentale du parser HTML5 qui n'est pas nécessairement très stable. Pensez à le désactiver une fois que vous aurez finit de jouer (Ceci dit, personnellement, je n'ai jamais eu de problème avec)

A terme, IE9 supportera toutes ces fonctionnalités. Malheureusement, la Plateform Preview 3 ne supporte pas correctement les filtres et comme je n'ai pas de machine tournant sous Windows 7, je n'ai pas pu tester pour voir ce que ça donnait en l'état.

Concernant Safari, Chrome et Opera, je n'ai pas entendu parler d'un support à court terme de SVG directement au sein des documents HTML5.

Mais pourquoi, John ? Pourquoi ?

Avant de détailler comment j'ai utilisé chacune des technologies mise en œuvre, voyons d'abord les raisons des choix techniques fait ici.

SVG directement utilisé dans un document HTML5
D'un coté, SVG va permettre de dessiner assez facilement les formes tarabiscotées des pièces du puzzle. D'un autre coté, HTML est plus facile à manipuler dès qu'il s'agit de mettre en œuvre une interface utilisateur. Le plus simple est donc d'inclure l'un dans l'autre. Techniquement parlant, il est plus facile d'intégrer du SVG dans HTML que l'inverse car on n'a (presque) pas à se soucier de la gestion des espaces de nom XML de SVG et de XHTML, le parser HTML5 s'en occupe tout seul.
Le support de la balise canvas
Prendre une source graphique pour en faire un puzzle requière de la manipuler, à minima pour la découper en morceau représentant les pièces. Dès lors qu'on parle de réaliser des opérations de cette nature, c'est canvas qui est le plus indiqué. En outre, cela permet également de traiter n'importe quelle source graphique supportée par le navigateur en entrée et d'en obtenir une sortie unifiée et manipulable de la même façon, peut importe qu'il s'agisse d'une image ou d'une vidéo (ou même d'une page web quelconque... mais je ne suis pas allé aussi loin ici).
Les filtres SVG
Les filtres SVG permettent d'appliquer très simplement des effets spéciaux sur n'importe quel élément SVG, et, dans le cas de Firefox, sur n'importe quel élément HTML. En outre, les filtres étant déclaratifs (matérialisé sous forme de balises SVG) il est très facile de les modifier et de les ajuster sans avoir à recourir à de complexes artifices de programmation.
Les balises SVG clipPath et foreignObject
La balise clipPath permet de créer des formes de découpes applicables à un objet. Par exemple, si vous voulez "percer un trou" dans une image, c'est exactement ce qu'il vous faut. Si vous vouliez faire la même chose avec canvas, ce serait possible, mais au prix d'un intense effort de programmation sans la souplesse de pouvoir changer simplement la forme de votre découpe. La balise foreignObject permet quand à elle d'embarquer n'importe quoi dans du SVG. En effet, si au sein d'un document HTML5 il est possible de mettre des îlots de SVG, ça ne veux pas dire que vous pouvez mettre du HTML n'importe comment au milieu des balises SVG.
L'API localStorage et JSON
Pas indispensable, mais c'est un moyen simple de pouvoir sauvegarder automatiquement la progression de votre Puzzle.

Bouger ou ne pas bouger, tel est la question

La première chose que j'ai faite c'est de prendre la source graphique qui servira de puzzle et de la redessiner dans un élément canvas. J'utilise cela comme une couche d'abstraction. En effet, une fois la source graphique convertis en un élément canvas, je n'ai plus à m'en soucier et quelques soit les opérations que je ferais par la suite, je me contenterai de manipuler un canvas. Accessoirement, l'opération est d'une trivialité absolue :

monCanvas.getContext('2d').drawImage(maSourceGraphique, 0, 0, maSourceGraphique.width, maSourceGraphique.height);

Néanmoins, ce n'est pas tout à fait suffisant pour gérer les vidéos. En effet, pour que l'élément canvas donne l'impression d'être animé comme la vidéo, il faut redessiner le canvas à intervalle régulière au fur est à mesure de la lecture de la vidéo. Pour cela, il suffit d'utiliser la fonction setInterval pour que la méthode drawImage soit appelée régulièrement.

Une fois que ce premier élément canvas est réalisé, chaque pièce du puzzle comprendra son propre élément canvas dans lequel on dessinera la portion du premier canvas qui lui correspond. Cette double utilisation de l'élément canvas est nécessaire pour 2 raisons :

Question de performance : Sean Christmann a montré dans un article sur l'utilisation des balises video et canvas que l'usage de deux canvas successifs pour réaliser des effets spéciaux sur les vidéos apporte un gain non négligeable vis à vis des performances.
Les limites de l'implémentation de SVG : En théorie, il serait possible de définir un élément canvas réutilisable au sein de SVG. Malheureusement les tests que j'ai pu réaliser mon montrés que ce n'était pas possible. Il faut donc créer un élément canvas distinct pour chacune des pièces.

One piece to rule them all

Chaque pièce du puzzle sera un élément svg à part entière créé sur le même modèle. Cela a plusieurs avantages :

Lors du déplacement des pièces, celles-ci pourront êtres déplacées sur l'intégralité de la surface du document HTML. Si elles avaient été une sous-partie d'un seul élément svg, le déplacement aurait été contraint à la zone visible du document SVG correspondant.
Toutes les pièces reposant sur la même arborescence DOM, il est possible de créer une arborescence générique qui sera clonée autant de fois que nécessaire pour créer toutes les pièces.

L'arborescence DOM d'une pièce de puzzle ressemble à ça :

<svg class="piece" width="155" height="155" x="0" y="0">
    <defs>
        <path id="p1_1" d="M10 10 h100 v26 a23,23 0 1,0 0,48 v26 h-25 a25,25 0 1,1 -50,0 h-25 Z"/>
    </defs>
    
    <clippath id="c1_1">
        <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
    </clippath>
    
    <g>
        <g clip-path="url(#c1_1)">
            <foreignobject x="10" y="10" width="125" height="125">
                <canvas width="125" height="125"></canvas>
            </foreignobject>

            <use xlink:href="http://jeremie.patonnier.net/post/2010/07/26/SVG-et-HTML5-font-bon-menage-avec-Firefox#p1_1"/>
        </g>
    </g>
</svg>

Quelques explications sur cette arborescence :

La balise path est encapsulée dans une balise defs. Grâce à cela la forme de la pièce est masquée et pourra être réutilisée à plusieurs endroit via la balise use. Elle est utilisée une première fois dans la balise clipPath pour définir la forme de découpe de la pièce qui sera appliquée à l'élément canvas. Elle est utilisée une deuxième fois après la balise foreignObject pour pouvoir dessiner un contour autour de la pièce tant que la pièce n'est pas à sa place définitive (pour donner un petit effet de lueur interne sans recourir à un filtre).
La balise foreignObject est entourée de deux balises g. La première (le parent direct de la balise foreignObject) permet d'appliquer la forme de découpe en même temps à l'élément canvas et à l'élément use. La deuxième balise g permet d'appliquer un éventuel filtre d'ombre porté. Si vous appliquez le filtre et la découpe sur le même élément g, le filtre sera appliqué avant la découpe. Si comme ici, vous voulez que le filtre s'applique à la forme résultante de la découpe, vous êtes contraint de sur-baliser votre code SVG pour forcer l'ordre d'application des effets.
Notez l'espace de nom "xlink" sur l'attribut href de la balise use. L'inclusion direct de SVG dans un document HTML5 simplifie drastiquement l'usage des espaces de nom XML mais ne nous en dispense pas totalement. En effet, même dans ce cas d'utilisation, SVG reste du XML et SVG utilisant le langage XLINK pour définir cet attribut href, il est obligatoire de bien spécifier cet espace de nom. Pour éviter d'avoir à faire des manipulations complexes à ce niveau, HTML5 fournis par défaut le raccourcis "xlink" pour gérer cet espace de nom.
Vous noterez que la taille de l'élément svg est plus grande que celle de l'élément canvas. C'est nécessaire car la zone visible de l'élément svg correspond à la portion de la source graphique représentée par l'élément canvas ET les éventuels filtres qui s'y appliqueront pour générer les ombres portées.
La valeur de l'attribut d de la balise path peut faire peur. Je ne vais pas vous détailler ici le pourquoi du comment (ça mériterai un article à part entière) mais sachez juste que c'est cette simple ligne qui fait qu'on a un tracé de pièce de puzzle (ici le coin haut-gauche). Si vous regardez la source du puzzle, vous verrez que j'ai regroupé toute l'intelligence de la construction de ce chemin dans une fonction dédiée. N'hésitez pas à vous amuser à la décortiquer.

T'as d'beaux yeux tu sais !

Pour rendre l'expérience de jeux un peu plus fun, on va rajouter quelques effet spéciaux et fonctionnalités qui vont permettre de lui donner un aspect un peu plus "fini".

Pimp my mouse

L'idée quand on créer des pièces de puzzle qu'on peut manipuler à la souris, c'est de pouvoir gérer la sélection de la pièce selon la forme de celle-ci. Le problème, c'est que si on ne fait rien, la souris régis à une zone rectangulaire, même sur les zones transparentes. Heureusement, de ce point de vue, SVG est bien fichue et sait gérer ça sans avoir à recourir à des dizaines de lignes de code. En fait, ça se résume à un peu de CSS :

svg{
    pointer-events : none;
}

svg canvas{
    pointer-events : auto;
}

La propriété pointer-events permet de définir comment la souris va réagir lors de ses interactions avec un élément. Ici on dit que la souris ne doit pas déclencher d'évènement lorsqu'elle interagit avec un élément svg mais par contre elle doit réagir normalement avec les éléments canvas présent dans nos éléments svg. Comme les éléments canvas sont découpés par un clipPath, seul les parties visibles de l'élément canvas réagiront à la souris (ce comportement est sans doute la principale différence entre les balises clipPath et mask de SVG). Notez que d'un point de vu Javascript, même si la souris ne renvoie pas d'évènement lorsqu'elle interagit avec les éléments svg, les évènements renvoyés par la souris sur l'élément canvas remontent normalement vers l'élément svg est peuvent être interceptés à ce niveau là. La propriété pointer-event ne fait que bloquer l'émission des évènements, elle ne bloque pas leur diffusion ni leur exploitation dans le DOM.

Ombrage, ô désespoirs !

Pour donner un peu de relief au puzzle, je me suis amusé à rajouter des ombres portés sur les pièces : une petite ombre porté quand une pièce est posée n'importe où, une grande ombre porté quand la pièce est "soulevée" et transportée et enfin, pas d'ombre du tout une fois que la pièce est à sa place définitive. Chacune des ombres (la petite est la grande) est définie à l'aide d'un filtre SVG distinct pour chacune. Par exemple, la petite ombre est définie comme cela :

<filter id="smallShadow" filterUnits="userSpaceOnUse">
    <feColorMatrix type="matrix" in="SourceAlpha" result="greySource"
                   values="0 0 0 0 0  0 0 0 0 0  0 0 0 0 0  .6 .6 .6 .6 0"/>

    <feGaussianBlur in="greySource" stdDeviation="2" result="flou"/>
    <feOffset in="flou" dx="1" dy="1" result="Ombre"/>
                
    <feMerge>
        <feMergeNode in="Ombre"/>
        <feMergeNode in="SourceGraphic"/>
    </feMerge>
</filter>

Pour faire simple, ce filtre prend la source alpha (la transparence) de l'élément auquel va s'appliquer le filtre, lui applique une matrice de couleur (feColorMatrix) pour quelle soit noir et légèrement transparente, va la flouter (feGaussianBlur), la décaler (feOffset) vers le bas et la droite et va recombiner le tout (feMerge, feMergeNode) avec la source graphique de l'élément. Je ne vous détail pas plus précisément que ça l'usage des primitives de filtres car cela mériterai un article à lui seul, mais c'est tout ça qui fait qu'on a une ombre de forme arbitraire (contrairement à la propriété CSS box-shadow qui ne produit que des ombres rectangulaires... éventuellement avec des coins arrondis, mais c'est tout).

L'application des filtres se fait très facilement directement via CSS

.shadow > g{
    filter:url(#smallShadow);
}

#drag.shadow > g{
    filter:url(#bigShadow);
}

.lock.shadow > g{
    filter:none;
}

Vous n'avez alors plus qu'à jouer sur les classes est les ID de vos éléments avec Javascript pour appliquer ou non un filtre. Notez que Firefox permet également d'appliquer un filtre SVG à n'importe quel élément HTML. C'est ce que j'utilise pour griser l'aide du puzzle qui n'est qu'un simple élément canvas affiché sur l'aire de jeu auquel j'applique un filtre de matrice de couleur.

Allo ! Caroline ! C'est Roger.

Dernière fonctionnalité, la sauvegarde automatique du puzzle en arrière plan. A chaque fois que vous déplacez une pièce, il y a un appel à l'API localStorage de HTML5 pour enregistrer la position de la pièce. De cette manière, si pour une raison ou une autre vous devez interrompre votre partie, vous pouvez la reprendre plus tard exactement là ou vous vous étiez arrêté.

Pour simplifier les traitements, je stocke toutes les données représentant l'état du puzzle dans un objet spécifique. L'API localStorage stocke les données sous la forme clé/valeur. La norme est assez flou sur le type de donnée qui peuvent être stockées mais Firefox n'accepte que les chaines de caractère comme valeur à stocker donc, pour enregistrer mon objet, je le transforme en chaine en utilisant le support natif de JSON tel que définie dans la norme ECMAScript 5 :

var data = JSON.stringify(this.savedData);

window.localStorage.setItem('currentPuzzle', data);

La récupération des données est tout aussi simple :

var data = window.localStorage.getItem('currentPuzzle');

data = JSON.parse(data);

Parfois, c'est le vil coyote qui gagne

Lorsqu'on manipule des technologies nouvellement implémentées dans des navigateurs qui en sont encore au stade des versions Alpha/Beta, il n'est pas rare que l'on soit confronté à des problèmes. Dans ce cas précis, j'ai travaillé avec Minefield qui est la version non-stable de Firefox (et qui représente au moment ou j'écris ces lignes la version de développement du future Firefox 4) et j'ai été confronté à trois types de problèmes différents.

Is there a Road Runner over here?

Les développeurs de Firefox 4 travaillent actuellement comme des malades sur les performances du navigateur et si l'on peut déjà percevoir une amélioration globale des performances, le travail n'est pas terminé et de nombreuses améliorations sont encore attendues dans les semaines à venir. Malheureusement, tout n'est pas parfait...

Dans le cas qui nous occupe ici, le principal problème de performance provient de l'usage des filtres SVG. Les filtres sont actuellement ultra consommateur de ressources pour pouvoir être calculés. Ils sont tellement gourmands que j'ai très vite mis la possibilité de désactiver les ombres portées sur les pièces. En effet, si vous activez les ombres portées et que vous construisez un puzzle basé sur une vidéo, la lecture de celle-ci sera saccadée et le déplacement des pièces ne sera pas fluide. Le problème sera d'autant plus perceptible si vous créez un puzzle avec de nombreuses pièces (plus de 50) car au problème des filtres vient s'ajouter l'augmentation du nombre de nœuds DOM à gérer ce qui peut très vite plomber l'utilisation du jeu (en particulier lorsque vous déplacez les pièces).

Autre point qui peut vite affecter les performances, l'utilisation de l'API localStorage. L'accès en lecture et en écriture via cette API est prohibitif au niveau performance (un peu moins de 100 milliseconde pour une simple opération d'écriture de chaine de caractère sur ma machine... iiirk !). Ainsi si j'avais voulut enregistrer séparément la position de chaque pièces, il aurait fallut près de 10 secondes pour enregistrer l'état d'un puzzle de 100 pièces ! Soyez donc très prudent si vous utilisez cette API car sinon cela peut vite se voir. Si vous prévoyez de faire beaucoup d'opération via celle-ci, je ne saurait trop vous conseiller soit de les traiter en tache de fond asynchrone via l'utilisation de l'API Web Workers, soit de travailler avec un objet contenant vos données que vous transformerez en chaine JSON avant de l'enregistrer intégralement en une seule fois (c'est cette dernière stratégie que j'ai choisie). Si vous n'y faite pas attention, vous pouvez vous retrouver avec un gel complet de votre page !

Robert ! Il y a un cafard dans la machine.

L'intérêt de réaliser ce genre de démo avec une version de développement d'un navigateur, c'est que ça permet de découvrir des bugs qu'il est possible de faire corriger avant la sortie de la version final du navigateur. Les bugs les plus faciles à corriger sont liés à l'implémentation de la balise SVG foreignObject :

Bug 576986 : la balise foreignObject ne respectait pas les règles d'application des évènements de la souris lorsqu'on lui appliquait une forme de découpe. La correction a été apportée dans les heures qui ont suivit. Waow !
Bug 578309 : La balise foreignObject redéfinissait son propre espace de coordonnées, comme si on y avait appliquée une transformation. La encore, il n'aura fallut que quelques jours pour que ce soit corrigé. J'en profite ici pour adresser un grand merci à Robert Longson qui a travaillé sur ces bugs en particulier et qui fait un énorme travail en ce qui concerne le support de SVG dans Firefox.

Mais il y a aussi quelques bugs plus durs qui vont sans doute être assez délicat à résoudre :

Bug 577824 : Quand on attache un élément HTML à l'arbre DOM du document via Javascript et qu'un filtre s'applique sur cet élément, l'élément n'est pas affiché.
Bug 577464 : Celui là, c'est le plus bizarre de tous, et sans doute le plus difficile à résoudre. Dans certain cas de figure, le rendu des éléments auquel est appliquée une forme de découpe n'est pas correctement réalisé. Il est tellement difficile de produire un cas d'utilisation unitaire que son simple diagnostique risque de prendre du temps. Une des pistes actuellement exploré serait un bug lié à la bibliothèque graphique Cairo qui est utilisée par Firefox pour rendre les éléments visuels.

Allo ! Tonton ? Pourquoi tu tousses ?

Après, au delà des éventuels problèmes d'implémentation, il y a aussi les problèmes liés aux spécifications elles-mêmes. Les spécifications qui tournent autour de HTML5 ne sont pas encore finalisées ou pas forcément adapté à certains cas d'utilisation et l'on tombe parfois sur des perles qui peuvent plonger un web designer dans des affres d'incompréhension. J'en ai découvert deux dans ce gout là. Une dans la spécification de l'API Canvas 2D et une dans la spécification de SVG 1.1.

Canvas pas aller ça monsieur.

En l'état de la spécification, avec la méthode drawImage de canvas, il est possible de dessiner soit une image, soit une vidéo. Quand vous dessinez une image, pas de problème, vous dessinez l'image elle-même. Quand vous dessinez une vidéo, ce qui est dessiné, c'est l'image qui est lut par le lecteur vidéo au moment ou on appel la fonction de dessin. Maintenant, que ce passe-t-il si vous voulez dessiner une image animé (aGIF, APNG, MNG, SVG, etc.) ? Moi, assez naïvement, je me suis dit que ça allait dessiner l'image courante de l'animation au moment ou on appel la fonction de dessin... bref que ça allait ce comporter comme avec une vidéo et c'est d'ailleurs comme cela que se comporte Firefox 3.6. Mais que nenni jeune Padawan ! La spécification dit que dans le cas d'une image animé, ce qui est dessiné, c'est la première image de l'animation et puis c'est tout !

http://www.w3.org/TR/2dcontext/#images

When the drawImage() method is passed an animated image as its image argument, the user agent must use the poster frame of the animation, or, if there is no poster frame, the first frame of the animation.

Et chez Mozilla, ils se sont dit que ce serai une bonne idée de suivre la spécification dans Firefox 4. Résultat des courses, j'ai ouvert un bug en pensant à une régression, mais non, c'est juste qu'ils on fait en sorte d'être respectueux de la spécification.

Alors, là, j'ai envie de dire : "Bravo, c'est bien". Mais d'un autre coté, maintenant, on fait comment pour accéder aux autres images qui composent une image animée ? On est typiquement dans un cas ou la spécification est difficile à comprendre et elle reflète sans doute les capacités des fabriquant de navigateur à gérer ce cas d'utilisation. Mozilla sait comment gérer les images animées dans ce cas de figure, mais se bride du fait de la faiblesse de la spécification sur ce point. C'est dommage.

La spécification n'est pas encore définitive et si vous pensez que ce cas d'utilisation est important, faite le savoir. Pour cela, vous pouvez soit faire du lobbying auprès du HTML Worging Group (bon courage !) soit auprès des fabricants de navigateur qui sont directement parti prenante. La discussion est ouverte chez Mozilla et si, par exemple, vous prenez simplement le temps de voter pour le bug que j'ai ouvert, peut-être que Mozilla considèrera qu'il y a matière à pousser le sujet.

SVG, ou l'art de Se Vautrer la Gueule ?

A la base, j'ai fait une mauvaise interprétation de la spécification SVG alors que je voulais réutiliser un élément foreigObject avec la balise use. J'ai naïvement crus que n'importe quelle enfant légitime de la balise g pouvait être réutilisé via la balise use. Malheureusement, ce n'est pas le cas. La balise use ne peut être utilisée que pour dupliquer des éléments explicitement graphique (ce qui n'est pas le cas de foreignObject) ou certains conteneurs (g, symbol et svg). Néanmoins, comme g est un élément valide pour use, il suffit d'envelopper un élément foreignObject avec un élément g est le tour et joué.

Et là de se poser la question : "Mais pourquoi la norme ne permet pas d'utiliser directement tous les enfants légitimes de g ? Pourquoi faut-il rajouter une balise supplémentaire qui a le gout et l'odeur de l'inutile ?". Bien évidement, il s'agit de questions de web designer, pas d'implémenteur. En effet, il y a fort à parier que lorsque la norme a commencé à être écrite (il y a plus de 10 ans, rappelons-le), les développeurs en charge de sa mise en œuvre ont du rencontrer un problème à ce niveau et faire un arbitrage dans ce sens. Ou bien il y a eu un débat philosophique quelconque a propos de ce qu'est la balise use et personne n'a réussie à challenger cette vision. Franchement, je n'en sais rien mais avec le recul que l'on a désormais, la question aurait le mérite d'être à nouveau posée.

De manière général, ce genre de collision malheureuse entre SVG et HTML5 risque de se représenter ailleurs (essayez de contrôler à l'aide de Javascript une balise HTML video que vous avez cloné via la balise SVG use... vous ne pouvez pas !). En effet, on a d'un coté une norme vieillissante (SVG) et de l'autre une norme toute neuve en construction (HTML5). A bien des égards, SVG a été conçus pour vivre dans un univers statique. A l'inverse, HTML5 redéfinis énormément d'éléments dynamiques au travers de nouvelles API Javascript. De ce point de vue, je ne serais pas surpris que HTML5 redonne un coup de fouet à SVG et il n'est pas exclus que dans les années a venir on voit arriver une norme SVG 2 pour résoudre tous ces nouveaux cas d'utilisation... mais bon, ne soyez pas trop pressé. C'est aussi ça qui fait que Flash à encore de beau jours devant lui.

Le mot de la fin (des haricots)

Voila, je viens de vous arroser avec un article copieusement long et en même temps extrêmement raccourcis. Si vous voulez comprendre plus précisément comme marche quoi, je vous encourage à regarder le code source que j'ai essayé de commenter le plus possible. Ce qu'il faut retenir, c'est que le support de SVG dans HTML est encore quelque chose de très expérimental mais cela donne déjà une bonne idée de ce que peut faire chaque technologie respective et ce que l'on gagne à les mixer.

Si vous voulez aller plus loin, n'hésitez pas à lire les spécifications. Elles peuvent parfois s'avérer très utile. La spécification SVG par exemple comporte de nombreux exemples de code très utile à la compréhension. D'autres ressources très utile également sont les documentations techniques des fabricants de navigateurs. En particulier dans le cas de cette démo, le Mozilla Developper Center, mais aussi MSDN, Opera Dev et le wiki de Webkit.

Quoi qu'il en soit, expérimentez vous même et faite vous votre propre idée. Ces technologies sont toutes assez nouvelles, les implémentations évoluent constamment et le processus de standardisation n'est pas linéaire...mais amusez vous, c'est comme ça que vous apprendrez de nouvelles choses

La spécification SVG : http://www.w3.org/TR/SVG/
La spécification HTML 5 : http://www.w3.org/TR/html5/
- L'API Canvas 2D : http://www.w3.org/TR/2dcontext/
- L'API Storage : http://www.w3.org/TR/webstorage/
- L'API Web Workers : http://www.w3.org/TR/workers/
ECMAScript 5 (PDF) : http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf

Devenir beta-testeur de Firefox sous Ubuntu/Linux

Jeremie — Fri, 19 Mar 2010 09:30:00 +0100

Suite à un article de Pascal Chevrez, qui soulignait qu'il n'y avait paradoxalement pas assez de beta-testeur de Firefox pour Linux, j'ai eu envie de me pencher sur la question de l'installation des beta de Firefox sous Linux (enfin sous ma Ubuntu surtout ). En temps que noob de Linux, ça a été assez intéressant de voir ça.

L'idée de cette article est de fournir un "How-to" pour devenir beta-testeur de Firefox sous Ubuntu (mais ça marche aussi pour les utilisateurs de Windows et Mac OSX, hein !) tout en étant volontairement orienté pour un public peu technique (j'assume le fait que vous sachiez tout de même ce qu'est un répertoire et que vous sachiez au moins ouvrir une fenêtre de ligne de commande, même si vous ne savez pas trop quoi en faire).

Petit préambule technique à destination des utilisateurs non techniques : le raccourci ~/ fait référence à votre répertoire de travail personnel. Le chemin d'accès "long" vers ce répertoire sous Ubuntu est /home/nom-d-utilisateur/.

Télécharger Firefox

La première chose à faire, c'est de télécharger la version de Firefox que vous voulez utiliser. Pour cela, vous trouverez tous ce qu'il vous faut sur les sites de Mozilla. Néanmoins, plusieurs choix s'offrent à vous selon ce à quoi vous vous intéressez :

Vous voulez la dernière version stable de Firefox, rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all.html
Vous voulez tester la dernière beta "public", rendez-vous ici :
http://www.mozilla.com/en-US/firefox/all-beta.html (actif uniquement en période de beta-test des versions majeurs, ce qui n'est pas le cas au moment ou j'écris ces lignes)
Vous êtes un aventurier et vous voulez tester une "nightly build", c'est ici que ça ce passe :
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ (notez qu'il s'agit de l'accès direct au "trunk", mais si vous remontez l'arborescence d'un niveau, vous pouvez accéder à d'autres branches de développements... ah ben oui, là, vous êtes vraiment en mode aventure hein)

Attention pour les utilisateur de Linux 64 bits. En effet, Mozilla ne fournis des versions compilées que pour les systèmes 32 bits. Ça ne vous empêchera pas d'utiliser Firefox, mais cela a deux conséquences : D'une part la stabilité de Firefox n'est pas garantis et d'autre part les plugins ne seront pas utilisables (en tout cas, pas facilement).

Vous pouvez également utiliser les dépôts PPA pour faire l'installation (ce qui vous permettra de trouver des compilations 64 bits !)... je ne vais pas trop m'appesantir la dessus vu que je fait une allergie complète à ce système (j'y comprend rien et je n'ai pas envie d'y comprendre quoi que ce soit... je sais, c'est génial et je ne sais pas de quoi je me prive, mais ça me gonfle et je trouve ça beaucoup trop nerd pour moi)

Installer Firefox

L'installation en tant que tel est assez trivial : décompactez l'archive que vous avez téléchargée, et voila, c'est installé. Bon, ok, soyons un peu sérieux. La version de Firefox que vous avez téléchargée est effectivement directement exécutable (sous Ubuntu, vous n'avez aucune question de dépendance à gérer, c'est assez confortable mais je ne sais pas si c'est aussi simple avec d'autres distributions) mais elle est loin d'être intégré au système.

Je ne vais pas vous harasser d'une explication fastidieuse alors que tout est extrêmement bien documenté en français ici : http://doc.ubuntu-fr.org/firefox

Ça y est ? Vous avez installé une autre version de Firefox ? Vous êtes près à double-cliquer sur l'icône de lancement ? Alors là, vous arrêtez tout, vous respirez un grand coup et vous vous posez la question de votre profil utilisateur !

On ne le dira jamais assez, mais avant toute chose, sauvegardez votre profil Firefox habituel ! J'insiste, un accident malheureux est si vite arrivé.

Sous Ubuntu 9.10, tous vos profils utilisateur se trouve dans ~/.mozilla/firefox

C'est particulièrement critique si vous voulez jouer le mode aventure extrême avec les nightly de Firefox. De manière général, je vous invite à vous créer plusieurs profils dédiés à vos tests. Pour créer de nouveau profil ou pour choisir un profil spécifique, il suffit de lacer Firefox avec l'option -p. Vous pouvez rajouter cette options dans les lanceurs d'application d'Ubuntu (clique droit, "propriété") ou bien lancer Firefox depuis la ligne de commande :

firefox -p

Selon les tests que vous voulez réaliser, il peut aussi être utile de créer un profil temporaire pour la seul durée de ces tests. Pascal documente très bien la façon de faire cela sur son site.

De même, vous pouvez avoir besoin de lancer plusieurs instances de Firefox en parallèle (par exemple si vous avez une version stable pour votre navigation quotidienne et que vous voulez réaliser un test sur une version instable). Pour cela, il vous suffit de lancer Firefox avec l'option --no-remote :

firefox --no-remote

La phase de tests

Voila vous êtes près, vous pouvez commencer vos tests. Soyons bien claire, vous êtes libre de tester ce que vous voulez : Le support des standards du Web, les performances du navigateur, la qualité de l'interface utilisateur, la gestion des extensions... c'est vous qui voyez ce qui vous intéresse. Personnellement, lors des phases de beta-test publique, je me contente de surfer "comme d'habitude" et de relever les éventuels problèmes que je rencontre.

Automatisez vos tests

Quoi qu'il en soit, dans une démarche de beta-tests (ou pire, d'alpha-tests), vous risquez d'être amener à reproduire plusieurs fois les mêmes actions. En effet, que ce soit pour vous assurer qu'il n'y a pas de régression d'une version à l'autre ou bien qu'une dysfonction a été corrigée, il va vous falloir refaire plusieurs fois les mêmes actions. En soit, c'est déjà quelque chose de fastidieux, mais en plus, il peut se passer plusieurs mois entre la réalisation de vos différents tests (ça peut prendre du temps de corriger un bug) et se souvenir de ce qu'on a fait il y a plusieurs jours/semaines/mois est loin d'être évident. Il est donc vivement conseillé d'automatiser vos tests pour éviter d'avoir à vous prendre la tête avec ça. Cette phase d'automatisation peut également vous faciliter la vie lorsque vous aurez des bugs à signaler (j'y reviens plus loin).

Pour réaliser cette automatisation, vous avez le choix des armes. cela dépendra de vos connaissances techniques et de vos besoins de test. Ça peut aller de la réalisation d'une page HTML qui recouvre un certain nombre de cas de test à la réalisation d'un script bash complet. Il existe néanmoins une extensions de Firefox qui peut vous être utile : iMacros pour Firefox. Cette extension permet d'enregistrer et rejouer toutes les taches que vous pouvez faire avec Firefox (pas seulement ce que vous faite dans un page web mais vraiment tout, y compris les interactions avec l'interface utilisateur).

L'équipe Assurance Qualité de Mozilla

Si vous êtes vraiment motivé, vous pouvez également aider (pour ne pas dire rejoindre ) l'équipe d'assurance qualité de Mozilla. Elle fédère l'effort de test des produits Mozilla. Elle propose un certains nombre d'outils, organise des évènements spécifiques et met en œuvre un catalogue de cas de tests. Vous trouverez plus d'informations sur le site de Mozilla dédié à l'Assurance Qualité (en anglais).

Cette équipe propose même une extension spécifique pour vous accompagner dans vos démarches de test : le Mozilla QA Companion.

Signaler un bug

Ça y est, là vous êtes chaud. Vous utilisez votre Firefox tout nouveau tout beau, et là... Paf ! C'est le drame ! Vous êtes confronté à un bug. Comme vous êtes quelqu'un de bien, vous allez le signaler à Mozilla. Je ne vais pas vous le cacher, en général, c'est là que ça se corse. Ça se corse parce que le reporting de bug se fait exclusivement en anglais. Là, il n'y a pas vraiment le choix, l'anglais étant la langue partagée par quasiment tous les développeurs de la planète, c'est ce qui est le plus facile pour tout le monde... mais pas forcément pour vous. Détendez vous quand même, il n'y a pas besoin d'être bac+5 d'anglais. Au pire du pire, si vraiment c'est un obstacle insurmontable pour vous, vous pouvez gentiment aller en discuter avec les différentes communautés Mozilla françaises. Que ce soit les traducteurs de FrenchMozilla (D'ailleurs, si votre bug est un bug de traduction, c'est eux qu'il faut aller voir) ou les administrateurs de GeckoZone, si vous leur demandez poliment de l'aide, vous ne devriez pas être bombardé de cailloux, au contraire

Pour signaler un bug, ça se passe sur le site Bugzilla de Mozilla. Mais ne nous précipitons pas, faisons cela dans les règles de l'art (il sera bien temps de faire ça n'importe comment le moment venu ).

Vérifier si ce bug n'a pas déjà été signalé

Alors avant de s'énerver, la première chose à faire est de vérifier si le bug que vous avez repéré n'a pas déjà été signalé par quelqu'un d'autre. En effet, ce n'est pas la peine de signaler un bug qui a déjà été pris en charge par les développeurs et qui sera donc corrigé dans la prochaine version stable/beta/nightly. De même, il est plus constructif de compléter un bug existant que de faire un doublon.

Bon, ne nous le cachons pas, l'interface de bugzilla est cauchemardesque d'un point de vue ergonomique. C'est un outils fait pour les développeurs de Mozilla. Si vous êtes un contributeur occasionnel, abandonnez ici tout espoirs ! Faire une recherche de bug si vous n'avez pas l'habitude des arcanes de l'organisation des développements chez mozilla, c'est l'horreur. Alors si malgré vos effort vous ouvrez un bug qui en doublonne un autre, ne vous inquiétez pas, Mozilla dispose d'une équipe de triage des bugs qui assure grave ! Ne soyez donc pas surpris si vous voyez que votre bug est marqué comme étant un doublon, ça vous arrivera régulièrement, surtout au début

Qualifier votre bug

Maintenant que vous savez (ou croyez savoir, ou n'avez pas envie de savoir) que personne n'a déjà signalé votre bug, vous pouvez vous lancer dans votre rapport de bug. Oui, mais pas de précipitation. Avant de vous jeter sur Bugzilla, prenez le temps de préparer un rapport complet. En effet, il n'y a rien de plus inutile qu'un rapport de bug sous la forme de "Y'a tel machin qui marche pas". En effet, les personnes qui vont traiter le bug ne sont pas à votre place, il faut donc leur donner un minimum de contexte pour qu'ils puissent travailler efficacement.

Un rapport de bug exploitable contiens un certain nombre d'informations clés :

Commencez par dire quel est la version de Firefox que vous utilisez et votre système d'exploitation. Le plus simple est de coller purement et simplement la "User Agent String" de votre navigateur dans votre rapport de bug. Vous la trouverez en vous rendant dans le menu : Aide > A propos de Mozilla Firefox
Décrivez toutes les étapes qui permettent de reproduire le bug (idéalement sous forme d'une liste ordonnée). Si vous avez pensé à automatiser vos tests, vous pouvez en plus joindre le script d'automatisation, les développeurs pourront alors reproduire assez simplement le problème (et donc potentiellement traiter votre bug plus vite ). Si ce bug ne peut pas être reproduit systématiquement, précisez le bien et essayez de qualifier sa fréquence d'apparition.
Précisez le résultat normalement attendu par votre test et le résultat réel constaté de votre test. Encore une fois plus vous serez précis sur ces deux points, plus le bug sera facile à identifier et à corriger.

Ouvrir un bug

Bon, ben nous y voila, c'est le grand moment. Si ce n'est déjà fait, commencez par vous ouvrir un compte sur Bugzilla et faites l'effort de survoler le guide de bonne conduite de Bugzilla (c'est court et pas prise de tête, mais on y retrouve quelque points important pour une bonne vie en communauté). Une fois identifié, vous n'avez plus qu'à remplir votre rapport de bug et voila... vous faites désormais partis de la grande famille des contributeurs au projet Mozilla. Bravo

Conclusion

Comme vous pouvez le voir, il n'y a rien de vraiment compliqué. Il n'est même pas nécessaire que vous ayez des connaissances techniques particulières. C'est tout l'intérêt du mode de développement ouvert de Mozilla : tout le monde peu participer dans la mesure de ses moyens, connaissances, disponibilités. En fait, le seul problème que j'ai avec Mozilla, c'est la difficulté à trouver comment participer. En effet, Mozilla communique assez mal sur comment il est possible de participer. Mozilla dispose de tout un tas d'outils et il est parfois difficile de savoir ou commencer dans la profusion des possibilité qui sont offerte. En dehors du développement, il existe des tas d'autres choses à faire avec Mozilla : du marketing, de la R&D, de l'ergonomie, et bien plus. C'est parce qu'il est difficile de savoir ou commencer que j'ai écris cet article. J'essayerai de vous parler de toutes ces autre opportunités pour les non-développeur au seins du projet Mozilla car ce n'est pas toujours claire pour s'y retrouver. N'hésitez pas à vous renseigner sur les forums de discutions francophone, les gens sont sympas et n'hésiteront pas à vous aider à démarrer. Bienvenu !