tips & tricks

 Des « Best Practices » : pourquoi ?

• Vous donner un aperçu, chers Clients, de la manière dont le maçon va construire votre maison
• Vous assurer que nous avons un référentiel commun
• Standardiser les projets par une méthode éprouvée et pérenne
• Démontrer que nous prenons au sérieux la notion de Qualité.

Ces bonnes pratiques sont le fruit d’une décénie d’expériences accumulées sur plus de 300 projets, de veille technologique, et d’échanges entre collègues, collaborateurs, clients, concurrents. Cet article est régulièrement mis à jour.

Il n’est pas question de les substituer à votre cahier des charges. Mais comme 99% des projets démarrent sans charte d’intégration, voici comment vos livrables seront codés en standard.

 Règles d’or

Validation W3C, oui mais...

Notre markup est toujours valide (X)HTML/CSS. Notez cependant que certaines exigences génèrent des erreurs, par exemple :

• Si vous demandez des iframe
• Si vous insérez du code externe (comme les appels aux "embed" vidéo YouTube, boutons "Like" Facebook)
• Si c’est pertinent : qui voudrait charger tout un framework javascript et une librairie externe si un simple "onLoad" (qui ne valide pas) fait le job en une ligne ?

Le validateur CSS retourne souvent des avertissements, par exemple :

• La même couleur est utilisée en tant que couleur et couleur de fond
• Vous n’avez pas de couleur de fond définie avec votre couleur
• Vous avez des longueurs absolues et relatives
• Vous êtes encouragés à proposer une famille générique comme dernier choix

Ces messages ne signifient pas que le code soit invalide ni qu’il doive être obligatoirement corrigé.

DRY (Don’t Repeat Yourself)

Le temps c’est de l’argent alors évitons les redondances de code :

• En CSS, mutualisons les déclarations autour de plusieurs propriétés
• En JS, privilégions la programmation procédurale (objets, fonctions) à la programmation séquentielle
• En jQ, faisons appel aux fonctions en utilisant les sélecteurs multiples

Parfois (ex. mise à jour d’ancien projet) dupliquer le code permet de réaliser en 30 minutes une tâche qui nécessiterait 2 heures pour être factorisée. Tiraillé entre les Bonnes Pratiques et la rentabilité, je vous laisserai le choix...

/* No comment */

Le code doit tojours être indenté et commenté :

• Pour faciliter la compréhension entre les équipes lorsque le dév back n’est pas réalisé par le dév front
• Pour permettre la communication entre ces équipes, en insérant un nameblock en en-tête
• Pour diminuer le temps d’adaptation lorsque nous faisons évoluer d’anciens projets
• Pour regrouper les fonctions de code par secteur (ex. : /* Styles du menu de navigation principale */). Ce n’est pas parce que le code est parfois self-explainative qu’il ne doit pas être rangé !

Les commentaires ont aussi vocation à rendre le code lisible et son parcours cohérent, voire agréable. Pour que cela soit efficace il est nécessaire d’en harmoniser la rédaction, aussi utilisons-nous des outils adaptés :

Inspiré de JavaDoc et PHPDoc, CSSDoc permet de générer les blocs faciles à lire :

Ex. : En-tête d’une feuille de style

Ex. : Nouvelle section dans la feuille de style

Lorsque cela est pertinent, explications sur @bugfix et @workaround

Pour le javascript, JSDoc est utilisé :

En matière de commentaires HTML il s’agit plus souvent de jalonner le code de repères de lectures que de donner des explications fonctionnelles.

Nous utilisons la syntaxe auto-générée du Zen coding :

Notre leitmotiv : rester organisés. Nous parsemons donc le code de plusieurs lignes séparatrices et de blocs de commentaires servant à se repérer. Le code fonctionnel peut prendre des formes raccourcies (ex. : syntaxe abrégée d’un if) mais nous nous évitons les blocs de JS massifs. Pour le code de présentation, les single line CSS (1 ligne par déclaration) sont bannies (c’est illisible), sauf s’il s’agit du format d’origine d’une CSS externe (ex. : CSS issue d’un plugin).

