Chez Jérémie

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 (^_^)

Des kiwis sans pépins

Jeremie — Sun, 06 May 2012 22:52:00 +0200

J’ai eu la chance de participer à la Kiwi Party organisé le 4 mai 2012 par l’agence Alsacréations. En toute simplicité, j’ai envie de dire : « c’était vachement bien ! ».

Avant toute chose, un grand bravo au staff qui a assuré grave pour faire de cette journée un franche réussite et un remerciement tout spécial à Mme. Goetter qui a passé 15 jours en cuisine pour nous offrir un goutaÿ™ épique

En suite, un grand merci également a tous ceux qui sont venu à Strasbourg pour assister à l’événement. votre enthousiasme, votre plaisir manifeste à être là ont fait de ce moment un moment exceptionnel.

Au niveau des conférences, nous avons eu droit à un panel de très bon orateurs avec des sujets allant du référencement au développement en passant par l’accessibilité et la conception. Une partie des conférences ayant eu lieu en parallèle les unes des autres, je n’ai pas pu voir tout ce que je voulais, mais heureusement, elles ont toutes été filmées. Vivement que ces vidéos soient diffusées car j’ai hâte de voir les conférences de Vincent de Oliveira sur les effets graphiques avancés et celle de Frédéric Kayser sur la gestion des images pour le Web.

Parmi celles que j’ai pu voir, deux ont plus particulièrement retenu mon attention :

« Le développement HTML5 au sein de Windows 8 » présenté par David Rousset. Il s’est agit d’une excellente introduction aux principes de développement d’applications HTML5 pour Windows 8. Ce fut vraiment l’occasion de voir à qu’elle point Microsoft a décidé de jouer le jeu des standards du Web. Et même si toute la couche d’accès au système (appelée WindowsRT) reste encore une API JavaScript propriétaire, je suis persuadé que le développement des Web API standards permettra à Microsoft de d’offrir toujours plus d’interopérabilité.
« Conquérir l’internet des objets avec les technologies web » présenté par Steren Giannini. Si j’ai malheureusement raté le début de la conférence, ce que j’en ai vu m’a passionné. En particulier, il est vraiment intéressant de voir à quel point le Web sort de plus en plus des navigateurs traditionnels pour aller se nicher là ou on ne l’attend pas. C’est également très instructif de réaliser à quel point la diversité des supports rend toute forme de prédiction sur l’usage, l’interactivité ou le rendu visuel complètement hasardeuse.

De mon coté, j’ai eu la lourde tache de clôturer la journée en proposant une introduction aux transitions et animations CSS3. Je suis bien sur très mal placé pour juger ma performance, mais le nombre de retours extrêmement positifs que l’on m’a fait laisse penser que ça s’est plutôt bien passé (J’ai même eu droit à une tape sur l’épaule et à un « super » de la part de Karl Dubost… je croie que désormais, je peux mourir l’esprit en paix :P). Les slides de cette présentation sont bien sur disponible en ligne :

Voila encore merci à tous. Vivement l’année prochaine

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

Lier CSS à Javascript : une mauvaise idée

Jeremie — Mon, 13 Feb 2012 09:30:00 +0100

J’ai récemment lancé un twitt qui a généré un nombre important et plutôt surprenant de réactions. Vous n’êtes pas sans savoir qu’actuellement, l’utilisation des préfixes vendeur en CSS est une source de grande tension. Parmi toutes les solutions qui existent pour essayer de limiter l’impact de l’usage de ces préfixes, le script -prefix-free de Lea Verou est une solution actuellement très en vogue… mais dont je déconseille très fortement l’usage.

Soyons clair, je n’ai pas l’intention d’alimenter le débat sur l’opportunité ou non d’utiliser les préfixes vendeur. Si vous les utilisez, utilisez les bien, utilisez toutes les variantes de tous les vendeurs. C’est tout.

Non, mon sujet ici, ce sont tous ces scripts Javascript qui vont conditionner l’usage de CSS lorsqu’ils sont utilisés dans un navigateur Web. -prefix-free bien sûr, mais également less.js, respond.js, cssFX, mediatizr, WebFont loader, etc. Je n’ai pas ici la prétention de vous convaincre de ne pas les utiliser. D’une part parce que vous faites bien ce que vous voulez (c’est aussi ça le Web) et d’autre part parce qu’il m’arrive même à moi de m’en servir et ce serait quand même assez gonflé de ma part de vous dire « faites ce que je dit, pas ce que je fait »

L’idée, c’est plutôt de vous détailler les risques auxquels vous vous exposez pour que vous puissiez ensuite faire votre choix en votre âme et conscience.

Performance

L’usage de ces scripts induit un certain nombre de biais dans les performances de vos sites. Souvent, les scripts comme -prefix-free sont appréciés car « ils permettent de réduire le poids des CSS ». Ce qui est vrai mais au prix du poids du script lui-même (le jeu en vaut-il la chandelle) et de requêtes HTTP supplémentaires (vous êtes sûr de n’avoir aucun problème de latence ?).

Au delà de ces points largement discutables il y a tout de même quelques autres éléments à considérer :

