Intégration web - Les bonnes pratiques
416 pages
Français

Vous pourrez modifier la taille du texte de cet ouvrage

Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Intégration web - Les bonnes pratiques

-

Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus
416 pages
Français

Vous pourrez modifier la taille du texte de cet ouvrage

Description

Intermédiaire entre le chef de projet, le designer et le développeur, intégrateur web (ou développeur front-end) est un métier à part entière. Maillon indispensable dans la création de sites, il rassemble tous les éléments pour monter les pages et livrer un site performant, accessible et utilisable. Son travail nécessite tout autant de compétences techniques en HTML, CSS et JavaScript qu'une bonne appréhension de la qualité web (ergonomie, accessibilité, performance...).



S'appuyant sur l'expérience de l'auteur, souvent appelée à la rescousse sur des projets mal engagés, ce livre offre aux intégrateurs débutants, comme aux plus expérimentés, un recueil précieux des meilleures pratiques, méthodes et outils pour améliorer et réussir leurs intégrations dans le respect des standards du Web.



Une référence pour tous les créateurs de sites web !



Avec une préface d'Elie Sloïm et Laurent Denis.




"Avec le mouvement d'industrialisation des métiers du Web, chaque métier voit émerger un livre de référence. Pour l'intégrateur web, c'est chose faite grâce à ce livre, qui représente un jalon important dans l'histoire de cette discipline en évolution permanente !"

Elie Sloïm, Président de Temesis et Directeur des projets Opquast et Openweb.





  • Bien préparer son projet


    • Organiser son espace de travail


    • S'équiper des bons outils


    • Mettre en place l'environnement de test




  • Elaborer un socle HTML solide


    • Adopter HTML5


    • Concevoir les fondations


    • Construire la structure


    • Injecter le contenu


    • Incorporer les images




  • Habiller le contenu grâce aux CSS


    • Réviser les bases


    • Définir une convention d'écriture


    • Organiser le code CSS


    • Prendre connaissance des facteurs d'optimisation


    • Contrôler et déboguer


    • Préparer la livraison (ou la mise en ligne)




  • Peaufiner les détails

Sujets

Informations

Publié par
Date de parution 25 octobre 2012
Nombre de lectures 291
EAN13 9782212177220
Langue Français
Poids de l'ouvrage 5 Mo

Informations légales : prix de location à la page 0,0165€. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Exrait



S'appuyant sur l'expérience de l'auteur, souvent appelée à la rescousse sur des projets mal engagés, ce livre offre aux intégrateurs débutants, comme aux plus expérimentés, un recueil précieux des meilleures pratiques, méthodes et outils pour améliorer et réussir leurs intégrations dans le respect des standards du Web.



Une référence pour tous les créateurs de sites web !



Avec une préface d'Elie Sloïm et Laurent Denis.




"Avec le mouvement d'industrialisation des métiers du Web, chaque métier voit émerger un livre de référence. Pour l'intégrateur web, c'est chose faite grâce à ce livre, qui représente un jalon important dans l'histoire de cette discipline en évolution permanente !"

Elie Sloïm, Président de Temesis et Directeur des projets Opquast et Openweb.





  • Bien préparer son projet


    • Organiser son espace de travail


    • S'équiper des bons outils


    • Mettre en place l'environnement de test




  • Elaborer un socle HTML solide


    • Adopter HTML5


    • Concevoir les fondations


    • Construire la structure


    • Injecter le contenu


    • Incorporer les images




  • Habiller le contenu grâce aux CSS


    • Réviser les bases


    • Définir une convention d'écriture


    • Organiser le code CSS


    • Prendre connaissance des facteurs d'optimisation


    • Contrôler et déboguer


    • Préparer la livraison (ou la mise en ligne)




  • Peaufiner les détails

' />

R sum
Intermédiaire entre le chef de projet, le designer et le développeur, intégrateur web (ou développeur front-end ) est un métier à part entière. Maillon indispensable dans la création de sites, il rassemble tous les éléments pour monter les pages et livrer un site performant, accessible et utilisable . Son travail nécessite tout autant de compétences techniques en HTML, CSS et JavaScript qu’une bonne appréhension de la qualité web (ergonomie, accessibilité, performance…).
S’appuyant sur l’expérience de l’auteur, souvent appelée à la rescousse sur des projets mal engagés, ce livre offre aux intégrateurs débutants, comme aux plus expérimentés, un recueil précieux des meilleures pratiques, méthodes et outils pour améliorer et réussir leurs intégrations dans le respect des standards du Web.
Une référence pour tous les créateurs de sites web !

