Note : nous vous invitons vivement à (re)lire la première interview de Daniel Glazman, car nous allons nous référer plusieurs fois à cette dernière. De plus, la vision d’ensemble d’un profil technique aussi extraordinaire que peut l’être celui de Daniel ne peut que vous enrichir, qu’on se le dise !

Pour ceux qui ne te connaîtraient pas encore, peux-tu te présenter à nouveau ?

Bonjour ! Et bien je suis un vrai geek tombé dedans depuis l’enfance qui a eu l’énorme chance de naître au bon moment pour participer à ces trois changements majeurs que furent l’informatique individuelle, la naissance de l’Internet et le Web. Je suis très impliqué depuis plus de vingt ans dans les standards du Web, et je suis aussi un développeur d’applications avec une forte spécialisation dans les éditeurs WYSIWYG.

Du côté perso, j’ai 48 ans, je suis père de deux grands garçons qui font mon admiration quotidienne, je vis en région parisienne et j’aime la linguistique, les systèmes d’écriture et les canards (oui, je sais, un peu cinglé donc…).

Je suis en train d’écrire un ebook regroupant un peu tout ça, mes confessions de geek. C’est loin d’être fini mais ça donne d’autres détails.

En quoi consistait clairement le métier de co-chairman CSS ? Est-ce que cela a changé par rapport à la précédente interview ?

Cela a peu changé, disons que cela a doucement évolué. Être chairman d’un groupe de standardisation, c’est être disons un chef d’orchestre. Ce n’est pas le chef d’orchestre qui écrit la musique, ce n’est pas lui non plus qui la finance ou la fait retentir, mais il s’assure que le résultat final est fait pour plaire et est réalisé en bonne intelligence. Comme je l’ai dit souvent, un chairman n’est pas le patron, il est la burette d’huile qui garantit que les rouages tournent bien et sans trop de frictions.

Alors comment tout cela a-t-il évolué dans le cas du CSS Working Group ? Et bien tout simplement, le changement de taille en sept ans du groupe, passé de 8 membres actifs début 2008 à plus de trente aujourd’hui, a amené des conflits inévitables. Des conflits de stratégie industrielle, parfois des conflits personnels. Rien que de très normal, mais c’est assez chronophage et pas toujours facile à régler. Inutile de demander, je ne dirais rien :-)

Avec la taille du groupe a aussi évolué le nombre de documents sur lesquels nous travaillons. Les propositions émergent à un rythme soutenu, nous avons plus de 60 documents actifs sur notre radar ! La priorisation est donc plus difficile qu’avant et il est également plus compliqué de pousser les gens à finir ce qu’ils commencent.

Corollaire heureux, le CSS Working Group est un des groupes les plus actifs et les plus productifs du W3C, ainsi que le plus ancien. Il est extrêmement visible, impacte rapidement les navigateurs, et nous avons été plusieurs fois cités comme « un exemple de Working Group qui tourne bien ». Cela fait toujours plaisir :-)

Cela a évolué aussi parce qu’au cours des disons huit derniers mois, mon co-chairman Peter et moi-même avons commencé à ressentir le besoin de passer la main, de faire entrer du sang neuf – et donc fort probablement des méthodes nouvelles – au chairmanship du groupe. Nous avons officié 2790 jours, ce qui est monstrueux. Il a donc fallu lancer une recherche de remplaçants et un processus de passation. Mais bon, rien que de très normal, hein ! Nous laissons le groupe à Rossen Atanassov de Microsoft et Alan Stearns d’Adobe, deux gars très talentueux qui sauront sans aucun doute gérer cette grosse machine à merveille.

Qu’est-ce qui t’a amené au chairing de CSS et à durer « aussi longtemps qu’un dinosaure » selon tes propres paroles dans la précédente interview ?