Le rendu complet de votre site est suspendu au chargement de vos scripts. Le temps de rendu peut donc être altéré si vous êtes sur des connexions de mauvaise qualité comme du EDGE en réseau mobile. Cela peut se constater de manière bénigne avec la présence d’un léger FOUC ou bien plus gravement en cas de problème de chargement du script ce qui peut complètement casser votre design.
Le rendu devient également dépendant des performances globales d’exécution de vos scripts. Avec un seul petit script qui va agir sur une petite feuille de style, vous ne verrez jamais de problème. Mais que va-t-il se passer avec plusieurs centaines de Ko de scripts et de feuilles de style ? Par exemple, un script comme -prefix-free est un script linéaire : plus la feuille de style sera grosse, plus il prendra de temps pour s’exécuter car il l’examine entièrement. Que se passera-t-il alors si ce script est ralenti ou gêné ou traité après tous les autres scripts de la page (ce qui inclut vos scripts, mais également ceux que vous ne connaissez pas et qui sont utilisés par les extensions ou les bookmarklets de l’utilisateur) ?

Bref, utiliser ce genre de script vous fait consommer des ressources que vous pourriez utiliser pour des choses plus importantes que du style avec tout les effets de bords potentiels que je viens de vous énumérer.

Maintenabilité

Un des principaux avantages mis en avant pour ces scripts, c’est la simplification de la maintenance. Raphael Goetter l’a d’ailleurs bien expliqué sur son blogue. Là, je crois qu’il faut s’y arrêter quelques minutes.

Chaque script apporte son lot d’avantages, mais il apporte également son lot de problèmes. Aucun script n’étant parfait du premier coup, vous allez également devoir assurer sa maintenance. Il vous faudra le mettre à jour en fonction de ses propres évolutions ou prendre le risque de vous retrouver coincé avec un outil qui ne vous rendra plus les services que vous attendiez.

Il faut prendre en considération que ces scripts sont intimement liés à vos feuilles de style car plus vous les voudrez génériques plus ils seront volumineux et potentiellement bugués. Concrètement, cela veut dire qu’à chaque fois que vous allez mettre vos feuilles de style à jour, vous allez devoir vous assurer que le script fait bien son travail. Cela signifie plus de tests et en cas d’erreur, plus de temps pour débuguer car vous aurez alors deux sources d’erreurs potentielles.

C’est particulièrement vrai avec un script du type de -prefix-free. Pour vous épargner de saisir quelques lignes de CSS en plus, vous vous rajoutez un risque projet non-négligeable. Tant que ça marchera, oui, vous gagnerez du temps. Par contre, à la seconde ou vous allez rencontrer un problème, vous allez perdre beaucoup de temps. Sera-ce plus ou moins que le temps gagné ? Difficile à dire car cela dépendra énormément de votre connaissance des technologies en jeu ainsi que des outils que vous utilisez. Mais encore une fois, pourquoi prendre un risque là ou vous n’en aviez pas avant ?

Et l’utilisateur dans tout ça ?

Alors malgré tout ça, faut-il vraiment renoncer à utiliser tous ces scripts pourtant bien pratiques ? Il n’y a pas de réponse simple à ça. Pour être franc, il n’y a jamais de réponse simple en matière d’utilisation des technologies Web. Les contextes projets sont tous différents et certains justifient pleinement l’usage de ces scripts.

Néanmoins, avant de les utiliser, je vous invite à vous poser les questions suivantes :

Le script que je vais utiliser me permet-il de compenser un manque de compétences (techniques ou organisationnelles) de l’équipe projet ?
Dans l’affirmative, cela reviens à essayer de mettre un pansement sur une plaie ouverte. Si la plaie est petite, cela permettra de patienter le temps que l’équipe se forme aux techniques requises. Si la plaie est profonde, ça ne fera que retarder le moment où il faudra prendre des mesures drastiques (et donc coûteuses) pour éviter l’infection.
Préférez un bon plan de formation à moyen terme et à court terme, prévoyez l’intervention d’un développeur sénior capable d’épauler l’équipe. Si vous travaillez seul, faites l’effort de vous former ou changez de métier.
Le script que je vais utiliser est-il là uniquement pour mon propre confort ?
Si c’est le cas, sachez que j’ai alors assez peu de considération pour vous (je sais, ça vous fait un belle jambe, mais au moins c’est dit). Ce genre d’attitude égoïste est exactement ce qui fait que le Web ouvert, standard et interopérable s’étiole. Si vous pouvez faire la même chose sans utiliser de script, faites le. Vous rendrez service à tout le monde en commençant par vous-même
Le script que je vais utiliser me permet-il d’améliorer l’expérience utilisateur ?
Là, effectivement on peut sans doute se permettre de l’utiliser. L’utilisateur devrait toujours être votre point de référence. Quand vous réalisez un site Web, il y aura toujours au final un utilisateur qui va s’en servir. C’est compliqué de se dire qu’on travaille pour un utilisateur. En effet, trop souvent, les promoteurs et acteurs d’un projet se concentrent sur leur propres préoccupations. Les developpeurs et la pureté technique, les responsables métier et leur ROI, les chefs de projet et leur suivi budgétaire, Les designers et leur égo démesuré… autant d’écueils qu’on a tous un jour rencontrés. L’utilisateur, c’est un peu la petite lumière dans la nuit… ne le perdez jamais de vue, c’est votre bouée de sauvetage.