« Avec le mouvement d’industrialisation des métiers du Web, chaque métier voit émerger un livre de référence. Pour l’intégrateur web, c’est chose faite grâce à ce livre, qui représente un jalon important dans l’histoire de cette discipline en évolution permanente ! »
Élie Sloïm,
Président de Temesis et Directeur des projets Opquast et Openweb
Biographie auteur
Intégratrice senior et Experte AccessiWeb en Évaluation, Corinne Schillinger s’est forgée une solide expérience dans le domaine du développement front-end avant de créer son entreprise, Inseo, en 2009. Ayant à cœur de promouvoir les standards et la qualité web, elle a intégré l’association Paris Web en 2011, rejoint l’équipe éditoriale du Train de 13h37 et partage son expérience en animant régulièrement des ateliers à l’occasion d’évènements dédiés à la conception web.
AU SOMMAIRE
Bien préparer son projet Espace de travail Outils : éditeurs et inspecteurs de code, préprocesseurs, systèmes de gestion de versions… Environnement de test : le « cas » Internet Explorer Élaborer un socle HTML solide HTML5 Fondations : compatibilité avec IE, styles CSS et interactions JavaScript, métadonnées Structure : balisage, sémantique et rôles ARIA, liens d’évitement Contenu : faut-il utiliser un framework ? Images : formats, images adaptatives, alternatives textuelles Habiller le contenu grâce aux CSS Schémas de positionnement, cascade, propriétés abrégées Convention d’écriture : instructions, blocs de déclarations, commentaires… Organiser les règles CSS Facteurs d’optimisation Concevoir la feuille de styles Contrôler le rendu et l’accessibilité Préparer la livraison.
www.editions-eyrolles.com
Corinne Schillinger
Intégration web :
les bonnes pratiques
LE GUIDE DE SURVIE DE L'INTÉGRATEUR !
Préface d’Élie Sloïm & Laurent Denis
ÉDITIONS EYROLLES
61, bld Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com
Remerciements à Virginie Caplet ( http://cheekfille.com ) pour ses illustrations d’ouverture de parties et à Renaud Scapin pour la réalisation des pictogrammes.
Attention : la version originale de cet ebook est en couleur, lire ce livre numérique sur un support de lecture noir et blanc peut en réduire la pertinence et la compréhension.
  En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation de l’éditeur ou du Centre Français d’Exploitation du Droit de Copie, 20, rue des Grands Augustins, 75006 Paris.
© Groupe Eyrolles, 2012 ISBN : 978-2-212-13370-7

PRÉFACE
Rappelez-vous. Il y a quelques années, la plupart des webmasters (car on les appelait encore comme cela) utilisaient des logiciels comme Dreamweaver, Frontpage ou Hotmetal pour créer leur sites Internet. Ces logiciels WYSIWYG (What You See Is What You Get) permettaient de faire du code plus ou moins propre pour un navigateur ultramajoritaire, en l’occurrence, Internet Explorer.
À cette époque, l’intégrateur n’existait pas et le webmaster n’avait pratiquement besoin d’aucune compétence spécifique ni d’aucune formation : il était en pleine invention de son métier, de ses outils et de ses technologies.
C’est alors que sont arrivées successivement les feuilles de styles et la séparation du fond et de la forme. Le processus de création de site web s’est alors découplé en deux phases successives : le design puis l’intégration. Ces deux activités ont longtemps été assumées par des personnes aux profils similaires, avant que chacun des deux métiers ne se constitue progressivement.
Intégrateur front-end est aujourd’hui un vrai métier et Corinne Schillinger nous le prouve à travers l’exposé détaillé de son utilisation des technologies, de ses méthodes, approches, processus, standards et pratiques. Il s’y dessine finalement un véritable écosystème, un ensemble de relations entre métiers du Web, où l’intégrateur joue un rôle clé.
L’intégrateur a une fonction pivot entre plusieurs compétences. On pense immédiatement au découpage et à l’intégration HTML-CSS, ainsi qu’au développement JavaScript côté client. En sus, on lui demande de maîtriser d’autres compétences beaucoup plus variées : la gestion de la compatibilité multinavigateur, la maîtrise des questions de performances, d’expérience utilisateur, la prise en compte d’ARIA en matière d’accessibilité, le choix de recourir ou non à HTML5, etc.
L’intégrateur doit jongler avec les exigences du référencement, de la performance, de l’ergonomie, de l’accessibilité, de la typographie, etc. Il doit en outre gérer la diversification des médias et des modes d’interaction : desktop, mobile, tablettes. Bientôt, il devra certainement assumer la généralisation du tactile.
En tant que « qualiticiens », nous ne pouvons que confirmer cet état de fait : lorsque nous travaillons sur les bonnes pratiques de la qualité web, bon nombre d’entre elles se concentrent sur la phase d’intégration.
L’intégrateur front-end doit donc savoir maîtriser un grand nombre de standards, de bonnes pratiques, de compétences, de méthodes, aussi bien du point de vue technique que managérial. Il était plus que temps de rassembler tous ces éléments dans un livre.
Jusqu’à présent, les ouvrages existants se concentraient principalement sur des sujets techniques, comme CSS, HTML, JavaScript. Là est la force de l’auteur : en plus de poser les bases, de formaliser et de déterminer ce qui est de l’ordre du savoir minimal de l’intégrateur, elle a su dépasser la technique pour aborder ces sujets sous l’angle métier.
La publication de livres comme celui de Corinne Schillinger est l’un des nombreux signes que le processus d’industrialisation est en marche. Alors, oui, la connaissance technique est fondamentale, mais, non, elle ne suffit pas. Des experts techniques, il en existe beaucoup, mais des personnes qui comprennent la philosophie qui sous-tend les techniques et la façon de les déployer sont beaucoup plus rares. C’est pourquoi il faut aller beaucoup plus loin.
Aujourd’hui, nous entrevoyons le moment où l’intégrateur va enfin devoir aller au-delà de la technique. Il est désormais celui qui doit accorder des violons souvent discordants, entre les exigences du design, du référencement, de la DSI… Il commence à en acquérir les moyens avec l’industrialisation du Web. Il est appelé à devenir de plus en plus un manager de solutions, appuyé sur une maîtrise rigoureuse des techniques et surtout des clés de décision.
D’une certaine manière, au même titre que les autres professionnels du projet web, l’intégrateur devient un véritable gestionnaire de risques. Les risques auxquels il doit faire face et qu’il sera de plus en plus amené à gérer sont particulièrement critiques pour les clients et les utilisateurs finaux.
Avec cette évolution, l’intégrateur se servira différemment de ses références techniques actuelles. Il aura rarement à produire du code : le cœur de son métier sera de choisir des solutions. Il n’est déjà plus un simple exécutant opérationnel : il lui revient de plus en plus souvent d’arbitrer sur le choix des formats, sur celui d’un framework JavaScript, voire d’un framework CSS, ou même sur la décision quant au CMS à utiliser.
Au terme de cette maturation du métier, sa compétence proprement technique pourra alors être réservée aux seuls cas où une certaine forme d’expertise sera requise pour des solutions sur mesure.
Gageons que si le mouvement d’industrialisation des métiers du Web se poursuit, il faut s’attendre à l’émergence de livres de référence sur chacun des principaux métiers du Web. Pour ce qui est du métier d’intégrateur, l’ouvrage que vous avez entre les mains sera à l’évidence l’un de ces livres de référence et, au minimum, un jalon important dans l’histoire de ce métier en évolution permanente.
Élie Sloïm (Président de Temesis, Directeur des projets Opquast et Openweb)
et Laurent Denis (Expert accessibilité)
TABLE DES MATIÈRES

Avant-Propos
À qui s’adresse ce livre ?
Pourquoi ce livre ?
Comment le livre est-il organisé ?
Remerciements
P ARTIE 1 Bien préparer son projet
CHAPITRE 1 Organiser son espace de travail
Arborescence : créer un dossier par projet
Avoir tous les éléments à portée de main
Organiser les répertoires en fonction du type de fichiers
Cas particulier : les images
Adopter une convention de nommage
Exemples de règles de nommage
Où placer la convention de nommage ?
Qualité : mettre en place une checklist détaillée
Index des maquettes
Évaluation individuelle des pages
Évaluation transversale de l’intégration
Rédiger la checklist au format Markdown
CHAPITRE 2 S’équiper des bons outils
Les éditeurs de code
Zen Coding
Produire du HTML
Produire du code CSS
Les préprocesseurs CSS
Les variables
Les déclarations imbriquées
L’héritage
Les fonctions mathématiques
Les inspecteurs de code
Édition des éléments HTML et des styles CSS
Débogage du code JavaScript
Validation du code HTML et CSS
Analyse des performances
Visualisation du temps de chargement
Le système de gestion de versions
Organiser logiquement les commits
Outils en ligne
Outils pour le HTML
CopyPasteCharacter
HTML-Ipsum
Outils pour les CSS
CSS3 Generator
ProCSSor
CSS Lint
Outils pour améliorer les performances
WebPagetest
SPOF-o-Matic
Ressources et outils pour la qualité web
Les bonnes pratiques Opquast
Opquast Reporting
Outils de vérification et de validation
Validateurs HTML et CSS
Contrôleur JavaScript : JSLint
Vérificateur de liens
Validateur pour les flux de syndication (Atom, RSS)
Ressources diverses
DocHub
Le wiki du W3C
JsFiddle
CHAPITRE 3 Mettre en place l’environnement de test
Quelles configurations tester ?
Le panel de test
Le contexte projet
Le « cas » Internet Explorer
L’affichage de compatibilité
Les installations multiples
IETester
IE Collection
Google Chrome Frame
Les services en ligne
Les services de captures d’écran
Browsershots
BrowserLab
Les services d’accès à distance
Sauce Labs
CrossBrowserTesting
La virtualisation
Des conditions de test réelles
Une grande flexibilité
Contraintes liées aux systèmes d’exploitation
Windows
Mac OS
Linux
Les terminaux mobiles
WebKit
Android
iPhone/iPad
Windows
Opera
Opera Mobile
Opera Mini
Les technologies d’assistance
JAWS
NVDA
VoiceOver
P ARTIE 2 Élaborer un socle HTML solide
CHAPITRE 4 Adopter HTML5
Prendre connaissance des différentes contraintes
L’instabilité de la spécification
Les problèmes d’accessibilité
Tirer parti des évolutions apportées
Une charpente HTML simplifiée
Un Doctype raccourci
Un en-tête de document allégé
Un gabarit minimaliste
Les éléments redéfinis
<a>
<cite>
<b>
<i>
<small>
Les nouveaux champs de formulaire
<input type="email" />
<input type="tel" />
<input type="url" />
Les problèmes d’implémentation
Exploiter les nouveaux attributs
Lier des valeurs à un élément grâce à data-*
Manipuler les données en JavaScript
Ajouter du sens avec les microdonnées
Un peu d’histoire : RDFa et les microformats
Découvrir les attributs spécifiques
Quelle syntaxe adopter : HTML ou XHTML ?
En résumé
CHAPITRE 5 Concevoir les fondations
Gérer les différentes versions d’Internet Explorer
Éviter l’emploi de hacks CSS
Éviter d’avoir recours à une feuille de styles dédiée
Les problèmes de performance
Les problèmes de maintenance
S’appuyer sur une classe CSS conditionnelle
Placer la classe à la racine de la page
Se limiter aux cas « utiles »
Préparer les inclusions CSS et JavaScript
Choisir la méthode la plus adaptée
Les instructions inline
Les instructions internes
Les instructions externes
Positionner les appels suivant leur nature
Les styles dans l’en-tête de document head
Les scripts à la fin du contenu body
Prévoir le cas où JavaScript est désactivé
Ajouter les métadonnées dans l’en-tête de document
La balise meta viewport
La balise meta description
En résumé
CHAPITRE 6 Construire la structure
Organiser la page
Identifier les zones principales
Mettre en place le balisage
Faut-il préférer les classes aux identifiants ?
Spécifier le rôle des éléments grâce à ARIA
À quoi sert ARIA ?
Améliorer l’accessibilité des interfaces riches
Doter les éléments de structure d’une valeur sémantique
Ajouter les rôles au balisage en place
Mettre en place les liens d’évitement
Valider la structure
CHAPITRE 7 Injecter le contenu
Faut-il utiliser un framework ?
Les frameworks CSS
Les frameworks HTML
Mettre en place le balisage
Établir une hiérarchie de titres logique
Sélectionner les balises pour leur valeur sémantique
Éviter l’emploi de <a href="#"> comme bouton d’action
Le cas particulier de <br />
Nommer les balises judicieusement
Éviter l’ajout d’éléments superflus
Utiliser des motifs déjà éprouvés
Valider le contenu
CHAPITRE 8 Incorporer les images
Multiplicité des supports : les images adaptatives
L’emploi de l’élément noscript
Le kit « adaptative image »
L’instruction max-width: 100%;
Choisir le bon format d’image
Le format GIF
Gérer la transparence
Optimiser pour le Web
Le format PNG
PNG 8
PNG 24
Optimiser pour le Web
Le format JPEG
Optimiser pour le Web
Quel format choisir ?
Renseigner correctement l’alternative textuelle
Les liens et boutons images
Les représentations graphiques
Les images d’illustration
P ARTIE 3 Habiller le contenu grâce aux CSS
CHAPITRE 9 Réviser les bases
Les schémas de positionnement
La notion de flux
Positionnement flottant : la propriété float
Positionnement statique
Positionnement relatif
Positionnement absolu
Positionnement fixe
Quel positionnement choisir en priorité ?
Erreur courante à éviter
La cascade CSS
L’origine de la règle
La spécificité d’une règle
La valeur !important
Les propriétés abrégées
Marges : margin et padding
Contours : outline
Bordures : border
Angles arrondis
Bordures en image
Listes : list-style
Polices de caractères : font
Arrière-plan : background
Arrière-plans multiples
CHAPITRE 10 Définir une convention d’écriture
Agencer les instructions
Éviter de regrouper plusieurs instructions sur une seule ligne
Aller à la ligne avant chaque instruction
Hiérarchiser les blocs de déclarations
Par ordre alphabétique
Par ordre fonctionnel
Préciser le rôle des commentaires
Rédiger les commentaires au format CSSDoc
Les blocs d’identification
Les blocs de documentation
Faire connaître la convention élaborée
CHAPITRE 11 Organiser le code CSS
Préciser le contexte projet
Tenir compte de la nature du site
Choisir l’approche « traditionnelle » pour les sites peu ou pas réactifs
Uniformiser les styles par défaut
Élaborer la charte typographique
Mettre en place la structure générale
Styler les composants internes
Ajouter les styles relatifs aux comportements JavaScript
Corriger l’affichage sur les anciennes versions d’Internet Explorer
Adapter l’affichage grâce aux media queries
Appliquer le principe de l’amélioration progressive pour un site adaptatif
Utiliser la version mobile comme base commune
Ajouter les styles destinés aux autres terminaux
Servir (si nécessaire) des images adaptées à la densité de pixels du terminal
Assurer la rétrocompatibilité sur les anciens navigateurs
CHAPITRE 12 Prendre connaissance des facteurs d’optimisation
Comprendre comment les règles CSS sont appliquées
Les règles CSS sont triées en fonction de leur type
Les sélecteurs sont lus de droite à gauche
Les sélecteurs courts sont les plus performants
Concevoir des règles efficaces
Limiter l’emploi de règles universelles
Utiliser des sélecteurs courts et efficaces
Éviter de redéfinir inutilement la valeur de certaines propriétés
Factoriser les instructions
Ne pas tomber dans l’excès d’optimisation
Diminuer le nombre de requêtes nécessaires à l’affichage des images
Utiliser la technique des sprites
Employer les data URI en complément
CHAPITRE 13 Élaborer les règles CSS
Se renseigner sur les propriétés autorisées
Employer les propriétés CSS3 à bon escient
Penser à spécifier tous les préfixes propriétaires
Fournir une alternative aux vieilles versions des navigateurs
Uniformiser les styles navigateurs
Réinitialiser les styles dans leur globalité
Appliquer des correctifs ciblés
Concevoir la charte typographique
Choisir une unité pour définir la taille de police et son interlignage
Éviter l’utilisation du pixel
Préférer l’emploi d’unités relatives
Procéder avec méthode pour ajouter une police personnalisée
Vérifier les droits accordés par la licence
Contrôler le rendu de la fonte sur les différentes configurations
Décliner la fonte en plusieurs formats
Élaborer le bloc d’instructions
Rendre visible la prise de focus
Le cas particulier des liens images
Organiser les blocs de structure et styler les composants
Ajouter les règles relatives aux comportements JavaScript
Les subtilités de l’approche « mobile first »
Utiliser la version mobile comme point de départ
Ajouter les styles destinés aux autres terminaux
Masquer certains éléments de contenu aux terminaux mobiles
Définir des points d’arrêt pour passer d’une version à l’autre
Servir (si nécessaire) des images adaptées à la densité de pixels du terminal
Assurer la rétrocompatibilité sur les anciens navigateurs
Les solutions JavaScript
La solution CSS pour Internet Explorer
Élaborer la feuille d’impression
Appliquer les styles génériques
Masquer les éléments superflus
Linéariser le contenu
Ajouter quelques règles complémentaires
CHAPITRE 14 Contrôler et déboguer
Contrôler le rendu
Prendre l’affichage d’un navigateur moderne comme référence
Surveiller le rendu des navigateurs obsolètes pendant le développement
Résoudre les problèmes détectés
Valider le code
Identifier l’élément incriminé
Isoler la ou les instructions problématiques
Corriger le problème
Vérifier le rendu sur Internet Explorer par ordre de version décroissant
Tester les gabarits
Détecter certaines erreurs HTML grâce une feuille de débogage
Simuler l’indisponibilité des ressources
Les images
JavaScript
Tester la navigation clavier
Agrandir la taille de caractères
P ARTIE 4 Préparer la livraison (ou la mise en ligne)
CHAPITRE 15 Peaufiner les détails
Réaliser les dernières optimisations
Les images
Le code CSS et JavaScript
Concaténer les différents fichiers
Minifier les fichiers obtenus
Proposer quelques règles de configuration serveur
Configurer les en-têtes HTTP
Indiquer que le codage de caractères utilisé est utf-8
Renseigner le type MIME de certains fichiers
Autoriser l’utilisation de fontes hébergées sur un domaine tiers
Interdire le mode de compatibilité sur Internet Explorer
Optimiser les performances
Compresser les fichiers
Contrôler la date d’expiration d’une ressource mise en cache
Supprimer les ETags
Renforcer les paramètres de sécurité
Restreindre l’accès aux fichiers sensibles
Interdire l’exploration des répertoires n’ayant pas d’index
Éviter certains problèmes de contenu dupliqué
Personnaliser les pages d’erreur
Annexes
Annexe A1
Annexe A2
Annexe B
Annexe C
Annexe D
Annexe E
Index
AVANT-PROPOS
Avant d’entrer dans le vif du sujet, permettez-moi de vous présenter cet ouvrage en quelques mots.
À qui s’adresse ce livre ?
Ce livre s’adresse à tous les intégrateurs, professionnels ou amateurs, qui ont à cœur de réaliser une intégration qui soit aussi propre, accessible et performante que possible. Il se veut clair et exhaustif, sans toutefois reprendre les bases fondamentales des langages HTML et CSS. De ce fait, il risque d’être assez difficile d’accès aux débutants souhaitant découvrir les joies du code, car il requiert une connaissance minimale de ces deux langages pour pouvoir être pleinement exploité.
Malgré tout, il cible un public relativement large puisqu’il est destiné à toutes les personnes qui ont envie de produire un code de qualité : les étudiants souhaitant approfondir leurs cours devraient y trouver leur compte tout autant que les professionnels aguerris désirant mettre leurs connaissances à jour.
Pourquoi ce livre ?
La qualité globale d’un site repose bien souvent sur des points de détail qui ont un impact positif ou négatif sur son utilisabilité, son accessibilité et ses performances d’affichage. Et bien que les outils et techniques aient considérablement évolué ces dernières années, l’intégration est une discipline qui reste encore très artisanale : son résultat fluctue en fonction des connaissances de l’intégrateur.
Or, bien souvent, il ne manque pas grand-chose pour que la qualité de l’intégration soit considérablement améliorée : spécifier un changement de langue, prévoir l’indisponibilité d’une ressource ou tirer parti de l’héritage en sont quelques exemples.
Forte de ce constat, j’ai mûri l’idée de créer une sorte de recueil de bonnes pratiques de l’intégration web. Mais ce n’est qu’une fois le travail rédactionnel commencé que je me suis rendue compte de l’ampleur réelle de la tâche. Car même si certains usages sont considérés comme étant de bonnes pratiques, beaucoup restent à la discrétion du développeur : l’intégration n’est pas une science exacte, elle dépend d’une multitude de paramètres qui en font une discipline aussi complexe qu’intéressante.

L’écriture de ce livre aura donc été l’occasion d’une remise en cause de mes méthodes de travail. Le plus difficile aura été d’évaluer la pertinence réelle de ma méthode, car même si elle me convenait parfaitement, rien ne pouvait me laisser penser qu’il s’agisse de la « meilleure » façon de faire. Je me suis donc posée de nombreuses questions, ai discuté avec d’autres professionnels, et ai souvent changé d’avis devant la justesse des arguments avancés. Vous tenez entre vos mains le fruit de ces dix-huit mois de recherches, de questionnements, d’introspection et de discussions passionnantes avec des intégrateurs de tous bords.
Durant ce laps de temps, la technique a évolué et des méthodes qui étaient autrefois conseillées sont aujourd’hui considérées comme de mauvaises pratiques : dix-huit mois dans un domaine où les techniques évoluent constamment, c’est beaucoup. Et s’il s’agitlà de la première version papier, sachez que certaines parties en sont au moins à leur troisième mise à jour : je n’ai eu de cesse de réactualiser le contenu pour assurer la véracité des informations qui y figurent.
C’est pourquoi j’espère sincèrement que ce livre répondra à vos attentes. S’il vous permet d’approfondir de nouvelles techniques, de vous mettre à niveau, de prendre connaissance de certains effets de bord indésirables ou de découvrir une nouvelle méthodologie, j’aurai gagné mon pari.
Comment le livre est-il organisé ?
Ce livre est organisé dans un ordre logique qui respecte les différentes étapes devant être effectuées pour mener à bien une intégration. Ces dernières sont réparties en quatre parties que sont la préparation en amont, la conception du contenu HTML, la mise en forme CSS et la préparation des livrables.
Vous aurez certainement remarqué qu’aucune partie n’est dédiée à JavaScript. Pourtant, il y aurait de quoi faire : un livre entier pourrait même être consacré à ses bonnes pratiques de développement. Mais je n’estime pas avoir les compétences suffisantes pour pouvoir l’aborder avec le degré d’expertise que je souhaiterais. C’est pourquoi je préfère laisser cette tâche à un développeur JavaScript qui saura le faire bien mieux que moi.
Pour autant, cela ne signifie pas que la question de son utilisation ne soit pas abordée : son emploi impose de nombreuses contraintes qui sont évoquées tout au long de ce livre. Car même si l’intégrateur ne développe pas lui-même les fonctions, il se doit de maîtriser les bases du langage et de pouvoir concevoir certaines interactions à l’aide (ou non) d’un framework.
La méthode présentée ici n’a pas vocation à devenir universelle : je doute d’ailleurs qu’aucune méthode ne fasse jamais cette unanimité. Elle tend plutôt à être aussi exhaustive que possible et aborde toutes les étapes qui peuvent affecter la qualité finale de l’intégration. C’est pourquoi ce livre débute avec l’organisation de l’espace de travail et se termine avec la préparation des livrables. Tout au long de son développement, vous retrouverez ces notions d’accessibilité, de sémantique, de lisibilité, de maintenabilité et de performance qui composent ce tout qu’est la qualité web.
REMERCIEMENTS
Si je m’écoutais, je remercierais la terre entière pour la chance qui m’a été donnée de concrétiser cette opportunité. Je commencerais d’ailleurs par ma maman, sans qui rien de tout ça n’eut été possible. Mais s’agissant d’un livre professionnel, je crains malheureusement que cela ne soit guère adapté… Je vais donc me restreindre aux personnes qui ont donné de leur temps et n’ont pas hésité à partager leur expertise pour que ce livre puisse voir le jour. Si cet ouvrage vous plaît, c’est aussi à toutes ces personnes que vous le devez : sans leurs remarques constructives, leurs encouragements et leur disponibilité, vous n’auriez certainement pas ce livre entre les mains.
Occasionnels ou au long court, les relecteurs ont eu la lourde de tâche de vérifier l’exactitude de mes assertions. Ils ont relevé les erreurs, approximations et incohérences qui avaient échappé à ma vigilance, et m’ont conseillé de nombreux ajouts très pertinents. C’est pourquoi je tiens à remercier chaleureusement :
• Anthony Ricaud, Laurent Denis, Loïc Mathaud et Sébastien Delorme, pour avoir gentiment accepté de se prêter au jeu ;
• Vincent Valentin, qui a trouvé un peu de temps entre deux biberons pour me relire et répondre à mes interrogations diverses et variées ;
• Jérémie Patonnier, pour avoir passé de longues heures, tard le soir, à relire plusieurs chapitres et pour m’avoir fait de nombreux retours toujours très judicieux, bien qu’un peu « bruts de décoffrage » parfois ;
• Et enfin, Marie Alhomme qui a accepté de relire ce livre dans son intégralité. Je la remercie du fond du cœur pour tout le temps qu’elle y a consacré et les longs moments passés à discuter détails techniques, méthodologie et bonnes pratiques.
Dans un registre différent, je tiens également à remercier :
• Noëlie Amiot pour ses éclairages sur certains points techniques ;
• Élie Sloïm et Laurent Denis qui m’ont fait l’honneur de rédiger à quatre mains la préface de cet ouvrage ;
• Virginie Caplet, une graphiste de talent, qui a accepté — pour mon plus grand bonheur — de réaliser les magnifiques illustrations qui introduisent les parties principales de ce livre ;
• les éditions Eyrolles pour m’avoir fait confiance, et plus particulièrement Karine Joly qui a fait preuve d’une patience sans borne, acceptant sans mot dire mes retards de livraison et n’ayant de cesse de m’encourager jusqu’à la dernière minute ; Sophie Hincelin et Géraldine Noiret qui ont repris le projet juste avant sa finalisation et se sont démenées pour le boucler dans les temps ;
• Et surtout Yannick — mon homme — qui m’a incitée à me lancer dans cette aventure, soutenue de la première ligne jusqu’à la dernière relecture, rassurée quand j’étais en pleine phase de doute, et supportée même lorsque des nuits bien trop courtes me rendaient absolument exécrable. Si j’ai réussi à mener ce projet à son terme, c’est surtout grâce à lui.

P ARTIE 1
BIEN PRÉPARER SON PROJET
On estime bien souvent que l’intégration d’un site web débute avec la conception du code HTML/CSS. Or si le code est très certainement la partie la plus visible du site, il est important de ne pas considérer la préparation du projet comme une simple formalité qu’il est possible d’expédier. Qu’il s’agisse de l’organisation des éléments (fichiers et répertoires), du choix des outils ou de la mise en place de l’environnement de test, toutes les étapes préparatoires doivent faire l’objet de la plus grande attention.
Une arborescence logique et facilement compréhensible, une règle de nommage appliquée à l’ensemble des composants ou encore la présence d’une fiche de suivi à la racine du projet participent pleinement à la qualité globale du site et contribuent à simplifier son évolution future. Ainsi, même s’il n’existe aucune règle absolue à suivre, ni aucune organisation qui soit parfaite, il est important de réfléchir à la façon dont le projet va être organisé, avant de rédiger la moindre instruction.

Dans ce chapitre
• Arborescence : créer un dossier par projet
• Uniformité : adopter une convention de nommage
• Qualité : mettre en place une checklist détaillée
ARBORESCENCE : CRÉER UN DOSSIER PAR PROJET
Avoir tous les éléments à portée de main
La première chose à faire avant de démarrer une nouvelle intégration est de préparer l’espace de travail. L’idéal est de rassembler tous les éléments relatifs à un projet dans un même dossier ou répertoire. Il suffit simplement d’organiser à l’intérieur de celui-ci une arborescence claire dans laquelle viendront se placer les documents. En centralisant ainsi toutes les données, vous ne perdrez pas de temps à chercher des éléments manquants ou à vérifier que vous vous référez à la dernière version des spécifications. De même, un collègue arrivant sur le projet en cours de route aura une vue exhaustive du projet et de son avancée.
Bien sûr, chaque intégrateur a sa façon de faire et son propre système d’organisation. L’essentiel étant qu’il s’y retrouve et qu’une personne tierce ne soit pas perdue dans l’arborescence. Voici par exemple une classification en trois dossiers, qui permet de répartir simplement tous les éléments du projet.
• Le dossier sources accueille les documents utiles à l’intégration. Il peut s’agir du code à reprendre, des maquettes à intégrer ou encore des textes à publier. Suivant le nombre d’éléments (et surtout de maquettes), il peut être utile d’avoir recours à des sous-dossiers.
• Le dossier spec recueille l’ensemble des spécifications fonctionnelles du projet. Y prennent place le cahier des charges, le zoning, l’arborescence ou encore les demandes d’évolution.
• Enfin, le dossier www est réservé à l’intégration proprement dite. Il constitue la racine du site web et contient l’ensemble des éléments qui vont être livrés ou mis en ligne, au contraire des sources et des spécifications qui ne seront pas poussées en production.
Certains préfèrent, pour plus de clarté, rassembler l’ensemble des ressources en ligne. Indispensable pour les gros projets (longs de plusieurs mois, sur lesquels interviennent plusieurs personnes en parallèle), cette organisation présente le défaut de nécessiter une connexion Internet lorsque vous travaillez. Ce qui n’est pas toujours le cas si vous êtes en situation de mobilité ou si vous faites les frais d’une coupure temporaire.

G LOSSAIRE Les composants d’un projet
Chaque nouvelle intégration amène son lot d’éléments à analyser. Détaillant le projet dans son ensemble ou traitant de points particuliers, les spécifications sont généralement composées de plusieurs documents : présentations, textes, images, graphiques…
Le cahier des charges (ou brief ) est sans conteste l’élément le plus important de toutes les spécifications : il sert de fil conducteur au projet et fait référence en toute situation. Il décrit entre autres les objectifs à atteindre, la forme du livrable, les critères d’évaluation, les contraintes à respecter, le délai de réalisation et, bien sûr, le résultat attendu.

L’ arborescence (ou architecture ) se concentre uniquement sur l’organisation du site. Généralement représentée sous la forme d’un arbre inversé, elle permet de visualiser rapidement l’agencement des pages et les interactions qui les lient les unes aux autres.
Le zoning schématise l’organisation générale d’une page en identifiant les différentes zones à l’aide de blocs (voir l’annexe A1). Il permet d’illustrer le fonctionnement global et de dégager les zones de contenu principales. Chaque zoning s’attachant à un seul type de page (page d’accueil, page de contenu…), il est fréquent d’en avoir plusieurs pour un même site.
Établi à partir du zoning, le wireframe (ou maquette fil de fer) met en avant le contenu. Les zones précédemment identifiées sont remplies et leur contenu est organisé de la manière la plus fonctionnelle et ergonomique possible (voir l’annexe A2).
Partant de l’agencement validé dans le wireframe, le graphiste imagine et réalise un univers propre à la marque qui véhicule ses valeurs et son identité. Il s’agit de la maquette graphique .
Organiser les répertoires en fonction du type de fichiers
Une fois que l’arborescence est en place et que les éléments sont répertoriés, il convient de préparer le dossier d’intégration ( www dans notre exemple).
Il arrive que l’organisation générale soit fournie par le client. C’est souvent le cas lorsqu’il s’agit d’une refonte et qu’il n’est pas envisageable de modifier le système de dossiers utilisé. En l’absence de consignes particulières, il est important de regrouper les fichiers suivant leur type et leur fonction.
Bien que certains usages se soient mis en place, il n’existe aucune règle stricte concernant le nommage des éléments. Ainsi, il est fréquent de rencontrer plusieurs approches différentes : l’emploi de noms très courts ( i pour les images, s pour les scripts, etc.), de noms complets ( images , scripts , etc.) ou encore de noms abrégés ( img , js , etc.). Au final, les noms utilisés importent relativement peu, du moment qu’ils sont courts et explicites. C’est pourquoi la tendance générale consiste à privilégier les appellations raccourcies et à utiliser l’extension de fichier comme nom de dossier : css , js , swf ou encore flv. Cette façon de faire est un bon compromis entre les performances et la lisibilité des noms abrégés.
Cas particulier : les images
Au cours d’une intégration, trois types d’images sont à distinguer : les images de contenu, les images décoratives et les images temporaires ou contribuables.
Les images de contenu
Porteuses de sens, elles font partie intégrante du code HTML : c’est le cas d’un logo ou d’une icône de menu. Généralement, elles sont enregistrées dans un dossier img à la racine du dossier d’intégration. Bien sûr, ce dernier peut contenir l’un ou l’autre sous-dossier (comme icone ou picto ), pour regrouper certaines images en fonction de leurs similitudes.
Les images décoratives
Utilisées pour la mise en forme du document, elles sont appelées depuis le code CSS. Certains les enregistrent dans un dossier img à la racine de css . Une autre manière de faire consiste à les placer dans un dossier theme directement dans www . Ainsi, il suffit d’ajouter un sous-dossier pour chaque nouveau thème ou déclinaison saisonnière (comme les fêtes de Noël ou la période des soldes).

B ONNE PRATIQUE Utiliser les classes et identifiants comme noms d’images
Nommer les images avec les noms de classes et d’identifiants qu’elles habillent permet d’établir un lien entre le code et les images. La gestion des ressources en est ainsi facilitée, puisque chaque élément peut aisément être relié à la structure HTML et aux styles CSS.
#footer { background: url("../theme/footer.jpg") repeat-x 0 100%; }
Les images temporaires (ou contribuables)
Issues de la maquette, elles sont généralement employées par le graphiste pour illustrer l’une ou l’autre mise en situation. Il peut par exemple s’agir d’un avatar, d’une illustration d’article, ou encore de la capture d’une vidéo. Faciles à identifier, elles doivent être stockées dans un dossier distinct qui ne sera pas mis en production. Dans notre arborescence, le dossier tmp se trouve à la racine de www . Nous y plaçons l’ensemble des éléments temporaires (images, sons, vidéos…) utilisés au cours de l’intégration.

C ONSEIL Employer des images factices
Dummy Image (Dynamic Dummy Image Generator) est un générateur d’images factices. Générées suivant les paramètres passés dans l’URL, les images peuvent être utilisées pour remplacer les fichiers temporaires. Ainsi, il n’est plus nécessaire d’exporter des éléments qui ne seront pas utilisés en production. Cela permet surtout d’attirer l’attention du client sur ses futures contributions (les dimensions du visuel étant incluses dans l’image).
http://dummyimage.com

C ONSEIL Créer un « dossier projet » type
Une fois que vous avez opté pour une arborescence qui vous convient et avec laquelle vous vous sentez à l’aise, enregistrez-la soigneusement, car il est fort probable que vous la réutilisiez sur l’ensemble de vos intégrations ultérieures. Ne perdez donc pas de temps à repartir de zéro à chaque fois : dupliquez plutôt cette arborescence au démarrage de chaque nouveau projet.


F IG . 1-1 : Exemple d’arborescence réutilisable à chaque nouveau projet
Adopter une convention de nommage
L’une des erreurs les plus fréquentes en intégration est sans nul doute l’erreur d’inattention. Qui n’a jamais passé de longues minutes à essayer de déboguer un élément au comportement étrange, avant de se rendre compte qu’une erreur s’était glissée dans l’appel du sélecteur ?
L’absence de convention de nommage standardisée force les intégrateurs à inventer la leur. Malheureusement, rares sont ceux qui se fixent un ensemble de règles à suivre et qui les appliquent d’un bout à l’autre du projet. Bien souvent, chacun établit ses règles de manière plus ou moins arbitraire sans réelle réflexion : les singuliers sont mélangés aux pluriels, l’anglais au français, les traits d’union côtoient les tirets bas et les majuscules sont utilisées sans raison apparente.
Un bon moyen pour diminuer le risque d’erreurs est de mettre en place une nomenclature stricte que l’on applique à tous les composants du projet : dossiers, fichiers et sélecteurs. Cela évite les allers-retours inutiles pour vérifier si le nom de fichier est en anglais ou en français, ou pour savoir exactement à quels endroits placer les tirets de séparation. Il est possible que certains y trouvent peu d’intérêt et considèrent qu’une bonne logique personnelle suffit amplement. Mais c’est sans compter les personnes qui reprendront le projet une fois l’intégration terminée : il y a fort à parier qu’un développeur ait à dynamiser le tout ou qu’une tierce personne soit en charge de la maintenance. En les prenant en considération, vous leur rendrez un fier service !

B ONNE PRATIQUE Demander conseil au développeur
Suivant le système de gestion de contenus utilisé, il est fort probable qu’un certain nombre de classes, d’identifiants et d’usages soient prédéfinis. Demandez au développeur de vous les donner et prenez-en connaissance avant de figer vos règles de nommage. Vous lui éviterez ainsi une surcharge de travail et il vous en sera reconnaissant.
Exemples de règles de nommage
Une nomenclature n’a pas besoin d’être très verbeuse. Il s’agit de faire simple et compréhensible. Une liste d’affirmations accompagnées d’exemples telle que celle présentée ci-après est donc largement suffisante.
• Employer des noms anglais pour tous les éléments, car la v2 sera multilingue : .alert au lieu de .alerte .
• Indiquer tous les noms au singulier : .slide au lieu de .slides .
• Utiliser uniquement le trait d’union - : .open-popin au lieu de .open_popin .
• Donner des noms pertinents aux éléments : #event au lieu de #block-block-1 .
• Utiliser les classes et identifiants comme noms d’images : body.jpg au lieu de fond.jpg .
• Privilégier les intitulés courts : #slideshow-control au lieu de #playpause_slideshow_slider_block-3 .
• Différencier le premier élément d’une liste plutôt que le dernier, car c’est plus facile à programmer que l’inverse.
À préférer

<ul>
<li class="first" >Premier item</li>
<li>Deuxième item</li>
<li>Troisième item</li>
</ul>
À éviter

<ul>
<li>Premier item</li>
<li>Deuxième item</li>
<li class="last" >Troisième item</li>
</ul>
• Classes et identifiants à employer :
– #breadcrumb pour le fil d’Ariane ;
– #search pour le formulaire de recherche générique ;
– .submit pour les éléments de soumission de formulaire ;
– .visually-hidden pour les éléments visibles aux seules technologies d’assistance.

Où placer la convention de nommage ?
Une fois la convention de nommage établie, placez-la à la racine du dossier projet afin que chaque intervenant puisse en prendre connaissance et se l’approprier. En la rendant ainsi accessible, vous augmenter vos chances d’avoir un projet uniforme de bout en bout, et ce, quel que ce soit le nombre de personnes prenant part au projet.
QUALITÉ : METTRE EN PLACE UNE CHECKLIST DÉTAILLÉE
La checklist permet de vérifier méthodiquement certains points récurrents à prendre en compte lors de l’intégration. Bien qu’elle ne puisse pas garantir la qualité d’un site à 100 %, elle y contribue fortement. Le rendu navigateur, l’accessibilité, la conformité et la performance y trouvent naturellement leur place, mais vous pouvez bien sûr y ajouter d’autres paramètres spécifiques au projet, comme le détail des fonctionnalités à implémenter.
La liste proposée ici est le résultat d’un recoupement de trois listes distinctes : les bonnes pratiques en intégration d’Opquast (voir la section « Les bonnes pratiques Opquast » dans le chapitre suivant), « la checklist ultime pour le lancement d’un site web » de Dan Zambonini (Box UK) et « la checklist d’accessibilité que je m’étais juré de ne pas rédiger » d’Aaron Cannon (North Temple).

R ESSOURCES Les checklists
Opquast Checklists : http://bp.inté.net/1-1 1
Box UK (Dan Zambonini) : http://bp.inté.net/1-2 2
North Temple (Aaron Cannon) : http://bp.inté.net/1-3 3
Véritable référence, la checklist Opquast dédiée à l’intégration regroupe 57 bonnes pratiques âprement débattues et triées sur le volet. C’est donc sans surprise que vous en retrouverez la grande majorité dans la liste ci-après. Scindée en trois parties, elle répond à plusieurs objectifs : servir d’index aux gabarits déjà intégrés, permettre l’évaluation individuelle de chaque page et, enfin, permettre l’évaluation transversale d’un ensemble de points communs aux différents gabarits. Suivant le contexte, ce fichier peut avantageusement être remplacé par un outil en ligne (comme Opquast Reporting) qui se charge de vérifier automatiquement un ensemble de points qui ne nécessitent pas d’être validés manuellement.

Index des maquettes
Toutes les pages à intégrer sont listées et associées à un numéro, afin qu’elles soient identifiables rapidement. Les URL sont par la suite progressivement ajoutées, permettant au fichier de servir d’index aux maquettes.

F IG . 1-2 : La checklist sert d’index aux maquettes et renseigne sur l’état d’avancement du projet.
Évaluation individuelle des pages
On regroupe ici l’ensemble des vérifications à faire de manière individuelle pour chaque page. Il s’agit sans conteste de la partie la plus importante de la checklist. En pratique, il s’agit d’indiquer pour chaque ligne si la vérification est un succès (OK), un échec (NOK) ou si elle n’est pas applicable dans le cadre du projet (N/A).
Les points à contrôler pour chaque page étant nombreux et variés, ils ont été regroupés par thématique. Cette partie de l’évaluation vous amènera donc à vérifier la conformité de vos pages et leur rendu sur les navigateurs visés, la qualité du code HTML, la structure et l’harmonisation du contenu, son accessibilité, l’optimisation pour le référencement et bien sûr le caractère fonctionnel du site.

Tableau 1-1 : Checklist d’évaluation individuelle des pages (version détaillée : https://github.com/inseo/bpi-checklist )













Évaluation transversale de l’intégration
Une fois l’évaluation individuelle effectuée, il s’agit de vérifier un ensemble de points communs aux différentes pages comme certaines caractéristiques de style, d’accessibilité et de performance. Là encore, il suffit d’indiquer pour chaque ligne le résultat de la vérification : OK, NOK ou N/A.
Tableau 1-2 : Checklist d’évaluation transversale CSS La taille des polices destinées à l’affichage écran est exprimée en taille variable.   Le focus clavier n’est ni supprimé ni masqué.   Les styles ne sont pas utilisés pour générer du contenu important.   Les liens sont visuellement différenciés du reste du contenu.   Le soulignement est réservé aux liens.   Un style différent est appliqué aux liens visités et non visités.   ACCESSIBILITÉ Le site n’impose pas de redirection ou de rafraîchissement automatique côté client ( <meta http equiv="refresh"> ).   Le site n’emploie pas la technique des jeux de cadres ( <frameset>, <frame>, <noframe> ).   PERFORMANCE Les images sont optimisées (le format est adapté et le poids contrôlé).   La feuille de styles est optimisée (utilisation de l’héritage, pas de surcharge inutile des sélecteurs).   Les fonctions de scripts sont placées dans un ou plusieurs fichiers externes.   Une fois le développement terminé, les sauts de ligne et les espaces inutiles sont supprimés dans l’ensemble des fichiers statiques (JavaScript/CSS/HTML)  
Rédiger la checklist au format Markdown
http://michelf.com/projets/php-markdown/
La simplicité de lecture et d’écriture de la syntaxe Markdown en font un format compréhensible et aisément modifiable par n’importe qui : il a été pensée pour être le plus lisible possible avant même d’être converti au format HTML. Il se révèle donc particulièrement adapté aux besoins de la checklist : prise en main rapide et mise à jour simplifiée. En voici un exemple d’utilisation.
Source Markdown

Titre de niveau 1
=================
Paragraphe précédant une liste ordonnées à 3 items et une liste non ordonnées à 2 items :
1. Item 1
2. **Item 2 mis en gras**
3. Item 3
- Item 1
- *Item 2 mis en italique*
- Item 3

Titre de niveau 2
- - - - - - - - - - - - - -
Paragraphe comprenant un lien : [intitulé du lien](url-du-lien.html)
Code HTML obtenu après conversion

<hl>Titre de niveau 1</hl>
<p>Paragraphe précédant une liste ordonnées à 3 items et une liste non ordonnées à 2 items :</p>
<ol>
<li>Item 1</li>
<li><strong>Item 2 mis en gras</strong></li>
<li>Item 3</li>
</ol>
<ul>
<li>Item 1</li>
<li><em>Item 2 mis en italique</em></li>
<li>Item 3</li>
</ul>
<h2>Titre de niveau 2</h2>
<p>Paragraphe comprenant un lien : <a href="url-du-lien.html">intitulé du lien</a></p>

1 . https://checklists.opquast.com
2 . http://www.boxuk.com/blog/the-ultimate-website-launch-checklist
3 . http://northtemple.com/1608
4 . Tests destinés à différencier un utilisateur lambda d’un robot, les captchas sont généralement utilisés dans les formulaires pour se prémunir d’une soumission massive effectuée par certains programmes malveillants.
5 . Les WCAG (Web Content Accessibility Guidelines) sont formées de recommandations destinées à rendre les contenus web plus accessibles.
Pour intégrer dans de bonnes conditions, il est essentiel d’optimiser son environnement de travail. Cela passe notamment par l’adoption d’outils conçus pour vous aider dans les différentes étapes que comporte une intégration. Voici une liste d’outils propres à rendre votre travail quotidien plus efficace. Loin d’être exhaustive, elle a pour objectif d’attirer votre attention sur certains aspects de ce travail qui peuvent sans doute être améliorés.

Dans ce chapitre
• Environnement de travail : adopter un bon éditeur de code, Zen Coding et un préprocesseur CSS
• Productivité : éditer, déboguer, valider et analyser les performances grâce aux inspecteurs de code
• Sauvegarde : opter pour les systèmes de gestion de versions
• Services divers et variés : petite sélection d’outils en ligne
LES ÉDITEURS DE CODE
De nombreux éditeurs sont disponibles sur le marché (Aptana, PSPad, Screem, TextMate…) : qu’ils soient gratuits ou payants, mono-plates-formes ou multi-plates-formes, livrés avec une batterie de caractéristiques impressionnantes ou disponibles avec pléthore d’extensions, il y en a vraiment pour tous les goûts. Et c’est bien pour cela que je ne me risquerais pas à vous en conseiller un en particulier…
Il revient à chacun de faire son choix en fonction de ses affinités et de ses préférences. Cependant, avant d’adopter un éditeur, il est fortement conseillé de vérifier l’implémentation de certaines fonctionnalités très utiles comme : la coloration syntaxique, la complétion automatique (ou autocomplétion) et la prise en charge de différents langages (a minima : HTML, CSS, JavaScript et PHP). Certains apprécieront également les fonctions de pliage-dépliage de nœuds de code (code folding) et d’indentation automatique (qui s’avère très pratique lorsque vous reprenez un code mal indenté).
Bien sûr, vous n’êtes pas limité aux seules fonctionnalités de l’éditeur retenu. N’hésitez pas à regarder les extensions qui sont développées à côté : conçues pour améliorer la version de base, il est fréquent qu’elles comblent l’une ou l’autre lacune et rendent certaines manipulations plus aisées. C’est par exemple le cas de Zen Coding, traité dans la section qui suit.

C ONSEIL Éviter les éditeurs en mode « WYSIWYG »
Les éditeurs en mode « WYSIWYG » (What You See Is What You Get) permettent de concevoir une page web sans connaissance technique particulière, et c’est bien là leur principal défaut. Bien souvent utilisés dans l’enseignement, ils sont pourtant à éviter si l’on veut obtenir une intégration de qualité.
L’agencement des blocs et le positionnement des différents éléments est effectué de manière mathématique, sans prendre en compte le contexte global de la page. Il en résulte bien souvent une imbrication inutile d’éléments et un système de positionnement beaucoup plus compliqué que nécessaire. Fort heureusement, l’importance croissante accordée à la sémantique et à la performance des pages rendent l’utilisation d’un éditeur de code incontournable.
Pour autant, les éditeurs offrant la possibilité de coder en mode WYSIWYG et en mode « code » (comme Dreamweaver) ne sont pas à proscrire. Utilisés en mode « code », ils donnent un résultat équivalent à n’importe quel autre éditeur et proposent parfois quelques fonctionnalités très pratiques pour mettre en place rapidement certaines instructions complexes.
Zen Coding
http://code.google.com/p/zen-coding/
Zen Coding est un outil très efficace qui étend la fonction d’autocomplétion de votre éditeur : il donne la possibilité de générer des blocs de code entiers à partir d’une syntaxe raccourcie basée sur les sélecteurs CSS. Très apprécié, il a rapidement été adapté pour un certain nombre d’éditeurs et est donc disponible sous la forme de nombreuses extensions. La logique de rédaction étant relativement simple, il est facile à prendre en main et s’avère rapidement très utile. Permettant de produire du code HTML aussi bien que du code CSS, Zen Coding est donc particulièrement adapté aux intégrateurs souhaitant améliorer leur productivité.
Produire du HTML
L’instruction doit être écrite de manière linéaire et sans espace. Certains caractères ayant une signification particulière, les balises sont à retranscrire sans chevron :
• # représente un identifiant ; il prend pour valeur le mot qui lui est accolé : #identifiant ;
• . est l’équivalent du # pour les classes : .classe ;
• > indique une descendance : parent>enfant ;
• + marque une adjacence : frere+frere ;
• * précise le nombre d’éléments à créer : li*5 ;
• les parenthèses ( ) permettent de regrouper certains éléments ensemble : (p>img)+a ;
• les crochets [ ] permettent d’introduire les attributs : input[type=text] .
Exemple de syntaxe Zen Coding

ul#pagination>(li.first>a)+(li*3>a)
Code HTML généré

<ul id="pagination">
<li class="first"><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
<li><a href=""></a></li>
</ul>

P OUR EN SAVOIR PLUS Produire du code HTML en s’appuyant sur la syntaxe des sélecteurs CSS
A new way of writing HTML code using CSS-like selector syntax : réalisée par l’auteur du logiciel lui-même, cette vidéo permet de comprendre en quelques minutes comment produire du code HTML avec Zen Coding.
http://bp.inté.net/2-1 1
Produire du code CSS
Souvent moins connu, le module d’extension CSS de Zen Coding s’avère également très pratique. Il permet de générer des portions de code CSS grâce à une série d’abréviations relativement intuitives. Par exemple, les abréviations m , pl , bg , bd ou encore ! permettent respectivement de générer les propriétés margin , padding-left , background , border et !important . Grâce à des séquences prédéfinies, il est également possible de générer des déclarations complètes. Par exemple : cur:p , pos:a , et td:u permettent d’obtenir cursor:pointer;, position:absolute; et text-decoration:underline; .
Les préprocesseurs CSS
Les préprocesseurs CSS permettent d’étendre le langage CSS grâce à quelques fonctionnalités qui lui font encore cruellement défaut : les variables, les déclarations imbriquées, la notion d’héritage et les fonctions mathématiques. Bien que l’intérêt de ces ajouts puisse sembler limité, les facilités apportées par ce genre d’outil deviennent très vite indispensables.

G LOSSAIRE Préprocesseur
Le terme « préprocesseur » signifie que le langage source doit être compilé pour être transposé dans un langage cible. En d’autres termes, ce dernier n’est pas utilisable et compréhensible en l’état par les navigateurs ; c’est pour cela qu’il nécessite d’être réécrit en CSS.
Il existe de nombreux préprocesseurs CSS qui présentent tous, plus ou moins, les mêmes caractéristiques. Dépendant des préférences personnelles de chacun et de l’utilisation que l’on va en faire, le choix d’un préprocesseur est à arrêter en connaissance de cause. Aussi, avant d’en adopter un, il est recommandé de les tester afin de trouver celui qui vous correspond le mieux.

O UTILS Les préprocesseurs CSS
LESS : http://bp.inté.net/2-2 2
Google Closure Stylesheets : http://bp.inté.net/2-3 3
Sass : http://bp.inté.net/2-4 4
Stylus : http://bp.inté.net/2-5 5
Scaffold: http://bp.inté.net/2-6 6
Pour ma part, j’ai opté pour le langage LESS : construit à partir de la syntaxe CSS, il est très intuitif et simple à appréhender, ce qui facilite grandement sa prise en main. De ce fait, l’ensemble des exemples qui suivent ont été rédigés dans ce langage. Ceci dit, la syntaxe employée est globalement la même d’un préprocesseur à l’autre et les utilisateurs de Sass devraient s’y retrouver facilement.
Les variables
Les variables permettent de définir une seule fois une valeur utilisée en plusieurs endroits. Il peut s’agir d’une suite de caractères, d’un code hexadécimal ou encore d’une valeur numérique. Précédées du caractère @ , elles se déclarent de la façon suivante : @variable: valeur; .
Variables en code LESS

@margin : 15px 0;
@color: gray;
@path: "../theme/halloween";
#header {
margin: @margin;
color: @color ;
background: url(" @{path} /header.jpg") 0 0 no-repeat;
}
#footer {
border-top : 2px solid @color ;
background: url(" @{path} /footer.jpg") 0 0 repeat-x;
}
Code CSS obtenu après compilation

