Blog - Britoweb - Tag - css

Unicorn, le validateur tout-en-un du W3C

Victor Brito — Wed, 28 Jul 2010 00:33:00 +0200

Le W3C vient de lancer Unicorn.

Ce validateur unifié permet de vérifier à la fois :

la validité du HTML ou du XHTML et bonne formation du XML,
la validité des CSS,
la compatibilité avec les mobiles (le service MobileOK),
la validité des flux de syndication.

À l'instar du validateur de balisage et du validateur CSS, Unicorn permet de vérifier en saisissant un URI, en chargeant un fichier ou en effectuant une saisie directe.

Mais, il se distingue des autres validateurs du W3C existants par le fait qu'il demande d'abord de sélectionner une tâche parmi cinq possibles :

vérification de la conformité générale, tâche qui effectue tous les tests possibles ;
validation des profils CSS, tâche qui tient compte de tous les niveaux de CSS présents et futurs (CSS 1, 2.0, 2.1 et 3), sans pour autant permettre de choisir le niveau des CSS ;
vérificateur MobileOK ;
validateur de flux ;
tâche personnalisée, qui permet de sélectionner un ou plusieurs tests à effectuer, au choix, avec possibilité de choisir le niveau des CSS.

Autre point de distinction : la validation par saisie directe permet de sélectionner le type de document à valider parmi les types MIME suivants :

text/html,
application/xhtml+xml,
image/svg+xml,
application/mathml+xml,
application/smil+xml,
text/css,
application/xml,
text/xml.

En revanche, il n'est pas possible de valider un fragment de code HTML, XHTML.

Enfin, Unicorn est disponible en 22 langues, dont le français.

Pour en savoir plus, lire le billet du W3C annonçant la sortie d'Unicorn.

Démonstration des effets des différentes valeurs de la propriété CSS display

Victor Brito — Thu, 08 Jul 2010 18:33:00 +0200

Un peu perdu entre les différentes valeurs possibles de la propriété CSS display ? Le site Sickdesigner met à votre disposition une démonstration très claire à ce sujet, intitulée Understanding the display property demo.

N'oublions pas les sélecteurs CSS 2.1

Victor Brito — Fri, 05 Feb 2010 09:08:00 +0100

Tel est le message que souhaite faire passer le site 456 Berea Street dans un billet publié hier et intitulé Forgotten CSS selectors.

Ce billet présente brièvement quelques sélecteurs avancés de la spécification CSS 2.1 qui ont été oubliés jusqu'à présent, à cause qu'Internet Explorer 6 ne les prend pas du tout en charge ou très partiellement, mais auxquels on peut songer, vu qu'IE 6 a atteint des parts de marché suffisamment basses pour que la prise en compte de cette version de navigateur ne soit plus synonyme de « rendu visuel au pixel près ».

Les sélecteurs évoqués dans le billet de 456 Berea Street sont les suivants :

le sélecteur d'élément enfant (E > F),
le sélecteur d'élément frère adjacent (E + F),
le sélecteur d'attribut (E[attribut] et E[attribut=valeur], notamment),
la pseudo-classe :first-child,
la pseudo-classe :hover applicable à n'importe quel élément et non seulement à l'élément a,
la pseudo-classe :focus,
le sélecteur de classes multiples (E.classe1.classe2).

L'enjeu de l'utilisation des sélecteurs avancés de CSS est résumé ainsi :

What these selectors offer us is cleaner HTML, since we can drop a lot of class names, and in some cases JavaScript, that were only necessary to achieve visual equivalence in IE 6. I am not saying that you should “drop support” for IE 6, just that it’s ok for some things to not look perfect in a Web browser that is eight and a half years old. Besides, Do websites need to look exactly the same in every browser?

En français :

Ce que ces sélecteurs nous offrent est du HTML plus propre, puisque nous pouvons retirer beaucoup de noms de classe, et de JavaScript dans certains cas, qui n'étaient nécessaires que pour parvenir à un visuel équivalent sous IE 6. Je ne dis pas que vous devriez « laisser tomber la prise en charge » d'IE 6, mais seulement de ce qui est bon pour que certaines choses n'aient pas l'air parfaites sous un navigateur Web qui a huit ans et demi. D'ailleurs, Les sites Web ont-ils besoin d'être exactement pareils sous chaque navigateur ?

