Interview de Daniel Glazman (chairman CSS working group W3C)

Openweb.eu.org > Articles  > Interview de Daniel Glazman (chairman CSS working group W3C)

Abstract

Daniel Glazman est impliqué depuis 1991 dans le monde des standards et depuis 1994 dans celui du Web. Il a participé au HTML Working Group pour la standardisation de HTML 4 et au CSS Working Group pour CSS 2 et CSS 3. Sa société Disruptive Innovations est membre du World Wide Web Consortium (W3C) depuis 2006. Il est depuis peu co-chairman du CSS Working Group au W3C. Son rôle au W3C, ses compétences techniques hors-pair et son inaptitude totale à la pratique de la langue de bois nous ont donné envie de lui poser quelques questions sur l’avenir des feuilles de style. Interview.

Article

1. Quel est votre rôle dans l’équipe du CSS working group ?

Je suis membre du CSS Working Group depuis pas loin de douze ans, ce qui me classe aisément désormais parmi les dinosaures du groupe :-) J’ai commencé en tant que représentant officiel de EDF, puis Invited Expert, puis représentant de Netscape, puis de nouveau Invited Expert et je représente désormais dans le groupe ma propre société, Disruptive Innovations. Je suis co-chairman du Groupe depuis avril 2008 avec Peter Linss de chez Hewlett-Packard et ancien de chez Netscape (il est en grande partie à l’origine du Style Engine de Mozilla). J’ai participé à la standardisation de CSS 2, suis l’auteur ou l’éditeur de plusieurs modules de CSS 3. Mon rôle peut être résumé en l’organisation quotidienne des travaux du groupe, l’édition puis le respect de la Charte du Groupe, etc. Il faut jongler avec les priorités technologiques ou stratégiques, les conflits entre les différentes compagnies membres du Groupe et autres soucis de gestion au jour le jour.

2. Quel est l’état du CSS Working Group aujourd’hui ? Les travaux avancent-ils aussi vite que vous le souhaitez ?

Le CSS Working Group reste un des trois groupes de travail les plus « visibles » du W3C avec ceux relatifs à HTML et XML. Nous avons énormément de travail sur la table, peut-être trop, et le focus est clairement désormais la sortie en tant que Recommandation de CSS 2.1 puis de divers modules stratégiques de CSS 3. Le Groupe est en cours de « recharterisation » pour une durée de deux ans à compter de juillet 2008.

Nous avançons vite, oui, mais probablement pas aussi vite que nous le souhaiterions. Il y a pas mal de raisons à cela : tout d’abord les membres du groupe sont aussi tous des ingénieurs de développement et la standardisation ne représente qu’une partie de leur activité, fort heureusement. Cela permet d’avoir des gens parfaitement au fait des soucis d’implémentation mais cela signifie aussi qu’en période de rush, comme en ce moment avec la sortie imminente de Firefox 3 ou la préparation d’IE8 sur desktop et mobiles, l’implication des membres dans le groupe diminue un peu. C’est la règle générale des groupes, et il faut vivre avec.

3. Comment sont définies les priorités du groupe de travail ?

Jusqu’à présent, je dirais qu’elles étaient définies « sur le tas ». Dans le cadre de la nouvelle Charte du Groupe en préparation, nous allons bien mieux focaliser notre activité sur les documents les plus stratégiques.

À cet effet, les chairmen du Groupe ont interrogé tous les implémenteurs de navigateurs du Groupe sur leur stratégie, en toute confidentialité bien entendu... Le résultat devrait être une liste d’activités bien plus conforme à ce qu’il faut attendre des implémentations dans un délai de deux ans, durée de vie de la Charte.

4. Comment sont effectués les arbitrages entre les différentes voies technologiques et modules possibles ?

Un Groupe de Travail du W3C fonctionne au consensus, et au vote si aucun consensus ne se dégage. Donc c’est le WG lui-même qui décide des arbitrages.

Bien entendu, les chairmen sont là pour aiguillonner un peu le groupe en cas de besoin et proposer de remettre sur les rails ou arrêter des activités si nécessaire.

5. Certains éléments que vous êtes amenés à spécifier peuvent être partiellement couverts par des brevets. Comment gérez-vous ces problématiques de propriété intellectuelle ?

Le W3C a mis en place des règles assez complexes et assez strictes, la Patent Policy, pour régler les problèmes de brevets et de propriété intellectuelle (IPR, Intellectual Property Rights). Ces règles sont lisibles sur http://www.w3.org/Consortium/Patent....

Elles obligent tout membre du W3C rejoignant un WG à déclarer ses IPR qui pourraient rendre impossible l’implémentation d’une REC du W3C, et à accorder une licence Royalty-Free aux implémenteurs.