C’est une excellente question. Je dirais trois choses : tout d’abord la chance, évidemment. Ensuite la passion, bien entendu. Et la persévérance enfin. Depuis 2006, le CSS Working Group était en mauvais état, sa taille diminuait lentement, il ne publiait pas grand’chose se perdant dans des discussions sans fin et je m’en suis ouvert au management du W3C sans penser une seule seconde à finir chairman… À cette époque, nous étions entre 7 et 10 à chaque réunion, c’est-à-dire en-dessous de la probable taille critique pour travailler correctement sur un sujet pareil. À mon immense surprise, j’ai reçu un appel téléphonique de Chris Lilley (Technical Director, W3C Interaction Domain), en fin d’année 2007 pour discuter de mon alerte sur la situation du groupe et en fin de discussion, Chris m’a annoncé qu’il avait proposé que mon vieil ami Peter Linss (HP, ex-Netscape, auteur originel du Style Engine de Gecko) et moi-même devenions co-chairs du groupe, à ma plus totale surprise. J’ai accepté pour trois raisons principales : tout d’abord, il fallait un nouveau chairing au groupe et je ne pouvais me limiter à lancer l’alerte. “Dirty job but someone had to do it” (« Sale job, mais quelqu’un doit le faire »). Ensuite, travailler à nouveau avec Peter me faisait vraiment très plaisir. Enfin, le W3C n’avait pas d’autre candidat potentiel…

Les raisons plus fondamentales qui ont probablement amener à me choisir sont, je pense, les suivantes et cela rejoint le début de ce paragraphe :

1. j’étais dans le groupe et mon entreprise était membre du W3C ;
2. je suis passionné par CSS depuis le début, actif dans les feuilles de styles depuis bien avant CSS ;
3. la santé du CSS Working Group et donc de CSS m’importait ;
4. j’étais déjà un ancien du groupe, qui savait comment le groupe travaille et comment il pouvait travailler mieux ;
5. je connaissais tout le monde ;
6. j’étais disponible pour le faire même si l’impact sur une petite entreprise comme la mienne (on n’est pas Google hein...) allait être conséquent.

Quant à la durée, jamais Peter et moi n’aurions pensé durer aussi longtemps. Elle s’explique probablement par le succès du groupe (« on ne change pas une équipe qui gagne ») et l’absence de remplaçants potentiels.

Combien de temps ça t’a pris en moyenne, par semaine ? (peu d’entre nous savent ce que cela peut représenter) Et qu’est-ce que tu vas faire de tout ce temps libre ?

Cela a été très variable. Disons entre 2,5 et 10 heures en pointe, c’est-à-dire en cas de conflit ou problème sérieux à gérer. Et bien entendu 100 % de mon temps pendant les réunions face-à-face du groupe.

Le plus dur aura été les quelques nuits blanches pendu au téléphone ou sur Skype lors des rares gros soucis arrivés pendant toutes ces années, et l’impact sur mes fils et mon entourage chaque mardi soir (préparation du conf-call du lendemain) et chaque mercredi soir (conf-call).

Dans la précédente interview, tu disais que le travail était colossal pour la spécification CSS 2.1 « Imaginez le nombre de tests que nous allons avoir sur une spec comme CSS 2.1 !!! ». Remise en perspective, vu que CSS3 est encore plus énorme que CSS 2.1 et bien plus complexe, que t’inspire ta phrase de l’époque ? (c’est encore pire, cela se gère différemment, etc. ?)

Évidemment que c’est énorme. Le foisonnement cérébral de ce groupe reste un étonnement quotidien, sa productivité est dingue et les problèmes techniques à régler démesurés. Mais notre travail n’est pas de soumettre toujours de nouvelles propositions, notre travail est de transformer ces propositions en standards consensuels. Et pour cela, oui, il faut des suites de tests unitaires qui sont d’une part parfois atrocement difficiles à rédiger et pas nécessairement l’activité la plus sexy de notre monde, et d’autre part une activité incroyablement chronophage.

L’écriture de ces tests est clairement un goulot d’étranglement de l’activité du groupe, cette étape est une de celles sur lesquelles nous perdons du temps. Vu la taille, la complexité et le nombre des documents sur lesquels nous travaillons, je crois qu’une évolution de notre politique de publication en la matière va devenir inévitable. Ce qu’elle
sera précisément, c’est aux nouveaux chairs du CSS WG de le définir avec les membres du groupe et le W3C :-)

CSS étant devenu une brique majeure des sites, comment peut-on gérer les effets qu’il peut avoir sur ce qui est connexe ou qui déborde de son domaine ? (accessibilité, etc. et on peut imaginer que les effets de bords sont de plus en plus nombreux)