Je ne crois pas qu’il soit approprié d’économiser quelques octets en serrant tous les blocs et se limitant dans les commentaires. En terme d’optimisation, nous préconisons l’utilisation par les dév back de compresseurs tels que JSMIN et YUI Compressor, nettement plus efficaces et pouvant être appelés à la volée !

 Conventions HTML

Doctypes

Nous utilisons de préférence le doctype XHTML 1.0 strict

Les développements démarrés en HTML5 s’inspire du HTML5 Boilerplate :

Les newsletters héritent en général d’un doctype XHTML 1.0 transitional :

Charset

Sauf demande expresse, tous les fichiers sont en UTF-8.

Métas

Dans la mesure du possible, nous essayons d’intégrer les balises meta minimales : titre, description, et depuis peu celles utilisées par Facebook en version standard ou OpenGraph. Plus de détails dans notre article consacré à ce sujet.

Favicon

Si le fichier est fourni, nous l’appelons avec :

Convertir un .png en .ico avec ConvertIcon

Styles et scripts

• Les styles sont appelés dans le head à l’aide de la balise link
• Les scripts sont appelés de préférence avant la balise </body>

Server-Side Includes (SSI)

Sur les projets imposants il est pertinent d’inclure une partie d’un fichier (ex. : header.html) dans une page utilisant SSI (ex. : homepage.shtml).

Cela facilite la lecture du code par les équipes front et back, respecte notre moto DRY (Don’t Repeat Yourself) en évitant les redondances, accélère les itérations, respecte la norme SGML sans nécessiter PHP (plus d’infos sur les SSI).

Ex. : homepage.shtml

Pour autoriser l’exécution des SSI dans l’hôte Apache (MAMP), on doit ajouter quelques lignes dans le .htaccess :

Lire la doc Apache SSI

Structure de page

Première partie directement inspirée des Bonnes Pratiques de l’agence Upian :

Dans la mesure du possible, les pages comprenant les éléments standards définis ci-dessous doivent suivre la dénomination appropriée, au niveau du nommage des identifiants.

Certains de ces éléments sont définis dans l’ébauche actuelle du futur HTML 5 à laquelle il est conseillé de se référer pour des exemples d’utilisation.

• wrapper – destiné à contenir d’autres éléments
• nav – menu de navigation principal
• subnav – menu de navigation secondaire
• search – bloc contenant le champ de recherche
• q – champ de recherche principal
• article – section de contenu
• sidebar – barre de côté
• header – en-tête de page
• footer – pied de page

Exemple de structure basique de page :

Seconde partie : conventions liées au balisage sémantique et optimisations SEO

Nous ne reviendrons pas sur l’utilisation évidente des usual suspects que sont h1-6, p, alt etc.

Pour faciliter le theming, notamment dans le cas où les pages doivent être transformées en thèmes pour WordPress, Drupal ou autre CMS, nous appliquons des classes génériques sur certaines éléments en suivant les recommandation d’implémentation du W3C sur les pseudo-classes (qui ne sont hélas pas suffisamment supportées).

Ex. : Utilisation de first et last dans une liste

Lorsque cela est pertinent, nous préférons l’utilisation des listes de définition par rapport aux listes énumératives ou à la multiplication illisible des div :

Exemple issu de pompage.net :

Enfin, les formulaires comportent des tags fieldset, label, et les types de boutons appropriés.

 Conventions CSS

Généralités

• Remise à zéro des styles avec le Reset Reloaded d’Eric Meyer
• Blocs flottants ajustés grâce au Clearfix (d’autres expérimentations sont en cours, chez Nicolas Gallagher par exemple. Nous en suivons l’évolution...)
• La syntaxe "shorthand" est privilégiée
• Les font-size en pixels sont privilégiés

Pour les projets HTML5

• Les styles hérités du HTML5 Boilerplate sont utilisés en sus