#header {
margin: 15px 0 ;
color: gray ;
background: url(" ../theme/halloween /header.jpg") 0 0 no-repeat;
}
#footer {
border-top : 2px solid gray ;
background: url(" ../theme/halloween /footer.jpg") 0 0 repeat-x;
}
Les variables peuvent être appelées à l’intérieur d’une chaîne de caractères. Pour ce faire, il suffit d’échapper la variable en utilisant la syntaxe suivante : @{nom-de-variable} .

À NOTER Nom de couleur ou code hexadécimal ?
Vous aurez certainement remarqué que j’ai pris le parti d’utiliser les noms de couleurs au lieu des codes hexadécimaux correspondants. J’ai fait ce choix pour des questions de lisibilité, leur emploi me paraissant tout à fait justifié dans ce cas précis.
À l’inverse, je déconseille fortement leur utilisation dans un contexte de développement : il convient de se référer à la palette utilisée dans la maquette graphique, en utilisant le code hexadécimal (ou la syntaxe RGB) de chaque couleur.

Les déclarations imbriquées
Les déclarations imbriquées permettent de simplifier le code et de gagner en lisibilité. Plutôt que de spécifier la totalité du sélecteur pour indiquer à quel ancêtre est rattaché l’élément visé, il suffit d’inclure le bloc de déclaration enfant dans le bloc ancêtre.
Déclarations imbriquées en code LESS

