Devinette ! Quel est le point commun entre les morceaux de code suivants ?
<!--[if IE 10]><html class="ie10"><![endif]-->
<!--[if IE 9]><html class="ie9"><![endif]-->
<!--[if IE 8]><html class="ie8"><![endif]-->
<!--[if IE 7]><html class="ie7"><![endif]-->
<!--[if !IE]>--><html><!--<![endif]-->-webkit-border-radius:5px;
-moz-border-radius:5px;
-o-border-radius:5px;
-ms-border-radius:5px;
border-radius:5px;Bon, à part le côté répétitif lourdingue, vous ne voyez pas ?
Ils contiennent tous les deux une licorne, une créature légendaire, inspirée du mélange d’autres créatures, elles, bien vivantes.
Dans le premier exemple, la ligne <!--[if IE 10]><html class="ie10"><![endif]--> n’a jamais existé. Microsoft a abandonné le support des commentaires conditionnels dans Internet Explorer 10, et ce dès la deuxième Platform Preview.
Dans le deuxième exemple, les lignes -o-border-radius:5px; et -ms-border-radius:5px; n’ont elles non plus jamais existé. Microsoft et Opera ont tous les deux supporté la propriété sans préfixe.
Pourtant, je tire ces exemples de code légendaire de sites récents, codés par de vrais intégrateurs, dans la vraie vie. Le premier exemple est un bon rappel que dans le métier d’intégrateur, la veille fait partie intégrante de notre travail. Et le deuxième exemple est un bon rappel qu’il n’y a jamais de bonne pratique universelle (et, non, désolé, ajouter tous les préfixes possibles pour toutes les propriétés ça n’a jamais vraiment été une bonne idée).
Nico, le
Pour le commentaire conditionnel IE10, je suis d’accord, aucun intérêt. :)
Pour les préfixes, je peux comprendre la logique même si c’est inutile dans ton exemple : si ça a été ajouté à une époque où les propriétés n’étaient pas standardisées, au moins le gars a fait l’effort de prévoir pour d’autres navigateurs « au cas où », et c’est pas si mal que ça de faire ainsi.
Nico, le
Je rajouterai même qu’il m’est même arrivé de le faire sciemment pour faire comprendre au stagiaire qui reprenait ma CSS qu’il fallait se poser la question de mettre les préfixes. Ceci dit, oui, on est d’accord, dans certains cas, c’est totalement inutile. Mais bon, que valent 2 lignes de CSS inutiles pour commencer l’éducation d’un stagiaire débutant ? :)
rivsc, le
« la veille fait partie intégrante de notre travail »
Une chose est de faire de la veille, une chose est de mémoriser ce que l’on a lu (mémoriser les supports de propriétés par navigateur/version…).
« et, non, désolé, ajouter tous les préfixes possibles pour toutes les propriétés ça n’a jamais vraiment été une bonne idée »
Quel est le pire ?
ça :
-webkit-my-property:value;
-moz-my-property:value;
-o-my-property:value;
-ms-my-property:value;
my-property:value;
ou ça :
-webkit-my-property:value;
ou peut-être encore ça :
my-property:value;
Si on est perfectionniste, on regarde quelles versions de quels navigateurs nous supportons encore et vérifier le support de chaque propriété CSS, c’est un boulot de plus que plein temps, non ?
Je tiens à préciser que mon commentaire n’est en aucun cas agressif, mais de participer à la discussion.
François "cahnory" Germain, le
C’est marrant ce post car c’est justement une problématique que j’essai actuellement de gommer via les pre-processeur. (je sais pas trop s’il serait correcte de poser le lien ici)
La difficulté que je rencontre, c’est surtout d’avoir une source fiable et complète (l’une ou l’autre ça se trouve mais les deux réunis c’est plus compliqué) de l’utilisation des préfixes par les navigateurs, en fonction de leurs versions et des propriétés. Je pense au -o-border-radius qui, comme tu le dit, n’a jamais existé mais que l’on retrouve sur beaucoup de sites (et pas que dans les sources).
Après comme dit nico, il vaut mieux une licorne en trop qu’un cheval en moins… c’est pas Can I use c’est canasson… désolé.
Kaelig, le
C’est marrant, j’ai justement passé mon après-midi d’hier à déprécier des vendor prefixes sur une codebase qui commençait à vieillir.
Ce n’est pas simple de rester à jour concernant les propriétés à préfixer ou non (et pour être honnête : dans le doute il vaut peut-être mieux trop en mettre que pas suffisamment, non ?).
Meursault, le
Concrètement, ce genre d’erreur apporte quoi comme conséquence ?
Je conçois bien qu’on se passerait volontier de lignes de codes superflues dans un fichier css bien rempli, mais au delà de ça ?
Je dirai que si on en vient à titiller la charte d’un site là dessus, c’est que finalement, il doit pas être si mal foutu que ça, nan ?
Rémi, le
@Nico : il s’agit bien d’exemple vus dans des sites lancés il y a moins de trois mois. Je comprendrais effectivement le « au cas où » de l’intégrateur un peu trop prévoyant. Par contre, tes méthodes de formation de tes stagiaires sont totalement machiavéliques. J’aime.
@rivsc, @cahnory et @kaelig : Attention de ne pas confondre une licorne (un animal légendaire qui n’a jamais existé) avec un dinosaure (une espèce préhistorique qui a eu son temps mais a disparu depuis). Je n’ai rien contre les dinosaures, même si dans un monde idéal j’estime que la maintenance et donc le nettoyage des préfixes inutiles fait partie de notre métier.
Marie, le
Pour le commentaire conditionnel dédié à IE10, comme les versions précédentes d’IE en ont toutes eu besoin, cela peut sembler logique d’en créer un ! On est tellement habitué à ce que IE nécessite un traitement spécial, de toute façon, qu’on est presque surpris d’apprendre qu’IE10 ne supporte plus les commentaires conditionnels. Heureusement ton article est là pour dissiper le doute. ;-)
En ce qui concerne les préfixes inutiles de border-radius, LESS et Compass les ajoutent automatiquement lors de l’utilisation des mixins associés. Pour Compass, cela est déjà corrigé dans la version de développement, et devrait l’être officiellement bientôt.
Cela étant dit, je rejoins Nico pour dire qu’il y a des erreurs bien plus graves en intégration que des lignes de code inutiles. Mais tu as bien fait de le souligner ! Je suis quand même déçue que ton article ne contienne pas de véritable licorne, majestueuse et pailletée.