Une terminologie de la conception web

Par Holly Bergevin et John Gallant

Les nouveaux venus dans le domaine du web design découvrent souvent que leurs prédécesseurs ont laissé dans leur sillage un jargon riche, fait d'expressions codées et autres mots à la mode. Il n'est pas facile de se frayer un passage à travers ce maquis de termes et de définitions, et celui-ci peut s'avérer un sérieux obstacle à la maîtrise des fondamentaux. Cet article va faire la lumière sur ce qui pourrait ressembler à première vue à une véritable langue étrangère.

Balises vs Éléments

Certains auteurs confondent ces deux termes, mais il s'agit de deux choses très différentes. Le mot balise se réfère au segment de code HTML délimité par des chevrons (< et >) et s'écrit (par exemple) comme <html>.

La plupart des balises vont par paires, avec une « balise ouvrante » et une « balise fermante ». L'élément entouré par ces balises est donc décrit entre la balise ouvrante et la balise fermante. Le <html> que nous venons d'écrire est une balise ouvrante, et avec sa balise fermante </html> il délimite l'intégralité de l'élément HTML. Notez la barre oblique juste avant le nom de l'élément dans la balise fermante. C'est elle qui établit le statut de la balise en tant que fermante.

Un petit groupe d'éléments sont appelés « vides », comme <img src="image.jpg" alt="" /> (élément image) et <meta http-equiv="content-Type" content="text/html; charset=iso-8859-1" />, qui est une « méta-balise » fréquemment utilisée. Ces balises sont des entités individuelles qui n'entourent donc aucun « contenu », bien qu'elles puissent « appeler » du vrai contenu dans une page. Les éléments vides comme <img src="image.jpg" alt="" /> comportent une barre oblique précédée d'un espace juste avant le chevron final, mais seulement pour les pages en XHTML ou en XML. Les pages HTML ne sont pas obligées d'avoir cet espace+barre oblique à la fin d'un élément vide.

Donc c'est quoi « l'Élément », alors ?

En termes simples, un élément est tout ce qui apparaît entre une paire de balises ouvrante et fermante. On se fiche du nombre de trucs à l'intérieur, ils font tous partie de l'élément. Ce qui veut dire qu'un ou plusieurs éléments peuvent être dans un autre élément. On appelle ce phénomène « imbrication », et l'élément imbriqué est appelé un « enfant » de l'élément « parent ». On dit que les éléments « parents » « contiennent » ou « entourent » leurs enfants. Ces termes signifient qu'un élément complet, avec ses balises, se trouve entièrement à l'intérieur d'une autre paire de balises, le plaçant donc à l'intérieur de cet élément.

L'apparence à l'écran d'un élément n'a rien à voir avec sa nature. Les styles, les attributs, le type d'un élément peuvent tous affecter son apparence mais n'altèrent pas son contenu réel. De plus, il n'est pas permis d'avoir un élément en partie à l'intérieur d'un autre, et en partie en-dehors. C'est ce qui s'appelle une « imbrication incorrecte ».

Div vs Calques

Une source énorme de confusion a pour origine un composant de Dreamweaver appelé « calques », qui permet aux éléments d'une page d'être placés au-dessus d'autres. Ces calques sont structurés dans le code en tant que « div ». En conséquence, beaucoup croient que les div sont des calques, mais ce n'est pas le cas.

Un div est l'abréviation de division, et c'est un élément créé par le W3C pour servir d' « élément bloc » générique quand il n'est pas souhaitable d'utiliser un des éléments blocs plus anciens, comme <h1> ou <p>. Ceux-là et les autres éléments sémantiques transmettent du sens à leurs contenus, en déclarant à la face du monde « Voici un titre » ou « Voici un paragraphe ». Toutefois, ces vieux éléments sémantiques sont aussi associés à des comportements par défaut. Leurs marges et remplissages sont généralement pré-réglés, de manière variable d'un navigateur à l'autre. D'autres comportements plus obscurs peuvent aussi s'appliquer.

Pour cette raison, il a été jugé sage d'ajouter à HTML un élément bloc tout simple, dépourvu de tout le bagage accompagnant les éléments « traditionnels ». C'est ainsi qu'est né le « div » et avec lui l'élément « span ». Le span sert en gros à envelopper un texte pour y appliquer un style, indépendamment du texte autour de lui. Un span est « en-ligne » comme du texte, au lieu d'être « bloc » comme l'élément div, et suit les mêmes règles de rendu que le texte. Par exemple, si vous voulez appliquer une couleur de fond à une phrase unique au milieu d'un paragraphe, placez une balise span de chaque côté de la phrase, et appliquez votre style à ce span.