#nav {
margin: 20px 0 0 20px;
list-style: none;
li {
border-left : 2px solid gray;
padding: 3px 0;
a {
line-height: 1.15;
}
}
}
Code CSS obtenu après compilation

#nav {
margin: 20px 0 0 20px;
list-style: none;
}
#nav li {
border-left : 2px solid gray;
padding: 3px 0;
}
#nav li a {
line-height: 1.15;
}
Bien que très pratiques, les déclarations imbriquées présentent un inconvénient : un bloc de déclaration profondément imbriqué verra son sélecteur allongé en conséquence, ce qui affectera d’autant ses performances d’affichage. C’est pourquoi il est préférable de réduire au maximum les niveaux d’imbrication, afin d’en conserver le bénéfice tout en s’affranchissant des inconvénients sous-jacents. Ainsi, le code précédent gagnerait à être réécrit comme suit.
Réécriture du code LESS avec imbrications

#nav {
margin: 20px 0 0 20px;
list-style: none;
li {
border-left : 2px solid gray;
padding: 3px 0;
}
a {
line-height: 1.15;
}
}

Code CSS obtenu après compilation

#nav {
margin: 20px 0 0 20px;
list-style: none;
}
#nav li {
border-left : 2px solid gray;
padding: 3px 0;
}
#nav a {
line-height: 1.15;
}
L’héritage
L’héritage permet d’appliquer toutes les propriétés d’une classe A à une classe B. Pour ce faire, il suffit simplement d’indiquer le nom de la classe A dans le bloc de déclaration de la classe B.
Code LESS avec héritage