La réponse est non. Du moins, à partir du moment où l'on se soucie de dégradation élégante pour les navigateurs obsolètes (ou d'amélioration progressive pour les navigateurs les plus avancés en matière de prise en compte des standards et de leur respect).

CSS 2 - Pratique du design Web de Raphaël Goetter, troisième édition : note de lecture

Victor Brito — Sun, 11 Jan 2009 02:10:00 +0100

Les éditions Eyrolles viennent de publier la troisième édition de CSS 2 - Pratique du design Web, de Raphaël Goetter.

S'il y a un seul ouvrage qui m'ait marqué dans mon parcours dans le Web, c'est bien celui de Raphaël Goetter : en effet, la lecture de la première édition, en 2006, m'a incité à plus de rigueur dans mon code, plus particulièrement dans le respect du balisage sémantique, tout en me faisant prendre conscience des problèmes de compatibilité entre navigateurs.

Cette troisième édition, tout en tenant compte des nouveautés de Firefox 3 et, surtout, d'Internet Explorer 8, reste fidèle à l'esprit des deux précédentes éditions. En effet, le livre commence par un exposé sur les standards du Web, tout en soulignant l'importance de l'accessibilité du Web, de la séparation entre la structure d'un document Web et sa présentation et de la sémantique de chaque balise HTML. Ensuite, après plusieurs chapitres théoriques sur l'essentiel des CSS, le livre aborde des cas concrets et très courants d'application de CSS, comme le centrage d'un élément ou l'habillage d'un menu de navigation. Enfin, le livre présente un exemple d'application de la matière abordée à un projet de site Web de qualité professionnelle, tout en offrant une méthodologie simple permettant aux concepteurs de sites Web plus ou moins maladroits de coder avec rigueur et de résoudre les problèmes d'affichage (et ce sans même recourir à des outils comme l'extension Firebug de Firefox).

En somme, c'est un livre indispensable pour connaître l'essentiel des CSS, tout en ayant conscience de certaines bonnes pratiques de conception de sites Web.

Feuilles de styles, médias CSS et navigateurs mobiles : une astuce pour garantir compatibilité et confort d'utilisation

Victor Brito — Tue, 06 Jan 2009 20:17:00 +0100

Que l'on déplore ou non, le Web sur les mobiles est de moins en moins négligeable, d'autant moins qu'il peut compter sur le succès, entre autres, de l'iPhone. Or, consulter un site Web depuis un mobile peut devenir un casse-tête quand le site consulté utilise des feuilles de style inadaptées aux mobiles ou que le navigateur mobile utilisé implémente mal les différents médias CSS ou n'en reconnaît pas certains.

En effet, une feuille de style destinée à un écran d'ordinateur (utilisant donc le média screen) peut être remplie de règles CSS dont l'objectif est d'afficher tout ou partie du contenu en colonnes (avec les propriétés display et float, notamment), en tenant compte d'une taille d'écran au moins égale à 800 ou à 1024 pixels de large. Or, sur un mobile, une telle feuille de style induira soit la présence d'une barre de défilement horizontale soit le recours à une fonctionnalité permettant de zoomer le contenu auquel on veut accéder, la page Web entière s'adaptant dans un premier temps à la largeur d'écran disponible, réduisant la taille des polices à un niveau tel qu'un problème d'accessibilité se pose.

Heureusement, en HTML 4 et en XHTML, il est possible de préciser le(s) média(s) concerné(s) par la feuille de style lorsqu'on l'appelle au moyen de l'élément link, grâce à l'attribut media. Il en est de même en CSS 2, grâce à la règle @media, d'une part, et à la possibilité de préciser le(s) média(s) concerné(s) par la feuille de style appelée au moyen de la règle @import. Ainsi, on peut créer plusieurs feuilles de styles, dont une ciblant les mobiles en utilisant le média handheld :

<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/screen.css" media="screen,handheld" />
<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/handheld.css" media="handheld" />

@import "screen.css" screen;
@import "handheld.css" handheld;

@media screen {
  /* Règles CSS pour les écrans d'ordinateur */
}
@media handheld {
  /* Règles CSS pour les mobiles */
}

Seulement voilà : si certains navigateurs mobiles implémentent le média handheld, d'autres, en revanche, l'ignorent et, qui plus est, iront même jusqu'à ne lire que les feuilles de style ciblant le media screen ! Et je ne me hasarde pas à parler des media queries, un module de CSS 3 qui permettra de cibler plus finement les médias (par exemple, ne cibler que les écrans dont la taille ne dépasse pas 480 pixels de largeur, ce qui donne le code suivant pour l'attribut media et les règles @media et @import : only screen and (max-device-width:480px)) ; mais, ce genre de requête n'est, pour l'instant, implémenté que par Opera et Safari.