Alors voilà, malgré toute ma bonne volonté et même si je trouve que -prefix-free ou cssFX sont de très beaux projets, les utiliser revient, pour moi, à répondre « oui » à ma deuxième question. Vous comprendrez donc qu’en ce qui me concerne, je ne peux pas cautionner son usage sur un site en production. Je peux comprendre qu’on n’ait pas envie de passer des heures à maintenir des listes sans fin de propriétés préfixées. Mais dans ce cas, faites plutôt le choix des préprocesseurs CSS (LESS, SASS, etc.) qui vous permettront de manipuler des feuilles de style plus simples tout en vous assurant qu’elles comporteront bien tous les préfixes qui vont bien au moment de leur publication.

PS : Merci à Julien et Richard pour la relecture de mon orthographe déficiente

Des effets pour le Web

Jeremie — Thu, 12 Jan 2012 09:00:00 +0100

Cet article est la traduction d’un article de Christian « Schepp » Schaefer à propos des nouvelles propriétés de filtres CSS3 et montre comment commencer à les utiliser tout en proposant des solution de repli basées sur ce que supportent les navigateurs actuels.

A la fin des années 90, CSS 2.1 nous a fourni un ensemble d’outils de base pour pouvoir enfin se débarrasser des mises en page en tableaux. Maintenant c’est le tour de CSS3 qui nous donne de nouveaux outils plus précis pour gérer les détails de mise en forme : Les fontes embarquées, les coins arrondis, les dégradés, la transparence des éléments et des couleurs, les ombre portées sur le texte et les boites, etc.

Évidement, lorsqu’on compare notre outillage à celui de logiciels comme Photoshop, on se dit qu’on pourrait rêver mieux. Ce genre de logiciel permet, par exemple, de désaturer une image ou bien de la rendre plus nette ou plus floue. Pourquoi aurions-nous besoin de ce genre d’outil pour le Web ? Et bien, désaturer ou flouter une partie de page Web peut être un moyen de guider le regard de vos visiteurs sur des zones choisies. Ça pourrais aussi aider vos visiteurs à concentrer leur attention sur les zones qui n’ont pas été modifiées. Par exemple, on peut utiliser ce genre d’effets pour mettre en scène une galerie d’images :

D’un autre coté, un effet de netteté peut être utile lorsque vous réduisez une image dans le navigateur. Sans lui, vous allez perdre un certain nombre de détails sur cette image.

Voila, ce serait génial si nous pouvions avoir ce genre d’effets à notre disposition, un peu comme la propriété CSS opacity qui nous permet de rendre un élément transparent. Malheureusement, ce n’est pas le cas.

Le status quo actuel

Au lieu de cela, pour simuler un effet de désaturation/niveau de gris nous sommes actuellement obligés de passer en revue « à la main », via Javascript, toutes les propriétés utilisant de la couleur sur un éléments donnée pour leur attribuer la valeur de gris que l’on veut. Dès que l’on doit faire face à des images ou de la vidéo, c’est encore plus compliqué : Dans ce cas-là, nous avons besoin de nous appuyer sur la balise Canvas de HTML5 pour pouvoir changer leur couleur pixel par pixel puis pour remplacer l’élément d’origine. Même si nous nous appuyons sur des bibliothèques tel que CamanJS ou Hoverizr, ça reste quand même un truc assez sale.

Un effet de flou peut également être simulé à l’aide des propriétés text-shadow et box-shadow en leur appliquant la même couleur que le texte ou l’arrière-plan auquel elles se rapportent. Le problème, c’est que cette illusion ne fonctionnera pas avec les boîtes multicolores non plus qu’avec les images ou les vidéos comme précédemment. Une fois de plus, il faudra se reposer sur des manipulation à base de Canvas HTML5. Arf!

Á propos de la balise Canvas: La bibliothèque blurry.js propose une solution particulièrement brutale à cette histoire de flou. Elle va extraire tout le contenu à flouter, va le recréer dans une balise Canvas (en utilisant partiellement Cufón), va le flouter et enfin va réinjecter le tout à l’emplacement de l’original.

En ce qui concerne la netteté, il n’existe actuellement aucun truc basé sur CSS pour réaliser un tel effet, ce qui nous laisse une fois de plus seul face à la balise Canvas.

SVG à la rescousse

Il est intéressant de noter que SVG connaît la notion de filtres depuis des lustres avec, entre autre, les mélanges de couleurs, l’ajustement de la luminosité et du contraste, les effets d’éclairage, le « displacement mapping », les flous gaussien et de déplacement, le bruit, la netteté, etc.

