Ce billet fait partie de la série « Dirty Hacky ». Le but de cette série est un objet critique sur les astuces de web-développement, et n'a pas pour vocation d'être une recette définitive, mais d'attirer l'audience par la polémique technique.
BANG! BANG!            BANG!

0. Je parse en HTML .357 S&W
1. Commentaires conditionnels
2. Magouilles dans les CSS
3. Du sprite explosé en petits glaçons
4. Liens serrés dans la police
5. Des Bleus et des Boss
6. Exécutions très rapides
7. Le script des bas-fonds
8. Préfixes frelatés

Commentaires conditionnels en HTML

Les commentaires conditionnels transforment l'usage d'une balise d'annotation en balise expressive. L'origine de ce hack du commentaire conditionnel est AFAIK une création de la IETeam, l'équipe de développement du navigateur MSIE. Son but est de servir selon des navigateurs un HTML différent dans le même document. Je n'ai pas souvenir qu'il aie été conçu en concertation avec les autres concepteurs de moteurs, mais au moins il a été très vite “accepté”. À l'origine, il devait faire la différence entre MSIE4 et les autres navigateurs (Netscape et Opera) pour proposer les fonctions avancées de Microsoft (eh oui !).
Actuellement, il sert plus à fournir des polyfill aux versions obsolètes de MSIE.

Si techniquement, le hack rempli parfaitement son office, philosophiquement, il n'est pas top : il rend difficile d'obtenir une hygiène XHTML pour le code destiné aux MSIE ciblés.

Il offre aussi un faux confort : on est dans un semblant de responsive, sauf qu'on utilise alors un browser targetting : on cible directement une marque précise de navigateurs, ce qui est déplorable. On cherche même pas à savoir si la fonction marche proprement (ou l'inverse), on se base sur le comportement d'une marque de navigateur. Ce qui veut dire qu'on avance empiriquement, sans se préoccuper que les mêmes tares s'appliquent à un autre navigateur, ou qu'il n'en soit pas affligé. Cela est déjà arrivé : MSIE 5.2 sur Macintosh était largement plus avancé que la version 5.5 sous Windows, merci à Tantek Çelik.

Pour vous montrer un exemple de commentaire conditionnel bordélique, je vais reprendre mon exemple du billet sur la dégradation élégante :

<audio controls="controls" [...] />
    <!--[if IE]>
      <object classid="clsid:D27CDB6E-[...]" codebase="http://download.macromedia.com/[...]">
    <![endif]-->
    <!--[if !IE]> <-->
      <object type="application/x-shockwave-flash" data="/interface/player_mp3.swf">
    <!--> <![endif]-->
        <param name="src" value="/interface/player_mp3.swf" />
        [...]
    </object>
</audio>

La première déclaration de la balise <object></> est à destination de MSIE versions 9 et inférieures qui ne comprend les plugins qu'en terme d'index dans la base des registres de MS-Windows. Leur servir la déclaration standard ne mène à rien. La deuxième déclaration utilise elle le système standard, s'appuyant notamment sur le type-mime pour appeler le bon logiciel client. En terme de lisible, j'ai vu mieux.

Les commentaires conditionnels sont définitivement bannis à partir de IE10. La IEteam souhaite ainsi marquer le coup : ils veulent aller vers la modernité et les standards. Abandonner les commentaires conditionnels, c'est faire oublier l'image désastreuse laissée en héritage par leurs prédécesseurs. Imposer ce choix radical, c'est aussi inciter le monde du webdesign vers des pratiques plus génériques, notamment la detection feature ou utiliser les media target des css.

Commentaires conditionnels en JScript

L'équivalent existe pour le javascript, pardon, le JScript by Microsoft™, et je le prouve :

/*@cc_on
  interprété que par MSIE

  @if (@_jscript_version == 10)
    Uniquement par MSIE10
  @end

@*/

Syntaxiquement, on est à la fois dans les commentaires expressifs, et proche des directives de compilations de certains langages. Personnellement, j'aime pas trop avoir du code expressif en commentaires.

Pourtant, j'adore les commentaires formatés. J'adore le JAVADOC, mes IDE dévorent le JAVADOC, mon code transpire du JAVADOC car il sert à aider à formater des commentaires non indispensables au code, tout en aidant fortement à sa compréhension. JAVADOC est un langage de mise en forme, comme le HTML et intervient comme un véritable ARN intron, l'imprécision n'y est pas dramatique.

Au contraire, je déteste les commentaires expressifs comme Doctrine et sa notation PHP, car ce dernier dicte la construction de la base de donnée en utilisant un autre métalangage. Doctrine utilise les commentaires comme directives d'interprétations. En plus, cette notation n'a qu'une implémentation incomplète par rapport à son implémentation YAML. C'est notamment le cas dans Symfony 2.1, et pourquoi je trouve l'ORM de CakePHP 2.3 plus cohérent car dans le PHP exon.

Logiquement, j'aurais plus préféré une variable globale, genre navigator.jscript_version, cela aurait donné une conditionnelle toute propre. Mais bon…

Si le commentaire conditionnel des JScript est toujours présent dans IE10, il faut quand même se faire une raison : la detection feature, c'est logiquement mieux. Et là, je suis surpris que la IEteam ne l'aie pas supprimé.

To be continued

Dans le prochain épisode : « Magouilles dans les CSS ».

En attendant, les pisses-froids des ligues de vertus et des droits de la défense peuvent hurler ↓ plus bas. Et non, InfestedGrunt, les commentaires ne sont pas conditionnels.