Malgré tous ces points délicats, il est possible de fournir à l'ensemble des navigateurs mobiles une feuille de style adaptée au support mobile. A List Apart vient de publier un article indiquant une astuce garantissant à la fois un confort d'utilisation du mobile pour consulter un site et la compatibilité entre navigateurs mobiles.

L'astuce part du principe de deux feuilles de style distinctes, l'une (ecran.css) pour les écrans d'ordinateurs, l'autre (correctifs-mobile.css) pour les mobiles (dont le rôle est d'annuler les règles énoncées par ecran.css qui sont inadaptées aux écrans de mobile). Ces deux feuilles sont appelées par une troisième (noyau.css), qui contient le code suivant :

@import "ecran.css";
@import "correctifs-mobile.css" handheld;
@import "correctifs-mobile.css" only screen and (max-device-width:480px);

Une quatrième feuille de style (mobile.css) apporte des styles supplémentaires pour les mobiles.

Les différentes feuilles de style sont appelées comme suit :

<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/noyau.css" media="screen" />
<link rel="stylesheet" href="http://blog.britoweb.net/post/2009/01/06/mobile.css" media="handheld, only screen and (max-device-width:480px)" />

Ainsi, les navigateurs mobiles ne tenant compte que du média handheld ne chargeront que la feuille de style mobile.css ; ceux qui tiennent compte à la fois des médias screen et handheld chargeront toutes les feuilles de style, de même pour ceux qui ne tiennent compte que du média screen tout en implémentant le module media queries de CSS 3. Quant à ceux qui ignorent ce module de CSS 3 et qui ne connaissent que le média screen, ils ne chargeront que la feuille de style ecran.css.

Opera 10, une future version très prometteuse

Victor Brito — Thu, 04 Dec 2008 15:17:00 +0100

La section pour développeurs d'Opera vient de publier un article sur Opera 10 et Presto 2.2.

Cet article propose un premier regard sur la future version majeure d'Opera, qui intégrera la prochaine version de Presto, le moteur de rendu d'Opera. Ce premier regard se résume à la présentation des améliorations et des implémentations de fonctionnalités liées aux standards les plus récents du Web :

l'implémentation du module des polices de caractères de CSS 3, qui permet, entres autres, d'utiliser une police de caractères localisée à une URL, la police en question pouvant ne pas être une police système (de quoi réjouir d'avance les concepteurs des maquettes sous Photoshop ) ;
l'implémentation du niveau d'opacité dans la déclaration des couleurs, une possibilité prévue par CSS 3 (on pourra, par exemple, déclarer une couleur d'arrière-plan rouge avec un niveau de transparence Alpha à 50 % : background-color: rgba(255, 0, 0, 0.5)) ;
la déclaration de couleur selon sa teinte, sa saturation et sa luminosité, encore une possibilité prévue par CSS 3 (exemple : background-color: hsl(240, 100%, 50%)), à laquelle la gestion de l'opacité s'ajoute (exemple : background-color: hsla(240, 100%, 50%, 0.5)) ;
l'amélioration du support du SVG, avec, entre autres, la gestion des polices créées sous ce format.

De plus, la version 2.2 de Presto réussit entièrement le test Acid3 (note de 100 sur 100), à l'instar de la version de développement de Safari 4. C'est un signe fort du fort respect d'Opera pour l'ensemble des standards du Web testés par Acid3 ; et Dieu sait qu'il y en a un paquet : HTTP, ECMAScript, HTML 4, XHTML 1.0, CSS 2 et certains modules de CSS 3, SVG, et j'en passe !

Si vous voulez constater ces améliorations par vous-même, vous pouvez télécharger la version alpha d'Opera 10. Bien entendu, comme toute version alpha qui se respecte, elle est à utiliser à vos risques et périls ; mais, elle mérite d'être essayée.

Ce n'est pas bien de mêler code HTML, CSS et JavaScript !

Victor Brito — Mon, 24 Nov 2008 13:17:00 +0100

Bruno Bichet a publié hier sur son blog un billet expliquant pourquoi ce n'est pas une bonne pratique que de mélanger le code HTML, les CSS (à coup d'attributs style) et le JavaScript (à coups d'attributs d'événements de type onnom de l'événement). Il s'agit d'une traduction (Bruno Bichet parle de craduction ) d'un billet de Robert Nyman, en anglais, à ce sujet.

Dans l'ensemble, il n'y a rien à ajouter aux explications de Bruno Bichet, explications qui se doublent d'une démonstration de ce qu'il faut faire si l'on se soucie de bonnes pratiques de codage en CSS et en JavaScript : autrement dit, il faut séparer le contenu (et la structure, de préférence conforme au balisage sémantique, de ce contenu) de sa présentation et des comportements dynamiques qui s'y appliquent. N'oublions pas que c'est pour tendre à cet objectif de séparation que les feuilles de styles sont apparues (pour rappel, il y a bientôt douze ans !) et qu'on a mis au point le concept d'unobstrusive JavaScript (en bon français, le JavaScript non intrusif).

D'ailleurs, à propos de JavaScript, j'ai une remarque à faire concernant la gestion des événements et la résolution des conflits éventuels entre plusieurs gestionnaires d'événement. Il n'est pas nécessaire de recourir à une bibliothèque JavaScript pour faire cohabiter pacifiquement plusieurs gestionnaires d'événements : en effet, la spécification DOM niveau 2 événements du W3C a de quoi suffire, ainsi que la gestion des événements propre à Internet Explorer.

function fnAjaxNews ()
{
  // Get news through Ajax
}

function fnGetNews ()
{
  var oGetNews = document.getElementById ('get-news');
  // For standards-compliant browsers
  if (oGetNews.addEventListener) oGetNews.addEventListener ('click', fnAjaxNews, false);
  // For Internet Explorer
  else if (oGetNews.attachEvent) oGetNews.attachEvent ('onclick', fnAjaxNews);
  // For browsers who do not understand DOM level 2, there is no event
  else return;
}

// Let us load the function above
function fnLoad ()
{
  // For standards-compliant browsers
  if (window.addEventListener) window.addEventListener ('load', fnGetNews, false);
  // For Internet Explorer
  else if (window.attachEvent) window.attachEvent ('onload', fnGetNews);
  // For browsers who do not understand DOM level 2, there is no event
  // (which means these browsers will behave as though JavaScript were deactivated or not supported)
  else return;
}
// Execute
fnLoad ();

Sans doute y a-t-il plus de code à pondre que si l'on utilisait une bibliothèque JavaScript ; mais, ce bout de code a l'avantage d'éviter les conflits (d'autres fichiers JavaScript pourront être appelés qui gèrent les événements de la sorte) et de ne pas servir de JavaScript (c'est un choix) aux navigateurs incapables d'implémenter l'une des deux méthodes d'ajout d'événement (que ce soit la méthode standard ou la méthode propriétaire d'IE) : pour ces derniers, il y aura donc une dégradation élégante, qui ne sera pas gênante, pourvu que le contenu soit parfaitement accessible sans JavaScript.

Internet Explorer 8 aura des propriétés CSS propriétaires nommées conformément au standard CSS

Victor Brito — Tue, 09 Sep 2008 19:29:00 +0200

La spécification CSS 2.1 prévoit, dans la syntaxe des CSS, la possibilité pour les navigateurs d'ajouter des extensions aux propriétés faisant partie des CSS. Ces extensions se reconnaissent à la syntaxe suivante : -identifiant du propriétaire de l'extension-nom significatif du rôle de l'extension. C'est ainsi qu'il existe des propriétés propriétaires comme -moz-border-radius, -khtml-border-radius ou -webkit-border-radius, des propriétés propriétaires propres aux navigateurs utilisant, respectivement, comme moteur de rendu Gecko (Firefox, Camino…), KHTML (Konqueror) et Webkit (Safari) qui permettent, dans ces exemples, d'obtenir des bordures à angle arrondi (en attendant la future propriété CSS 3 border-radius).

Internet Explorer n'est pas en reste ; mais, jusqu'à présent, le navigateur de Microsoft ne suivait pas la syntaxe standard, nommant ses propriétés propriétaires comme s'il s'agissait de propriétés incluses dans la spécification CSS. Sous Internet Explorer 8, en revanche, les propriétés propres à Microsoft suivent la syntaxe préconisée par le W3C : désormais, on n'utilisera plus filter, mais -ms-filter. Le blog de MSDN recense les propriétés propriétaires concernées par ce changement.

Ce changement n'est valable que si Internet Explorer 8 n'est pas en mode de compatibilité pour le rendu. Toutefois, par souci de rétro-compatibilité, les anciennes appellations des propriétés en question seront tolérées et continueront à fonctionner.

Connaissez-vous les JSSS ?

Victor Brito — Mon, 23 Jun 2008 22:12:00 +0200

En lisant un entretien accordé par Daniel Glazman à Openweb sur les CSS, je suis tombé sur le sigle suivant : JSSS.

J'ai ainsi appris qu'il y a une décennie (ce qui, à l'échelle du Web, veut dire dans l'Antiquité), Netscape mit au point les feuilles de style JavaScript (en anglais JavaScript StyleSheets), qui concurrençaient les CSS.

Si elles pouvaient être puissantes pour des calculs dynamiques hautement complexes ; en revanche, elles se rélévaient bien pauvres à côté des CSS, en ne supportant que le sélecteur d'élément simple. De plus, la syntaxe, issue de JavaScript, était plus verbeuse et sensible à la casse : là où en CSS on écrit h1 { font-size: 20pt; }, en JSSS on écrivait document.tags.H1.fontSize = "20pt";.

Bien que Netscape eût soumis les JSSS au W3C, elles ne furent jamais acceptées comme standard. Qui pis est, elles furent d'autant plus boudées par le marché que le principal concurrent de Netscape, Internet Explorer, n'hésita pas à adopter les CSS comme langage de feuille de style. Seul Netscape 4, sorti en 1997, supportait les JSSS ; mais, très vite, la société Netscape laissa tomber la promotion de ce langage propriétaire pour s'intéresser aux CSS et cessa tout support des JSSS à la sortie de Netscape 6, en 2000.

Pour plus de détails, un article de Wikipédia lui est consacré, qui m'a servi de source pour les propos tenus dans ce billet.

Les CSS mises à nu

Victor Brito — Wed, 09 Apr 2008 00:00:00 +0200

Où est donc passé l'habillage du site ? Le site se serait-il mis à poil ?

En quelque sorte, oui. Aujourd'hui, c'est la troisième édition du CSS Naked Day.

Il s'agit d'une initiative, lancée par Dustin Diaz, qui consiste à dépouiller, pour une journée, un site Web de ses feuilles de style, afin de promouvoir les standards du Web, et plus particulièrement le bon usage du (X)HTML, le balisage sémantique et la bonne hiérarchisation de la structure d'une page Web. Bref, il s'agit de montrer qu'une bonne structure (X)HTML se moque de la mise en forme et de la présentation et reste parfaitement consultable, voire accessible, puisqu'elle va à l'essentiel : le contenu et la nature de ce contenu.

Sur ce, si votre site Web est une charmante jeune femme en lingerie, qu'elle ose ôter son <body> et se mette à poil !

CSS, PNG : ne pas rester prisonnier d'Internet Explorer 6

Victor Brito — Mon, 24 Mar 2008 23:19:00 +0100

La spécification CSS 2.1 offre des possibilités d'appliquer un style à un document Web si riches (et je ne parle pas de ce que nous réserve CSS 3…) qu'elle paraît trop en avance pour les navigateurs « mauvais élèves », comme Internet Explorer 6. Même si ce dernier est encore, hélas ! répandu, ce n'est pas une raison de ne pas utiliser toute la puissance des CSS.

Prenons l'exemple de ce bout de code HTML :

<div id="exemple">
  <h1>Titre</h1>
  <ul>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section1.html">Section 1</a></li>
    <li>
      <a href="http://blog.britoweb.net/post/2008/03/24/section2.html">Section 2</a>
      <ul>
        <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-1.html">Section 2.1</a></li>
        <li>
          <a href="http://blog.britoweb.net/post/2008/03/24/section2-2.html">Section 2.2</a>
          <ul>
            <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-2-1.html">Section 2.2.1</a></li>
            <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-2-2.html">Section 2.2.2</a></li>
          </ul>
        </li>
        <li><a href="http://blog.britoweb.net/post/2008/03/24/section2-3.html">Section 2.3</a></li>
      </ul>
    </li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section3.html">Section 3</a></li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section4.html">Section 4</a></li>
    <li><a href="http://blog.britoweb.net/post/2008/03/24/section5.html">Section 5</a></li>
  </ul>
</div>

Nous voulons que chaque élément de liste ait une bordure en haut, sauf le premier de chaque liste, et que les listes imbriquées aient une couleur d'arrière-plan différente de celle de la liste qui la contient. Pour corser les choses, le deuxième élément de chaque liste doit avoir son texte en gras.

Il est possible de réaliser cette volonté sans qu'on touche au code HTML, en codant, par exemple, le code CSS suivant :

/* Texte en gras pour le deuxième élément li de chaque liste */
#exemple li:first-child + li {
  font-weight: bold;
}
/* Si ce deuxième élément contient une liste,
   seul le deuxième élément de cette dernière est en gras
   (le reste est en graisse normale) */
#exemple li > ul {
  font-weight: normal;
}
/* Bordure */
#exemple li {
  border-top: 1px solid black;
}
/* Pas de bordure pour chaque premier élément li */
#exemple li:first-child {
  border-top: none;
}
/* Couleurs d'arrière-plan différentes pour les listes selon leur niveau */
#exemple > ul {
  background-color: yellow;
}
#exemple > ul > li > ul {
  background-color: orange;
}
#exemple > ul > li > ul > li > ul {
  background-color: red;
}

