Les intégristes

Cibler Internet Explorer dans une CSS ? Oui, et sans hack.

La méthode commence à être rodée : pour intégrer un design en CSS, on commence par le faire sur un navigateur “moderne”, puis on corrige les différents problèmes rencontrés sur Internet Explorer, surtout dans sa version 6, qui commence à sérieusement à s’incruster.

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.

Que se passe-t-il en mode quirks ? (traduction)

Ce billet est la traduction de l’article “What happens in Quirks mode” de Jukka “Yucca” Korpela initialement paru sur le site du Tampere University of Technologie (Finlande) le 13 avril 2007, dernière modification le 28 février 2008.

Le mode quirks est un mode de fonctionnement des navigateurs Web tels qu’Internet Explorer (IE), Firefox et Opera. En gros, le mode quirks (aussi appelé mode compatibilité) signifie qu’un navigateur relativement moderne simule intentionnellement de nombreux bugs des anciens navigateurs, en particulier IE 4 et IE 5.

Le mode quirks est déclenché par le doctype sniffing aussi connu sous le nom de doctype switching. Cela signifie que le navigateur inspecte le début d’un document HTML pour voir si il contient une déclaration de doctype comme requis par les spécifications HTML.

Le but du mode quirks est de faire que les vieilles pages s’affichent comme l’a voulu leur auteur. Les vieilles pages peuvent avoir été écrites pour utiliser les caractéristiques connues des vieux navigateurs ou du moins de s’y adapter. Pour plus d’informations sur le mode quirks, en général, consultez le site QuirksMode.org.

Il n’existe pas de spécification de ce qui se passe en mode Quirks. Après tout, le mode est, par essence, une violation intentionnelle des spécifications CSS et HTML. Cependant, puisque les auteurs peuvent avoir besoin d’une description de ce qui peut réellement se passer dans le mode quirks, j’ai rédigé ce document.

Si vous avez une page existante qui semble bien fonctionner mais qu’il lui manque une déclaration de doctype (exigés par les spécifications HTML), pour commencer vous devriez éviter d’ajouter cette déclaration. La raison en est que la déclaration fait basculer les navigateurs en mode standard opposé au mode quirks. Cela peut donner à peu près n’importe quoi. J’ai vu tout le contenu d’une page disparaître lorsqu’on ajoute une déclaration de doctype. Plus souvent, le [layout] change de façon plutôt inattendue. Eh bien, les résultats ne sont pas inattendus que ça si vous savez ce qui peut se passer en mode quirks. Avant d’ajouter une déclaration de doctype, vous devriez vérifier à la fois le code HTML et CSS pour la correction syntaxique en utilisant les validateurs et vérificateurs. Ce n’est peut-être pas assez, puisque la page pourrait encore avoir été écrit en se fondant sur ce qui «marche» en mode quirks. Ainsi, vous devez tester la page au moins sur IE 7 et Firefox 2 en mode standard, c’est-à-dire après avoir ajouté une déclaration de doctype. Si la page ne fonctionne pas alors, la liste suivante pourrait être utile pour repérer le problème.

Lors de la création d’une nouvelle page, vous n’avez pas besoin d’avoir de connaissances sur le mode quirks et ne devriez normalement pas y penser. Il suffit d’écrire selon les spécifications HTML et CSS, ce qui inclut l’utilisation d’une déclaration de doctype qui fera passer les navigateurs modernes en mode standard. En outre, la déclaration de doctype indiquée dès le début fait passer certains navigateurs en mode quirks, s’il y a quelque chose (même un commentaire) avant. (Ceci entraîne des problèmes si vous utilisez XHTML, mais dans la plupart des cas, vous ne devriez pas utiliser XHTML pour les pages Web de toute façon, pour l’instant.) Mais si vous décidez d’utiliser certaines fonctionnalités qui fonctionnent seulement en mode Quirks, comme l’attribut height = "100%" pour l’élément table, il vous faudra vérifier la liste pour les autres incidences possibles.

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>

$Une boîte avec le text \$ (Mode quirks)

$Une boîte avec le texte \$ (Mode standard)

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

stuff

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”.

06 04 2008 Eric Le Bihan Internet Explorer
Intégration
Navigateurs Commentaires (1) Lien permanent

Les formulaires d’inscription doivent disparaître (traduction)

Voici la traduction d’un article publié sur A List Apart par Luke Wroblewski, dont le titre original est « Sign Up Forms Must Die ».

Il y est question de différentes solutions regroupées sous l’appellation “engagement progressif”, permettant à vos visiteurs de comprendre et d’utiliser votre service avant (ou pendant) l’inscription, en évitant autant que possible le classique et indigeste formulaire d’inscription.

Poursuivre la lecture ›

25 03 2008 Pierre Bertet Accessibilité
Ergonomie
Traduction Commentaires (7) Lien permanent