Plus nombreux ? Oui et non. CSS est assez bien « isolé » dans la Web Platform, il ne modifie pas le Document Tree et n’est toujours pas un langage de programmation. Mais oui certes il y a des interactions. Comme nous ne sommes ni des experts d’accessibilité, ni de sécurité, nous nous reposons sur le process du W3C qui fait passer nos documents à plusieurs étapes par une revue auprès des membres du W3C et des autres groupes. Dont ceux sur accessibilité et la sécurité… Bref, la revue horizontale évite les grosses bêtises.

Comment gère-t-on des intérêts toujours plus énormes… et parfois contradictoires ? (à propos de CSS)

En restant hors du jeu, ce qui est compliqué pour les chairmen car ils sont aussi représentants de leur propre entreprise dans le groupe et ces entreprises ont évidemment elles aussi des stratégies à appliquer. Il faut acquérir le respect, rester objectif, être impartial et appliquer sans trembler les règles de fonctionnement du W3C et du CSS Working Group. Il faut aussi un peu de pif, hein :-) Alors la direction du chef d’orchestre est (relativement) aisément acceptée par les musiciens…

Est-ce que les « batailles de pouvoir » se sont déplacées par rapport à 2008 ? On entend parfois que les navigateurs ont pris une position beaucoup plus importante.

C’est le cas et c’est normal. S’il y a des outils non-navigateurs qui implémentent CSS, leur visibilité est faible comparée à celle de navigateurs déployés sur toute la planète et sortant une nouvelle version toutes les six semaines...

Les chairs tentent d’être impartiaux, et chaque membre du CSS WG a évidemment une voix d’importance égale à celle des autres. Ceci dit, si des navigateurs rejettent une proposition venant d’un non-navigateur, il sera bien entendu plus compliqué de la faire passer… C’est comme ça, même si ce n’est pas idéal.

Souvent, des développeurs aimeraient bien contribuer, CSS étant un des langages les plus aimés (et haïs, mais c’est une autre histoire), mais ne savent pas comment s’y prendre. À notre humble niveau, que pouvons-nous faire ?

Il n’y a que deux moyens : participer à la liste de travail www-style@w3.org ou envoyer des messages aux membres du groupe, par exemple aux éditeurs d’une spec, pour rapporter des bugs, des suggestions, voire des cas d’école. Et ne pas hésiter à aller discuter avec eux lors de conférences ou meetups. Nous ne sommes que des humains, nous commettons des erreurs, ne voyons pas tout, et le feedback des développeurs nous est indispensable.

Selon toi, la/les plus grande(s) réussite(s) de CSS ?

Hmmmm. Difficile ça comme question… Probablement deux choses :

1. l’idée de départ des CSS était judicieuse, et le fait que CSS soit encore là vingt ans après, avec ses fondamentaux de départ, le prouve ;
2. les sélecteurs, très lisibles, faciles à comprendre et apprendre qui ont permis à CSS d’être « notepadable ».

Des regrets ?

Deux :

1. notre conservatisme parfois, qui a conduit certaines choses à être repoussées à bien plus tard ;
2. notre perfectionnisme, qui est malheureusement le commun de bien des gens en standardisation. Il faut savoir finir une spec quitte à dire « le comportement de cet edge case est indéfini dans ce niveau de spécification » ou « on repoussera ça à la version suivante, on n’avance pas assez vite ».

Quel est ton regard avec quelques années de recul sur ton appel suite aux préfixes constructeurs ? (que nous avions d’ailleurs relayé ici-même)

Il a été étonnamment efficace, même s’il n’a pas été toujours bien compris. Les éditeurs de navigateurs eux-mêmes n’arrivaient à l’implémentation des préfixes webkit que contraints et forcés. Le relais de mon article par de grands noms de la presse technologique en ligne a eu un effet fort, et tout le monde s’est rendu compte qu’effectivement la situation était à deux doigts de déraper. Nous sommes donc lentement passés des préfixes aux flags, même si cela n’est toujours pas parfait…
Voir à ce propos : CSS Vendor Prefixes

Y a-t-il des gens injustement méconnus du monde CSS dont tu voudrais mentionner les mérites ?