Pour résumer, nous recourons aux sélecteurs d'élément enfant (>) et adjacent (+), ainsi qu'à une pseudo-classe (:first-child), pour traiter les différents niveaux de liste. Et ça marche sous Firefox 2, Opera 9 et Safari 3, ainsi que sous Internet Explorer 7.

Ça ne marche pas sous IE 6, me direz-vous. C'est un fait, certes ; mais, cela ne doit pas être une excuse pour mépriser les sélecteurs évoqués ci-dessus, sous prétexte que cela compliquerait la maintenance pour les intégrateurs ou que tout ce qui en CSS n'est pas compris par IE 6 est à ignorer parce que les utilisateurs d'IE 6 sont la cible principale.

Pour ma part, j'estime que la maintenance est plus compliquée lorsqu'on doit ajouter des attributs class (ou quelques id lorsque le contexte du code HTML le permet), au risque de friser la classite aiguë (comme dirait Raphaël Goetter), alors qu'en utilisant toute la puissance des CSS, notamment grâce à ses sélecteurs, on garde la faculté d'alléger le code HTML (et donc de réaliser des économies de bande passante, même s'il ne s'agit que de quelques kilo-octets ).

Cela ne veut pas dire, pour autant, qu'il faille interdire l'utilisation des classes en CSS. Si l'on souhaite ou doit tenir compte d'IE 6, on peut s'en servir dans notre exemple (pour distinguer les éléments li devant être mis en gras). Mais, la classe ajoutée ne servira qu'au correctif pour IE 6 si l'on veut y reproduire le style recherché. Auquel cas il faudra créer une feuille de style à part, qui ne servira que pour IE 6 (et les versions antérieures à la 6, si l'on veut) et qu'on appellera par un commentaire conditionnel. C'est une méthode à la fois plus pérenne et plus propre, en ce sens qu'une fois qu'IE 6 aura disparu du marché des navigateurs (et plus vite il disparaîtra, mieux ce sera ), on pourra non seulement ôter les classes du code HTML, mais surtout supprimer la feuille de style pour IE 6, sans qu'on ait besoin de maintenir la feuille de style principale, contrairement à la méthode des hacks CSS (ou de l'utilisation d'une seule feuille de style, qui mélange règles CSS standards et corrections pour IE), qui pollue une feuille de style qui, après tout, ne doit contenir que des règles CSS conçues pour être appliquées sans broncher par les navigateurs, à commencer par ceux qui respectent les standards.

