1. CSS
1.1. Production
1.1.1. Utiliser des techniques trop techniques (que seul le développeur comprend).
1.1.2. Refactoriser, purger le code mort.
1.1.3. Charger via commentaires conditionnels pour IE.
1.1.4. Utiliser les microformats pour poser le style. Il faut utiliser des classes dédiées ; pour éviter de lier fond et forme.
1.1.5. Ne pas prendre en compte l'ordre de chargement des CSS.
1.1.6. Utiliser des hacks.
1.1.7. Utiliser des filtres IE.
1.1.8. Utiliser "expression".
1.1.9. Concaténer les fichiers.
1.1.10. Atomiser les CSS (multi-classes).
1.1.11. Fragmenter à l'extrême (surtout sans concaténer, peut poser problème avec IE qui a une limite à X fichiers).
1.1.12. Préprocesseurs (LESS, SASS)
1.1.13. Utiliser reset.css + typography/base.
1.1.14. Oublier :focus à côté de :hover. Permet de signaler à l'utilisateur l'élément actif alors qu'il navigue au clavier. :hover implique une utilisation de souris ou d'un dispositif de pointage.
1.2. Équipe
1.2.1. IDE (ou éditeur) avec auto-complétion.
1.2.2. Dégradation des CSS par navigateur.
1.2.3. Convention de codage. Indentation, ordre des propriétés, organisation des fichiers etc.
1.2.4. Versionner.
1.2.5. Faire valider le rendu de l'intégration par le webdesigner.
1.2.6. Utiliser un framework/librairie.
1.2.7. Écrire une nouvelle définition systématiquement en fin de fichier. Il vaut mieux respecter la logique de groupement déjà en place.
1.3. Documentation
1.3.1. CSSDoc
1.3.2. Placer des liens pour renvoyer vers des fix ou exemples.
1.3.3. Indiquer les fix pour IE au niveau des déclarations concernées.
1.3.4. Utiliser le même sélecteur de règle pour un fix IE.
1.4. Tests
1.4.1. Prévoir recette finale HTML/CSS avec l'intégrateur.
1.4.2. Validation (W3C, Jigsaw)
1.4.3. Performances (PageSpeed, YSlow)
1.4.4. Gabarits HTML de test
2. HTML
2.1. Production
2.1.1. Zen Coding
2.1.2. Utiliser des patterns existants et/ou reconnus (microformats, microdata, RDFa)
2.1.3. Utiliser des techniques trop techniques (que seul le développeur initial comprend)
2.1.4. Créer des classes HTML "visuelles" (type -left, -right, .redblock, .block214)
2.1.5. Pré-processeurs (HAML)
2.1.6. Gabarits HTML complets (page type)
2.1.7. Framework (Boilerplate)
2.2. Équipe
2.2.1. Consensus d'un IDE commun
2.2.2. Versionning et gestion de projet
2.2.3. Considérer l'intégration comme une intervention ponctuelle. Problème de maintenance et d'évolutions par les dev back
2.2.4. Expliquer / montrer son code aux développeurs. Permet d'effectuer des ajustements en amont et de faciliter leur travail d'intégration, et de donner des directives qui permettront de gagner du temps par la suite.
2.3. Documentation
2.3.1. Conventions de nommage pour les classes CSS
2.3.2. Antisèche sur le projet (??)
2.4. Tests
2.4.1. Validateur HTML (W3C ou ??.nu)
2.4.2. Selenium IDE. Permet de vérifier la génération du back par rapport à la maquette front.
2.4.3. HTML Tidy ; pour vérifier que le code est bien formaté.
2.4.4. Supprimer la visibilité des images, regarder le résultat ; supprimer la visibilité des CSS, regarder le résultat ; supprimer la visibilité du JavaScript, regarder le résultat ; essayer de naviguer. Pour toutes les pages. Permet de tester l'accessibilité.
2.4.5. Outliner (HTML5 Outliner).
2.4.6. Opquast.
2.4.7. Prévoir recette finale HTML/CSS avec l'intégrateur.
3. JavaScript
3.1. Production
3.1.1. Utiliser la délégation d'évènements.
3.1.2. Utiliser la délégation d'évènements sur les évènements de survol ; peut causer des artefacts visuels.
3.1.3. Utiliser e.preventDefault() au lieu de return false.
3.1.4. Ajouter/supprimer des classes plutôt que modifier le style CSS inline.
3.1.5. Gérer la mise en forme.
3.1.6. Intégration non-intrusive (écoute d'évènements).
3.1.7. Écouter les bons évènements (focus en plus de click par exemple).
3.1.8. Masquer en CSS des contenus qui seront affichés en JS. Si pas de JS, on prive l'utilisateur d'une partie du contenu.
3.1.9. Itérer sur des liveElements (à confirmer).
3.1.10. Polluer l'espace de nom.
3.1.11. Ne pas utiliser var (ne pas bien utiliser le scope).
3.1.12. Créer des plugins réutilisables, sous forme de logique métier, plutôt que du code spécifique, hors fonction, non-réutilisable.
3.1.13. Se baser uniquement sur JS pour valider/vérifier un formulaire.
3.1.14. Se fier à JS pour l'aspect sécurité.
3.1.15. Injecter trop de HTML. Mauvais pour la visibilité du DOM et les performances.
3.1.16. Être uber produdent si on étend le DOM.
3.1.17. Minifier.
3.1.18. Concaténer.
3.1.19. Mélanger plusieurs frameworks, redondants de surcroît.
3.2. Équipe
3.2.1. N'utiliser que « The Good Part ».
3.2.2. Penser aux impacts sur la performance.
3.2.3. Connaître JavaScript et pas seulement la librairie (jQuery, MooTools etc.).
3.2.4. Versionner.
3.3. Documentation
3.3.1. JSDoc.
3.3.2. Pour tous les plugins tiers, y adjoindre/conserver un lien vers la documentation.
3.4. Tests
3.4.1. JSLint.
3.4.2. Firebug.
3.4.3. Tests unitaires (QUnit etc.).