Donc, un calque Dreamweaver n'est rien d'autre qu'un div qui a été positionné en absolu, ce qui donne à ce div les mêmes comportements que n'importe quel autre élément « absolu ». Quels sont ces comportements ? Eh bien ils sortent du périmètre de cet article, mais jetez un œil à notre article Flowing and Positioning pour tous les détails. Et non, nous n'allons pas définir « périmètre » !

Classe vs ID

Confus pour beaucoup, ce sujet est vraiment simpliste une fois qu'on l'a compris. Il y en a qui se demandent : « Lequel dois-je utiliser ? L'un est-il meilleur que l'autre ? Hein ?! » Si vous vous reconnaissez dans ces questions, préparez-vous à pousser un délicieux soupir de soulagement.

Une classe est simplement un groupe de styles auquel on a donné un « nom » de classe, pour pouvoir l'associer à un élément. Quand une classe est créée dans la feuille de style, on peut l'appliquer à la balise ouvrante de n'importe quel élément. C'est un peu comme une baguette magique que vous pouvez pointer vers un élément en disant « Toi ! Obéis à ces styles ! » Comme toutes les baguettes magiques, vous pouvez la pointer encore et encore, stylant des éléments à gogo. Boum, boum, boum ! Allez-y, stylez votre page jusqu'aux extrêmes, si vous voulez. Le pouvoir de la classe est tellement grand qu'on ne peut plus s'en passer !

Tout ça est bel et bien bon, jusqu'à ce que débarque ce truc, là, ID. Il a l'air de faire la même chose que les classes, alors quelle est la différence ? En fait, la seule vraie différence est qu'ID doit être utilisé seulement une fois par page. Pourquoi est-ce nécessaire ? À cause d'un truc appelé le « DOM », ou « document object model ». Il est utilisé principalement par des scripts pour contrôler dynamiquement les éléments d'une page, et ces scripts sont très pointilleux, en particulier sur « l'identité » des éléments. Vous saisissez ? Quand on applique un ID, on attribue à un élément non seulement des styles, mais aussi une identité précise. Si cet IDIDest utilisé sur plus d'un élément, le DOM ne saura pas lequel vous voulez contrôler, provoquant une erreur de script.

Dans le « monde réel », les navigateurs vous permettront d'utiliser un ID plus d'une fois, généralement sans problème d'affichage, mais seulement si aucun script n'est utilisé. Il vaut donc mieux prendre les bonnes habitudes tout de suite. De cette manière vous ne serez pas « surpris » plus tard. Vous n'avez sans doute pas besoin qu'on vous explique ce mot-là.

Attributs vs Propriétés

Attributs et propriétés sont souvent confondus, mais ils n'ont rien d'identique. Un attribut est placé directement dans une balise HTML ouvrante, et affecte le contenu de l'élément que cette balise délimite. Un bon exemple serait <table bgcolor="#c0c0c0" width="300">. bgcolor et width sont tous les deux des attributs de ce tableau. La syntaxe d'un attribut comprend toujours le nom de l'attribut, suivi d'un signe « égal », et de la valeur de l'attribut. Les guillemets autour de la valeur (comme dans l'exemple précédent) sont optionnels pour des pages écrites avec un doctype HTML, mais obligatoires pour des pages XHTML et XML.

Les propriétés CSS sont (généralement) utilisées dans une feuille de style. Elles ont aussi des valeurs qui définissent l'apparence d'un élément. Certaines propriétés sont similaires aux attributs, par exemple {width : 300px ;} mais la plupart peuvent avoir beaucoup plus de valeurs possibles que n'importe quel attribut. Remarquez la différence de syntaxe pour la propriété width et sa valeur, avec l'ajout obligatoire à cette dernière d'une unité de longueur. L'attribut bgcolor est remplacé en CSS par la propriété background-color. Cette propriété utilise des valeurs similaires à celles disponibles pour l'attribut, ainsi gcolor="#c0c0c0" devient {background-color: #c0c0c0;} dans une feuille de style.