Ainsi, maintenant que SVG est de plus en plus largement supporté, nous pourrions essayer de placer nos contenus, non plus dans du HTML, mais plutôt dans du SVG que l’on placerait dans du HTML. Nous serions alors capables d’appliquer n’importe quel effet à notre contenu. Le problème, c’est que la plupart des intégrateurs HTML risquent de ne pas être très chauds pour se mettre à produire du balisage SVG de ce genre :

<text font-family="Arial" font-weight="900" font-size="40" x="20" y="55%">SVG Example</text>

Il existe un truc un peu plus sympa en SVG, c’est la balise foreignObject. Elle nous permet d’inclure n’importe quel type de balisage à l’intérieur d’un contenu SVG. C’est un peu comme mettre du SVG directement dans un document HTML5, mais dans l’autre sens. Dès que vous avez inclus vos trucs dans du SVG, vous pouvez y appliquer des filtres comme vous le feriez pour n’importe qu’elle autre partis de votre contenu SVG. Vous pouvez embarquer une page HTML entière et lui appliquer des filtres, ou vous restreindre à une simple image bitmap. Bien sûr, vous devez mettre votre contenu SVG lui-même dans une page HTML, ce qui peut conduire à quelques migraines (du HTML embarqué dans du SVG embarqué dans du HTML). Le support navigateur pour la balise foreignObject est plutôt bon. Seul Internet Explorer reste à la traine. Heureusement, Internet Explorer 10 va rattraper le coup en supportant à la fois les filtres SVG et la balise foreignObject.

Les filtres SVG sur du contenu HTML via CSS

Depuis sa version 3.5, Firefox va encore plus loin. Il vous permet d’appliquer un filtre SVG, défini dans un document externe, à n’importe quel contenu HTML en passant simplement par une feuille de style. Nous pouvons, par exemple, définir dans un document SVG un filtre de flou gaussien (feGaussianBlur) ayant un rayon de 2 pixels et lui donner l’identifiant gaussian_blur :

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" 
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="1" height="1" version="1.1" 
xmlns="http://www.w3.org/2000/svg" 
xmlns:xlink="http://www.w3.org/1999/xlink">
  <defs>
    <filter id="gaussian_blur">
      <feGaussianBlur in="SourceGraphic" stdDeviation="2" />
    </filter>
  </defs>
</svg>

On peut alors référencer ce filtre à l’aide du nom du fichier SVG et de son l’identifiant au sein de notre feuille de style pour l’appliquer à toutes les images :

