Le choix de mon parser CSS

J’ai décidé d’implémenter les CSS dans mon projet swinger. Le W3C propose une interface (SAC) écrite en Java qui est implémentée par deux API, Flute et Batik.

Flute est une implémentation basique de SAC, il s’agit d’un simple parser, tandis que Batik est un projet beaucoup plus vaste qui est en fait un toolkit pour le support du format SVG.

Il n’existe que très peu de documentation sur ces deux parsers, j’ai donc commencé par étudier le code source de ces deux API. Le parser de Flute repose sur un ParserTokenManager qui a la responsabilité d’extraire les éléments gramaticaux du fichier CSS. Dans l’api Batik, ce role est dévolu à la classe Scanner. Dans les deux cas, le parser est associé à un DocumentHandler qui reçoit les évènements qui surviennent lors du parcours du fichier CSS.

J’ai effectué des tests de performance pour comparer les deux parsers, et il ressort que le parser de Batik est 40 à 50% plus rapide que celui de Flute. Cette différence ne me surprend pas vraiment car le parser de Flute a été généré avec JavaCC. Il s’agit d’un outil extrêmement puissant mais qui a l’inconvénient de produire un code absolument dégueulasse.

J’ai également comparé les évènements produits par les deux parsers. Et là je suis tombé sur un os. Toute la puissance du langage CSS repose sur les sélecteurs. Tant que l’on utilise des sélecteurs élémentaires telles que des id, des classes ou des élements xml, il n’y a aucun problème. Mais dès que l’on introduit un peu de complexité en jouant sur les opérateurs, on constate des différences d’interprétation. Je ne maîtrise pas suffisament les CSS pour savoir lequel des parsers est en faute.

Il s’agit d’un problème assez sérieux, mais pas rédhibitoire. La nécessité de standardiser les usages du web vient du fait qu’il existe une grande diversité de navigateurs. Firefox, Opera, Safari, Chrome, Internet Explorer, pour ne citer que les plus connus. Dans mon cas, la nécessité de respecter les standards n’est dicté que par le soucis de bien faire. Néanmoins, compte tenu de cette différence d’interprétation, il est évident qu’il sera nécessaire de modifier le code source et qu’il ne sera pas possible de considérer le parser comme une simple boîte noire.

Cette dernière considération me fait choisir le parser Batik, car l’utilisation de JavaCC dans le cas de Flute me parait rendre l’analyse et la correction de bugs trop complexe, sans compter qu’il n’est pas totalement exclu que JavaCC soit lui-même à l’origine de cette différence d’interprétation.

Maintenant que le choix de mon parser est fait, je dois maintenant décider jusqu’à quel point je souhaite utiliser la librairie Batik. En effet, Batik propose un modèle de CSS complet accompagné d’un moteur qui implémente l’héritage et la cascade. Mais cela reste à vérifier. Je vous ferai partager mes réflexions à ce sujet lors d’un projet billet.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s





%d blogueurs aiment cette page :