clear="all" est une paire attribut/valeur de HTML, alors que {clear: both;} est la paire propriété/valeur équivalente en CSS. Beaucoup de gens habitués à l'attribut HTML clear vont écrire {clear: all;} dans leur règle CSS au lieu d'employer la syntaxe correcte {clear: both;}. Malheureusement, il est peu probable que {clear: all;} fonctionne, parce que la valeur d'attribut incorrecte all est utilisée au lieu de la valeur de propriété both. Bref, ces deux systèmes comportent de nombreuses différences, tout comme leur syntaxe.

Le W3C a « déclassé » certains attributs HTML , c'est à dire qu'ils devraient être évités au profit de leurs équivalents CSS. align est l'un de ces attributs, tout comme bgcolor d'ailleurs. Cela dit, ils passeront la validation dans des pages au doctype non strict, et peuvent donc être utilisés si nécessaire. De nombreux autres attributs comme href et src ne sont pas près de nous quitter.

L'attribut Style

Une source de confusion possible est la syntaxe des styles CSS « en-ligne ». Ces styles sont contenus dans la balise ouvrante d'un élément, affectant cet élément et lui seul. Il s'agit pourtant toujours de CSS. Comme seuls les attributs sont autorisés dans une balise ouvrante, un nouvel attribut a été créé pour gérer le problème. C'est l'attribut style.

L'attribut style est utilisé pour appliquer des styles à base de CSS directement à l'intérieur de la balise ouvrante d'un élément, et ressemble à ceci : style="width: 300px; background-color: #c0c0c0;". C'est comme une mini-feuille de style complète, nichée dans une balise via l'attribut style.

Notez que l'attribut style suit la même syntaxe que les autres attributs, sauf que sa valeur consiste en une ou plusieurs propriétés CSS suivies de leurs valeurs respectives. L'attribut style exige aussi l'application de guillemets autour des paires propriété/valeur qu'il contient. Pour nous, l'attribut style est pratique pour des tests de style rapides, et aussi pour ajouter des styles à des articles comme celui que vous lisez en ce moment. Ils complètent une feuille de style qui ne peut pas être modifiée par les auteurs. Exemple :

~ Qui a volé l'orangedu marchand ? ~

Feuilles de styles externes, intégrées, et en-ligne

À la différence des attributs HTML qui doivent résider dans les limites d'une balise ouvrante, les styles CSS se présentent sous la forme de « feuilles de styles » ou de listes de règles de styles. Ces feuilles de styles peuvent être appelées depuis un fichier externe (aussi appelé fichier distant), intégrées dans l'élément head d'un document, voire balancées directement dans la balise ouvrante d'un élément en tant que style en-ligne. Toutes ces feuilles de style sont appliquées à une page, mais les différences entre elles peuvent désorienter les non-avertis, et impacter leur ordre dans la « cascade ».

Les feuilles de styles externes sont appelées depuis le head d'un document à l'aide de l'élément <link>, ou de l'élément <style>qui importe (avec @import) la feuille de style. Des feuilles de styles distantes additionnelles peuvent être importées depuis une feuille de styles externe, toujours en utilisant @import dans cette dernière.

Les feuilles de styles intégrées sont les règles contenues à l'intérieur de l'élément <style></style> qui se place dans le head d'une page. Typiquement, si une page contient des styles intégrés, on ne trouvera qu'un élément <style>, mais head peut en contenir plusieurs. Les styles en-ligne, décrits précédemment, sont ceux appliqués à un élément à l'aide de l'attribut style.

Il n'est pas permis d'avoir deux attributs conflictuels au sein d'une même balise. Par exemple, utiliser align="left" et align="right" dans la même balise serait idiot, et de fait un seul des deux serait appliqué. Vous serez peut-être surpris d'apprendre que c'est le premier attribut qui est pris en compte, pas le second. Mais comme les styles CSS sont souvent appelés depuis plus d'un endroit externe au document HTML, par plusieurs pages différentes, et qu'ils existent aussi dans le document source, il est plutôt difficile de prévoir les conflits. Le système de cascade de CSS a été créé pour prendre en charge ce type de problèmes quand ils surgissent. Étudiez Understanding the Cascade pour plus de détails à ce sujet.

XHTML1.0 vs HTML4.01