img {
    filter: url(blur.svg#gaussian_blur);
}

Vous pouvez voir cette démo en live ici. Hélas, comme je vous le disais, ça ne fonctionne qu’avec Firefox.

Bien heureusement, ce n’est pas la fin de l’histoire. Internet Explorer connaît lui aussi les filtres. Ceux-ci ne sont pas basés sur SVG, mais sur des mécanismes propres à la bibliothèque graphique de Windows : DirectX. Parmi ces filtres certains sont bien connus pour nous aider à résoudre certains bugs (le filtre alpha pour les image PNG) ou pour imiter certaines fonctionnalités de CSS3 (le filtre des dégradé). Néanmoins, il en existes d’autres très similaires aux filtres SVG :

/* Flou de 2 pixels de rayon */
filter: progid:DXImageTransform.Microsoft.Blur(pixelradius=2);
/* Flou de mouvement de 13 pixel avec un angle de 310° */
filter: progid:DXImageTransform.Microsoft.MotionBlur(strength=13, direction=310);
/* niveau de gris / désaturation */
filter: gray;
/* Effet « Rayon X » (inversion des niveaux de gris) */
filter: xray;
/* cône de lumière */
filter: light();
/* Extrusion */
filter: progid:DXImageTransform.Microsoft.emboss();

Vous trouverez une liste complète de ces filtres ici : http://msdn.microsoft.com/en-us/library/ms673539(v=VS.85).aspx

Ainsi, à l’aide de commentaires conditionnels, nous pouvons désormais proposer un certain nombre d’effets à deux familles de navigateurs qui à elles deux représente une part non négligeable du marché :

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie" lang="en"> <![endif]-->
<!--[if gt IE 9]><!--> <html lang="en"> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

margin: -2px permet de contre balancer le changement de dimension de l’image provoqué par le filtre. zoom: 1 est necessaire pour que la plupart des filtres fonctionnent avec in IE6/7. Malheureusement, IE10 ne supporte plus les filtres propriétaires de Microsoft et n’autorise pas encore les filtres SVG sur du contenu HTML

Vous trouverez ici la version modifié de l’exemple

Un certain nombre de personnes ont apprécié l’idée de Firefox d’ouvrir les filtres SVG au contenu HTML. Ils ont donc formé un nouveau groupe au W3C appelé W3C FX Task Force dont l’objectif est de standardiser et simplifier l’usage des filtres SVG dans tous les navigateurs. Puisque Firefox avait défriché le terrain des filtres d’effets, le premier brouillon de spécification est vite arrivé sous le nom de W3C Filter Effects 1.0. Les mécanismes proposés dans ce brouillon fonctionnent à peu près comme dans Firefox tout en offrant en plus un certain nombre de raccourcis vers les effets les plus intéressants. Les filtres bénéficiant d’un raccourci fonctionnent sans l’aide d’un fichier SVG externe. Ils sont directement codés au cœur du navigateur. Les raccourcis en question sont :

grayscale
sepia
saturate
hue-rotate
invert
opacity
brightness
contrast
blur
drop-shadow

Un autre avantage de ces raccourcis, c’est qu’ils peuvent être animés via les transformations et les animations CSS :

.foo {
  filter: blur(2px);
  transition: filter 1s ease-in-out;
}
 
.foo:hover {
  filter: blur(0);
}

Ce serait plus difficile et moins efficace de réaliser cela dans un document SVG.

Pour finir, les effets de filtre prévois d’être enrichie à l’aide des vertex shaders et fragment shaders d’OpenGL/WebGL. Les vertex shaders permettront d’appliquer un maillage 2D sur un élément que vous pourrez alors déformer en déplaçant tous les points du maillage selon une formule mathématique de votre choix. Les fragment shaders d’un autre côté permettront de réaliser ces transformations mathématiques sur les couleurs de chacun des pixels de cet élément. Ces deux types de filtres bénéficieront en plus de l’accélération matérielle de votre carte graphique.

Par un heureux hasard, il y a quelques semaines les premières implémentations de ces filtres sont apparues dans les compilations nocturnes de Webkit et sont à présent disponibles dans Chrome Canary. Ça veut dire que d’ici 3 mois les filtres CSS seront disponibles dans la version stable de Chrome et à brève échéance dans Safari. Ça veut également dire que nous ne sommes pas loin de pouvoir commencer à utiliser des filtres CSS sur 90 à 95% du marché des navigateurs !

Si l’on en revient à notre exemple, tout ce que nous avons à faire pour supporter Webkit est de rajouter un simple -webkit-filter: blur(2px);. Néanmoins, il faudra faire attention de le placer après la propriété filter non-préfixée. La raison étant que lorsque Webkit supportera la version non-prefixée de la propriété filter, la syntaxe propre à Firefox créra des problèmes avec la transition CSS que nous allons appliquer pour passer doucement entre la version flou et nette de l’image via -webkit-transition: -webkit-filter 1s ease-in-out;.

<!DOCTYPE HTML>
<!--[if lte IE 9]> <html class="ie"> <![endif]-->
<!--[if gt IE 9]><!--> <html> <!--<![endif]-->
<head>
<meta charset="utf-8">
<title>Blur via CSS</title>
<style>
img {
  filter: url(blur.svg#gaussian_blur);
  -webkit-filter: blur(2px);
  -webkit-transition: -webkit-filter 1s ease-in-out;
}
img:hover {
  filter: none;
  -webkit-filter: blur(0);
}
.ie img {
  margin: -2px;
  filter: progid:DXImageTransform.Microsoft.blur(pixelradius=2);
  zoom: 1;
}
.ie img:hover {
  margin: 0;
  filter: none;
}
</style>
</head>
<body>
  <img src="http://jeremie.patonnier.net/post/2012/01/12/stadt.jpg"
   alt="Some rights reserved by zigazou76"
   width="500" height="333">
</body>
</html>

La dernière version de l’exemple

Et voila, des effets de filtres pour tout le monde ! Faisons de 2012 l’année des filtres CSS et amusez-vous bien avec.

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

Paris Web 2011 : SVG et Typographie

Jeremie — Tue, 18 Oct 2011 16:58:00 +0200

Paris Web 2011 s’est tenu les 13, 14 et 15 octobre dernier. Cette année encore j’y étais et force et de reconnaitre qu’une fois de plus, l’équipe a sué sang et eau pour en faire un évènement de qualité inégalé. Bravos à tous, vous avez assuré grave

Le programme était vraiment d’excellente facture, et je retiendrai en particulier deux conférences : D’une part, celle d’Antony Ricaud qui a pris le temps d’expliquer et de détailler comment fonctionne un navigateur (chose que peu de web designer connaissent mais qui explique beaucoup de choses, comme par exemple “pourquoi les sélecteurs CSS sont lus de droite à gauche”) ; D’autre part, celle de celinecelines qui a fait la démonstration d’une énergie incroyable et d’un enthousiasme peu commun, mais ô combien communicatif et stimulant. Merci Céline.

De mon coté, ça a été un peu le grand schelem. En effet, l’équipe d’organisation à accepter toutes mes propositions (‘^_^) je me suis donc retrouvé à présenter un lightning talk, une conférence et un atelier… argle !

Lightning talk

Le challenge consistait à parler d’un sujet pendant seulement 4 minutes. Ça demande d’aller droit à l’essentiel et d’être percutant. Vu que je traitai déjà de sujet assez sérieux pour ma conférence et mon atelier, j’ai proposé un “truc rigolo”. J’ai donc fait une animation SVG pour illustrer la lutte permanente des standards du Web pour un Internet meilleur. J’ai demandé l’aide de ma collègue Corinne Massacry pour réaliser tout le “Character Design” et j’ai réalisé toute les animations à la main (il n’y a pas d’éditeur d’animation SVG connu à ce jour, donc, tout à la mimine… ce qui prend un temps infinie, j’ai terminé l’animation la veille de la conf en y passant la nuit :-/)

Voila le résultat :

Vous pouvez télécharger le fichier SVG ici : http://jeremie.patonnier.net/experiences/parisweb2011/animation.svg

Pour la petite histoire, l’ensemble des éléments graphiques ont été réalisés avec Adobe Illustrator. Pour ce qui est de la réalisation de l’animation, dans le mesure où, lorsqu’on code à la main, c’est très difficile de se déplacer d’un point à l’autre de l’animation, je l’ai animée à l’envers. Concrètement, j’ai animé la dernière scène, puis l’avant dernière scène, etc. De cette manière, à chaque fois que je rafraichissais l’animation, je voyais immédiatement ce que je venais d’animer sans avoir à attendre que le début de l’animation soit joué (plusieurs minutes) pour pouvoir vérifier ce que je venais de faire (parfois moins d’une seconde d’animation)

Conférence : “La typographie, mon navigateur et moi”

Lors de cette conférence, j’ai eu l’occasion d’expliquer comment les polices typographiques sont miraculeusement affichées par les navigateurs Le coté sympa, c’est qu’à l’origine, cette conférence devait durée 30 minutes et que suite au désistement de dernière minute d’un orateur, elle a finalement pu durée 1 heure avec plein de questions et réponses. Je vous met les slides ici, mais la vidéo sera sans doute beaucoup plus intéressante. Je vous tiens au courant dès qu’elle est disponible.

Atelier : “SVG et le web design moderne”

1h30 à la découverte de SVG. Je ne cache pas que pendant l’atelier j’ai un peu angoissé en voyant les nombreux visages extrêmement sérieux et concentré en face de moi. Heureusement, il semblerai que l’atelier ait bien plus à tout le monde. Je vous met ici les slides, les exemples et les différents liens que j’ai eu l’occasion d’évoquer.

Les slides : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/presentation.odp
Les exemples :
- Exemple d’un fichier SVG basic : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/basic.svg
- Les différentes manière d’inclure du SVG dans du HTML : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/inclusion.html
- Comparaison entre SVG, RaphaelJS et Canvas : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/svg-raphael-canvas.htm
- Exemple d’usage avancé avec CSS3 : http://jeremie.patonnier.net/experiences/parisweb2011/atelier/monsieur-ou-madame-1.htm
Les liens à voir (en vrac) :
- http://raphaeljs.com
- https://github.com/wout/raphael-svg-import
- http://mbostock.github.com/d3/
- http://jvectormap.owl-hollow.net
- http://rickardsund.com
- http://discover.store.sony.com//piiq/
- http://evolutionofweb.appspot.com
- http://vlog.it
- http://type.method.ac
- http://www.goodreads.com (l’icone de “rating” est en SVG et reprend les données réelles de vote sur chaque livre)
- http://www.drawastickman.com
- http://www.nissanusa.com/leaf-electric-car/index
- https://developer.mozilla.org/en/SVG

Là aussi, la vidéo sera bien plus parlante, je vous la mettrai dès qu’elle sera là

Voila, comme d’habitude, c’était bien chouette, encore un gros merci aux organisateurs et vivement l’année prochaine (mais je proposerai moins de choses parce que là, c’était vraiment trop dur de préparer tout ça).

SudWeb 2011 : Coup d'essai, coup de maitre

Jeremie — Tue, 21 Jun 2011 09:54:00 +0200

Note for English speaker, there is an English version down below

Le 27 mai dernier, j’ai eu la chance de participer à la toute première édition de SudWeb à Nîmes. Partie sur une boutade lors du dernier Paris Web, les organisateurs se sont juste arrachés pour arriver à monter le truc en à peine 6 mois. Bravo à tous, ce fût beau ! Car on peut le dire, pour un coup d’essai, ce fût un coup de maitre. Au delà de la logistique impeccable, l’ensemble du programme des conférences était tout simplement parfait. Mixant à la fois les aspects fonctionnels, techniques et prospectifs, l’équilibre du déroulé m’a complètement estomaqué (ainsi que le respect des horaires, tenus d’une main de fer, couplé à des moments de pause ô combien conviviaux).

Vous n’y étiez pas ? Ce n’est pas grave. D’une part toutes les conférences ont été filmées et devraient être disponibles prochainement et d’autre part, il y aura une autre édition l’année prochaine, viendez-y

En ce qui concerne mon nombril, j’ai eu l’occasion d’y donner une conférence sur un sujet qui me tient à cœur depuis un peu plus d’un an : SVG. Au cours de cette conférence, j’ai montré ce qu’il était possible de faire aujourd’hui avec SVG (qui, rappelons le, est disponible dans tous les navigateurs moderne). Plutôt que de m’attacher aux questions techniques qui tourne autour de cette technologie, j’ai préféré mettre l’accent sur des outils et des résultats concrets. L’idée étant de montrer comment des designers et les développeurs on déjà utilisé SVG et ce qu’il apporte au web design moderne.

Évidemment, même si j’ai oublié de le préciser pendant la conférence, je n’ai pas pu m’empêcher de réaliser mes slides en SVG, les voici (cliquez sur l’image pour lui donner le focus et utilisez les flèches de direction pour passer d’un slide à l’autre) :

Vous pouvez accéder à ma présentation SVG à cette adresse : http://jeremie.patonnier.net/experiences/sudweb2011/presentation.svg

A noter que je cite tous les sites suivant :

Outils

http://code.google.com/p/svgweb
http://raphaeljs.com : Vous devriez tous avoir cette bibliothèque dans votre trousse à outils si vous voulez réaliser du SVG tout en étant compatible avec les vieux IE.
http://www.highcharts.com : LA bibliothèque pour faire des graphiques de données sans vous casser la tête.
http://mbostock.github.com/d3/ : D3.js est une bibliothèque qui vous permet de mapper des données au seins de graphiques vectoriels en SVG. C’est un pont technique idéal entre les développeurs qui doivent manipuler ces données et les designers qui doivent les mettre en scène.

Références

http://www.thenounproject.com : Projet mettant à disposition des icones libres de droit au format SVG. Indispensable pour réaliser de la signalétique. A noter que toutes les icones proposées sont composées d’un seul est unique chemin SVG ce qui en fait une base travail extrêmement propre et malléable pour les Web designers.
http://www.bifter.co.uk : Web comics humoristique intégralement réalisé en SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : Le journal allemand Zeit propose une visualisation de données démographiques intégralement réalisée en SVG
http://www.nissanusa.com/leaf-electric-car/index : Dans la série “Non, ce n’est pas du Flash” Nissan USA fait une magnifique utilisation de SVG pour proposer une navigation non linéaire des caractéristiques de sa nouvelle voiture électrique. A noter que RaphaelJS est utilisé pour assurer la compatibilité avec IE6, 7 et 8 (et oui).
http://rickardsund.com : Je n’ai pas de mot assez fort pour exprimer l’adoration que j’ai pour ce site. Pour moi, Il représente la quintessence du Web design moderne. D’un coté un design épuré à l’extrême qui sert parfaitement son propos. Il est l’œuvre de Hugo Ahlberg qui a un lourd passif de designer Flash, ce qui lui a permis de s’extraire des contraintes (artificielles) du design web traditionnel. D’un autre coté, il est intégré à la perfection en utilisant exclusivement des standards Web : HTML5 (à noter en particulier la magnifique utilisation de l’API History), CSS3, JS (Du “mouse gesture” de toute beauté) et bien sur du SVG (par petites touches mais indispensables). Ce travail formidable a été réalisé par Daniel Mahal et Daniel Connor qui font là une démonstration d’excellence de ce que devrais toujours être une intégration aux standards, en particulier la maitrise de la dégradation élégante qui est quasi parfaite : Ce site fonctionne dans IE6 ! Vous DEVEZ regarder la source de ce site et vous en inspirer.

Pour conclure, je n’ai plus qu’une chose à dire : Longue vie à SudWeb, vivement l’année prochaine

On May 27th, I got the chance to attend the very first SudWeb event in Nîmes, France. Starting on a joke during the last Paris Web event, the people behind SudWeb make it possible in just 6 months. Thanks dudes that was awesome! We can say it, for a first run that was a master piece. Beyond the perfect logistic, the program was just great. Talks were amazingly well balanced between functional, technical and prospective subjects (and the schedule was perfectly mastered with good time to talk and network with people).

You wasn’t their ? Don’t worry. First, all the talks were camcorded and should be available soon. Second, there will be another edition next year, attend it

On my own, I had the opportunity to give a talk about one of my favorite subject for a year now : SVG. During this talk, I show off what is it possible to make with SVG today (which, as a reminder, is available in all modern browsers). Instead of talking about technical stuffs, I focused on tools and practical results. The idea was to demonstrate how designers and developers had used SVG and what that technology brings to modern Web design.

Of course, even if I forgot to mention it during my talk, I felt oblige to made my slides with SVG. Here there are (see above, click on the image to give it the focus then use the arrow keys to switch between the slides).

Note that I use all the following web sites as examples:

Tools

http://code.google.com/p/svgweb
http://raphaeljs.com : You should all have that library in your toolbox if you want to use SVG with IE compatibility in mind.
http://www.highcharts.com : THE library to build charts without headache.
http://mbostock.github.com/d3/ : D3.js is a library that allow you to connect data with graphics. This is an awesome bridge between developers that deal with data and designer that deal with graphics.

References

http://www.thenounproject.com : That project collect visual symbol and make them available in SVG. Note that all the symbols are made of one single SVG path. That make them highly usable as a work basis for Web designers.
http://www.bifter.co.uk : A humorous Web comics build with SVG.
http://opendata.zeit.de/pisa-wohlstands-vergleich/visualisierung.php : The dutch newspaper Zeit had a demographic data representation driven by SVG.
http://www.nissanusa.com/leaf-electric-car/index : Ok, so “This is NOT Flash”. This is a great SVG work made by Nissan USA to build a non-linear navigation system. Take care about the library behind the scene, it’s RaphaelJS. This means that it works properly even with IE6, 7 and 8 (crazy!).
http://rickardsund.com : I do not have strong enough words to express my love for this web site. To me, it’s the best of modern Web design. On the one hand, the simplistic design suits its subject perfectly. It has been made by Hugo Ahlberg who has extensive skills in Flash design. Those skills give him the ability to overcome the classic HTML web design. On the other hand, This Web site is perfectly develop with Web standards only : HTML5 (with a noticeable use of the History API), CSS3, JS (awesome mouse gesture) and, of course, some small (but essential) touches of SVG. This amazing work has been done by Daniel Mahal and Daniel Connor who demonstrate what a Web standards front-end development should always be. They especially mastered the graceful degradation: This site works perfectly with IE6 ! You SHOULD look at the source and use it as an inspiration.

To conclude, there is one thing left : Live long SudWeb, I strongly hope for the next edition

Alors s'en vient le temps du changement.

Jeremie — Wed, 13 Apr 2011 11:59:00 +0200

Je sais que je blogue assez peu en ce moment. Ne m’en veuillez pas, c’est qu’il se passe pas mal de choses actuellement pour moi avec peux de temps pour venir écrire ici.

D’abord, si vraiment vous voulez lire des trucs que j’ai écrit moi-même comme un grand, allez faire un tour sur typographisme.net, mon dernier billet en date parlant des ligatures dans les navigateurs.

En suite, je suis en train de préparer ma présentation pour SudWeb 2011. Comme je vais y parler de SVG, je ne peux bien sur pas faire autrement que de préparer un support de présentation lui aussi en SVG (il sera en ligne après la conf). Ça se passe le 27 mai à Nîmes, le programme est alléchant et le prix raisonnable, n’hésitez pas à venir y faire un tour.

Enfin, je change de travail Après 5 ans passé au sein de Cetelem (organisme de crédit pour les particulier du groupe BNP Paribas) en temps que responsable d’équipe de développement web, je vais rejoindre CleverAge où je serais consultant web (ou chef de projet ça dépendra des clients et des missions ). C’est prévu pour le 2 mai et en attendant, c’est un peu “je cours dans tous les sens pour plier les questions administratives”.

Sur ce… qu’un millier de colombes constipées illuminent votre journée.
A bientôt

Paris-Web 2010 : CSS3 Aujourd'hui

Jeremie — Wed, 16 Feb 2011 13:00:00 +0100

Maintenant, que les vidéos sont en ligne, voici un petit retour sur Paris-Web 2010 ou j’ai animé un atelier sur le thème “CSS3 Aujourd’hui”.

Depuis maintenant 5 ans, Paris-Web, c’est un peu le rendez-vous annuel des faiseurs de Web français. Cette année fut assez exceptionnelle, et tous les participants (visiteurs, orateurs et organisateurs) sont tous à peu près d’accord pour dire que c’était un excellent millésime (si ce n’est le meilleur pour l’instant). Les conférences étaient d’un niveau exceptionnel, l’organisation sans tache et le hashtag #sharethelove a été largement employé sur Twitter pour qualifier l’ambiance générale (bon, on n’a pas pu éviter tous les trolls, mais ça s’est bien passé).

Sur les conférences, j’ai noté en particulier celle de Anne-Sophie Fradier sur la macro-typographie (qui a subtilement servi de tremplin au projet que j’ai monté avec elle et d’autres d’un site dédié à la typographie sur le Web) et celle de Paul Rouget sur les nouvelles API issu de HTML5. Paul était super content car d’une part tout a marché et les démos montrées étaient franchement bluffantes (faire un sondage en live grâce aux Web Sockets, c’est un peu la classe quand même).

De mon coté, j’ai animé un atelier sur le thème “CSS3 Aujourd’hui”. J’y ai passé en revue ce qu’il est possible de faire dès à présent avec CSS3 en commençant quand même sur quelques rappels importants liés à CSS2. En effet, CSS3 n’est jamais qu’une “amélioration” de CSS2. L’atelier s’est bien passé mais il a duré 1h30, là ou j’avais du matériel pour 3h. Ceci dit, grâce à la vidéo, je me rends compte que ça ne s’est pas trop vu (sauf vers la fin), même si je n’ai pas pu entrer dans le code autant que je le voulais. Ceci dit, il a été possible de bien discuter avec la salle (c’était le but, mais dans la vidéo c’est un peu frustrant car il n’y avait pas de prise de son d’ambiance) et les principaux thèmes ont pu être vu.

Si vous y étiez ou si vous voulez voir les exemples en même temps que vous regardez la vidéo, toutes mes slides sont disponibles :

http://jeremie.patonnier.net/experiences/parisweb2010/

Ainsi que tous les exemples de code :

http://jeremie.patonnier.net/experiences/parisweb2010/exemples/

Et donc, la vidéo de l’atelier car cette année pour la première fois, certains ateliers ont été filmés (merci aux étudiants de Cifacom et à l’équipe Paris-Web pour le boulot réalisé) :