blog

Vestiges d’un CSS Guru

Tag : ie6

Billet

Mais arrêtez avec IE6!

Je le dis et je le répète : il faut arrêter de s’acharner à faire fonctionner parfaitement son site sous IE6. Chaque semaine, il y a un nouvel article qui prône cette idée, et c’est très bien.

stop-ie6

Est-ce qu’un site doit apparaître exactement pareil sous chaque navigateur ?

Pour ceux qui ne le sauraient pas encore : la réponse est non.

Notez l’adverbe “exactement”. Parce que d’un côté, il faut que l’utilisateur puisse reconnaître un site, quel que soit le navigateur utilisé. Mais des différences (plus ou moins) légères dans le graphisme sont non seulement tolérées mais parfaitement admises. Ne pas avoir de coins arrondis (par CSS ou PNG), de dégradés complexes (par PNG), des ombres portées… sous IE6 n’est pas un problème.

C’est surtout qu’un utilisateur d’IE6 ne verra aucune dégradation dans sa version vu qu’il ne verra pas la “bonne version”!

Et puis d’abord, tout le monde n’a pas toutes les polices utilisées sur un site (Arial inexistant sous Linux ?), donc il y a déjà obligatoirement des différences, et des grosses différences : la typographie c’est au moins la moitié du design.
Lire la suite →

Billet

Une CSS universelle pour IE6

Que faire face à IE6 ?

  • s’embêter avec des hacks CSS ?
  • faire 2 versions du site ?
  • laisser les bugs partout ?
  • utiliser une CSS alternative ?
  • utiliser du JavaScript pour améliorer la compatibilité ?

IE6, c’est vieux, c’est lourd, c’est moche, c’est chiant. Ca prend du temps, pour pas grand chose, et pour de moins en moins de monde (20% grande moyenne à l’échelle mondiale).

Et puis le web, c’est pour le contenu avant tout. Au lieu d’avoir un site buggé de partout sur IE6, pourquoi ne pas offrir une CSS propre et claire ? C’est l’idée derrière Universal Internet Explorer 6 CSS.

css-universelle-ie6

Billet

Le temps d’intégration

Je me suis posé la question de savoir combien était divisé mon temps pendant que j’intégrais. J’ai divisé en 5 parties ce temps (peut-être en oubliant des parties) et évalué grossièrement leur répartition. Je suis arrivé à ce graphique :

bbx-temps-d-integration

HTML : vers davantage de modularité

Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.

A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).

CSS : une seule css, un reset et de moins en moins de contextualisation

C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.

Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.

Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer

Appliquer le même style à des éléments HTML différents

Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :

  • copier-coller les mêmes propriétés pour la nouvelle classe (bouh, pas bien!)
    .maclasse { propriétés identiques }
    .monautrelement { propriétés identiques }
    .montroisieme { propriétés identiques }
  • mettre les éléments qui ont les mêmes propriétés à la suite
    .maclasse, .monautreelement, .montroisieme { propriétés identiques }
  • créer une nouvelle classe et rajouter cette classe dans le HTML
    .manouvelleclasse { propriétés identiques }

La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus “modulaire” je dirais. Un élément HTML aura par exemple : class=”.maclasse .manouvelleclasse”. On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?

Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents. :-)

IE6 : 40% de perte de temps

J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.

Nommer les class/id

Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).

Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément “grillade” par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.

Découper les images

Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.

Conclusion

J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?

Billet

Si IE6 n’existait plus…

J’avais lu un article sympa il y a quelques jours : “10 cool things we’ll be able to do once IE6 is dead“. Je me suis dit que j’allais me faire une petite liste perso.