D'abord un peu d'histoire. Dans les années 1980, le SGML (Standard Generalized Markup Language) fut développé pour décrire les langages structurels en général. Le SGML est suffisamment flexible et complexe pour gérer presque tous les cas de figure. Alors que Tim Berners-Lee travaillait à installer un intranet pour les scientifiques du CERN à Genève, il développa un sous-ensemble simplifié de SGML qui devint HTML (Hyper Text Markup Language). HTML introduisit aussi la nouveauté de l'« hypertexte », qui est le « lien » que nous connaissons aujourd'hui.

Ce langage, HTML, avec sa capacité de faire des liens, devint vite populaire, évoluant dans un court laps de temps vers l'Internet que nous aimons tous. De nombreux nouveaux éléments furent ajoutés, ainsi que le support du multimédia, entraînant des problèmes d'interopérabilité des documents entre différentes plate-formes. Il devint clair que HTML en tant que tel ne pourrait pas constituer une norme à long terme, et XML fut développé dans le but de conserver la plupart des fonctions enviables de SGML sans la complexité qui rendait la vie si difficile aux programmeurs et aux créateurs.

L'un des grand attraits de XML est que les navigateurs basés sur lui seul sont beaucoup plus simples, une qualité hautement désirable pour les appareils portables et consorts. Une autre de ses qualités est qu'il fonctionne bien couplé à des choses comme MathML et Scalable Vector Graphics (SVG). MathML est un langage conçu pour afficher des formules mathématiques exactement comme elles apparaissent sur le papier, et SVG est une méthode permettant des images nettes à n'importe quelle échelle, ainsi qu'un contrôle dynamique de l'image elle-même.

C'est super, mais XHTML dans tout ça ?

L'idée derrière XHTML1.0 est de créer une version de HTML4.01 qui soit en fait du XML ressemblant à HTML. XHTML1.0 doit normalement être servi différemment des pages en HTML4.01, à l'aide du type MIME "application/xhtml+xml" au lieu de l'habituel "text/html". Cela dotera la page des mêmes avantages que les technologies avancées disponibles pour les pages XML, et dénoncera les erreurs présentes avant publication. XML doit être valide, et dans le cas contraire les agents utilisateurs ne sont pas supposés l'afficher.

Néanmoins, la plupart des pages affirmant être du XHTML1.0 sont toujours servies comme du "text/html". Quand cela se produit, la page XHTML est traitée exactement comme une page HTML, et tout code invalide sera considéré avec la tolérance coutumière des agents utilisateurs (les navigateurs) depuis des années. Donc, en fait, il n'y a généralement aucun avantage à écrire des pages en XHTML1.0, à moins d'être prêt à faire en sorte que le serveur les présente comme "application/xhtml+xml".

Notez quand même que si vous faites cela (servir la page en "application/xhtml+xml") et que les règles strictes de XML ne sont pas suivies, il se produira des erreurs. XML n'est pas tenu de tolérer les erreurs comme HTML, ce qui explique pourquoi une application XML peut être tellement plus simple et abordable (et nous nous mordons la langue pour ne pas mentionner un certain navigateur populaire qui ne comprend pas le type MIME application/xhtml+xml...)

La signification de tout cela pour le codeur web moyen qui ne veut qu'une page traditionnelle, c'est qu'il n'y a aucun intérêt à écrire en XHTML1.0. En fait, utiliser un doctype XHTML1.0 sans le servir comme "application/xhtml+xml" pourrait causer des problèmes dans le futur. En gros, si vous n'êtes pas familiers avec l'essentiel de cette discussion, vous faites probablement partie de ceux qui n'ont pas besoin de s'embêter avec XHTML pour l'instant. Vous pouvez continuer à écrire du HTML et à utiliser des doctypes HTML4.01 valides. D'accord, c'est cool d'avoir un bouton XHTML1.0 valide sur votre page, mais vous savez maintenant qu'il faut un peu plus qu'un code nettoyé et un doctype différent pour vraiment faire du XHTML correct.

Note : les trois doctypes XHTML1.0 (strict, transitional, et frameset) peuvent être servis comme "text/html". Par contre il existe un autre doctype XHTML, XHTML1.1, qui doit être servi comme "application/xhtml+xml".

Mais quelles sont les différences entre HTML4.01 et XHTML1.0 ?

L'essentiel de la différence entre XHTML1.0 et HTML4.01 réside simplement dans une rigueur accrue des règles de balisage. Pour les curieux, voici les pré-requis de XHTML1.0 qu'on ne trouve pas dans HTML4.01 :