Des tétraflopées ! Robert Stevahn (ex-HP) et Mike Wexler (ex-Adobe) qui ont été cruciaux du temps de CSS 2. Toute l’équipe Internet Explorer de Microsoft qui a poussé CSS à une époque où son succès n’était pas encore garanti. Michel Suignard (ex-Microsoft) sans qui l’internationalisation du texte en CSS serait encore loin d’être prête. Les auteurs de tous les préprocesseurs CSS qui ont pérennisé CSS au stade industriel. Et tant d’autres que trop de noms se bousculent dans ma tête !

Mais s’il y a une personne à citer, même si elle n’est pas méconnue, c’est « Fantasai », un pilier du CSS Working Group, une force de travail, et une gourou monumentale du secteur. Un nom à mettre au panthéon des CSS.

Peux-tu nous parler d’une demande incongrue vue de notre point de vue d’Occidentaux mais qui a énormément de sens pour une autre culture ?

Ruby ? Ruby, c’est un système permettant pour les textes japonais d’insérer en plus petits caractères au-dessus d’un mot en kanji une translittération en kanas. C’est fondamental pour l’apprentissage de la lecture par les enfants et utiles pour les mots récemment forgés.
On pourrait aussi parler des marquee, adorés en Asie :-)

Pour toi qui a une certaine vision d’ensemble sur CSS, y a-t-il quelque chose qui te surprend dans la perception que peut en avoir le « grand public » ?

Oh oui, bien entendu. Combien de fois avons-nous entendu « mais c’est facile à ajouter à CSS, je peux décrire ça en une seule propriété et quelques valeurs ». Il est très difficile de se rendre compte, pour le « grand public », de l’extrême difficulté de la standardisation et parfois de l’implémentation des standards. Une ligne de CSS hyper-simple à comprendre peut être un enfer à spécifier, à cause des effets de bord dans le layout, et pire encore à implémenter. Le coût de son implémentation peut parfois être tellement prohibitif que l’idée doit être abandonnée.

C’est assez difficile à vivre, parce que notre réponse sera forcément mal comprise de la communauté. Et pourtant, nous tentons toujours de faire au mieux, rien n’est refusé a priori.

On t’offre une tribune pour tordre le cou à une idée qui t’agace sur CSS, ce serait laquelle et pourquoi ? :)

Ce qui m’a énervé le plus au cours de ces 7.5 années aura été de lire de la part de grands éditeurs de logiciel, Membres du Groupe, que le CSS Working Group travaille lentement. Le CSS Working Group n’est que la somme de ses Membres, il ne publie que le travail de ses membres et si le Working Group est perçu comme lent, c’est parce que ses membres ont shifté de priorité, temporairement délaissé une spec, traîné sur les tests, ou discuté ad nauseam au lieu de savoir finir un document. Bref, c’est souvent « celui qui dit qui est » et cela a été assez rageant de faire face à des articles de presse ou des interviews de cette nature.

On t’offre une seconde tribune pour une question qu’on ne t’a jamais posée, et à laquelle tu aurais bien aimé répondre sur CSS ?

Je vais encore me faire des copains, hein ? ;-)

CSS est une technologie mature, qui a fait vaincre la vieille idée de séparation du contenu et de la présentation. Elle a même éclipsé XSL-FO et je pense qu’il est temps d’offrir une semi-retraite à XSLT, ce langage atrocement compliqué même s’il est hyper-puissant, et avoir une solution de transformation de documents à base de la syntaxe CSS, utilisant la simplicité des sélecteurs, et la lisibilité de propriétés simples et leurs valeurs. Je crois qu’il est temps et cela serait très utile au Web.

Le mot de la fin : Si tu n’avais qu’un conseil à donner aux gens qui font le web à propos de CSS ?

Share the love ? :-)

Non, je ne vais pas finir sur un conseil, qui serais-je pour oser donner un conseil... Je vais plutôt finir par un remerciement à tous ceux avec qui j’ai été en contact pendant ses 7,5 années, tous ceux qui ont bossé sur ou avec CSS pendant ce temps, ceux qui m’ont invité à des conférences ou simplement envoyé du feedback. Je n’aurais pas pu faire ça sans eux donc merci à tous, très sincèrement.

Et longue vie à CSS et au CSS Working Group !

Au nom de tout le collectif : Daniel, merci… pour tout !