Pour les projets mobiles (sites BlackBerry, Android, iPhone, iPad

• Nous précisons les règles d’utilisation des viewport (balise permettant de définir les règles de (re)dimensionnement d’une page sur les écrans mobiles)

Pour les newsletters

• Utiliser le moins de CSS possible, au profit des balises font (à placer dans des table bien entendu...). Les reset et clearfix ne s’appliquent pas.
• Le CSS se déclare inline
• Utiliser quelques hacks comme évoqué précédemment dans cet article
• Il est de bon aloi que le Client se renseigne sur les tendance directement chez de vrais spécialistes (comme Campaign Monitor ou MailChimp, qui sont autrement plus utiles que Nielsen et le JDN). On apprend par exemple dans cet article que l’utilisation de règles CSS3 permet d’adapter le layout d’une newsletter pour les périphériques mobiles, bien entendu cela demande un travail de conception et de design en amont de la phase d’intégration.

Techniques modernes

• Avec votre accord, le parc informatique se régénérant petit à petit, nous privilégions CSS3 pour les ombrages, arrondis, ombres de textes, dégradés. Voir la liste des propriétés prises en charges selon les versions des navigateurs
• Les textes dans des polices spécifiques sont de préférence intégrés à l’aide des propriétés font-face générées par FontSquirrel, au détriment des images-textes fort peu pratiques. Voir la comparaison des systèmes de font-replacement.
• Il est de bon aloi que le Client briefe ses créatifs sur l’utilisation des systèmes de grilles, par exemple 960.gs ou encore Blueprint, qui accélèrent considérablement la phase d’intégration.

Hacks

• Nous utilisons de préférence des feuilles spécifiques appelées grâce aux commentaires conditionnels, par exemple :
  <!--[if lte IE 8]> <link rel="stylesheet" href="css/ie.css" type="text/css" media="screen,projection" /> <![endif]-->

• Cependant certains projets ne nécessitent que très peu d’adaptations. Il nous apparaît alors opportun d’utiliser 2 ou 3 hacks parmi plusieurs centaines de déclarations, que d’alourdir le code html en commentaires + ajouter un hit par page.
• N’oublions pas par ailleurs que d’autres navigateurs nécessitent parfois des hacks
• Le bug des PNG transparents sous IE6 est résolu (au mieux) avec l’adjonction du script DD_belatedPNG

 Conventions JS

• Les développements sont réalisés à l’aide du framework jQuery (dernière version systématiquement)
• Dans la mesure du possible, les widgets et effets seront issus de jQuery UI
• Utilisons les sélecteurs multiples afin d’éviter la redondance du code

 Arborescence type

• .htaccess contient un fix de header pour les fichiers fonts sous FF
• /css
  • ie.css styles spécifiques IE
  • tools.css reset css, clearfix, contraintes extérieures
  • main.css styles propres au projet
• /fonts
• /images éléments d’interfaces. On privilégie le PNG.
  • bg_xxx (_left right top bottom)
  • btn_xxx (_active _inactive _hover)
  • header_xxx
  • ico_xxx
  • nav_xxx
  • picto_xxx (_ffffff_ltr _000000_rtl ff0000_ttb 0000ff_btt)
  • text_xxx
  • title_xxx
• index.html liste des gabarits / numéro de version ou date / changelog (si applicable)
• /js
  • /lib
    • jquery.js dernière version minified
  • /vendor
    • Plug-ins
  • main.js
• robots.txt livré par défaut avec Disallow: / afin que le site de dév ne soit pas indexé par erreur...
• /temp visuels utilisés pour le montage, qui seront remplacés dynamiquement lors du dév back (ex. : thumbnails des articles)

 FAQ Procédures et tests

Pour une bonne compréhension de notre workflow, un nouvel article est en cours de rédaction : Environnement de travail sous Mac pour développeur web

• Comment un projet démarre-t-il ?
  Avec une réunion, un brief, un bon de commande

• Partez-vous de zéro ?
  Non, nous utilisons une matrice par type de projet (projet XHTML, projet HTML, projet Mobile, projet Newsletter...). Cette matrice inclut notre Arborescence type (cf. ci-dessus) et un certain nombre d’éléments de base énumérés ici même. Les matrices évoluent très souvent, et elles sont versionnées. Cela vous garanti de toujours bénéficier des dernières innovations que nous mettons en œuvre dans l’ensemble de nos projets.

• Votre intégration est-elle "pixel-perfect" ?
  Oui, nous plaçons temporairement un JPG de votre page en background ou en overlay et construisons le layout de la page en accord. Notez que les maquettes reçues comportent parfois des incohérences qu’il nous faut corriger (exemple : interlignes inconsistants dans un même paragraphe, texte qui déborde des cadres à cause d’un mauvais calage, superposition hasardeuse de plusieurs transparences...)

• Dans quelle langue sont intégrés les fichiers ?
  Par défaut : noms de classes, blocs, images, etc. en anglais (ex. : #header, #search, .column, .post)
  Contenu précis d’une page : adjonction de la langue d’origine (ex. : title_h1_nos_offres_speciales.png)
  Lowercase privilégié
  Séparateur underscore privilégié
  Nous savons intégrer, stocker, manipuler, afficher les contenus en caractères non-latins (cyrillique...) et lus en RTL (right-to-left) (hébreu...)

• Comment puis-je voir l’avancée de la programmation ?
  Les livrables sont envoyées à chaque "milestone" sur nos serveurs de test, pour lesquels nous vous confions un accès.

• Comment vais-je obtenir les livrables ?
  Au choix :
  • Upload sur votre ou notre serveur FTP
  • Commit sur votre ou notre serveur Git
  • Par mail
• Comment sont testés les sites ?
  Nous disposons d’une machine virtuelle PC par version de navigateur (une pour IE6 + FF3 + Safari 4, une pour IE7 + FF4 + Opera 9 + Safari 5, une pour IE8, une pour IE9, etc...).
  Nous développons sous Mac avec : la dernière version de Safari, la dernière version de Chrome, la dernière version de Firefox, la version 3.6 (legacy) de Firefox.
  Nous pouvons également tester vos développements sous les dernières versions de iOS (iPhone/iPad) et Android (HTC) et d’autres navigateurs ésotériques, comme AOL, Konqueror, et même Lynx.
  Nous pouvons inclure des copies d’écran du rendu de chaque page dans chaque navigateur (à réserver aux milestones important, car c’est une tâche chronophage et nous facturons au temps passé).
  Les modalités précises de test et rendu sont définies explicitement pour chaque projet dans le bon de commande.

• Comment sont testées les newsletters ?
  Physiquement (pour le dév) : Apple Mail, Outlook 2007, Outlook 2010, Gmail, iPhone, Android.
  Par un service de screenshots à distance (pour la validation) : à votre demande, une 30aine de mailers sont disponibles chez Campaign Monitor et Litmus App (des frais supplémentaires s’appliquent)

• Comment sont testés les développements mobiles ?
  BlackBerry : des machines virtuelles faisant tourner les émulateurs officiels (RIM) de la gamme BB de votre choix. Quelques mobiles physiques disponibles (Bold et Curve). iOS et Android : directement sur mobile HTC, iPhone ou iPad (généralement dernière ou avant-dernière version de l’OS).

 Versionning et mise à dispo

Nous utilisons Git pour le versionning. Les livrables sont à votre disposition via :

• Repository Git privé
• Zip download privé
• URL "live" de test pouvant être protégé par .htaccess

Les URLs seront prochainement à votre disposition dans notre "Espace client" flambant neuf...

 Éléments nécessaires au démarrage de la production

• Avant tout : un bon de commande
• Maquettes : PSD RVB 72 DPI avec calques. Si vous utilisez un profil colorimétrique, veuillez l’inclure au fichier afin d’éviter les différences de teintes.
• JPG de contrôle : merci de joindre à vos PSD un JPG des pages/états.
• Achat d’art : images Fotolia, Corbis, etc. à inclure dans le PSD (et non en externe) afin d’éviter toute différence de recadrage, colorimétrie, etc.
• Polices : TrueType ou OpenType. Les "valises de polices" (type Adobe ATM (Type Manager), Adobe AFM (Front Metrics) ne peuvent être converties pour raison légales. De même, les polices PostScript peuvent être protégées contre l’importation.
• Textes : de préférences en Word ou PowerPoint, à défaut nous utilisons ceux du PSD ou du "Lorem ipsum" (faux-texte)
• Toute information technique issue de votre client est la bienvenue !

J’espère que la mise à plat de cette méthodologie vous aura convaincu de travailler avec moi.

En cous de rédaction : « Best Practices dév back : PHP/MySQL »