On peut en dire tout autant concernant les images en PNG contenant une couche de transparence. Sous prétexte qu'IE 6 ne gère pas nativement la transparence du format PNG, beaucoup en viennent à brider la créativité en matière de design Web, en se contentant du format GIF pour utiliser de la transparence, mais sans pouvoir utiliser de couche Alpha ni aller au-delà de 256 couleurs (ce qui condamne l'utilisation de dégradés de couleurs). Si l'on souhaite ou doit tenir compte d'IE 6, même motif, même punition que pour les CSS : un commentaire conditionnel, où l'on remplacera le PNG qui ne passe pas par un GIF ou, mieux, par un JPEG équivalent, l'idéal étant que l'image en question soit une image générée en CSS (même si l'on peut utiliser les commentaires conditionnels pour afficher ou masquer un contenu HTML à Internet Explorer).

Et je ne vais pas me hasarder à parler du DOM et de la manière standard de parcourir l'arborescence d'un document HTML, où l'on peut jongler à merveille entre les liens de parenté qu'entretiennent les élements entre eux, voire boucler entre éléments frères.

Bref, tout cela pour dire que, malheureusement, même dans le milieu des agences Web, on continue encore à coder « à la cochonne », en n'osant pas exploiter à fond toutes les possibilités des CSS parce qu'on reste prisonnier d'un navigateur et d'une version qui ne respectent pas les standards du Web : on crée des classes pour sélectionner le premier élément enfant, on pollue la feuille de style principale de hacks et de propriétés CSS propriétaires (comme filter ou zoom) qui l'invalident dès qu'elle passe au validateur CSS du W3C… Même s'il faut tenir compte des problèmes de compatibilité entre les navigateurs et entre les versions d'un même navigateur, il ne faut pas rester prisonnier de ce cancre qu'est Internet Explorer 6, d'autant moins que la version 7 fait son bonhomme de chemin, que la version 8 pointe déjà son nez et qu'un code pérenne doit se tourner vers cet avenir, de plus en plus présent, qu'est la généralisation des standards du Web.