Si IE6 n’existait plus :

  • les dégradés, ombres portées, arrondis… ne me prendraient plus la tête ! Je vous aime les PNG.
  • je n’aurais plus besoin de mettre des display:inline à mes float
  • j’utiliserais les pseudo-classes :first-child, :after, :lang…
  • les hacks du type * html ou _left iront aux oubliettes
  • j’arrêterais les <input class=”text” type=”text” /> parce que je pourrais mettre input[type=text]. Ah les sélecteurs d’attributs
  • les overflow:hidden seraient réduits de 95%
  • je mettrais des :hover sur ce que je veux
  • plus besoin de li{ display:inline;}
  • je pourrais sélectionner les enfants directs (p > a)
  • je n’aurais plus besoin de twitter mon score face à IE6 (actuellement IE6 mène 4 à 3 )
  • j’installerai IE8 sur mon PC à la maison
  • je passerais 50% de mon temps à faire autre chose
  • je devrais trouver un autre bouc-émissaire
  • je ne stresserais plus en appuyant sur F5

En attendant, je galère encore.

Billet

Microsoft lance Internet Explorer 8 à 18h

A midi (EST), IE8 sera lancé officiellement.

Est-ce que je vais le télécharger?

Non.

Est-ce que beaucoup de gens vont le télécharger?

Autant que ceux qui ont téléchargés IE7 à mon avis.

Est-ce que IE6 va en pâtir?

Pas du tout. Je pense que la sortie d’IE8 ne change en rien le problème de mise à jour de IE6 vers un navigateur plus moderne. Ceux qui utilisent encore IE6  le font, non pas parce qu’ils ne veulent pas de meilleur navigateur, mais parce qu’ils ne peuvent/savent pas mettre à jour.

Passer de IE6 à IE8, c’est comme passer de IE6 à IE7. Ceux qui le feront l’ont en fait, déjà fait.

Billet

Transformer IE6 en IE7 avec un JavaScript

Hier je suis tombé sur un post très surprenant : une librairie JavaScript qui fait fonctionner IE6 comme IE7.

Il s’agit d’un JS à implanter sur son site et qui (si le JS est actif chez le client) fixe les divers problèmes HTML et CSS de IE6. En gros, plus de problème de :

  • PNG
  • Margin
  • Pseudo-classes (hover notamment)
  • Positionnement

Je l’ai implanté sur mon site, mais n’ayant pas d’IE6 sous la main, je n’ai pas pu vérifier la performance du JS. Si un passant encore sous IE6 pouvait me le dire, ça serait sympa. Comment vérifier ? C’est simple : mon site est cassé sous IE6 (parce qu’il est bien codé ;) ) et ne le serait pas a priori avec ce JS.

“It sounds to good to be true, right?”

Comme le dit le site lui-même, ça semble trop étonnant pour être vrai. Les heures passées à régler les innombrables bugs d’IE6 seraient de l’histoire ancienne ? Cela voudrait dire aussi que l’excellent Position Is Everything ne serait plus indispensable ?

La réponse est : attendons de voir. Ce JS est relativement passé inaperçu donc je ne sais pas ce qu’il vaut exactement. Mais ça reste un grand espoir pour les web designers hostiles à ce fossile qu’est IE6.

Billet

Faut-il arrêter de coder pour Internet Explorer 6 ?

Tombe IE6

Ce débat est récurrent dans le temps parce qu’encore aujourd’hui, beaucoup d’intégrateurs s’efforcent de faire marcher leur site (ou ceux de leurs clients) sur IE6. Je ne suis pas le seul (français en tout cas) à réfléchir à ce problème, voire à y répondre carrément en proposant 5 raisons d’arrêter de coder pour IE6.

L’état des lieux

Internet Explorer 6 a globalement une part de marché de 36%. J’utilise TheCounter.com comme référence parce que d’autres sites (comme w3schools ou webreference) ne prennent en compte que leur propre traffic. Ce n’est que depuis février dernier que IE7 est passé devant IE6.

IE6 est sorti en 2001, et sa dernière grosse MAJ date de 2004. Le web étant ce qu’il est en terme de rapidité, IE6 est technologiquement dépassé depuis quelques années. Mais il reste encore très populaire parce qu’il est installé par défaut sur Windows XP.

Le logiciel est tellement buggé que cette page de résolution des bugs est (malheureusement) devenue une référence incontournable : Explorer Exposed.