.border-radius {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;
}
.box {
.border-radius;
}
Code CSS obtenu après compilation

.box {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
border-radius: 5px;
}

G LOSSAIRE Propriétés préfixées
Depuis CSS 2.1, le W3C recommande aux éditeurs de navigateurs de préfixer les propriétés non standards qu’ils implémentent. Il peut s’agir de propriétés qui ne sont pas encore finalisées ou de propriétés propriétaires proposées par l’éditeur.
Les préfixes se présentent sous la forme d’une chaîne de caractères qui permet d’identifier le moteur les exploitant. Les plus courants sont : -moz- pour Gecko (Mozilla), -ms- pour Trident (Internet Explorer), -o- pour Presto (Opera), -webkit- pour WebKit (Chrome, Safari, etc.). Lorsqu’une propriété est finalisée, mais que la valeur ne l’est pas encore, le préfixe est alors placé devant la valeur et non sur la propriété :
-webkit-border-radius: 30px; /* la propriété n’est pas finalisée, elle est préfixée */
display: -moz-grid; /* la valeur n'est pas finalisée, c'est elle qui est préfixée */

Bien sûr, l’héritage s’applique aussi aux fonctions, ce qui confère au langage un véritable comportement dynamique. Lorsque la valeur d’une variable est indiquée en argument, elle sert de valeur par défaut. Elle est alors appliquée à toutes les fonctions dont l’argument n’est pas précisé.
Code LESS avec héritage de fonctions

.border-radius (@radius: 5px) {
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @radius;
}
.box {
.border-radius;
}
.circle {
.border-radius(30px);
}
Code CSS obtenu après compilation

.box {
-webkit-border-radius: 5px ;
-moz-border-radius: 5px ;
border-radius: 5px ;
}
.circle {
-webkit-border-radius: 30px ;
-moz-border-radius: 30px ;
border-radius: 30px ;
}
Notez qu’il est possible de passer plusieurs variables en argument. Dans le cas présent, il pourrait, par exemple, être utile de spécifier une variable par coin. Pour une meilleure lisibilité, les propriétés préfixées ne sont pas mentionnées.
Code LESS avec plusieurs variables en argument

.border-radius ( @tr , @br , @bl , @tl ) {
border-top-right-radius: @tr ;
border-bottom-right-radius: @br ;
border-bottom-left-radius: @bl ;
border-top-left-radius: @tl ;
}
.semi-circle {
.border-radius(30px, 0, 0, 30px);
}
Code CSS obtenu après compilation

.semi-circle {
border-top-right-radius: 30px ;
border-bottom-right-radius: 0 ;
border-bottom-left-radius: 0 ;

border-top-left-radius: 30px ;
}
Très utile dans de nombreuses situations, l’héritage présente cependant un défaut : il arrive quelques fois que le code généré ne soit pas nécessaire dans son intégralité. C’est le cas de l’exemple ci-dessus : la valeur par défaut étant border-radius: 0; , les déclarations border-bottom-right-radius: 0; et border-bottom-left-radius: 0; sont inutiles et gagneraient à être supprimées. Il est donc important de faire une passe de vérification pour nettoyer le code CSS avant de le livrer.
Les fonctions mathématiques
Dès lors qu’une règle de calcul est applicable pour obtenir la valeur d’une marge, d’une dimension ou même d’une taille de caractère, il devient utile d’employer les fonctions mathématiques. Le calcul étant automatiquement réalisé à la compilation, il est très facile de générer un code différent en modifiant simplement la variable passée en argument.
Dans l’exemple qui suit, nous allons calculer la largeur que doivent prendre les colonnes grâce à une fonction mathématique :
• @container représente le conteneur global ;
• @gutter représente une gouttière interne (espace entre les colonnes) ;
• @column représente une colonne.
Pour trouver la largeur d’une colonne, il faut tout d’abord soustraire à la dimension du conteneur l’ensemble des gouttières. Puis, il suffit de diviser la largeur obtenue par le nombre de colonnes présentes côte à côte.
Une fois la fonction retranscrite en LESS, il ne reste plus qu’à l’appeler en indiquant en argument le nombre de colonnes souhaitées.
Code LESS faisant appel à une fonction mathématique

@container: 700px;
@gutter: 40px;
.width(@column) {
width: ((@container) - ((@column - 1) * @gutter)) / @column;
}
.half {
.width(2);
}
.quarter {
.width(4);
}

Code CSS obtenu après compilation

.half {
width: 330px;
}
.quarter {
width: 145px;
}

F IG . 2-1 : Le nombre de gouttières est égal au nombre de colonnes retranché de 1.
LES INSPECTEURS DE CODE
Présent dans tous les navigateurs récents, l’inspecteur de code est un outil qui permet de visualiser et d’interagir avec tous les composants d’une page web. Très pratique pour identifier les instructions générant des différences d’affichage entre plusieurs navigateurs, il permet de gagner un temps considérable en évitant de nombreux allers-retours entre l’éditeur de code et le navigateur. En effet, il est possible d’y modifier le code HTML, d’éditer les propriétés CSS ou encore d’exécuter et de corriger le code JavaScript à la volée.
À l’heure actuelle, les inspecteurs de code proposent tous – à quelques différences près – les mêmes fonctionnalités. Ils peuvent facilement être affichés sur Chrome, Firefox et Opera grâce à un simple clic droit sur la page. Il suffit alors de sélectionner l’option Inspecter l’élément (ou formulation équivalente) pour les faire apparaître. Dans le cas d’Internet Explorer (à partir de la version 8), il est nécessaire d’afficher les Outils de développement en se rendant dans le menu Outils ou d’utiliser le raccourci F12 .

À NOTER L’inspecteur de code de Safari est masqué par défaut
L’inspecteur de code de Safari se trouve dans le menu Développement qui est masqué par défaut. Pour l’afficher, il suffit de se rendre dans les Préférences de Safari, dans l’onglet Avancées , et de cocher la case Afficher le menu Développement dans la barre des menus . Vous verrez alors apparaître dans votre menu principal un nouvel item Développement qui vous donnera accès, entre autres, à l’inspecteur. Vous pourrez également y accéder via un simple clic droit sur la page, en sélectionnant l’option Inspecter l’élément .
Scindés en plusieurs onglets, les inspecteurs donnent une vue exhaustive de la page web et de ses composants. Chaque onglet a une utilité précise : l’édition du code HTML/CSS, la visualisation des ressources affichées ou encore l’exécution du code JavaScript…
À défaut d’une présentation exhaustive de chacun, voici un aperçu succinct des éléments que je trouve très utiles dans le cadre d’une intégration web.

C ONSEIL Installer Firebug pour Firefox
Créée en 2006 par Joe Hewitt, à l’époque où les inspecteurs de code n’existaient pas encore, l’extension Firebug – qui permet de manipuler et d’interagir avec les composants de la page web – s’est rapidement imposée pour devenir une référence en la matière. Encore utilisée par de nombreux développeurs, elle est régulièrement mise à jour et bénéficie elle-même d’extensions qui permettent d’augmenter le nombre d’outils proposés par défaut.
https://getfirebug.com

C ONSEIL Installer Firebug Lite pour Internet Explorer 7
IE 7 n’ayant aucun inspecteur de code par défaut, l’instruction CSS ou la fonction JavaScript à l’origine d’une erreur de rendu ou d’une interaction non fonctionnelle est généralement difficile à identifier sur ce navigateur. Pour compenser cette absence, il est possible d’installer Firebug Lite.
Prévu pour fonctionner sur différents navigateurs, cet outil permet d’utiliser quelques-unes des fonctions de Firebug sur Chrome, IE, Opera et Safari. Il permet non seulement d’éditer les instructions CSS, de voir les styles calculés et le DOM de la page, mais fournit également une console pour pouvoir déboguer le code JavaScript.
https://getfirebug.com/firebuglite

Édition des éléments HTML et des styles CSS
L’onglet Éléments (aussi appelé Documents ou HTML , suivant le navigateur utilisé) est sans nul doute celui que j’utilise le plus au quotidien, car il permet de manipuler les éléments du DOM et les propriétés CSS de la page.