La liste ci-dessus n'est pas exhaustive, mais elle devrait vous donner une bonne idée des différences essentielles entre XHTML1.0 et HTML 4.01. Pour plus d'informationsur le sujet, voyez les articles et spécifications suivantes :

« Positionné »

Position est une propriété CSSquis'applique à tous les éléments, à l'exception du contenu généré (en CSS 2, la propriété content utilisée en conjonction avec les pseudo-éléments :before et :after,ou les éléments dont la propriété display est établie à list-item, sont les principales méthodes pour générer du contenu).

Les valeurs possibles de la propriété position sont :

Bien que n'importe quel élément puisse effectivement être positionné, on ne parle généralement d'un élément positionné que quand sa propriété position a été réglée à autre chose que static, d'où la confusion à propos du terme « positionné ». Toutefois, en l'absence de propriété position définie, la position d'un élément est static par défaut, ce qui correspond à son flux normal. Cela veut dire qu'un navigateur affichera l'élément en suivant les règles normales de l'affichage écran, en basant la position de l'élément sur son ordre d'apparition dans le code source, de haut en bas, et sur les autres règles gouvernant l'affichage de contenu bloc et en-ligne.

Savoir si un élément a une valeur de position différente de static est important, parce que seuls les éléments en {position: relative;}, {position: absolute;}, ou {position: fixed;} peuvent servir « d'origine» ou de « bloc conteneur » à des éléments « enfants » positionnés en absolu. Les éléments blocs comme <div> ou <li>, et les éléments en-ligne comme <span> ou <strong> peuvent tous servir de blocs conteneurs à des éléments positionnés en absolu. Cela dit, les éléments en-ligne ne peuvent contenir que d'autres éléments en-ligne, pas des éléments blocs. Note : même quand un élément a été positionné, il peut contenir des éléments de « flux normal », c'est à dire qui n'ont pas de propriété position explicitement définie, et donc sont statiques par défaut.

L'utilisation d'éléments avec {position: relative;} ou {position: absolute;} comme conteneurs d'autres éléments positionnés en absolu fonctionne bien, mais {position: fixed;} n'est malheureusement pas pris en charge par IE/Windows (en clair, ça ne marche pas). IE/Win traite un élément ayant {position: fixed;} comme s'il avait {position: static;}, et le laisse dans le flux normal de la page. Dans IE5/Mac, les liens à l'intérieur d'éléments ne fournissent aucun indicateur visuel sur leur état, à moins de cliquer ou de tabuler sur eux. En d'autres termes, le curseur ne se modifie pas pour indiquer que la souris survole un lien. Quelle plaie !