La concurrence

Etant donné le succès très mitigé de Windows Vista, Internet Explorer 7 a des difficultés à se répandre, malgré le fait qu’il soit, contrairement à son prédécesseur, disponible en téléchargement gratuit.

Chez la concurrence externe à Microsoft, on trouve :

  • Firefox : populaire chez les web developers et chez les jeunes
  • Safari : populaire chez les Mac users
  • Google Chrome : très récent et relativement peu populaire (sans compter le buzz à sa sortie)
  • Opera : une perle malheureusement très inconnue du grand public

Aucun de ces logiciels ne peut néanmoins exploser au niveau du grand public, cette part de marché, grandissante, novice et à ne surtout pas négliger.

Pourquoi continuer à coder pour IE6

Pour le grand public justement. On peut se poser la question “Mais qui est assez bête pour continuer à utiliser IE6 ?”, mais l’on serait peu respectueux du fait que la plupart des gens ne savent pas ce qu’est un navigateur web. Vous en connaissez surement autour de vous, et vous ne pouvez pas les considérer comme imbéciles pour autant.

N’oublions pas que Tim Berners-Lee (l’inventeur du Web) veut que le Web soit ouvert et accessible à tout le monde, quelle que soit la plate-forme utilisée. Cela passe bien sûr par les Standards du Web, mais il faut tenir compte des faits, c’est à dire la popularité d’IE6.

Une autre raison de coder pour IE6, ce sont les clients. Imaginez que vous fassiez un site pour un prestataire, mais en le prévenant : “Votre site marchera très bien, à part pour un tiers de vos visiteurs, pour qui le site sera totalement buggé.”
Et si il vous demande pourquoi, il sera difficile de lui dire “Parce que le site est parfaitement codé.”

La grand majorité des clients se contrefichent du code derrière un site, et se soucient uniquement du résultat, ce qui est totalement légitime. Ils veulent un site qui fonctionne. Point. D’ailleurs, certaines web agency m’étonnent en mettant en avant le fait qu’ils codent en respectant les standards, tel un argument marketing de premier plan. Leurs clients sont peut-être des développeurs purs et durs qui n’aiment pas intégrer, je ne sais pas, mais ça m’intrigue.

Pourquoi arrêter de coder pour IE6

La raison principale : le temps.
Pour ma part, cela prend 50% de mon temps de faire fonctionner un site sous IE6, ou devrais-je dire, de débugger mon site… C’est comme créer deux sites distincts. Il faudrait facturer cette rétro-compatibilité (parce que oui, je considère IE6 comme rétro) au prix fort.

Autre raison : ne pas avoir à se brider.
Il y a les incapacités d’IE6 (png, hover, position fixed…) et les difficultés d’IE6 (float, margin, alignement…). Avec l’arrivée prochaine des propriétés CSS 3 (border-radius, ombre portée, display table…), ça sera encore plus vrai.

Pour les utilisateurs
Si un internaute voit la plupart des sites buggés sur son ordinateur, il pensera peut-être que le problème ne vient pas des sites mais de son logiciel. Mais il faudrait une action commune et concertée des web developers pour arriver à changer les mentalités. Ca semble compliqué à l’échelle de la planète ? Il suffit que Google dise “Arrêtez de coder pour IE6″ et le monde changera.

Faire un choix

Je pense que le choix se fait au cas par cas. Par exemple, je n’ai pas testé mon blog sous IE6 parce que le temps m’en manque, et parce que le public visé (très vaguement) n’est surement pas grand utilisateur d’IE6.

Mais pour un client (une assocation par exemple), il faudra se plier à cette compatiblité, par respect des utilisateurs, même si, sans qu’ils le sachent, ces utilisateurs ne nous respectent pas. ;)

Billet

Internet Explorer sur iPhone

IE6 sur iPhone

Non ce n’est pas un montage, ni une simple image. C’est l’iPhone qui prend le contrôle d’un Mac Mini qui lui-même émule Windows XP avec IE6.