Il est important d'avancer en CSS ; sinon, nous en serions à coder en mode Quirks, ce qui n'arrangerait pas du tout le W3C, dont le travail essentiel est de faire en sorte que, sur le Web, tout le monde parle les mêmes langages côté client, afin de faciliter la tâche des concepteurs de sites.

Internet Explorer 8 : un pas de géant vers les standards

Victor Brito — Sun, 09 Mar 2008 15:47:00 +0100

Quelle riche semaine que celle qui s'achève ! En effet, l'équipe des développeurs d'Internet Explorer s'est montrée particulièrement réactive, à en croire les billets récemments publiés sur le blog de MSDN consacré à Internet Explorer.

D'abord, contrairement à ce que l'on craignait initialement (et à ce qui avait été annoncé dans un premier temps), le mode affichant les améliorations d'Internet Explorer 8 en matière de respect des standards sera le mode utilisé par défaut. Le souci de rétro-compatibilité est maintenu, la nouvelle balise meta affichant le mode standard d'IE 7 et le mode Quirks restant tel quel (plus de détails sur les différents modes d'affichage d'IE 8).

Ensuite, la liste des progrès d'IE 8 en matière de support des standards est agréable à lire, que ce soit en CSS, en HTML ou en DOM.

Enfin, la bêta 1 d'IE 8 est disponible sur le site de Microsoft. Elle nécessite, à l'instar d'IE 7, le SP2 sous Windows XP.