G LOSSAIRE DOM (Document Object Model)
Le DOM est l’interface par laquelle les programmes informatiques accèdent aux objets composant la page web. Il fournit des méthodes qui permettent de manipuler le contenu, la structure ou le style de ces objets. C’est grâce à cette interface que l’on peut facilement mettre à jour la page web, son contenu et sa mise en forme.
http://bp.inté.net/2-7 7
Il répertorie l’ensemble des styles qui entrent en concurrence dans le rendu d’un élément HTML, qu’il s’agisse d’une propriété héritée ou d’un style qui lui est directement appliqué. Cet onglet s’avère donc très pratique lorsqu’il s’agit de trouver pourquoi un style n’est pas pris en compte.

F IG . 2-2 : Onglet Documents de Dragonfly, l’inspecteur de code d’Opera

Lorsqu’un élément HTML est sélectionné, son « style calculé » est affiché. Il permet, par exemple, de connaître la valeur exacte (en pixels) d’une police exprimée en em ou d’un élément dont la dimension est fixée en pourcentage. Toutes les informations concernant son positionnement, ses marges et ses dimensions sont répertoriées dans cet onglet, dans la partie Dimension ( Disposition ou Apparence , selon le navigateur utilisé).
Débogage du code JavaScript
L’onglet Script permet de contrôler et de déboguer facilement le code JavaScript, grâce à un ensemble de fonctionnalités assez complètes comme le point d’arrêt ou l’exécution pas à pas. Secondé par la console, il permet d’identifier et de corriger à la volée la moindre erreur qui pourrait empêcher le script de s’exécuter normalement.

F IG . 2-3 : Onglet Scripts de l’inspecteur de Chrome

O UTIL Réindenter un code JavaScript
Chrome propose une fonction permettant de rendre lisible n’importe quel code JavaScript réduit au strict minimum, en le réindentant. Pour ce faire, il suffit de se rendre dans l’onglet Script , d’ouvrir le fichier à éclaircir et de cliquer sur les deux accolades présentes dans la barre d’outils.
Permettant d’arriver au même résultat, le site JS beautifier recense des extensions équivalentes pour Opera et Safari.
http://bp.inté.net/2-8 8

Validation du code HTML et CSS
Intégrées dans les versions 8 et 9 d’Internet Explorer et en partie sur Opera (qui ne propose étonnamment pas la validation HTML), les fonctions de validation permettent de vérifier l’intégrité des codes HTML et CSS.

O UTILS Extensions pour Chrome, Firefox, Internet Explorer et Safari
Développée par Chris Pederick, l’extension Web Developer est disponible pour Chrome et Firefox. Elle fournit, en plus des outils de validation HTML et CSS, un certain nombre d’options vraiment pratiques. La documentation et les liens de téléchargement sont disponibles sur le site de l’auteur :
http://bp.inté.net/2-9 9
Fortement inspirée de Web Developer, l’extension Internet Developer Toolbar n’est malheureusement pas aussi puissante. Très utile pour les versions 6 et 7 du navigateur, elle est avantageusement remplacée par les outils intégrés des versions ultérieures :
http://bp.inté.net/2-10 10
Développée pour Safari, l’extension Safari Validator permet de valider rapidement le code HTML et CSS d’une page, en soumettant ce dernier au validateur du W3C. La documentation et le lien de téléchargement sont disponibles sur le site de l’auteur :
http://bp.inté.net/2-11 11

F IG . 2-4 : Fonctions de validation intégrées dans l’inspecteur d’Internet Explorer

Analyse des performances
Disponible sur Chrome et Safari, sous la forme de l’onglet Audits , la fonction d’analyse des performances met en évidence un ensemble de points qui ralentissent le chargement de la page. Il peut s’agir de l’ordre d’appel des fichiers CSS et JavaScript qui n’est pas optimal, ou encore du poids des images qui ne sont pas correctement optimisées.

F IG . 2-5 : Onglet Audits de l’inspecteur de Safari

O UTILS Extensions pour Chrome, Firefox et Opera
Développée par Yahoo!, l’extension YSlow est disponible pour Chrome, Firefox et Opera. Quant à l’extension Page Speed, développée par Google, elle est uniquement disponible pour Chrome et Firefox. La documentation et les liens de téléchargement sont accessibles en ligne :
http://bp.inté.net/2-12 12
http://bp.inté.net/2-13 13
Visualisation du temps de chargement
L’onglet Réseau complète idéalement les fonctions d’analyse des performances : on y trouve l’ensemble des informations concernant l’ordre et le délai de chargement des éléments. Le tout est retranscrit sous la forme d’un graphique en cascade (waterfall) aisément compréhensible. Cet onglet est donc très utile dès que vous cherchez à améliorer les performances de votre page, car il permet d’identifier facilement les composants restant à optimiser pour minimiser le temps de chargement.

F IG . 2-6 : Onglet Réseau de Firebug (Firefox)

R ESSOURCES Les inspecteurs de code
Les fonctions présentées précédemment ne donnent qu’un petit aperçu des possibilités offertes par chaque inspecteur. Pour en savoir plus sur les avantages de chacun et les extensions disponibles, consultez la documentation en ligne :
Chrome (en anglais) : http://bp.inté.net/2-14 14
Safari (en anglais) : http://bp.inté.net/2-15 15
Opera : http://bp.inté.net/2-16 16
Firefox (en anglais) : http://bp.inté.net/2-17 17
Internet Explorer (en anglais) : http://bp.inté.net/2-18 18

LE SYSTÈME DE GESTION DE VERSIONS
Mettre en place un système de gestion de versions pour un projet consiste à dupliquer celui-ci sur un dépôt de référence (local ou distant). Chaque fichier enregistré se voit alors attribuer un numéro de version qui évoluera au gré des mises à jour. Cela permet, entre autres, d’avoir un historique complet des modifications apportées à chaque fichier, de visualiser facilement les différences qui existent entre deux versions données et, surtout, de pouvoir revenir à une version antérieure. Très prisé sur les projets requérant l’intervention de plusieurs intervenants, il permet aussi d’éviter les écrasements malencontreux en donnant la possibilité de régler facilement les conflits dès qu’ils sont détectés.
De nombreux systèmes de gestion de versions existent, sans toutefois offrir les mêmes avantages. Bien que très utilisé, Subversion présente un gros inconvénient : il n’est pas possible de créer un dépôt local sur son poste de travail. Ainsi, un intégrateur travaillant seul sera obligé d’avoir recours à un dépôt distant pour pouvoir versionner son projet. À l’inverse, avec une solution telle que git, Mercurial ou encore Bazaar, toutes les modifications sont soumises à un dépôt local avant d’être éventuellement poussées sur un dépôt distant. Tous les avantages de la gestion de versions sont donc disponibles sur l’ordinateur.

O UTILS Les systèmes de gestion de versions
Git : http://bp.inté.net/2-19 19
Mercurial : http://bp.inté.net/2-20 20
Bazaar : http://bp.inté.net/2-21 21
Organiser logiquement les commits
Éléments incontournables de la gestion de versions, les commits correspondent à l’envoi des modifications sur le dépôt. Ils sont accompagnés d’un certain nombre de renseignements qui permettent de les identifier : l’auteur de la modification, la date de mise à jour et le commentaire renseigné lors de l’envoi. Bien souvent négligé, ce dernier est pourtant d’une aide précieuse lorsqu’il s’agit de retrouver la version précise d’un fichier. Qu’il s’agisse du client qui souhaite revenir sur une évolution demandée ou simplement d’un effet de bord dû à un changement de style, il est relativement fréquent de devoir se référer à une portion de code qui n’existe plus dans la version actuelle.

Or, renseigner ses commits par « modif. » ou « évol. » n’est pas très utile quand vient le moment d’identifier une mise à jour. Pour ma part, j’ai pris le parti de segmenter mes commentaires en trois parties :
• s’il s’agit d’un bogue ou d’une demande d’évolution, j’indique « correctif », suivi de l’identifiant numérique du bogue ou « évolution » ;
• si cela concerne une seule page, je précise de laquelle il s’agit, puis la nature de la modification : « ajout », « suppression » ou simplement « mise à jour » ;
• enfin, si cela est nécessaire, je décris précisément à quoi correspond la mise à jour effectuée.
Il en résulte des commentaires comme « agenda : ajout du calendrier » ou « bogue 237 – correctif IE6 : display: inline-block; sur la pagination » qui me donne une idée très précise du contenu de la version concernée.

C ONSEIL Utiliser un dépôt local
Dans l’idéal, chaque modification significative devrait faire l’objet d’un commit séparé et correctement décrit. L’intérêt principal du dépôt local étant de permettre à chacun de pouvoir versionner toutes les étapes de son travail sur son ordinateur.
Dans le cadre d’un projet en équipe, le passage par un dépôt local permet de trier et d’organiser les commits afin de ne pousser sur le dépôt partagé que les évolutions importantes, sans soumettre toutes les étapes intermédiaires.

P OUR EN SAVOIR PLUS Git : un système de gestion de versions efficace
Modern Version Control with Git : Publié sur le site du Smashing Magazine, cet article consacré à git présente de manière exhaustive le fonctionnement et les avantages de ce système de gestion de versions.
http://bp.inté.net/2-22 22
Un mémento a également été publié sur le sujet récemment. Il récapitule les commandes essentielles et donne de nombreux conseils d’utilisation :
R. Hertzog, P. Habouzit, Git à 100 %, Eyrolles, 2012
OUTILS EN LIGNE
Qu’il s’agisse d’écrire du code HTML ou CSS, de vérifier l’intégrité d’un code JavaScript ou de s’assurer de la qualité des pages mises en ligne, de nombreux outils ont été conçus pour simplifier la tâche des développeurs web. Loin d’être exhaustive, la liste ci-après rassemble quelques-uns de ceux que j’utilise le plus au quotidien, les autres étant abordés dans les chapitres suivants.
Bien sûr, il serait possible d’y ajouter les applications de bureau. Cependant, ces dernières sont généralement liées au système d’exploitation, ce qui impose bon nombre de restrictions quant à leur utilisation. C’est pourquoi je me suis volontairement restreinte aux outils qui sont disponibles en ligne, et qui peuvent être utilisés sans contraintes dues à l’environnement de travail.
Outils pour le HTML
CopyPasteCharacter
http://www.copypastecharacter.com
CopyPasteCharacter est un site qui regroupe, sur une seule page, les entités HTML des caractères spéciaux les plus courants. Un clic sur le caractère souhaité suffit pour que le code correspondant soit automatiquement mémorisé dans le presse-papier.
HTML-Ipsum
http://www.html-ipsum.com
HTML-Ipsum rassemble des extraits de code HTML (paragraphe, liste, tableau, etc.) remplis de portions de faux-texte prêtes à être copiées. Cela permet, par exemple, de tester une intégration avec un contenu plus fourni que celui proposé dans la maquette graphique.
Outils pour les CSS
CSS3 Generator
http://css3generator.com
CSS3 Generator est un outil qui permet de générer simplement du code CSS3 (comme les ombrages, les colonnes de textes, ou encore les bords arrondis). Il suffit d’indiquer les caractéristiques souhaitées et de copier le code affiché. Petit plus appréciable, la compatibilité navigateur est indiquée pour chaque propriété.
ProCSSor
http://procssor.com
ProCSSor est un outil en ligne qui permet de rendre parfaitement lisible et compréhensible un code CSS obscurci. Les nombreuses options disponibles permettent de personnaliser l’affichage du code selon ses préférences.

CSS Lint
http://csslint.net
CSS Lint est un outil qui permet d’analyser et d’améliorer la syntaxe d’un code CSS. À partir de l’exemple qui lui est envoyé, il signale les erreurs potentielles, mentionne les points pouvant être améliorés et donne quelques conseils pour y remédier. Si l’outil s’avère très pratique, les recommandations ne sont cependant pas à prendre au pied de la lettre : elles ont pour objet d’initier une réflexion sur l’un ou l’autre point de la syntaxe soumise et ne sont – en aucun cas – à appliquer les yeux fermés. Il est d’ailleurs possible d’affiner le niveau d’analyse souhaité en indiquant les recommandations à prendre en compte et celles à ignorer.
Outils pour améliorer les performances
WebPagetest
http://www.webpagetest.org
WebPagetest est un outil très complet qui sert à auditer les performances d’une page web. Les différentes mesures effectuées donnent lieu à un rapport détaillé qui met en évidence les points à optimiser.

P OUR EN SAVOIR PLUS Le principe du chargement d’une page
Cet article publié sur OpenWeb décrypte l’affichage d’une page et donne des pistes pour accélérer son chargement :
http://bp.inté.net/2-23 23
SPOF-o-Matic
http://bp.inté.net/2-24 24
SPOF-o-Matic est une extension Chrome qui détecte les scripts tiers et permet de simuler l’indisponibilité des ressources liées. Ainsi, il est possible de vérifier qu’aucun appel ne constitue un point de défaillance unique (SPOF : Single Point of Failure ) qui pourrait bloquer le rendu de la page.
Ressources et outils pour la qualité web
Développé par la société Temesis, le projet Opquast (Open Quality Standards) a pour objectif de faire avancer la qualité web, en proposant des ressources (les bonnes pratiques Opquast) et des outils d’évaluation (Opquast Reporting), tous disponibles en ligne.

Les bonnes pratiques Opquast
https://checklists.opquast.com
Les « bonnes pratiques Opquast » désignent un référentiel constitué (dans sa seconde version) de 217 bonnes pratiques dédiées à la qualité web. Chacune d’elles est affectée à l’un des trois niveaux Opquast (1, 2 ou 3), qui indique l’importance qu’il faut accorder à sa prise en charge. Cela permet, par exemple, de classer les correctifs à réaliser par ordre de priorité. Pour la plupart, des recommandations, solutions techniques et moyens de contrôle sont indiqués, afin d’aider l’utilisateur à résoudre le problème rencontré. Toutes les listes peuvent être triées en fonction d’une thématique particulière (comme l’intégration, le prototypage, la performance, etc.) et sont disponibles en téléchargement pour une utilisation hors ligne.

