ClearideazLa tentation de recourir à des hacks est grande lorsque l’on commence à se lancer dans l’intégration d’un site web. Lorsque l’on s’aperçoit que la page développée s’affiche différemment d’un navigateur à l’autre, on se dit très souvent que c’est le navigateur (Internet Explorer pour ne pas le citer) qui interprète le code ou la feuille de style n’importe comment.
Cette réaction est plus ou moins justifiée. Nous sommes tous conscients des lacunes du navigateur Microsoft et plus particulièrement des versions antérieures à la 7. Toutefois, ce n’est pas une raison pour charger sa feuille de style de propriétés invalides en prenant comme bouc émissaire le navigateur de Monsieur Redmond.
Une feuille de style doit, au même titre que le document XHTML, passer l’épreuve du validateur W3C. Ce n’est pas en insérant des « _width: » ou encore de « %margin: » dans votre CSS que vous pourrez vous vantez de faire un site au codage propre. J’irais même jusqu’à dire que les hacks sont bons pour les fainéants la plupart du temps.
Dernièrement, j’avais fais remarquer à un intégrateur remonté contre IE que notre boulot perdrait de l’intérêt sans ces soucis de compatibilité. Même si j’affirmais cela ironiquement, je trouve passionnant de découvrir pourquoi telle propriété ne fonctionne pas de la même manière d’un navigateur à l’autre et surtout, comment y remédier.
Les hacks que l’on pourrait éviter
Les images PNG
Prenons l’exemple du PNG. Beaucoup de webmasters s’extasient devant les possibilités de ce format d’image. L’utilisation des différentes couches alpha de transparence offre effectivement de nombreuses possibilités. Seulement voilà, ce format n’est pas pris en charge par les anciennes versions d’IE. Le hacker en herbe viendra me faire remarquer que l’on peut remédier à ce problème en utilisant la propriété CSS DX.Transform dans la feuille CSS ou dans un fichier .htc. Cette utilisation pose plusieurs soucis :
- La feuille de style n’est pas valide W3C.
- La feuille CSS n’est pas censée intégrer ce genre de propriétés ou faire appel à des fichiers chargeant du JavaScript.
- Ce hack fait appel au moteur Direct X et selon la version, une simple image peut faire bugger le système d’exploitation, ce qui est, vous en conviendrez, un peu gênant…
Si vous souhaitez vraiment utilisez le PNG sur Internet Explorer, appelez plutôt un fichier JavaScript pur pour arriver à vos fins.
Parfois, un simple découpage de l’illustration au format GIF ou même une image JPEG placée intelligemment peut offrir au visiteur le même effet. Le PNG n’est pas une fin en soit.
Les pseudo-classes
Concernant les pseudo-classes, évitez également de passer par un fichier .htc dans votre feuille de style pour intégrer le :hover sur une balise div ou un :target sur une tout autre balise. Encore une fois, si cette utilisation est requise, passez par de pures fonctions JavaScripts.
Un problème de taille !
Arrêtons de nous prendre le chou avec les débats philosophiques sur le model box ou autre double-margin. Ces problèmes peuvent être aisément contournés. De plus, vous le verrez par vous même, quand on commence avec des hacks de placement ou d’ajustement de dimension, on en finit plus. Les hacks attirent les hacks 
Comme vous pourrez le constater sur l’exemple suivant, les soucis de padding ou de margin peuvent parfois être causés par une simple propriété qui n’a pas lieu d’être. Pour être certain de contrôler pleinement votre mise en page, efforcez-vous de tester plusieurs méthodes de positionnement sans passer par les hacks et testez le résultat sur différents navigateurs. Il y aura toujours une méthode qui fasse plaisir à tout le monde
Pour résumer
Avant de se décider à utiliser un hack, il faut d’abord se questionner sur les autres alternatives valables. Dénigrer IE sans chercher plus loin n’amènera rien de bon. N’intégrez pas de fonctions JavaScripts dans votre feuille de style par le biais de fichiers .htc mais préférez un fichier JavaScript pur. N’abusez pas du format PNG et ne l’utilisez qu’en dernier recours. Privilégiez l’utilisation de « !important » aux notations bidons telles que « _width: » ou encore « %padding: ». Les hacks CSS c’est taboo, on en viendra tous à bout.
Quelques précisions s’imposent
Au regard de cet article, on peut se demander ce qui est à ranger dans la catégorie des hacks ou non. Si je voulais résumer, j’engloberais les éléments qui ne valident pas la feuille CSS mais voici une petite liste détaillées :
- Dans un premier temps, j’inclus l’ensemble des propriétés mal orthographiées : « _width: », « %padding: » par exemple.
- Les inclusions de fichiers .htc pour faire appel à du javascript par exemple.
- Les propriétés CSS non reconnues par le W3C tel que « opacity ».
- Les propriétés en double pour une même classe ou ID (deux propriétés de taille pour un même bloc).
- Les appels à Direct X dans la feuille de style.
Et voici ce que je ne considère pas comme des hacks :
- Les sélecteurs non reconnus par tous les navigateurs mais valides W3C tel que « div > p » (logique non?).
- Les propriétés non reconnues par tous les navigateurs mais valides W3C. « min-height » en est un exemple.
- Les feuilles de style appelées par des commentaires conditionnels (même si on s’en passerait bien…)
« »"La feuille CSS n’est pas censée intégrer ce genre de propriétés ou faire appel à des fichiers chargeant du JavaScript. »" »
C’est oublier XBL2 qui est justement en préparation et qui propose un principe similaire. XBL dans sa première version est déjà sur Gecko.
Quant à la validation ça reste de la validation, ce n’est pas un objectif en soi, juste un moyen. Quel est l’objectif d’acces au contenu qui est mis en échec si tu ajoutes un htc pour palier les problèmes de IE ?
Je ne dis pas que c’est forcément la voie à prendre mais tu as un objectif (publier pour un maximum de monde), des contraintes (accessible sur différents navigateurs) et des principes (ne pas forcer l’accès via un logiciel unique propriétaire). Tu disqualifies des méthodes utiles avec des arguments qui aident tes objectifs sans casser ni tes contraintes ni tes principes.
Après tout si tu fais autrement, tant mieux. Mais là où ça commence à poser problème c’est quand tu conseilles de passer par !important. Le !important est là pour … ce qui est important, pas pour bidouiller et contourner les priorités. (d’ailleurs, j’emploie bidouiller, la traduction de « hack » à dessein, il s’agit bien d’un hack : d’une bidouille). Parce que là tu vas poser un problème concret à tous ceux qui ont une feuille de style utilisateur un peu différente de la tienne.
Tu remplaces un truc qui fonctionne en pratique avec des objections théoriques, par un truc qui fonctionne correctement en théorie mais qui a des problèmes pratiques. Pas sûr qu’on y gagne.
(j’en profite même si ça n’a rien à voir : Bleu très clair 11px c’est illisibe pour écrire un commentaire, pas assez de contraste. Il faudrait grossir et assombrir, sérieusement.)
Répondre
Bonjour,
A priori l’underscore devant une propriété n’est pas un hack à proprement parler, puisque les recommandations n’interdisent pas ce caractère. Il se trouve que seul IE (pour le coup, c’est balot…) est conforme
Répondre
@Eric : Par rapport à ma remarque sur le javascript intégré dans une feuille de style, je le ré-affirme, une feuille de style ne sert en aucun cas à ça. Notre objectif est de réaliser des sites accessibles, non-obstrusifs. Pour moi, un site est composé de plusieurs couches : Un langage serveur (PHP, ASP) pour rendre le site dynamique, l’espace dédié aux données (bases MySQL, fichier XML), le document HTML, la couche javascript éventuelle et la feuille de style (CSS). Séparer ces différentes couches permet d’organiser le site. On peut se passer de fichier htc en utilisant un fichier javascript pur et c’est beaucoup plus règlementaire.
Pour ce qui est de la validation, il est certain que ce n’est pas une fin mais les standards restent les standards. La validation n’est pas ce qui détermine le niveau d’accessibilité du site mais il pose une base. Commencer par un code propre est déjà une grande étape.
Je dirais que je préfère organiser la création d’un site web sans passer par des raccourcis qui n’ont pas de sens. La feuille de style ne doit incorporer que des propriétés de style. Le javascript permet d’ajouter des fonctionnalités à la page. D’ailleurs, pour ce qui est du PNG, je trouve que les webmasters se laissent souvent trop vite aller à la solution de facilité. Parfois une bonne vieille image JPG ou GIF peut faire l’affaire et peser moins lourd au final qu’une image PNG associée à un script pour gérer l’affichage sur IE. D’ailleur, sur une de mes réalisations, j’avais été tenté par le PNG : voilà le début d’une première version. Puis je me suis dis que je pourrais très bien m’en passer dans une seconde version.
Concernant !important, à la base, il ne s’agit pas d’un hack. Le W3C reconnait la présence de cette syntaxe dans la feuille de style. Il s’agit en fait de différencier les propriétés de style auteur des propriétés utilisateur. Pour plus d’info, il y a la doc du W3C. Pour ma part, ce n’est pas non plus une excellente méthode mais c’est beaucoup moins crade que d’utiliser des syntaxes pourries et encore une fois, c’est à utiliser en dernier recours.
@bro : c’est toléré on va dire
mais ça fait vraiment désordre dans la feuille de style. Quand je vois des feuilles de style avec des déclarations dans le genre :
#header {width:650px;
width:620px !important;
_width: 625px;
%width: 630px;
}
C’est vrai que je trouve ça un peu limite
Cet article est, je vous le confirme, une vision personnelle. Je n’ai pas la science infuse mais j’ose me dire que cette démarche va dans la logique des choses. Des concepts ont été introduit avec XHTML / CSS, l’accessibilité, le javascript non-obstrusif. Il revient maintenant aux intégrateurs et programmeurs d’utiliser ces ressources sans aller à l’encontre des grands principes établis.
Répondre
L’intégration web, c’est une suite de compromis entre de nombreux paramètres plus ou moins importants.
Dans ce que j’écris sur mon blog, j’essaie d’être aussi proche que possible de ma pratique réelle, en restant pragmatique par rapport au « respect » des standards.
Parfois, une fois le site terminé, on se rend compte qu’on a « merdé » quelque part et qu’on aurait pu organiser le code html différemment etc.
Malheureusement, les contraintes en terme délai ne permettent pas toujours de réfléchir sereinement aux différentes options et stratégies de conception et surtout, une fois que le site est livré, il est quasiment impossible de dire « attendez, je crois qu’on pourrait optimiser deux ou trois trucs »…
Au mieux, les corrections seront faite lors d’une refonte.
Le web est vivant et on court toujours après des mises à jours, des corrections de bugs qui créent d’autres bugs, à des procédés nouveaux qu’il faut prendre le temps de décortiquer et tester avant de passer en production, etc.
Bref, ce qu’on appelle les « standards » ne sont en fait que l’ensemble des technologies reconnues par l’ensemble du marché à un moment donné par le biais des recommandations dont il est important de connaitre la raison d’être
Répondre
Sur HTC.
Ah mais on est d’accord sur le fond pour la séparation. On sépare bien contenu – présentation – comportement. Là où on diverge c’est sur la question suivante :
Une bidouille pour gérer les images avec transparence appartient à la couche présentation ou à la couche comportement ? Il s’agit bien de parler de présentation et pas de comportement du site. Donc si, ça aurait au contraire tout à voir avec la feuille de style, d’ailleurs c’est là que ça se trouve si on ne considère pas le bug MSIE sur le PNG.
Il s’agit d’une correction d’un bug CSS, c’est quand même vachement plus logique et normal de l’attacher à la CSS que de l’attacher au contenu HTML (qui n’a rien demandé et qui lui fonctionne très bien).
Maintenant à la limite peu importe. Je ne te demande pas de mettre du javascript dans ta feuille de style. Le javascript en question restera dans son propre fichier HTC. Que tu considère ce fichier comme du comportement ou de la présentation ne gêne pas. Par contre contenu, présentation et comportement doivent forcément être attachés ensemble. Et vu qu’on n’a pas de surcouche qui attache les trois, il faut forcément faire la liaison de notre comportement soit dans notre contenu (ce qui n’aurait rien à y faire), soit dans la présentation (ce qui comme tu le dis n’a rien à y faire non plus).
J’ai l’impression que ton problème c’est surtout que tu considères que le comportement ça doit être du pur javascript lié dans le HTML, et pas un format tiers ou une liaison dans la feuille de style. Je pense ou j’espère que tu révisera ta position quand XBL2 sera prêt au W3C, ce qui ne tardera pas à arriver. Si la syntaxe CSS est utilisée c’est justement parce que ces comportements (XBL et HTC sont assez proche sur le principe) sont finalement quasiment des présentations qui sont affectés au contenu. Il s’avère que ces présentations sont programmatives et pas déclaratives, mais c’est quand même beaucoup plus proche de la présentation que du contenu. Et surtout c’est beaucoup plus facile à les maintenir là.
En voulant absolument tout gérer dans du javascript pur lié au contenu (et pas dans du demi déclaratif lié à la feuille de style) tu fais le chemin inverse de ce vers quoi on se dirige partout (et oui, au W3C aussi).
Maintenant pour répondre à ta première phrase : non, ça ne devrait pas servir à ça. Maintenant rien ne devrait servir à ça. Il ne devrait pas y avoir de problème au départ. Par contre, si on veut corriger le problème alors si : HTC/XBL ça sert justement à faire ce genre de comportement. C’est un outil dessiné pour ça. Le seul reproche que tu peux faire à HTC c’est de ne pas être standardisé ou compatible, mais vu qu’il s’agit de corriger le bug d’un navigateur particulier et ciblé, ça n’entre pas vraiment en ligne de compte (ton bug non plus il n’est pas compatible
Pour le !important :
Hack ça veut dire « bidouille » en gros. Utiliser une propriété qui n’est pas faite pour dans l’optique de palier un bug du navigateur, je vois mal comment appeler ça autrement.
Oui sinon ça existe dans les specs (ceci dit le fait d’ignorer _width c’est dans les specs aussi hein). C’est juste que ce n’est pas fait pour ça et que en le faisant tu empêches justement ton utilisateur d’avoir une feuille de style efficace de son côté. Les syntaxes pourries elles n’ont presque aucun défaut pour l’utilisateur. La tienne elle lui fera des problèmes. Aimer les « solutions élégantes » c’est bien, mais il ne faudrait pas que ça se fasse aux dépends de l’utilisateur, c’est tout.
C’est le gros problème de ce qu’on a fait ces dernières années en reveillant les gens sur la validation. Oui valider le code c’est bien, mais ce n’est pas parce qu’il valide que c’est mieux. Un <blockquote> utilisé pour faire de l’identation dans le HTML ça valide. Un code CSS qui gère cette même indentation avec quelques hacks pour le box model ça ne valide pas. Pourtant le second est clairement mieux. L’exemple n’est pas totalement innocent car la problématique est la même que pour ton !important : c’est la perversion d’un élément qui n’est pas là pour ça. Certes « techniquement ça valide », mais l’utilisation que tu en fais elle elle n’est pas du tout valide par rapport aux specs.
Pour moi détourner un élément existant de son rôle (ce que tu fais avec !important) c’est bien plus grave que d’utiliser un élément inexistant et non perturbant, parce que ça peut avoir des conséquences bien plus embêtantes que le simple « je ne comprends pas donc je n’utilise pas » qui est la règle de base dans les specs HTML et CSS.
Sur le PNG :
Je te met au défi de me trouver une image réelle qui passe mieux en GIF qu’en PNG. quand il a un réglage équivalent en profondeur de couleur et en transparence le PNG a toujours une meilleure compression que le GIF, au pire elle est équivalente à moins de 100 octets près. Si tu trouves des résultats différents c’est probablement que tu utilises plus de couleurs dans le PNG. C’est vrai même pour la question de transparence : si tu peux accepter un GIF alors tu aurais pu faire un PNG8 avec une transparence binaire, ce qui passe très bien sous MSIE. Tu n’aurais de toutes façons pas eu besoin de htc ou d’une bidouille js.
Le Jpg est une autre histoire, ça dépend de ton type d’image et tu ne devrais même pas te poser la question : photo ou décoration ->jpg, élément d’interface ou texte ou logo -> png.
(rien à voir encore une fois, mais ta validation me refuse le é majuscule pour mon prénom et l’espace pour ajouter mon nom)
Répondre
Il m’arrive aussi de me dire que j’aurais pu coder différemment la page. Comme j’ai déjà pu le dire sur un autre article, toute interprétation sémantique est contestable. Mon but est avant tout de limiter au maximum l’usage de balise inutile. Ca me rebute par exemple de devoir encadrer un texte avec deux conteneurs à base de div pour créer un cadre arrondi mais parfois on est poussé par les contraintes du design.
Mais pour ce qui concerne les hacks, je me refuse à les utiliser à tort et à travers. Lorsque l’on doit maintenir un site avec une feuille de style hacké à gogo, on se rend vite compte que ça devient ingérable. C’est du temps gagné à court terme. En s’efforcant d’intégrer un site sans hack, on perd peut être du temps sur le moment mais ce temps sera vite rentabilisé par la suite
Présenté comme ça, c’est loin d’être idiot
Après c’est encore une fois une question de principes. Si on considère ça comme une couche présentation, alors ta vision des choses est appropriée, si au contraire, on situe cela sur la couche comportement, on évitera de placer du .htc dans la feuille de style. Je trouve beaucoup plus clean de laisser à la feuille de style le soin d’appliquer des propriétés CSS et au javascript la tache d’executer des fonctions javascript. Et d’ailleur, je serais plus précis en évitant de parler d’affichage mais plutôt de style puisque c’est bien de cela dont il s’agit avec CSS
Ce qui me gène, c’est de considérer que c’est à la feuille de style d’implémenter une fonction d’interprétation des couches alpha du PNG
Il faut constamment se remettre en cause et donc s’il le faut, je réviserais ma position. C’est comme ça que l’on avance
Tout à fais d’accord, et justement mon objectif, c’est d’avoir une feuille de style propre et qui garantisse un affichage homogène sur l’ensemble des navigateurs.
Concernant le !important, je ne l’utilise jamais. Mais pour ceux qui se sentent contraint d’utiliser des hacks, je leur recommande de privilégier ça aux syntaxe pourries. Mais je suis un extremiste et je dirais que tout hacks est pourri
Mais on est d’accord, ça ne devrait pas servir à cela.
Je n’ai rien affirmé de tel, je dis juste qu’on peut parfois obtenir un effet quasiment équivalent. Beaucoup choisisse le PNG sans se poser la question de savoir si effectivement, son utilisation est judicieuse. Maintenant, je ne nie pas que son utilisation peut être encouragée dans certain cas.
Je pense que ça ira mieux maintenant
Dans tous les cas, c’est un débat très interessant !
Répondre
De toutes façons on peut espérer que ce genre de problème deviendra plus rare dans un an ou deux (oui, je suis optimiste
)
Répondre
Oui le jour ou on se débarrassera des vieux IE qui ont fait tant parler d’eux
Répondre
!!! Effectivement, si on se contente de faire des sites « lookés informaticiens qui fait du graphisme », et qu’on se fout totalement des attentes du client… pas de problèmes, on peu toujours faire des trucs moches, sans effets de transparence, sans flash, sans vidéo, ni sons, bref du papier en ligne quoi ! Et lorsque tu dis « passez par de pures fonctions JavaScripts. », c’est plutôt sympa pour les gens qui naviguent avec le javascript désactivé… après toute la question est : A qui mon développement est-il dédié ?
Si je m’adresse à un public non averti, il est évident que le média de référence avec lequel je suis en compétition frontale c’est la Télé… donc on use d’artifices graphiques dont le but est de provoquer un intérêt pour mon contenu… Par contre si je m’adresse à des développeurs, des Geeks de la première heure, ou mieux des « ingénieurs informaticiens », là, alors, carément pas pareil ! Au trou le graphisme à maman, et j’axe tout sur les fonctionnalités et le contenu…et là, je dirais même que la question de compatibilité de navigateur….pfffff……z’ont qu’a utiliser Firefox !
Répondre
@Dav50 : l’objectif est justement de faire des sites jolis et du plus bel effet sans pour autant passer par la solution de facilité qui consiste à foutre des hacks partout.
Si tu utilises un htc et que tu désactives javascript, tu n’auras pas non plus accès aux fonctionnalités que tu as ajouté aux navigateurs comme IE. Et j’ajouterais qu’il faut faire du javascript non-obstrusif mais tout le monde s’en doutait
Mes réalisations, pour la plupart, n’utilisent aucun hack et cela n’empiète pas sur le graphisme.
Répondre
Bonjour,
Je viens de lire avec attention votre débat qui était très intéressant. Je viendrai ajouter une solution que je vais peut être envisagée.
L’utilisation de hack est à préconiser en dernier recours on est tous d’accord la dessus. Elle survient généralement pour palier à des problèmes d’interprétations des navigateurs face aux standards. Comme les navigateurs évoluent vers le mieux (normalement), ces problèmes tendent à disparaitre. Alors pourquoi ne pas isolé les hacks dans un fichier CSS différent qui serait pour le coup non valide, mais qui permettrait de rendre valide le fichier CSS « commun ». Le jour J ou le navigateur non respectueux tombera aux oubliètes il deviendra facile de jeter avec notre feuille de style « hacks » associée.
Travaillez-vous déjà comme ceci ? Que pensez-vous de cette méthode ?
Bravo pour ce blog
Répondre
Bravo pour ce blog, sauf qu’il bug un peu sous ie6…
Répondre
Bonjour,
Pour ma part, je pense aussi que les validateurs W3C ne sont rien de plus que des outils pour développeurs qui aident à repérer plus facilement les erreurs de syntaxes qui pourraient, par exemple, poser des problèmes pour l’accessibilité ou le référencement.
Les hacks CSS ne sont pas réellement des erreurs, et nuisent en rien au code.
Aussi, les commentaires conditionnels ne sont pas des hacks.
Répondre
Cela est assez étrange de faire ce genre d’article quand on a 85 erreurs sur cette page…
Répondre
@Cohen : Cet article date d’avril 2008 et depuis j’ai changé d’optique notamment avec l’utilisation plus courante de CSS3. Alors en ce qui concerne les écritures exotiques de type _margin ou encore %padding, je reste convaincu qu’on peut s’en passer. Mon avis sur l’utilisation de !important reste le même également. On a pas à forcer le comportement d’un terminal pour le simple plaisir d’ajuster un style sur tel ou tel navigateur. Et concernant les filter, même combat. Ça n’a pas à apparaitre dans la CSS.
Tu remarqueras que les erreurs que tu as pu retrouver sur la feuille CSS sont des propriétés standardisées CSS3 mais préfixées par les navigateurs les ayant supporté avant leur support dans la spécification CSS3.
Il serait dommage de se priver des possibilités de CSS3 à cause des fameux prefixe -moz, -webkit ou encore -o.
Répondre