Il existe également un processus d’exclusion à ces règles générales. Plus généralement, ces problèmes sont tellement complexes que les techniciens que nous sommes (nous = les membres du Groupe) ne pouvons pas nous en occuper ni même les commenter ; nous laissons donc cela aux avocats, qui sont les seuls capables de gérer des problèmes de cette nature. Les recommandations des avocats sont transmises au W3C et aux Groupes de Travail par l’intermédiaire de l’Advisory Committee Representative (AC-Rep) de la société en question.

6. Comment jugez-vous les évolutions des spécifications CSS depuis la création de ce standard ?

Cela a énormément évolué, et très positivement. Håkon Lie et Bert Bos, les deux « inventeurs » de CSS sont tout de même partis d’une idée qui ne faisait pas à l’époque l’unanimité, la séparation du contenu et de la présentation... Seuls les anciens de SGML y croyaient, au moment où Netscape introduisait des éléments stylistiques comme font ou blink...

La spec CSS 1 était extrêmement simple à lire, puissante grâce au mécanisme de la Cascade qui gère non seulement les styles de la page mais également les styles par défaut du navigateur et les styles imposés par l’usager ; une vraie révolution. Alors que Netscape envisageait de gérer les styles via JavaScript (Cf. la spec JSSS ), Internet Explorer a permis aux CSS de décoller en investissant massivement dessus.

La sortie de CSS 2 en 1998 fut un évènement majeur pour le Web tel que nous le connaissons. Malgré des différences d’implémentation, des lacunes et des imperfections, cette spec a permis des avancées considérables avec la gestion du positioning, de l’impression et encore plein d’autres choses novatrices.

CSS 3 est tout aussi prometteuse, même si les différents modules gagnent malheureusement en complexité ; il est très difficile de conjuguer « specs sans aucune ambiguité » et simplicité...

7. Quel est le poids d’Håkon Lie sur le développement actuel de CSS ? Et comment se situe ce développement par rapport à la vision initiale d’Håkon Lie et Bert Bos ?

Håkon reste un des piliers de CSS même si son activité de CTO chez Opera est très prenante et que nous le voyons moins dans le Groupe que nous le souhaiterions. Il reste aussi avec Bert un des Gardiens du Temple, un gardien de la vision initiale des CSS. Bon, c’est à la fois un bien et un mal, et toute la communauté des auteurs CSS se réjouit aujourd’hui de voir peut-être arriver les CSS Variables même si elles ne collent pas précisément avec l’esprit initial des CSS...

Håkon et Bert restent des super-pros pour inventer des mécanismes purement déclaratifs pour des fonctionnalités complexes, là où d’autres s’orienteraient naturellement vers la simplicité c’est-à-dire des choses plus programmatiques. Voir à cet effet le CSS 3 Advanced Layout, une spécification superbe.

Ils sont aussi des célébrités dans notre monde de geeks et leur implication personnelle dans le futur des CSS est clairement très importante pour le devenir de cette technologie.

8. Selon vous, les spécifications CSS sont-elles correctement mises en application par les différents outils ?

Honnêtement, vu la complexité de l’implémentation de CSS, on peut dire que oui. Le principal grief revient évidemment à Microsoft, qui a stoppé tout développement après la sortie de IE6 et n’a donc pas amélioré son support des CSS depuis des années. Mais cela avance et IE8 est déjà nettement meilleur que IE6 ; Microsoft est de nouveau un membre très actif du Working Group et nous n’avons aucune raison de douter du fait qu’ils implémenteront correctement ce qui est stratégique pour eux.

Maintenant, tout reste soumis à la stratégie technologique que chaque compagnie veut. On peut être, à cause de la structure de son marché, très intéressé par les Media Queries et pas du tout par les fonctions étendues dédiées à l’impression de document.

Il ne faut donc pas hurler avec les loups si un éditeur de navigateur décide d’implémenter tel module de CSS 3 mais pas tel autre. C’est parfaitement normal.

9. Comment expliquez vous la lenteur de l’apparition dans les navigateurs des modules CSS3 et du support total de CSS 2.1 ?

Trois raisons principales :

  1. La complexité de l’implémentation, comme je l’ai signalé plus haut. Cela prend du temps, parfois beaucoup de temps... Il faut également se rappeler qu’une spec du W3C doit sortir avec une suite de Tests officiels et que chaque test doit être passé correctement par deux implémentations. Imaginez le nombre de tests que nous allons avoir sur une spec comme CSS 2.1 !!! Tout cela prend un temps fou, tout simplement.
  2. Le focus qu’ont donné les implémenteurs de navigateurs à d’autres fonctions réclamées à grand cri par les éditeurs de sites comme Ajax, le offline, etc. ainsi que les fonctionnalités globales du navigateurs (intégration RSS, bookmarks intelligents, etc.). On ne peut pas tout faire en même temps, tout est toujours question de priorité et d’arbitrage.
  3. Peut-être le fait que le CSS WG ne priorisait que trop peu ses actions dans le passé...