À LIRE Mémento : Les bonnes pratiques Opquast
Aide-mémoire de 14 pages, ce mémento constitue un excellent outil d’appoint pour vérifier rapidement le contenu d’une bonne pratique Opquast.
É. Sloïm, Sites web : Les bonnes pratiques, 3 e édition, collection Mémento, Eyrolles, 2010
Opquast Reporting
http://reporting.opquast.com
Opquast Reporting est un outil d’audit qui permet de contrôler un site par rapport à une liste de critères. Il est possible d’entrer des points de contrôle personnalisés ou de choisir une liste parmi celles proposées par défaut : les bonnes pratiques Opquast, le RGAA (Référentiel général d’accessibilité pour les administrations), ou encore les WCAG (Web Content Accessibility Guidelines), pour ne citer qu’elles.
La réalisation de l’audit est facilitée par deux outils qui permettent d’accélérer l’évaluation du site. Une fois finalisée, un état des lieux de la conformité du site est fourni et il est possible, si besoin, d’en générer un rapport récapitulatif.
Outils de vérification et de validation
Validateurs HTML et CSS
Disponibles sur le site du W3C, les validateurs HTML 25 et CSS 26 permettent de vérifier la conformité du code qui leur est soumis. Au vu des difficultés rencontrées par le validateur officiel pour analyser correctement un document HTML5 doté d’une surcouche ARIA, un validateur alternatif a été mis en place : http://validator.w3.org/nu/ .

Contrôleur JavaScript : JSLint
http://www.jslint.com
JSLint est un outil qui permet d’analyser, de contrôler et de corriger la syntaxe d’un code JavaScript. Très strict sur la syntaxe employée, il détecte les erreurs qui peuvent être la cause d’un dysfonctionnement sous certains navigateurs.
Vérificateur de liens
http://validator.w3.org/checklink
À partir d’une URL donnée, le vérificateur de liens parcourt la totalité du site à la recherche d’éléments manquants. Une fois l’analyse terminée, la liste des fichiers non trouvés est affichée.

R ESSOURCE Identifier les liens brisés sur votre site web
Réalisé courant 2010, ce mini-comparatif détaille les avantages et les inconvénients des trois solutions les plus couramment utilisées pour identifier les liens brisés d’un site web : le validateur du W3C, Google Webmaster Tools et Xénu Link Sleuth.
http://bp.inté.net/2-25 27
Validateur pour les flux de syndication (Atom, RSS)
http://validator.w3.org/feed/
Disponible sur le site du W3C, ce validateur permet de vérifier la syntaxe des flux de syndication Atom et RSS.

R ESSOURCES Les outils du W3C
D’autres outils sont également proposés par le W3C. Par exemple, Unicorn (pour vérifier la conformité globale d’une page) ou MobileOK (pour voir si une page est adaptée pour le mobile). Tous ces outils sont disponibles à l’adresse suivante :
http://bp.inté.net/2-26 28

Ressources diverses
DocHub
http://www.dochub.io
DocHub est un moteur de recherche qui permet de trouver simplement de la documentation sur le DOM, HTML, CSS, JavaScript et jQuery. Issues du Centre de documentation de Mozilla (MDN) et du site officiel de jQuery, les informations fournies sont pertinentes et très complètes.
Le wiki du W3C
http://www.w3.org/community/webed/wiki/
Tout comme MDN, le wiki du W3C est en constante évolution. Pour l’heure, il rassemble déjà de nombreuses ressources sur HTML, CSS, JavaScript, l’accessibilité et le développement mobile. Une partie consacrée au langage SVG a également été créée : de la documentation ne devrait pas tarder à y être ajoutée.
JsFiddle
http://jsfiddle.net
Éditeur de texte en ligne, jsFiddle est un outil de test et de partage de code source. Chaque exemple publié (HTML, CSS et/ou JavaScript) peut facilement être étudié, modifié et testé par une personne tierce. Les modifications apportées peuvent à leur tout être sauvegardées et partagées.

1 . http://vimeo.com/7405114
2 . http://lesscss.org
3 . https://code.google.com/p/closure-stylesheets/
4 . http://sass-lang.com
5 . http://learnboost.github.com/stylus/
6 . https://github.com/anthonyshort/Scaffold/wiki/
7 . https://developer.mozilla.org/fr/À_propos_du_Document_Object_Model
8 . http://jsbeautifier.org
9 . http://chrispederick.com/work/web-developer/
10 . http://www.microsoft.com/download/en/details.aspx?id=18359
11 . http://zappatic.net/projects/safarivalidator
12 . http://developer.yahoo.com/yslow/
13 . https://developers.google.com/speed/pagespeed/?hl=fr-FR
14 . https://developers.google.com/chrome-developer-tools/
15 . https://developer.apple.com/technologies/safari/developer-tools.html
16 . http://www.opera.com/dragonfly/
17 . https://getfirebug.com/wiki/
18 . http://msdn.microsoft.com/en-us/library/dd565622%28v=vs.85%29.aspx
19 . http://git-scm.com
20 . http://mercurial.selenic.com
21 . http://bazaar.canonical.com
22 . http://coding.smashingmagazine.com/2011/07/26/modern-version-control-with-git-series/
23 . http://openweb.eu.org/articles/performances_avancees_sites_internet
24 . https://chrome.google.com/webstore/detail/plikhggfbplemddobondkeogomgoodeg
25 . http://validator.w3.org
26 . http://jigsaw.w3.org/css-validator/
27 . http://www.bootleygues.net/index.php?post/2010/05/11/Identifier-les-liens-brises-sur-votre-site-web
28 . http://www.w3.org/QA/Tools/
La plate-forme de test est sans nul doute l’un des composants clés de l’environnement de travail ; c’est pourquoi elle doit être élaborée avec soin, pour fournir des conditions de test fiables et variées. Comptant parmi les solutions les plus employées, les services en ligne et la virtualisation permettent de vérifier la bonne compatibilité d’une intégration sur la suite Internet Explorer et sur les principaux navigateurs actuels. Néanmoins pour assurer une compatibilité aussi exhaustive que possible, il convient d’ajouter à ce panel les terminaux mobiles les plus courants, ainsi que certaines technologies d’assistance.

Dans ce chapitre
• Configurations : que faut-il tester ?
• Internet Explorer : comment vérifier le rendu sur les anciennes versions du navigateur ?
• Panel de test : les services en ligne, la virtualisation, les terminaux mobiles et les technologies d’assistance
QUELLES CONFIGURATIONS TESTER ?
Face à la multiplication des moyens permettant d’accéder à Internet, il est tout à fait légitime de s’interroger sur le panel de navigateurs et de terminaux à tester. Bien qu’il soit utopique de vouloir vérifier l’ensemble des configurations existantes, il est néanmoins possible d’assurer une compatibilité maximale grâce à un minimum de configurations.
Parmi elles figurent bien évidemment les différentes versions d’Internet Explorer. Nécessitant une attention toute particulière, ces dernières doivent être testées individuellement, tant la prise en charge des CSS est hétéroclite d’une version à l’autre. Cependant, bien qu’Internet Explorer soit sans conteste le navigateur dont les versions précédentes posent le plus de problèmes, la vérification d’une intégration ne peut en aucun cas se limiter à ce navigateur, ni au seul système d’exploitation Windows. En effet, le rendu dépend non seulement du navigateur utilisé, mais également de la plate-forme sur laquelle il est installé. C’est pourquoi, afin de s’assurer de l’affichage et du fonctionnement d’un site, il convient de le tester sur les couples système d’exploitation/navigateur les plus utilisés, ainsi que sur certaines configurations identifiées grâce à une analyse du contexte dans lequel s’inscrit le projet.
Dans le panel des configurations à tester, il convient d’inclure les versions précédentes des navigateurs autres qu’Internet Explorer. Souvent délaissées, il arrive pourtant que leur prise en compte soit incontournable. C’est notamment le cas lorsque l’on a recours à des propriétés non finalisées qui sont uniquement prises en charge par les versions les plus récentes : il faut alors vérifier le rendu sur les navigateurs les moins performants et mettre en place une alternative de remplacement si cela s’avère nécessaire.
Le panel de test
Pour permettre aux développeurs de tester leurs intégrations dans de bonnes conditions, Yahoo! a établi une liste de navigateurs à vérifier afin de garantir la compatibilité d’un site : http://yuilibrary.com/yui/environments/ . Publiée pour la première fois au début de l’année 2006, cette matrice recense, pour chaque navigateur, la (ou les) version(s) à tester. Mise à jour deux fois par an, elle prend en compte l’actualité et les parts de marché des différents navigateurs.
N’apparaissant pas dans la liste, Opera fait figure de grand absent. Certes moins populaire que ses concurrents, il est tout de même étrange que Yahoo! n’en fasse pas état. Volontairement omis, les systèmes d’exploitation ne sont pas non plus mentionnés. Il est cependant vivement conseillé de vérifier le rendu d’une intégration sur plusieurs systèmes d’exploitation, a minima Windows et Mac OS.


F IG . 3-1 : Publiée en juillet 2012, la matrice recommande de tester le rendu sur la suite IE ainsi que sur différentes versions d’Android et de l’iOS.

B ONNE PRATIQUE Tester les versions en développement
Fournissant une très bonne base de référence, la matrice de Yahoo! présente le défaut de ne pas prendre en compte les versions en cours de développement mises à disposition par les éditeurs. Composante importante de l’environnement de test, les versions bêta permettent de vérifier le rendu sur la (ou les) future(s) version(s) des navigateurs. Grâce à elles, il est possible de détecter (et donc de corriger) une éventuelle incompatibilité avec une version donnée, avant que cette dernière ne devienne officiellement disponible. Cela permet d’éviter les mauvaises surprises, comme une fonction JavaScript qui cesse de fonctionner après la mise à jour du navigateur.
Le contexte projet
Bien qu’elles constituent une excellente base de référence, les recommandations de Yahoo! ne sont, pour autant, pas les seuls éléments qu’il faille prendre en considération. En effet, il faut également tenir compte du contexte global dans lequel s’inscrit le projet avant de choisir les différentes configurations à retenir.
Paramètre essentiel, ce contexte permet de moduler les recommandations générales pour mettre en place un environnement de test parfaitement adapté : quelle est la nature du site ? S’agit-il d’une refonte, d’une extension de services ou d’un nouveau projet ? Des statistiques sont-elles disponibles ? Quelle est la cible visée ? Autant de questions qui permettent de cerner précisément le cadre et les spécificités du projet. Grâce aux réponses apportées, il est alors possible de revoir l’environnement de test initialement prévu et d’ajouter ou de supprimer l’une ou l’autre configuration.
Cette phase de réflexion en amont de la réalisation constitue un moment privilégié pour échanger avec le client. Accessibilité, performance, emploi des nouvelles balises HTML5 sont quelques exemples de sujets qui peuvent être abordés. En partageant ainsi un peu de son expertise, il est possible d’entraîner une prise de conscience des différents tenants et aboutissants de l’intégration. Ainsi, il peut arriver – suivant la compréhension du client et le budget alloué au projet – que le niveau de qualité visé soit revu à la hausse.

P OUR EN SAVOIR PLUS Conformité, validation et surqualité
La recherche de conformité est toujours considérée comme un gage de qualité. Cependant, dans certains cas, il n’est pas forcément pertinent de choisir le chemin de la conformité absolue. Cet article explique en détail pourquoi.
http://bp.inté.net/3-1 1

R ESSOURCE Revue d’outils pour éprouver la compatibilité navigateur
Review Of Cross-Browser Testing Tools : s’intéressant aux outils qui permettent de tester la compatibilité d’un site, cet article fait le tour d’horizon des différentes solutions pour éprouver un rendu sur un panel étendu de navigateurs. Bien qu’il ait été écrit en 2011, ce billet reste toujours d’actualité. Pour autant, il y a fort à parier que d’autres solutions pour le moins intéressantes soient apparues depuis. C’est pourquoi, même si la base de tests évolue relativement peu, il est vivement conseillé de rester curieux sur le sujet.
http://bp.inté.net/3-2 2
LE « CAS » INTERNET EXPLORER
Bête noire de l’intégrateur, Internet Explorer (IE) doit sa mauvaise réputation aux versions 6 et 7 de son navigateur, IE 6 interprétant de manière erronée certaines propriétés CSS essentielles et IE 7 ne prenant en charge les propriétés CSS 2.1 que de façon très minimale. Aujourd’hui encore, bien que IE 6 ait dix ans révolus, certaines entreprises continuent malgré tout à l’utiliser pour des questions stratégiques. Cela porte donc à quatre le nombre de versions différentes d’Internet Explorer présentes sur le marché des navigateurs (IE 10 n’étant encore disponible qu’en version bêta). Mais, contrairement à ce que l’on pourrait penser, le principal problème n’est pas tant le nombre de versions utilisées en parallèle, que la prise en charge hétéroclite des CSS d’une version à l’autre.
Respectueux des standards et permettant – dans leurs versions initiales – d’utiliser une palette de propriétés CSS relativement étendue, les navigateurs alternatifs posent naturellement moins de problèmes.
Les années passant, les maigres possibilités offertes par IE 6 sont devenues une véritable contrainte. Au point qu’un temps de développement spécifique est généralement comptabilisé en sus pour toute intégration devant être compatible avec cette version.