Faire cohabiter plusieurs versions d’Internet Explorer

Avec la version béta d’Internet Explorer 8, se pose la question habituelle aux développeurs et intégrateurs à chaque sortie d’une nouvelle mouture du navigateur de Microsoft : comment faire cohabiter plusieurs versions d’Internet Explorer sur son PC ?

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)

12 03 2008 Eric Le Bihan CSS
HTML
Internet Explorer
Intégration
Navigateurs
actualité Commentaires (8) Lien permanent

Internet Explorer 8 Beta 1 !

Microsoft vient de publier la première beta de la prochaine version de son navigateur, Internet Explorer 8.

Un article sur le blog dédié nous en liste les différentes améliorations :

La version définitive apportera un support complet de CSS 2.1.
Ils ont contribué à la création de plus de 700 tests en collaboration avec le Groupe de travail CSS du W3C, publiés sous licence BSD. Selon l’équipe, la spécification CSS est bien conçue mais pas suffisante, car ambigüe sur de nombreux points. Une suite de tests devrait permettre aux éditeurs de mieux les interpréter, en s’appuyant sur des tests pouvant être suivis par l’ensemble des éditeurs.
De meilleures performances pour les scripts. Il s’agit d’un gros enjeu pour les navigateurs ( Firefox 3 sera lui aussi bien plus rapide, et Safari se présente d’emblée comme [Le] navigateur web […] le plus rapide de la planète. ) : les bibliothèques Javascript permettent aujourd’hui de créer de véritables applications en ligne, bien plus complexes et gourmandes qu’il y a quelques années. Le navigateur est allé bien au-delà de son rôle principal : il est devenu une plate-forme de choix pour de nombreuses applications innovantes.
Un début de support d’HTML5.
La création prochaine d’outils pour débugger les CSS et le Javascript.
Une fonctionnalité appelée “Activities” apparaît. Elle permet de mieux intégrer les différents services web au navigateur, comme sélectionner du texte sur une page et l’envoyer vers son blog, ou rechercher directement une adresse sur un service de cartes en ligne. Voici une excellente occasion d’ajouter un support des microformats, mais en fait non. C’est une bonne opportunité pour Microsoft d’amener plus d’utilisateurs vers ses différents services, bien que des concurrents soient également présents, comme ~~Facebook~~ ~~Yahoo~~ eBay. Non, pas Google.
Une autre fonctionnalité a été intégrée, appelée “WebSlices“. Globalement, ça ressemble aux Web Clips de Safari, mais ne nous y laissons pas prendre : ce sont les WebSlices, d’Internet Explorer.

Le test Acid2 ne passe pas tout à fait s’il est effectué sur un autre domaine que www.webstandards.org, pour une raison de sécurité. Ce devrait être réglé dans la prochaine beta.

Vous pourrez le télécharger ici : http://www.microsoft.com/windows/products/winfamily/ie/ie8/default.mspx
Tristan Nitot en parle : http://standblog.org/blog/post/2008/03/05/Internet-Explorer-8-et-les-standards-le-retour

Peu de temps après l’abandon in extremis de solutions permettant d’activer le moteur de rendu “moderne” pour finalement l’activer par défaut (il faudra à l’inverse demander explicitement à passer en “mode compatible”), Microsoft semble plus que jamais impliqué dans une nouvelle guerre des navigateurs, mais du côté des standards cette fois.

Qu’en pensez-vous ?

06 03 2008 Pierre Bertet Internet Explorer
actualité Commentaires (2) Lien permanent

La vie des intégrateurs
Chapitre I : Les intégrateurs sont-ils des développeurs ou des webdesigners ?

La question peut paraître incongrue, mais bien que ce métier commence à être reconnu (qui d’autre connait aussi bien les subtilités d’interprétation de navigateurs comme IE6 qui malgré son grand age continue à être utilisé par 40% des internautes français ?), ses représentants sont souvent ballotés d’un service à l’autre, développeurs frustrés pour certains, webdesigners en panne de créativité pour d’autres, il est difficile pour ces deux corps de métiers que sont le webdesign graphique et le développement informatique, de croire que ce métier auquel aucune école ne forme soit un choix délibéré. Pourtant quel autre métier prépare autant aux métiers de chef de projets, référenceur, ergonome ou expert es-accessibilité ? Aucun !

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 …

02 03 2008 Eric Le Bihan Accessibilité
CSS
Ergonomie
HTML
Internet Explorer
Intégration
JavaScript
Référencement
Sémantique Commentaires (22) Lien permanent

La place du moteur de recherche sur les sites de e-commerce