10. Certaines propriétés CSS sont de plus en plus souvent utilisées pour générer des contenus (generated-content), ce qui nuit à l’accessibilité des contenus Web par les utilisateurs finaux. La problématique de l’accessibilité est-elle intégrée en amont, dès la création des spécifications ?

Elle l’est dans le processus de maturation de nos documents, oui. A chaque sortie d’une version intermédiaire d’une spec (Working Draft, Last Call Working Draft, CR, PR, REC), les Membres du W3C et les Groupes de Travail sont invités à commenter le document. Les groupes traitant d’accessibilité font partie du lot. Nous ne sommes pas nous-mêmes des experts en accessibilité et nous devons nous reposer sur les commentaires faits par les experts.

Je reconnais que l’utilisation du generated-content (usage de la propriété 'content' sur les pseudo-éléments ::before et ::after) pose clairement problème en termes d’accessibilité. Utiliser cela pour insérer du contenu est un dévoiement de cette fonctionnalité. Il va falloir que nous y réfléchissions sérieusement.

11. Lors des échanges préalables à cet entretien, vous nous avez parlé d’une voie consistant à utiliser CSS comme un langage de transformation ? Cette voie vous semble-t-elle réaliste, et comment se positionne CSS par rapport au couple XML/XSLT ?

Non, je n’ai pas dit ça. J’ai dit que la syntaxe générale de CSS, qui est suffisamment simple pour qu’on comprenne en gros comment cela marche en un coup d’œil, peut être réutilisée pour faire autre chose que de la présentation, par exemple des transformations. Imaginez la règle suivante :

  b {
    transform-element: span[style+="; font-weight: bold"];
  }

dans laquelle on utilise une propriété de transformation prenant pour valeur un sélecteur (avec un sélecteur d’attribut nouveau). Appliquons cela à un document HTML qui contient des élements "bold". Hop, ils sont tous automagiquement transformés en <span> avec un style équivalent à <b>. Super-simple, bien plus lisible que XSLT, trivial à apprendre si on connaît déjà CSS. Voila ce qu’on pourrait aisément faire en réutilisant la syntaxe des CSS et ses sélecteurs ; c’est d’ailleurs pour cela que les sélecteurs s’appellent Selectors et pas CSS Selectors.

La XMLisation de CSS est une vraie arlésienne qui nous fait souvent rire. On en fait même des blagues du 1er avril... Nous n’avons pour le moment aucun plan pour XMLiser les CSS. Je dirai même plus qu’aucun des membres du CSS WG n’a jamais exprimé ce souhait.

12. Peut-on espérer voir apparaître de vrais outils de création de sites WYSIWYG utilisant la totalité des possibilités données par CSS (stylage des contenus, positionnement, création de templates conformes) ?

J’espère bien ! Je suis moi-même en train de m’y atteler dans le futur successeur de Nvu. Il est clair que pour l’instant les éditeurs Wysiwyg en sont encore au b-a-ba de ce que permet CSS.

Mais il faut bien voir que l’on n’aura jamais un outil idéal car l’outil idéal doit permettre d’éditer des documents créés à la main, par un autre outil, etc. Il faut donc analyser les règles CSS existantes dans le document, analyser les techniques qu’elles utilisent pour être cross-navigateurs, et ainsi de suite. Tout cela est d’une complexité monstrueuse.

Donc des éditeurs de nouvelle génération fonctionnant en vase clos, oui, sans aucun doute. C’est déjà énorme.

13. Quels types de jeux de tests utilisez-vous ? Acid test est-il utilisé dans certains cas, ou utilisez-vous des jeux spécifiques ?

Non n’utilisons pas directement les tests ’Acid’. Ces tests regroupent en un seul document des dizaines de tests ultra-spécifiques et complexes. Cela fait avancer le Web, oui, clairement. Mais nos suites de tests doivent tester une spec donnée et une seule, et doivent tester CHAQUE fonctionnalité de la spec... À un smiley géant ou aux graphismes d’Acid3, nous préférons en général des tests unitaires très simples résultant en une couleur verte si le test est OK et rouge sinon.

Si on regroupait n tests en un seul document à la manière d’Acid, il serait bien plus difficile de savoir quel test génère une erreur et les interactions potentielles entre les différents tests pourraient rendre l’entreprise hasardeuse. Donc tests unitaires. Beaucoup. Enormément :-)

On les développe dans le groupe même, même si nous recevons régulièrement des contributions de la part de membres du W3C. Microsoft vient par exemple de donner au CSS WG plus de 700 tests unitaires de CSS 2.1...

À propos de cet article

  • Openweb.eu.org
  • Profil : Expert
  • Technologie : CSS
  • Auteur :
  • Publié le :
  • Mise à jour : 12 octobre 2015

Vos commentaires

modération a priori

Attention, votre message n’apparaîtra qu’après avoir été relu et approuvé.

Qui êtes-vous ?
Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Suivre les commentaires : RSS 2.0 | Atom