D’abord pourquoi passer à HTML5 alors que pendant des années on a seriné à tous ceux qui voulaient l’entendre que XHTML, c’est l’avenir, il y a rien de mieux et que franchement HTML c’est has-been (ok je caricature, mais à peine). Est-ce que tous ces évangélistes aussi prompts à faire du prosélytisme auraient retourné leur veste ? Effectivement nous de notre côté on a pu avoir des doutes au début et puis on s’est rendu compte que ça changeait pas grand chose finalement, on peut très bien continuer à faire du XHTML dans la syntaxe en utilisant les nouvelles balises HTML5, c’est vrai que Les Intégristes ont l’avantage de parler à des professionnels qui ne portent pas forcément Internet Explorer dans leur cœur. En revanche l’avantage et qui n’est pas des moindres c’est qu’HTML5 intègre ARIA et en terme d’accessibilité c’est un grand pas en avant. Si vous voulez un petit rafraichissement de mémoire allez voir par là, la traduction qu’avait faite Pierre de Introduction to WAI ARIA.

Si pour un blog ou l’administration d’un site on peut s’amuser avec HTML5 et CSS3 en ajoutant les JS qui vont corriger les déficiences d’Internet Explorer (http://code.google.com/p/html5shiv/ et http://www.keithclark.co.uk/labs/ie-css3/), il est moins possible de le faire pour un site grand public générant un chiffre d’affaires de plusieurs millions d’euros. Le moindre ko est traqué et il serait risqué de s’appuyer sur un script qui demain pourrait ne plus être mis à jour et créer pas mal de désagréments.

Plusieurs solutions :

• Continuer à faire du bon vieux XHTML 1 et CSS 2.1
• Faire accepter qu’avec IE ce sera moins bien
• Faire du code forking, comme on faisait avant que des bibliothèques JS gèrent ça pour nous : une version pour IE une version pour les autres
• Prendre le risque des solutions JS quand même

Aucune de ces solutions n’est parfaite mais les intégrateurs et développeurs sont tellement impatients d’utiliser des specs qui sont encore à l’état de brouillon, que je suis sur que les arguments ne manqueront pas pour vanter les mérites d’une technologie balbutiante, quitte à faire le travail deux fois.

Un petit tour d’horizon sur ce qu’il faut savoir de HTML5 et CSS3, comment l’utiliser, quelles solutions JS, etc. :

• Les specs officielles :
  • http://dev.w3.org/html5/spec/Overview.html
  • http://www.w3.org/Style/CSS/current-work

  On n’y coupe pas !

• HTML5 et l’accessibilité
  • http://on-air.hiseo.fr/html5/html5-accessibilite-aria-wai-microformats/
  • http://www.cfit.ie/news-and-commentary-archive/96-wai-aria-in-html5
• Quelques lectures intéressantes sur le sujet :
  • http://diveintohtml5.org/
  • http://www.fredcavazza.net/2009/09/10/html-5-css-3-une-revolution-pour-les-interfaces-web/
  • http://html5doctor.com/
  • http://desgeeksetdeslettres.com/blog/programmation-java/html5-audio-et-video
  • http://www.seomix.fr/web/developpement/videolink-javascript-video-html5/
  • pas mal de liens sur html5 et css3 sur maxdesign.com
• Faire du html5 quand même :
  • http://52framework.com/
  • http://css3pie.com/
  • http://code.google.com/p/html5shiv/
  • http://www.keithclark.co.uk/labs/ie-css3/
  • http://media1.smashingmagazine.com/wp-content/uploads/images/html5-cheat-sheet/html5-cheat-sheet.pdf
• Démos et tutos
  • http://www.1stwebdesigner.com/resources/css3-tutorials/
  • http://dev.opera.com/articles/view/custom-html5-video-player-with-css3-and-jquery/
  • http://html5tutorial.net/
  • http://html5demos.com/
  • http://ie.microsoft.com/testdrive/Default.html
• Où en est votre navigateur ?
  • http://www.html5test.com/
  • http://www.findmebyip.com/litmus#target-selector
  • http://www.quirksmode.org/dom/html5.html
  • http://html5readiness.com/
  • http://w3c.html5.free.fr/

Et vous quel usage faites vous d’html5 et ses amis ? Applicable en milieu professionnel ou à réserver pour des projets isolés ?

Ce que vous ne faites pas (liste non exhaustive) :

- ne pas mettre de doctype à votre page,
- inclure une autre page html dans votre page html (doctype, balises html, head et body dans la première balise body)
- mal fermer vos balises ou ne pas fermer vos balises,
- faire vos structures de page en tableau,
- générer du contenu en javascript,
- faire du javascript intrusif,
- mélanger structure, styles et scripts,
- mettre des images de contenu en background (sans aucun texte alternatif),
- ne jamais valider votre code avec le validateur W3C

Il est facile de reprendre chacun de vos arguments et bonnes pratiques pour vous démontrer qu’elles n’ont aucune raison d’être :

- javascript non intrusif : avec 0,5% d’utilisateur sans javascript, ce n’est pas la peine de s’attarder là dessus, on fait au plus simple,
- maintenance facilitée par la séparation de la forme et du contenu : les pages sont refaites si souvent qu’on fait peu de maintenance sur les pages existantes,
- code léger : maintenant tout le monde a le haut débit, donc on peut faire des pages de 500ko,
- alternative à flash : t’as vu les stats ? Flash est présent à 98%  !

Il faut savoir que le plus souvent bien coder ne prends pas plus de temps que coder « à l’arrache », quand on a pris l’habitude ça devient vite une seconde nature. Du coup on devient vite exigeant, on fait la moue quand on doit reprendre un code moyen voire franchement dégueulasse. La tentation est grande de tout vouloir refaire, et si le temps est compté, il faut ronger son frein et exécuter ce travail peu valorisant en espérant qu’on ne sera jamais cité comme intégrateur sur ce projet.

L’avantage pour certains et l’inconvénient pour d’autres, est que quelque soit la qualité de votre code, le résultat restera correct dans le navigateur de l’internaute. On est loin du X(HT)ML…

Bien qu’incomplètement prise en compte par les différents navigateur, il est possible de l’utiliser avec quelques connaissances supplémentaires, démonstration :

Prenons l’exemple simple d’un formulaire d’inscription, où il faut aligner des label à 150px du bord d’input de type texte :

Pour le code html suivant :

<form action="http://www.example.net" method="post" id="inscription">
  <fieldset>
    <label for="prenom">Prénom <em>*</em></label>
    <input type="text" id="prenom" /><br />
    <label for="nom">Nom <em>*</em></label>
    <input type="text" id="nom" /><br />
    <label for="email">Email <em>*</em></label>
    <input type="text" id="email" /><br />
    <label for="password">Mot de passe <em>*</em></label>
    <input type="password" id="password" /><br />
    <label for="confirm-password">Mot de passe <em>*</em></label>
    <input type="password" id="password" /><br />
    <input type="submit" value="valider" class="input-submit" />
  </fieldset>
</form>

Je définis le styles des base, auxquels je vais ajouter (en gras) la propriété inline-block et les styles qui vont avec :

#inscription fieldset{border:none;}
#inscription label{display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}

Première constatation : ça fonctionne sur la plupart des navigateurs (IE6, IE7, Opera, Safari) mais pas sur les versions de Firefox antérieures à Firefox 3…

On ajoute alors la propriété display:-moz-inline-box; pour Firefox 2 et les versions antérieures, mais attention, il faut la placer avant display:inline-block, sinon ça ne fonctionne plus pour Internet Explorer et Firefox prend en compte display:-moz-inline-box; au lieu de prendre en compte display:inline-block.

#inscription fieldset{border:none;}
#inscription label{display:-moz-inline-box;display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}

Dans certains cas j’ai constaté des problème de layout avec Internet Explorer, dans ce cas ajouter la propriété display:inline dans une déclaration séparée :

#inscription fieldset{border:none;}
#inscription label{display:-moz-inline-box;display:inline-block;padding:5px 0 0;width:150px;font-weight:bold;}
#inscription input{border:1px solid #666;}
#IE #inscription label,
#IE #inscription .input-submit{display:inline;}

On obtient le résultat suivant, un formulaire structuré sans tableau, sans éléments flottant ou positionnés en dehors du flux html :

Seule limitation constatée, les éléments mis en inline-block dans Firefox se comporte comme ayant une propriété white-space:nowrap appliquée, il n’est pas possible d’avoir des textes sur plusieurs lignes…

Pour cela, il existe plusieurs solutions.

Eviter les embrouilles

Avec la pratique, un certain nombre de réflexes se mettent en place, et on anticipe immédiatement les problèmes.
Un float:left, avec une marge sur sa gauche ? Un display:inline placé dans la même déclaration permet d’éviter le bug de la double marge. Tous les navigateurs ignorent ce display:inline, car la propriété float est prioritaire. C’est toujours ça de pris.

Malheureusement ça ne suffit pas toujours, et il n’y a parfois d’autre solution que de déclarer une propriété spécialement pour IE.

Le bon vieux hack

Allons-y joyeusement, il faut résoudre un bug sur IE6, et les hacks semblent pratiques et simples à utiliser.
Allez, au hasard… Le sélecteur d’enfant : html > body

IE6 ne comprend pas le sélecteur « > ». Il donc est possible de profiter de ce bug pour cibler IE6, de cette façon :

.my_element{margin-left:5px;} /* Cette déclaration est interprétée par tous les navigateurs */
html > body .my_element{margin-left:8px;} /* ... Puis est écrasée par la suivante, sauf pour IE6 qui ne comprendra pas cette déclaration. */

C’est pratique. Seulement IE7 ne corrige pas le bug pour lequel nous devions corriger la propriété margin. Pour le sélecteur d’enfants, pas de problème, IE7 l’interprète. Logiquement, le bug réapparaît.

En suivant la même méthode, il faut donc trouver un nouveau bug de sélecteur dans IE7, et revoir la CSS. Il arrive également que IE7 ne doive pas recevoir la même correction. Il faut donc trouver un bug qui s’applique à IE7 mais pas à IE6.
Et comment être sûr de ne cibler qu’IE6 ? Un autre navigateur ne prenant pas en charge ce sélecteur pourrait exister.

Il nous faut une autre solution, permettant de cibler efficacement Internet Explorer.

Les commentaires conditionnels

Microsoft a ajouté quelque chose de formidable à Internet Explorer : les commentaires conditionnels.

Ils permettent de ne servir un contenu qu’à Internet Explorer en général, ou à une de ses versions, en utilisant une syntaxe particulière à l’intérieur de commentaires HTML.

Ils n’ont certainement pas être prévus pour ça au départ, mais ils sont aujourd’hui principalement utilisés pour corriger les bugs de ce navigateur.

Il est donc possible d’utiliser le code suivant :

<!--[if IE 6]> <link rel="stylesheet" href="styles/internet-explorer-6.css" type="text/css" media="screen" /> <![endif]-->

Pour un navigateur suivant la spécification HTML4.01, la balise <link> est simplement ignorée car elle est placée dans un commentaire, mais pas pour Internet Explorer. Il va lire ce commentaire, et si une condition est déclarée, et qu’elle correspond au navigateur utilisé, le code sera tout de même interprété.

Cette solution est fiable, car il n’existe aucune raison pour qu’un autre navigateur interprète, dans le passé ou l’avenir, un commentaire de ce type.

Il est donc possible de créer une CSS pour IE6, une autre pour IE7 au cas où, et allez, encore une pour les versions d’IE inférieures à 8, histoire de cibler toutes les version passées de ce vieil ami.

Nous voici donc avec notre feuille de style, et une, deux voire trois nouvelles pour Internet Explorer. Si les CSS du site sont réparties sur plusieurs fichiers, il va falloir créer autant de nouveaux ensembles de fichiers « IE », ou les utiliser de manière globale en prenant le risque d’appliquer à certaines pages des styles qui ne leur sont pas destinés.

Avec le temps, cette solution est beaucoup moins pratique : il faut jongler avec plusieurs fichiers, se souvenir que la déclaration de la ligne 310 du fichier « home.css » est corrigée à la ligne 14 du fichier « internet-explorer-6.css », mais aussi à la ligne 8 du fichier « internet-explorer-7.css ».

Il se pourrait aussi qu’un jour cette correction provoque un effet indésirable, placée dans un certain contexte. Il faudrait alors se souvenir que cet élément a été corrigé dans l’autre CSS, et que cette correction peut être la cause du dysfonctionnement.

Mais existe-t-il une méthode fiable et pratique ? P’t'êt’ bien, ouais.

Les commentaires conditionnels, en plus malin

Il s’agit avec cette technique d’utiliser les commentaires conditionnels non pas pour appeler une feuille de style, mais pour entourer la page d’un conteneur qui prendra comme attribut « id » IE6, IE7, IE ou encore NOTIE.

Cet identifiant permettra de cibler précisément une version d’Internet Explorer, dans une CSS « normale ».

Le code se présente sous cette forme :

<body>
<!--[if IE 6]><div id="IE6"><![endif]-->

Et avant la balise de fermeture </body> :

<!--[if IE 6]></div><![endif]-->
</body>

Pour les navigateurs « normaux » et un outil de validation html, il s’agit de commentaires html tout à fait classiques, et sont ignorés.

De cette manière, il est aussi possible d’ajouter le support d’IE, en ajoutant une balise d’ouverture <div id="IE7"> en haut et en modifiant la condition du bas pour cibler IE6 et IE7 à la fois.

Nous pouvons aussi utiliser des conditions de type « n’est pas », ce qui permet de cibler tous les navigateurs sauf IE.

Voici le code modifié :

<body>
<!--[if IE 6]><div id="IE6"><![endif]-->
<!--[if IE 7]><div id="IE7"><![endif]-->
<!--[if (IE) & (!IE 6) & (!IE 7)]><div id="IE"><![endif]--> <!-- Pour les anciennes et prochaines versions d'Internet Explorer (autres que 6 et 7) -->
<!--[if !IE]>--><div id="NOTIE"><!--<![endif]--> <!-- Le commentaire est fermé, puis rouvert -->

<!-- Structure HTML de la page -->

</div> <!-- Une simple fermeture de balise à la fin, car tous les navigateurs sont ciblés. -->
</body>

Il suffit ensuite d’utiliser ces sélecteurs de la même manière qu’un hack, mais plus clairement, plus facilement et surtout de manière fiable :

.mon_element{margin-left:2px;}
#IE .mon_element{margin-left:3px;}
#IE6 .mon_element{margin-left:4px;}
#IE7 .mon_element{margin-left:5px;}
#NOTIE .mon_element{margin-left:6px;}

Evidemment l’exemple est stupide, puisqu’il n’y a aucune raison de cibler tous ces éléments à la fois.

Les avantages sont nombreux :

• C’est fiable : une nouvelle version d’Internet Explorer sera considérée comme « standard » (mais attention à l’utilisation de #NOTIE, qui ne sera vraisemblablement pas reconnue par les futures version d’Internet Explorer)
• Une seule CSS à maintenir
• Le code HTML et CSS reste parfaitement valide
• La déclaration a du sens, il n’est pas utile de commenter ceci : #IE6 .mon_element{margin:-3px;}
• Lors de la sortie d’une nouvelle version d’IE, il suffit de lister les bugs qui n’ont pas été corrigés, et d’ajouter une nouvelle déclaration (IE8) pour ceux-ci.

A vous ensuite de composer avec ces différents exemples pour créer une structure adaptée à vos besoins : l’utilisation des éléments <div id="IE6"> et <div id="IE7"> devraient suffire à la majorité des cas.

En mode quirks, les navigateurs se comportent de la façon suivante, bien que tous les navigateurs ne présentent pas toutes ces caractéristiques :

• Le modèle de boîte est incorrect (différent des spécifications CSS bien que peut-être intuitivement plus naturel). Cela veut dire que les propriétés de largeurs et de hauteurs, donnent les dimensions de l’élément »boîte » dans son intégralité incluant les marges intérieures (padding) et les bordures et non juste le contenu de l’élément. (Demo plus loin dans ce document)
• Les dimensions des éléments inline (par exemple les éléments span par défaut) prennent en compte les propriétés de largeur et de hauteur spécifiées (alors que d’après les spécifications CSS, elles doivent être ignorées).
• Les hauteurs en pourcentage pour les éléments (par exemple
<table style="height: 100%;" border="0"> en HTML ou table { height: 100% } en CSS) sont appliquées en utilisant la taille disponible à titre de référence, même si le bloc conteneur a sa hauteur fixée à auto (valeur par défaut). Dans le mode standard, la hauteur est déterminée par les exigences du contenu, mais la hauteur en pourcentage marche quand le bloc conteneur a une valeur spécifique comme hauteur.
• Overflow provoque l’agrandissement de la boite. Quand le contenu d’un élément ne rentre pas dans les dimensions spécifiées (explicitement ou implicitement), overflow:visible (valeur par défaut) veut dire que le contenu dépasse des dimensions définies de la boîte. En mode quirks, les dimensions changent, ça peut être vu facilement par exemple si la boîte à une couleur d’arrière plan ou une bordure.
• Les marges intérieures (padding) pour les images sont ignorées lorsqu’elles sont définies en CSS pour l’élément img ou l’élément input de type image.
• La marge horizontale par défaut d’une image flottante est de trois pixels (au lieu de zéro). Ce qui veut dire que si l’élément img a les attributs align= »left » ou align= »right » ou se voit appliquer les règles CSS float:left ou float:right, le navigateurs se comporte comme si l’image avait l’attribut hscpace= »3″ (ou que sa marge de gauche ou de droite avait une valeur de 3px). Ceci ne s’applique qu’à IE; dans les autres navigateurs, le mode quirks provoquera cette marge d’un seul côté de l’image et sa largeur sera de 2 pixels au lieu de 3.
• L’alignement vertical d’une image se fait sous certaines conditions sur le bas de la boite conteneur, et non sur la ligne de base du texte. Cela arrive quand l’image est le seul contenu à l’intérieur d’un élément, typiquement une cellule de tableau. Ceci veut dire que par exemple, une image dans une cellule de tableau est par défaut en bas de la cellule en mode quirks (ce qui est souvent ce que veut l’auteur) quand en mode standard il y a quelques pixels d’espacement en dessous de l’image (à moins qu’on indique, par exemple vertical-align:bottom pour l’élément img).
• Centrer un bloc en utilisant par exemple margin: 0 auto ne marche pas.
• Les propriétés de font ne sont pas héritées de l’élément body pour les éléments inclus dans les tableaux. Ceci arrive surtout pour font-size mais peut également se produire pour font face, color et line-height. Par exemple, si vous mettez : body{font-family: arial}, il est possible que la police dans le tableau reste celle du navigateur par défaut.
• Pour la propriété font size dans une cellule de tableau, un pourcentage est interprété comme relatif à la taille de base de la police du navigateur, et pas à la taille de police qui est appliquée à l’élément conteneur (la ligne du tableau) par les CSS.
• Les valeurs de taille de police ne sont pas interprétées correctement, la taille medium est plus grande que la taille de police de base du navigateur et small est de la même taille. De la même manière, toute l’échelle, xx-small, x-small, small, large, x-large, xx-large, est systématiquement mal interprétée : chaque valeur est interprétée une taille plus grande qu’elle ne devrait l’être.
• Les valeurs incorrectes des propriétés sont souvent interprétées comme des devinettes, par exemple margin: 10 pour margin: 10px et color:ffffff pour color:#ffffff. Cette erreur de traitement imposée viole les règles des CSS : une règle utilisant une valeur syntaxiquement incorrecte doit être ignorée.
• La casse des lettres n’est pas prise en compte lors l’interprétation des sélecteurs de classe et d’id en CSS. Ainsi, le sélecteur .foo correspond à un élément ayant la classe class= »foo » ou class= »FOO ». Selon la spécification CSS, la casse des sélecteurs de classe ou d’id doit être prise en compte.
• Les noms incorrects sont acceptés dans les classes et sélecteurs d’id. Plus précisément les noms commençant par un point ou un nombre (par exemple, les sélecteurs .123a et #42) sont acceptés.
• La déclaration white-space: pre est ignorée.
• La position fixed n’est pas supportée : la déclaration position: fixed est traitée comme position: static (dans IE7)
• De nombreux ajouts au support des CSS ( comme la propriété max-width et les sélecteurs d’attribut) dans IE7 ne sont pas utilisables en mode quirks. Ce qui veut dire que beaucoup de caractéristiques css n’étaient pas supportées dans IE6 et le sont dans IE7, mais seulement en mode standard. Voir le blog de Microsoft pour les détails sur les modifications CSS pour IE7.
• Interprétation de soupe de balise. Par exemple, si un document contient le code : <p>text<table>...</table>, Firefox traite l’élément p comment étant le conteneur de l’élément table en mode quirks. Dans le mode standard, l’élément ouvrant de table ferme implicitement l’élément p. La différence peut être vue, quand par exemple on met une bordure sur l’élément p. De même, Firefox, accepte un élément ul à l’intérieur d’un élément font. IE suit des règles fausses dans ce genre de cas, même en mode standard, mais un comportement conforme aux standards peut être obtenu en utilisant du code valide et en utilisant explicitement des balises fermantes comme </p> même quand elles sont facultatives.
• Les espaces blancs entre les éléments peuvent être significatifs. Par exemple, disons que vous ayez une liste de liens. Normalement vous écririez le code avec des sauts de lignes entre les éléments de la liste, les éléments li (ce qui est entre les balises </li > et <li>)
  

  <ul>
  <li><a ...>...</a></li>
  <li><a ...>...</a></li>
  ...
  </ul>

  
  Cependant, si vous indiquez display: block et une bordure pour les liens, vous vous retrouvez avec des écarts verticaux (des lignes vides) entre les éléments. Ceci arrive dans IE7 en mode quirks et toujours dans les versions précédentes d’IE.

• Les formulaires ont une marge (margin-bottom) de 1em dans les navigateurs Mozilla. (Dans IE, il y a cette marge dans les deux modes). Ceci est apparemment destiné à poursuivre la tradition des navigateurs web de laisser autant d’espace sous un formulaire. C’est une question fréquemment posée : comment se débarasser de la ligne vide sous un formulaire.
• Les marges verticales sont supprimées dans certains contextes. Par exemple quand un élément p est le premier élément d’un élément td. Ceci est plus ou moins un comportement habituel dans les navigateurs et est présent dans IE dans les deux modes.
• Les navigateurs Mozilla (comme Firefox et Seamonkey) ont des caractéristiques supplémentaires, documentés dans le fichier quirk.css. Par exemple, la couleur par défaut des bordures de tableau est gris (gray) (comme dans la plupart des autres navigateurs), contrairement à l’utilisation de la couleur de premier plan en mode standard. Dans ces cas, le mode quirks est vraiment juste un mode différent de compatibilité. NB : Les paramètres de ce fichier ne s’appliquent pas à toutes les versions de Mozilla.

La liste n’est probablement pas exhaustive. Elle se réfère principalement à IE7. Les autres navigateurs peuvent avoir un mode quirks qui ne simulent les anciennes versions de IE dans la même mesure.

Démo simple

Les images suivantes montrent une des nombreuses différences entre le mode quirks et le mode standard dans Internet Explorer, à savoir le modèle de boîte. Voici les présentations du code suivant dans les deux modes :

<div style="border: solid 2px #006; width: 8em; padding: 0 2em">stuff</div>

(Mode quirks)

(Mode standard)

Voilà l’élément rendu par votre navigateur actuel, pour une vérification rapide :

L’explication est qu’en mode quirks, la propriété width est comprise (incorrectement) comme étant la largeur totale de la boîte, 8em dans ce cas. En mode standards, elle est comprise comme étant le total des éléments de la boîte, soit 12em (plus la largeur des bordures). La largeur totale inclut les marges intérieures (padding) gauche et droite, chacune d’une valeur de 2em.

Dans Firefox, le modèle de boîte correct est appliqué dans les deux modes. Cependant, on peut simuler le modèle de boîte incorrect utilisé par IE en mode quirks en utilisant la commande CSS/ utiliser le mode « border-box » dans l’extension « Web Developper » (Qui est un outil très utile pour toute les questions relatives aux CSS et beaucoup d’autres choses)

Vérifier le mode

Pour vérifier dans quel mode est un navigateur (quirks contre standards),

Dans Firefox, utiliser la commande Outils/Informations sur la page (et regarder l’onglet général); ou si vous avez l’extension « Web Developer », aller dans information/informations sur la page.

Pour IE, taper javascript:alert(document.compatMode) dans la barre d’adresse, et vérifier si la fenêtre d’alerte renvoit alors CSS1Compat (indiquant qu’il s’agit du mode standard) ou BackCompat (indiquant qu’il s’agit du mode quirks); autre alternative,télécharger et installer le Bokmarklet « Quirks or Standards Mode ».

Habituellement faire cohabiter deux versions d’IE suffit, mais étant donné qu’une partie encore importante des internautes se cramponne au vieux navigateur IE6, il est souhaitable de pouvoir tester ses pages dans les trois dernières version du navigateur.

1ère étape : Installer Internet Explorer 8 version beta.

Pour celà aller sur le billet de Pierre du 6 mars dernier ou encore plus rapide : ici.

Une fois que c’est fait le navigateur installé, vous pouvez passer à l’étape 2.

2ème étape : Installer les précédentes versions d’IE

Il y a une solution que j’avais adopté pour la version précédente (la 7) : multiple IE, le soucis c’est que ça ne fonctionne pas avec Windows Vista. Si vous avez Windows XP, c’est nickel, mais le problème c’est que vous n’aurez pas IE7 puisque multiple IE s’arrête à IE6.

La deuxième solution consiste à installer IE7 en version standalone. Pour les infos : c’est ici ou encore ici.

Une fois avoir installé IE7, on va essayer d’installer multiple IE, mais auparavant on va voir si IE8 et IE7 s’entendent… D’après mes tests, ça marche pas trop mal, mais il ne faut pas être gêné par les messages d’erreurs. J’ai principalement ce message au chargement de la première page dans IE7 :

L'ordinal 14 est introuvable dans la bibliothèque de liaisons dynamiques iertudil.dll

On peut ensuite installer Multiple IE. D’après mes test cette solution n’est pas pleinement fonctionnelle. Je n’ai pas pu accéder au champs de recherche de Google, impossible de prendre le focus…

Si vous n’avez pas XP mais Vista, vous allez forcément opter pour la troisième solution : installer un émulateur de PC pour faire tourner windows… sous windows. Virtual PC est disponible sur le site de Microsoft, mais je n’ai pas réussi à l’installer jusqu’au bout, il est vrai que je dispose de la version light de Vista, la home premium*, donc si vous êtes comme moi, vous allez plutôt vous porter sur mon deuxième choix : Virtual Box. Là pas de problème l’install se passe sans encombre. Il ne reste plus qu’à installer la version native d’IE6 ou IE7 en téléchargement sur le site de Microsoft. Après, à vous de voir : soit installer multiple IE ou IE7 en version standalone, soit opter pour une version différente par PC virtuel…

Vous avouerez que ça fait pas mal de soucis pour un navigateur qu’on n’utilise uniquement pour tester ses pages, non ?

* Host operating system: Windows Vista Business, Windows Vista Enterprise, Windows Vista Ultimate, Windows Server 2003 Standard Edition, Windows Server 2003 Standard x64 Edition, Windows XP Professional, or Windows XP Tablet PC Edition (source site microsoft.com)

En effet loin d’être de simples exécutants, les intégrateurs sont souvent détenteurs d’un savoir et de compétences polyvalentes, car il faut bien l’avouer, ceux qui auparavant étaient regroupés sous le vocable fourre-tout de webmaster sont souvent des passionnés du web pour ne pas dire des accros ne comptant pas leurs heures de netsurfing afin de saisir toutes les subtilités qu’il est nécessaire de posséder pour arriver à concevoir le site parfait…

Prenez un intégrateur, immergez-le dans une entreprise pourvu d’un service webdesign et d’un service informatique, hésitez sur l’endroit où le placer Informatique ? non webdesign ! non informatique ! non webdesign ! non informatique ! Bref ! Demandez lui de recruter quelques-uns de ces pairs (lui seul est en mesure de les reconnaitre). Voilà votre pôle intégration constitué.

Maintenant il s’agit de faire sa place… XHTML strict, accessibilité, ergonomie, javascript non intrusif, il vous sera difficile au départ de comprendre son langage. Il manie des concepts dont vous comprenez mal l’intérêt. Il paraît se compliquer la vie et opter délibérément pour des choix à l’exact opposé des votres, Ces modèles : Eric Meyer, Jakob Nielsen, Dean Edwards, Dave Shea sont des parfaits inconnus pour vous ! Vous n’avez pas de leçon à recevoir de ces nouveaux venus, vous vous en êtes bien passé jusque là !!! Pourvu que vous lui accordiez un peu d’attention, vous verrez assez rapidement que « l’intégrateur » cette bête curieuse va rapidement vous faciliter la vie.

Plus sérieusement : qu’est-ce qu’un intégrateur ? Quel est son rôle ? Quelle doit être sa place ?

L’intégrateur maîtrise le code html ou xhtml, les styles en cascade (CSS) et a de bonnes notions de Javascript. Avec ces trois langages il est en mesure de vous construire une interface qui tient la route. En effet c’est lui qui va permettre de structurer les données dans la page web, chaque balise html ayant une utilité bien spécifique, il va donner de l’importance à la valeur sémantique de chacune. <h1> pour les titres, <p> pour les paragraphes, <ul><li> pour les listes non ordonnées, etc..; la liste est très longue mais sachez qu’il existe 91 balises html et que toutes ont une utilité bien particulière.

Vous l’aurez compris l’intégrateur attache plus d’importance au sens de chacune de ces balise qu’à ces qualités graphiques. Les styles CSS étant spécifiquement dédiés à cette utilité depuis que les fabricants de navigateurs ont eu la bonne idée, mais un peu tardive il faut bien le dire, d’ y implémenter les CSS. Il reste encore du boulot néanmoins, rendez-vous compte par vous même : compatibilité des css dans les navigateurs.

Une fois qu’il a structuré sa page, ajouté les styles pour rendre la page plus agréable, il ne lui reste plus qu’à ajouter quelques comportements qui devront être non-intrusif (ça veut dire que sans JS ça marche quand même ! Magique, non ?). Effectivement l’intégrateur a toujours une petite pensée pour les minorités : ceux qui n’ont pas flash, qui n’ont pas javascript, qui ont de petits écrans, des vieux navigateurs (enfin pas aussi vieux qu’IE6 , j’espère), de mauvais yeux, des mouvements peu surs, des connexions lentes, bref nous tous quoi ! :-)

Ce dernier point s’appelle l’accessibilité et sans pousser le bouchon trop loin, un zeste d’accessibilité dans un site ce sont des internautes en plus qui n’auraient certainement pas pu y naviguer…

Je ne parlerais pas d’ergonomie, ni de référencement, ni même d’interopérabilité parce que vous l’avez déjà compris un intégrateur ce n’est ni un développeur ni un webdesigner graphique, c’est bien autre chose ! Et le jour où une entreprise aura enfin compris ce qu’est la maitrise et la puissance de l’intégration, et bien ce jour là le web lui appartiendra ! (non je déconne là, vous emballez pas !) Enfin ce que je voulais dire c’est qu’intégrateur, c’est un métier !

Bon bah voilà, c’est dit. J’ai fini. vous aussi vous faites ce métier ? ah ouais ? Bon on n’est pas seuls alors… Et autrement ça se passe comment, vous ? Ah ouais ? Vous voulez pas nous en parler ? Dans les commentaires ? Ouais… parfait …

Firebug 1.1 beta n’a pas ce problème : vous trouverez cette version sur le site du projet Fireclipse, dont le but est d’apporter une interaction entre Firebug et Eclipse.
Diverses améliorations et corrections de bugs ont été apportées au passage à notre très chère extension, mais il ne s’agit pas d’un fork : la version 1.1 finale sera bien distribuée sur getfirebug.com, comme l’indique un billet sur le blog du site.

Fireclipse regroupe les éléments suivants :

1. L’extension Firebug patchée
2. Un plugin Eclipse
3. Une extension à Firebug, lui permettant d’interagir avec Eclipse

Ainsi, l’extension Firebug améliorée est totalement indépendante, et peut être installée seule.

Voici la liste des modifications apportées :

• eval() debugging
• External editor interface
• Browser-generated event handler debugging
• Executable lines marked with green line numbers
• User-controlled naming of eval() buffers
• Stack side panel on « Script » panel for callstack
• Supports Firefox 3
• « Better » debugging icons
• CSS errors report against source lines
• Bug fixes (incl. issues 8, 69, 218, 230, 239, 249, 269, 314, 321, 345)
• Internal firebug debug output

Je profite du sujet pour mentionner l’extension YSlow pour Firebug proposée par Yahoo!, permettant d’analyser vos pages (poids des éléments, nombre de requêtes, …) puis de consulter diverses optimisations afin d’en accélérer le rendu. Très pratique !

Télécharger Fireclipse / Firebug 1.1b : http://fireclipse.xucia.com/#Downloads
Télécharger YSlow : https://addons.mozilla.org/en-US/firefox/addon/5369