Quand j’arrive sur un site de e-commerce c’est souvent pour y trouver un produit ou un type de produit bien défini. Je ne veux pas chercher et je veux accéder à mon information le plus rapidement possible. Aussi je privilégie le moteur de recherches à la navigation traditionnelle que je trouve rébarbative. Mais cette habitude m’est personnelle et en discutant autour de moi je me suis rendu compte que les autres personnes n’étaient pas aussi directes que moi et passaient par tout un tas d’étapes avant d’accéder à leur produit. Après tout, chacun ses habitudes. Cependant Google étant le moteur de recherche le plus utilisé dans le monde, il est difficile d’imaginer que les internautes ne seraient pas emballés de trouver une telle simplicité sur leurs sites préférés… En début de mois je suis tombé sur un article dans Capitaine commerce et ce chapitre m’a interpellé :

Les évolutions les plus récentes du web ont montré la supériorité écrasante des moteurs de recherche sur les arborescences (voir le triomphe de Google sur les Directories de Yahoo). Actuellement, plus d’un internaute sur deux, lorsqu’il “fouille” un site de ecommerce utilise en premier le moteur de recherche du site. J’ai, en fait, de plus en plus tendance à croire que les sites de ecommerce devraient s’orienter vers une morphologie de moteur de recherche, les éléments arborescents ne venant plus qu’à l’appui des résultats de recherche. L’exemple extrême serait d’imaginer la page d’accueil d’un site ecommerce identique à celle de Google, tout l’enjeu serait alors de fournir simplement les meilleurs résultats de recherche à l’internaute et d’oublier les classifications lourdes en arborescence qui rendent si longue et si fastidieuse la navigation sur des sites contenant parfois plusieurs dizaines de milliers de références.

Source : http://www.capitaine-commerce.com/index.php/2008/02/04/506-esquisse-d-un-moteur-de-recherche-pour-le-e-commerce

Alors que de nombreux sites de e-commerce continuent à aligner les onglets et les navigations compliquées au risque de perdre leur clients dans les dédales de leur site, à noyer leur moteur de recherche au milieu de publicités, macarons et autres messages promotionnels, quelques sites de grande envergure ont pris le pari de proposer une autre organisation au risque de dérouter leurs clients : dans le genre le site américain amazon.com fait très fort : plus d’onglets, une navigation à gauche qui reprend la liste des catégories de produit et un moteur de recherche très présent puisque le champs de saisie occupe plus de la moitié de la page dans sa largeur !

La Fnac, même si ce n’est pas aussi spectaculaire a également mis en valeur son moteur de recherche dans sa nouvelle version, Kelkoo propose une navigation innovante ainsi qu’un moteur de recherche très présent, like.com place son moteur de recherche tout en haut de la page avant toute autre information, une tendance à suivre ?

24 02 2008 Eric Le Bihan Ergonomie
actualité
e-commerce Commentaires (0) Lien permanent

Des problèmes avec Firebug depuis Firefox 2.0.0.12 ?

Depuis la dernière mise à jour de Firefox (2.0.0.12), l’onglet “HTML” de Firebug n’affiche plus le style des liens.

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 :

L’extension Firebug patchée
Un plugin Eclipse
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

13 02 2008 Pierre Bertet Intégration
Outils Commentaires (2) Lien permanent

Webkit supporte document.querySelectorAll();

Le seul moyen de sélectionner des éléments en Javascript est d’utiliser les méthodes DOM classiques : document.getElementById(), getElementsByTagName(), nexSibling(), etc.

C’est assez fastidieux, et n’incite pas vraiment les développeurs à concevoir leurs scripts de manière non-intrusive.

Voilà pourquoi plusieurs librairies Javascript ont ajouté une couche supplémentaire : il suffit de passer une chaîne de sélecteur CSS, et cette chaîne est retranscrite en méthodes DOM classique par le moteur de la librairie pour retourner un tableau d’éléments correspondant à ce sélecteur. Evidemment, toutes ces opérations ont un coût en termes de performances.

Selectors API propose de régler ce problème : il sera tout simplement possible de passer une chaîne CSS à la méthode document.querySelectorAll();, qui renverra un tableau d’éléments correspondant à la sélection. Bien entendu, cette méthode sera exécutée par le navigateur, ce qui est beaucoup plus intéressant.

La dernière version de Webkit vient d’intégrer cette méthode, et les résultats sont très concluants. Pour le démontrer, ils ont utilisé le benchmark slickspeed du projet mootools, permettant justement de comparer les performances des sélecteurs CSS pour chaque bibliothèque : http://webkit.org/perf/slickspeed/ .

Les différentes bibliothèques utilisant un sélecteur de ce type, comme jQuery, peuvent d’ores et déjà prendre en compte les navigateurs supportant cette méthode : il suffit de tester document.querySelectorAll(), et de lui passer la main s’il existe.

L’article sur Webkit.org : http://webkit.org/blog/156/queryselector-and-queryselectorall/
Télécharger la dernière version de Webkit : http://nightly.webkit.org/

10 02 2008 Pierre Bertet JavaScript
Webkit Commentaires (0) Lien permanent