On pourrait se demander pourquoi static fait partie des valeurs de la propriété position, puisque les éléments sans valeur explicite appliquent static par défaut. {position: static;} peut être employé pour transformer un élément ayant une « position » non statique en élément statique. Çela se fait soit en redéfinissant la valeur depuis une autre feuille de style (par exemple une feuille de style d'impression), soit en utilisant un script pour altérer la valeur de position. Retenez juste que static n'est pas considéré comme "positionné", même si c'est une valeur de la propriété position. Oui, c'est un peu bête, mais c'est comme ça.

Dreamweaver peut créer des éléments appelés « calques » (layers en anglais), qui sont en fait des éléments <div> de niveau bloc déclarés en {position : absolute}. Cependant, le terme « calque » n'est utilisé ni dans la spécification de HTML4.01, ni dans celle de CSS 2. De fait, on parle de « présentation par couches » (layered presentation) dans le contexte de la propriété z-index, et pas de la propriété position. Pour plus d'informations sur le positionnement en général, voyez notre article Flowing and Positioning.

Par définition, les propriétés de position ne sont pas héritées par les éléments enfants. Par exemple, l'élément enfant d'un <div> positionné en absolu n'héritera pas du {position : absolute} de son parent. Toutefois, en établissant la valeur de la propriété position à inherit ({position : inherit}), la propriété position d'un élément donné prend la même valeur calculée que celle de son parent.

Au fait, on entend parfois le terme « CSS-P » pour désigner le positionnement CSS (en anglais surtout, mais l'expression peut surgir au détour d'une conversation française - NDT). Ce terme n'a rien de différent, de spécial ou d'officiel, c'est juste une façon de se référer au positionnement en général.

« Conteneur »

Habituellement, quand les gens parlent de « conteneur », ils se réfèrent à un élément bloc qui contient un ou plusieurs éléments enfants entre ses balises. Étant donné que n'importe quel élément bloc comme <div>, <p>, ou <ul> par exemple, peut être le parent d'autres éléments, il est plus facile d'employer « conteneur » comme mot générique. Le W3C appelle ces conteneurs des blocs conteneurs.

Les conteneurs sont fréquemment mentionnés dans le contexte d'éléments positionnés en absolu. Les éléments positionnés en absolu (ou « éléments absolus ») calculent leur origine, c'est-à-dire le point à partir duquel ils sont positionnés, de plusieurs manières.

Comme il a été mentionné précédemment dans cet article, les éléments absolus, en relatif ou en fixe, peuvent servir de conteneurs à des éléments enfants positionnés en absolu. Si un conteneur parent n'est pas positionné (c'est à dire qu'il est dans le flux normal), l'élément enfant absolu ignorera son parent direct non positionné et cherchera plus loin un parent de ce parent qui est positionné. Si ce parent extérieur est positionné, c'est lui qui devient le conteneur origine pour l'élément enfant absolu. Dans ce cas, le parent intermédiaire non positionné ne joue plus aucun rôle dans le positionnement.

Si le parent extérieur n'est pas non plus positionné, l'élément enfant absolu continue sa recherche généalogique en quête d'un parent positionné, jusqu'à ce qu'il soit à court de parents. À ce moment, l'élément racine HTML est utilisé comme origine, ou bloc conteneur initial, par défaut.

Par contraste, les éléments qui ont {position : fixed;} utilisent toujours la zone d'affichage du navigateur comme origine, sans s'occuper du positionnement de leurs parents.

On dit souvent que les éléments flottants sont « retirés du flux », mais ce n'est pas tout à fait correct. Il est vrai qu'un flottant va s'étendre au-dessus du contenu qui le suit (un peu comme les éléments positionnés en absolu), mais le coin supérieur gauche de l'élément flottant restera placé exactement au même endroit où irait une boîte non flottante. Donc, tout en n'étant pas « dans le flux » comme des éléments statiques, ils sont contenus à l'intérieur de leur parent tout comme les éléments dans le flux. Le parent n'a pas à être positionné pour contenir un flottant, à l'inverse du cas d'un élément enfant positionné en absolu.

« Hack CSS »

Le terme « hack » est largement utilisé dans les différentes branches de l'informatique, et comporte certaines nuances selon le contexte, mais globalement il signifie coder d'une manière non orthodoxe dans le but d'obtenir un certain résultat. C'est aussi le sens du terme « hack CSS ». La raison d'être d'un hack CSS est presque toujours de faire en sorte qu'un navigateur obéisse à une règle qu'un autre ignore, dans le but d'avoir dans les deux cas un affichage de page web identique.

Si tous les navigateurs se comportaient de manière similaire, nous n'aurions pas besoin des hacks. Malheureusement, c'est loin d'être le cas. Les "zones floues" dans les spécifications du W3C, les bugs de programmation, voire l'incapacité à adhérer à des comportement standards pourtant acceptés, contribuent tous aux difficultés que rencontrent les codeurs CSS. Tout cela en plus de devoir apprendre CSS ! Pourquoi tant de haine...

Il y a quelques années, les navigateurs ne brillaient pas par leur capacité à bien gérer CSS, mais depuis 2001 la situation s'est radicalement améliorée. Les navigateurs basés sur Gecko (Mozilla, Camino, Netscape7, Firefox) servent maintenant d'étalon pour les autres. Parmi les autres navigateurs actuellement disponibles, citons Opera 7 (sorti en janvier 2003) et Safari (Mac OS X).

Malheureusement, Internet Explorer pour Windows s'est fait distancer. Entre 1995 et 1998, Microsoft a lancé les versions 1 à 5, et en 2001 a sorti IE6. Au moment où nous écrivons (octobre 2004), le support de CSS n'a connu aucune amélioration. De fait, très peu de progrès ont été réalisés par IE/Win en CSS depuis la version 5, il y a 6 ans.

Hack ou pas hack

Certains veulent se montrer irréprochables et codent strictement aux normes de CSS, quelles qu'en soient les conséquences. C'est une noble attitude. Toutefois, comme la plupart des "problèmes" restants se produisent dans Internet Explorer pour Windows, une stricte conformance aux normes sur un site commercial pourrait occasionner des pages "cassées" dans ce navigateur.

À l'autre extrême on trouve ceux qui ne codent que pour IE/Win, ignorant de façon innocente ou délibérée les navigateurs autres que ce "King-Kong" qu'est Explorer. Cette méthode a l'avantage de rendre la mise en page bien plus simple, mais avec le risque potentiel de perdre un certain nombre de visiteurs. Pour toute entreprise avec un volume de ventes internet élevé, même 5% de transactions perdues est un chiffre sérieux. De plus, si vous comptez toucher des professionnels avertis des choses du web, sachez qu'un nombre disproportionné d'entre eux utilise des navigateurs conformes aux standards.

Le doigt dans l'engrenage

Habituellement, quand de nouveaux codeurs commencent à apprendre CSS, ils regardent le résultat de leurs efforts dans IE/Win, ce navigateur étant installé sur la plupart des ordinateurs. Étant novices en CSS, ils expérimentent jusqu'à trouver un code qui rend bien sous IE. Mais sans le savoir ils se forment à utiliser du code non standard pour y arriver. Puis, quand ils entendent parler d'autres navigateurs et téléchargent l'un ou l'autre, ils sont choqués de voir leurs belles créations mutilées. Naturellement, ils blâment ces navigateurs, convaincus de leur culpabilité, alors que la faute revient en fait à leur IE bien-aimé. Quand un patron leur dit qu'il doivent « faire marcher le site » dans tous les navigateurs modernes, ils tentent frénétiquement de corriger ces navigateurs alternatifs, sans savoir que IE est la source du problème.

Des légions de débutants tombent inutilement dans ce piège. Le moyen le plus simple est de lancer un Gecko ou un autre navigateur respecteux des standards, de coder la page pour qu'elle s'y affiche bien, et ensuite d'appliquer des hacks pour IE/Win, en corrigeant tous les problèmes. Oui c'est embêtant, mais c'est bien plus facile que de travailler dans l'autre sens.

IE/Win est tellement important que les auteurs de pages sont forcés de le chouchouter en prenant garde à ses nombreuses failles. Cela ne veut pas dire que IE est le seul navigateur buggé, oh non. Tous les navigateurs ont des bugs, mais aucun ne s'approche seulement du nombre ou de la diversité qu'on trouve dans IE/Win. Il faut remonter jusqu'à Netscape Navigator 4 pour pour constater des écarts de conduite dépassant ceux de IE.

Les codeurs qui préfèrent se passer de hacks, s'ils veulent espérer y parvenir, sont obligés de bien connaître la plupart des problèmes de IE, mais la plupart n'ont pas cette connaissance. Connaître les détails pervers du fonctionnement interne de IE n'est parfois même pas suffisant, parce que sans hack pour résoudre le problème, il devient nécessaire de limiter sévèrement la complexité de la maquette. Cela rend de nombreux designs irréalisables. Frustrant, pour ne pas dire plus.

Le bon, le mauvais et le très méchant

Les hacks CSS sont parfois appelés des filtres, mais ce sont tous des moyens de tromper un navigateur pour lui faire afficher quelque chose de la même manière qu'un autre (en général plus correctement), ou de cacher des sections de code à un ou plusieurs navigateurs. Ils sont répartis entre ce qu'on appelle les "bons" hacks, ou "valides", et les "mauvais" hacks, selon la façon dont ils travaillent. D'une manière générale, la syntaxe d'un bon hack respecte entièrement la spécification CSS, et son utilisation ne cause aucune erreur de validation. Les mauvais hacks sont écrits de manière illégale, par exemple à l'aide d'une syntaxe CSS incorrecte, et ne valideront pas.

Cela ne veut pas dire que la police de CSS viendra frapper à votre porte si vous écrivez un mauvais hack, mais mais attendez la suite. Des modifications dans le code d'un navigateur futur pourraient rendre inefficaces certains hacks aujourd'hui valides, tout en échouant à résoudre le problème que le hack évitait. Dans ce cas, un nouveau hack sera soudainement nécessaire. L'emploi de hacks invalides augmente fortement ce risque. Ça n'en vaut pas la peine.

Un exemple de hack valide est le hack « Tan » :

* html .truc {width: 100px;}

Ce code ne peut être vu et exécuté que dans les navigateurs IE (Windows et Mac) à cause de la construction du sélecteur précédant la déclaration propriété/valeur. Ce sélecteur indique spécifiquement :

Sélectionne un élément avec la classe .truc, quand il est contenu à l'intérieur d'un élément HTML, et que cet élément HTML est contenu dans n'importe quel autre élément, et donne-lui 100 pixels de largeur.

Les espaces entre les différentes parties du sélecteur sont d'une importance critique. Ils sont ce qu'on appelle des « combinateurs descendants ». Un combinateur descendant est un espace qui sépare deux sélecteurs simples ou plus, comme des noms d'éléments, des classes, etc. L'ordre dans lequel apparaissent ces sélecteurs simples détermine quel élément est sélectionné. Les classes, les ID, les sélecteurs d'attributs et les pseudo-classes peuvent être combinés avec des noms d'éléments en utilisant le combinateur descendant.

Selon la spécification HTML, HTML est supposé être « l'élément racine » à l'intérieur duquel résident tous les autres éléments. En conséquence, aucun autre élément ne peut entourer HTML, mais il se trouve que les navigateurs IE croient qu'il existe un tel élément ! Nous ne connaissons pas son nom, et Microsoft ne l'a jamais mentionné dans sa documentation, mais il existe sans aucun doute puisque tous les navigateurs IE obéissent à ce sélecteur.

L'important ici est que ce sélecteur est valide, car il suit une syntaxe et des règles de construction CSS correctes. Le fait qu'il repose sur un « élément racine mystère » entourant l'élément HTML ne signifie pas que ce sélecteur est illégal, mais seulement qu'il ne devrait en fait rien sélectionner du tout. Tous les navigateurs autres que Internet Explorer réalisent que la construction du sélecteur ne peut rien sélectionner, et ignorent donc toutes les déclarations suivant ce sélecteur.

Parlez-moi des mauvais hacks !

Un mauvais hack est par exemple celui qui utilise un caractère incorrect à un endroit étrange et invalide. Un navigateur respectueux des normes ignorera la règle de style, alors qu'un autre plus permissif lui obéira. Devinez quel navigateur est généralement le plus permissif ? Oui, vous avez tous trouvé, c'est ce bon vieux IE/Win. C'était trop facile.

Un grand nombre de caractères illégaux peuvent être directement placés devant un nom d'élément à l'intérieur d'un sélecteur, et IE/Win dira « Tranquille ! Ça a l'air tout bon pour moi ! » Les navigateurs plus au courant des normes ignoreront simplement toute la règle, comme le demandent les spécifications. Quelques tests révèleront plusieures façons de tromper IE/Win, mais tous ces hacks sont basés sur une syntaxe incorrecte tolérée par IE. Mauvais plan.

Quoi ? Vous voulez des infos sur les hacks « très méchants » ? Croyez-nous, vous vous porterez bien mieux sans !

« Contournement »

À l'inverse d'un hack, un contournement ne s'amuse pas avec le code. Un problème est « contourné » en trouvant une façon alternative de faire qui ne causera pas de souci. Il n'existe aucune liste magique de contournements, mais une fois qu'on sait jouer la gamme des effets de CSS, il est incroyable de voir comment un même effet peut être obtenu à l'aide d'une méthode complètement différente. Les familiers de la programmation comprendront ce que nous voulons dire.

De temps en temps, une difficulté surgit, et en employant une méthode différente on découvre que de nouvelles difficultés ralentissent la progression. Parfois, une troisième méthode est essayée, entraînant encore plus de problèmes étranges. Si cela vous arive, il vaut peut-être mieux reprendre la conception de votre design à la base. Nous n'insisterons pas sur ce conseil, mais beaucoup ont frôlé la crise de nerfs à force de se taper la tête contre de tels problèmes. Ne vous laissez pas entraîner trop loin jusqu'à en perdre le sens des perspectives, d'accord ?

http://www.positioniseverything.net/articles/terms.html

Fiche technique

À propos de l'auteur

Holly Bergevin et John Gallant sont les animateurs du site Position Is Everything, où ils exposent les bugs CSS les plus obtus des navigateurs modernes, ainsi que des exemples concrets d’une utilisation efficace des feuilles de styles.

Article du même auteur

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

Web design

© 2001-2024 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site