P OUR EN SAVOIR PLUS Les surcoûts de production liés à la rétrocompatibilité IE 6
S’appuyant sur sa propre expérience de chef de projet, l’auteur livre ici une estimation globale du surcoût engendré par la prise en charge d’Internet Explorer 6.
http://bp.inté.net/3-3 3
Pourtant, il faut savoir qu’à sa sortie, IE 6 fut précurseur dans la prise en charge des CSS. Dominant très largement le marché des navigateurs (grâce à la disparition de son concurrent principal Netscape), il faudra attendre cinq ans pour que Microsoft se décide à sortir IE 7. Se contentant de corriger une partie des bogues identifiés sur IE 6 et d’implémenter certaines propriétés CSS 2.1, cette version ne sera – de loin – pas à la hauteur des attentes qu’elle suscitait.
L’affichage de compatibilité
Sorti en 2009, IE 8 se caractérise par une avancée conséquente dans le respect des standards. Bénéficiant d’un nouveau moteur de rendu, il est conforme (en quasi-totalité) aux spécifications CSS 2.1 et passe le test Acid 2 avec succès.

G LOSSAIRE Test Acid
Les tests Acid sont, pour l’instant, au nombre de trois. Respectivement publiés en 1998, 2005 et 2008, ils permettent de tester la mise en œuvre par les navigateurs de certaines fonctionnalités spécifiées par les standards du Web. Il est prévu que le développement du test Acid 4 commence lorsque le test Acid 3 sera passé avec succès par les moteurs de rendu les plus utilisés.
http://bp.inté.net/3-4 4
Loin d’être anodin, le changement du moteur de rendu ne s’est pas fait sans mal. En effet, lorsqu’ils étaient consultés avec IE 8, certains problèmes d’affichage pouvaient être constatés sur les sites spécifiquement conçus pour une ancienne version du navigateur. Afin de résoudre le problème, Microsoft a donc implémenté un mode « affichage de compatibilité » censé faciliter la transition entre les deux versions de son navigateur.


F IG. 3-2 : Le mode de compatibilité s’active grâce à une icône placée dans ou à côté de la barre d’adresses (suivant la version exécutée).
Malheureusement, cette nouveauté s’est bien vite révélée être une mauvaise surprise pour les développeurs, le rendu généré par l’affichage de compatibilité n’étant pas identique à celui affiché par IE 7. En effet, bien que le moteur de rendu utilisé soit le même dans les deux cas, de nombreux autres éléments intervenant dans la génération de l’affichage divergent. C’est pourquoi l’affichage et le comportement des sites ne sont pas similaires en tous points.
Malgré le fait qu’un certain nombre de ces différences soient connues, aucune liste exhaustive n’a été établie. De ce fait, il est plus qu’hasardeux de se fier au mode de compatibilité pour simuler l’apparence d’une intégration sur IE 7.

B ONNE PRATIQUE Forcer Internet Explorer à utiliser son moteur de rendu le plus récent
Afin d’obliger Internet Explorer à utiliser la version la plus récente de son moteur de rendu et éviter l’activation du mode de compatibilité, il est possible de placer dans l’en-tête de document head la métadonnée suivante :
<meta http-equiv="X-UA-Compatible" content="edge" />
Cependant, la présence de cette balise propriétaire empêche la validation de la page. C’est pourquoi il est généralement conseillé de spécifier ces instructions via un en-tête PHP, ou dans le fichier .htaccess (voir le chapitre 15 ).

Les installations multiples
Le principal problème de Windows réside dans le fait qu’il est – en théorie – impossible d’installer plusieurs versions d’Internet Explorer sur un seul et même système d’exploitation. Afin de tester le rendu d’une intégration sur plusieurs versions, la solution la plus simple est donc d’avoir recours à des outils simulant les différentes versions du navigateur. Nécessitant d’être installés sur une plate-forme Windows, les deux émulateurs IETester et IE Collection sont certainement les plus utilisés à l’heure actuelle.
IETester
http://www.my-debugbar.com/wiki/IETester
IETester est un navigateur permettant de simuler l’affichage d’un site avec Internet Explorer 5.5, 6, 7, 8, 9, ainsi qu’avec la version bêta de IE 10. Apprécié pour les fonctionnalités qu’il propose, il permet, entre autres :
• de tester simultanément, dans une seule et même fenêtre, le rendu d’un site sur plusieurs versions, grâce à un système d’onglets ;
• de désactiver le cache, les images et les scripts ;
• de déboguer les pages directement dans le navigateur, grâce à l’installation de la DebugBar 5 .
Considéré comme une référence par beaucoup, IETester n’est pourtant pas totalement fiable. Bien que le rendu HTML/CSS soit plutôt fidèle, de nombreux problèmes relatifs à l’usage de JavaScript ont été constatés. C’est pourquoi son utilisation est déconseillée.
IE Collection
http://utilu.com/IECollection/
IE Collection est un utilitaire permettant d’installer une ou plusieurs versions d’Internet Explorer parmi les douze proposées. Il est, par exemple, possible de choisir les versions 1.5 ou 3, mais en pratique, seuls IE 6, 7 et 8 sont réellement utiles. Les versions 9 et 10 ne sont, à l’heure actuelle, pas encore disponibles.
À l’instar de IETester, IE Collection propose deux outils de débogage tout aussi performants :
• l’extension Internet Explorer Developer Toolbar, qui est disponible sur toutes les versions à partir d’IE 5 ;
• l’extension Firebug Lite, uniquement disponible sur IE 7 et IE 8.

À NOTER La fiabilité des émulateurs
Permettant de tester rapidement le rendu d’un site sur une ou plusieurs versions d’Internet Explorer, les émulateurs simplifient sans conteste la tâche du développeur web. Cependant, aussi performants soient-ils, un doute subsiste toujours quant au degré d’exactitude de l’affichage fourni : il est fort probable qu’ils ne parviennent jamais à répliquer à l’identique le rendu et le comportement d’une version native.
Solution séduisante a priori, s’en remettre au rendu d’un émulateur revient donc à prendre le risque de faire confiance à un outil qui n’est pas fiable à cent pour cent. L’idéal reste de tester le site en conditions réelles par le biais d’un service en ligne, de la virtualisation ou d’une machine physique. Si toutefois vous souhaitiez continuer à tester vos rendus à l’aide d’un simulateur, préférez IE Collection à IETester, pour des questions de fiabilité.
Google Chrome Frame
https://code.google.com/intl/fr/chrome/chromeframe/
Google Chrome Frame est un plug-in pour Internet Explorer qui permet d’embarquer, de manière totalement transparente, le moteur de rendu et le moteur JavaScript de Chrome à l’intérieur de ce dernier. Dans les faits, WebKit ne vient pas remplacer Trident : il est simplement utilisé comme alternative, pour peu que l’utilisateur ait installé le plug-in sur son poste et que le développeur ait permis son utilisation. En effet, il n’est pas activé par défaut : les sites qui souhaitent y avoir recours doivent utiliser une balise meta spécifique ou l’en-tête HTTP équivalent.
Balise meta permettant d’activer Google Chrome Frame

<meta http-equiv="X-UA-Compatible" content="chrome=1" />
Une fois installé sur le poste utilisateur, le plug-in est disponible pour tous les sites qui le souhaitent. Cette solution pour le moins attrayante permet donc d’améliorer l’expérience utilisateur sur les postes équipés. Cependant, son utilisation pose certains problèmes d’accessibilité et elle est donc déconseillée pour les projets ayant une forte contrainte à ce niveau-là.

P OUR EN SAVOIR PLUS Google Chrome Frame est-il encore un trou noir d’accessibilité ?
Google Chrome Frame – still an accessibility black hole? : bien que l’accessibilité du plug-in ait été améliorée depuis la première version, certains points problématiques sont toujours présents dans la dernière mise à jour.
http://bp.inté.net/3-5 6

Ces différentes raisons font qu’il est impératif de ne pas considérer ce plug-in comme la solution idéale pour obtenir un rendu satisfaisant sur les anciennes versions d’Internet Explorer : tous les utilisateurs naviguant avec IE 6, 7 ou 8 ne l’ont pas nécessairement installé.
LES SERVICES EN LIGNE
De nombreux services en ligne permettent de visualiser le rendu d’un site sur plusieurs configurations différentes. Ces outils sont répartis en deux catégories : les premiers génèrent des captures d’écran, tandis que les seconds donnent le contrôle à distance d’un navigateur présentant les caractéristiques souhaitées.
Les sites présentés ci-après ne constituent pas une liste exhaustive. Il s’agit plutôt d’un ensemble de solutions relativement complètes permettant de tester un site sur différentes configurations. En fonction des navigateurs présents sur la machine de test, il est tout à fait possible de se tourner vers des services moins fournis.
Les services de captures d’écran
Permettant d’obtenir un rendu statique de la page, les sites générant des captures d’écran sont d’une utilité relativement réduite. En effet, il est impossible de visualiser les problèmes découlant d’une interaction de l’utilisateur ou d’une fonction JavaScript mal exécutée. Malgré tout, ces outils peuvent être utilisés comme base pour identifier les problèmes de positionnement ou d’affichage inhérents à une configuration particulière.
Browsershots
http://browsershots.org
Lancé en 2005, Browsershots est certainement l’un des services de captures d’écran les plus connus et les plus intuitifs. Il permet de générer des captures pour un nombre impressionnant de navigateurs sous Windows, Linux et BSD (une famille de systèmes d’exploitation Unix), Mac OS étant le grand absent. Il suffit simplement de renseigner l’URL de la page à tester et de sélectionner les navigateurs pour lesquels une capture est souhaitée. La requête est alors ajoutée à la file d’attente jusqu’à ce qu’elle soit traitée. La disponibilité des captures dépend du nombre de requêtes en attente et du nombre de simulations attendues.
BrowserLab
https://browserlab.adobe.com/fr-fr/index.html
BrowserLab est un service en ligne qui permet de générer et de comparer facilement le rendu d’un même site sur plusieurs navigateurs. Bien plus qu’un simple outil de capture d’écran, cette application est agrémentée de quelques fonctions assez pratiques.

• Un retardateur permet à la page de se charger en totalité avant que la capture ne soit effectuée.
• Les captures peuvent être superposées ou mises côte à côte pour être comparées plus facilement.
• Les liens sont conservés et permettent de naviguer d’une capture à l’autre, chaque nouvelle page faisant l’objet d’une capture à la volée.
• Enfin, l’ajout d’une extension dédiée 7 permet de visualiser l’impact des modifications réalisées dans Firebug. Créant un lien entre le navigateur et l’application, elle permet de générer de nouvelles captures sur la base du code modifié par son intermédiaire.
À l’instar de Browsershots, ce service est gratuit.
Les services d’accès à distance
Les services d’accès à distance permettent de visualiser et de tester en conditions réelles n’importe quel site en ligne par l’intermédiaire d’un navigateur installé sur une machine distante. Considérés comme la solution idéale par beaucoup, ces services évitent au développeur d’installer et de maintenir les versions des différents navigateurs sur la (ou les) machine(s) de test.
Bien que très pratiques, ces services présentent tout de même un petit défaut : la réactivité. Selon le débit Internet et la puissance de la machine dédiée, il est fréquent de constater des latences plus ou moins importantes à l’affichage. Cet inconvénient mineur peut cependant rapidement devenir bloquant lorsqu’il s’agit de tester une quinzaine de gabarits (voire plus) sur différentes configurations.
Sauce Labs
http://saucelabs.com
Ce service en ligne permet, entre autres, de consulter n’importe quel site Internet via l’un des navigateurs proposés par l’application. Une vidéo est automatiquement générée lors de chaque session, ce qui s’avère très pratique pour identifier l’origine d’un bogue ou la suite d’actions l’ayant fait apparaître. De plus, il est également possible d’enregistrer une capture d’écran à tout instant.
Le principal inconvénient de cette application réside dans le nombre restreint de configurations proposées : Mac OS n’est tout simplement pas listé. En revanche, elle est très utile pour tester l’ensemble des navigateurs disponibles sur un environnement Windows.
Gratuit, l’abonnement de base donne droit à un accès mensuel limité. Les autres abonnements sont compris entre 29 et 279 USD par mois.

CrossBrowserTesting
http://crossbrowsertesting.com
CrossBrowserTesting permet lui aussi de tester un site Internet par le biais des différents navigateurs proposés, en réalisant des captures photo et vidéo durant le test. Il se différencie néanmoins de son concurrent en proposant un ensemble de configurations beaucoup plus varié (incluant même certains terminaux mobiles). Il est également possible d’enregistrer l’activité réseau du site testé lors de chaque session, ce qui permet d’évaluer les performances du site sur différents environnements. Les résultats sont retranscrits sous la forme d’un graphique en cascade, de façon similaire à ceux affichés par les inspecteurs de code.
Solution payante, l’abonnement de base proposé par CrossBrowserTesting est de l’ordre de 30 USD par mois. Il est cependant possible de tester le service gratuitement pendant sept jours.
LA VIRTUALISATION

F IG . 3-3 : Cette matrice permet de tester un rendu sur IE (6, 7, 8 et 9), sur Firefox (3.6, 10, 13 et Aurora), sur les dernières versions de Chrome et d’Opera et avec les versions 9, 10 et 11 du player Flash. Pour compléter ce panel, il faudrait y ajouter une distribution Linux.

À mi-chemin entre un parc de machines physiques et les services d’accès à distance, la virtualisation est une solution qui permet de faire cohabiter différents systèmes d’exploitation sur une seule et même machine. Le principal intérêt réside dans le fait d’avoir plusieurs configurations à disposition pour tester une intégration, sans qu’il soit nécessaire de se déplacer, de redémarrer le poste de travail ou d’avoir recours à un service externe.

O UTILS Les logiciels de virtualisation
Pour installer un nouveau système d’exploitation, il est nécessaire de créer un environnement clos (une machine virtuelle) grâce à un logiciel de virtualisation. Les principales solutions disponibles sur le marché sont les suivantes.
VMware : http://bp.inté.net/3-6

  • Accueil Accueil
  • Univers Univers
  • Ebooks Ebooks
  • Livres audio Livres audio
  • Presse Presse
  • BD BD
  • Documents Documents