Comment puis-je écrire du HTML, du CSS et du JavaScript pour faciliter le travail des développeurs principaux?

Lorsque je reçois un dessin d'un concepteur, je l'obtiens sous forme de fichier PSD (Photoshop). Je m'attends toujours à des noms de couche et de dossier corrects, essentiellement un PSD propre et géré. À partir de cette conception, je développe du HTML, du CSS et du JavaScript et je les livre aux développeurs back-end. Pour leur faciliter la compréhension, je

• écrire du code sémantique,
• conserver JavaScript et CSS dans des fichiers externes,
• ajouter des commentaires utiles dans les fichiers HTML, CSS et JS,
• utiliser des sprites CSS (bien que les développeurs ne l'aiment pas),
• utiliser la plaque de chaudière HTML5,
• utilisez jQuery pour JavaScript,
• essayez d'utiliser de nouvelles balises HTML5 et CSS3 autant que possible et
• envoyé un fichier Zip contenant le HTML, CSS, JS et les images.

Je m'attends à ce que si de petits changements doivent être apportés à la mise en page, les développeurs peuvent gérer cela.

J'aimerais entendre des développeurs back-end et d'autres ninjas CSS ce que l'on pourrait faire de plus en termes d'organisation de fichiers et de balisage pour faciliter l'intégration avec les systèmes back-end (ie technologies back-end, PHP, .NET , Ruby, etc.) Différents clients utilisent différents systèmes.

Beaucoup de ces réponses vont couvrir de larges pans d'idées, mais voici mes idées personnelles:

• Laissez de la place dans la conception du formulaire pour les messages d'erreur.
• Ne mettez pas d'étiquettes dans les zones de saisie!
• Mettez votre CSS et JavaScript dans un fichier séparé, à moins que vous ne sachiez ce que vous faites et que vous vous sentiez mal à ce sujet.
• Gardez les éléments de conception identiques entre les pages. C'est exaspérant lorsqu'un composant de conception (comme une boîte "récemment consultée") a un balisage différent sur chaque page.
• Ne faites pas ce qui est facile pour vous, faites ce qui est bien. <button>les balises sucent. backround-imagepour des choses qui devraient vraiment être <img>nulles.
• Assurez-vous que si vous créez un composant de page, il peut évoluer. Je sais que la plupart des bons développeurs frontaux font cela, mais j'ai eu de nombreux cas où quelqu'un a utilisé une seule image dans ce qui aurait dû être une situation de plafond supérieur / inférieur. Les programmeurs n'aiment pas ouvrir Photoshop.
• Relisez vos modèles. Les programmeurs (bons) sont des gens dévoués et soucieux du détail. S'ils commencent à voir des problèmes dans votre conception (peut-être que la navigation dans le pied de page comporte des fautes d'orthographe ou une orthographe incohérente), cela leur fera poser des questions et ralentir leur travail.

Enfin, et peut-être le plus important:

• Apprenez les conventions de base du langage en cours de développement dans le back-end. Être capable de regarder un modèle PHP et de comprendre la syntaxe de base derrière une foreachou une ifinstruction et comment formater une echoinstruction ou déplacer une <?php ?>balise augmentera considérablement votre valeur en tant que développeur frontal - J'aime quand un développeur frontal a besoin pour faire un changement simple et peut le faire dans le modèle au lieu de me remettre un nouveau zip de tous leurs fichiers.
• En complément, apprenez à utiliser un logiciel de contrôle de version. Vous n'avez pas besoin d'être un expert, mais si je peux regarder un diff au lieu d'avoir à essayer de comprendre ce qui a changé entre deux fichiers zip, cela rend mon travail cent fois plus facile.

Ce ne sont que quelques-uns - je suis sûr qu'il y en a beaucoup plus, mais si vous accomplissez tout cela, vous êtes sûr de gagner le respect et l'appréciation de celui qui transforme vos modèles en site Web.

Les choses évidentes auxquelles je peux penser qui faciliteraient la vie d'un gars de back-end sont la simplicité de comportement. Lorsque vous concevez des éléments d'une page Web qui ont différents comportements (roll-over, menus, etc.), tous ces comportements doivent être standardisés de manière courante afin que le développeur n'ait pas continuellement à revenir à un graphique pour déterminer quelle fonction il doit appeler pour qu'une page se comporte.

Les grilles ne doivent pas nécessiter de manipulation cellule par cellule des données ou des fonctionnalités. Les éléments de bloc des pages doivent être facilement définissables comme éléments communs afin de pouvoir être facilement segmentés dans le code derrière. Cela aidera le développeur à réutiliser le code et / ou à faciliter la communication entre les différentes facettes de la page.

Les zones de la page ne doivent pas traverser des limites de conception spécifiques. Les éléments d'un élément ne doivent pas empiéter sur les éléments d'un autre élément.

Il arrive un moment, cependant, où vous ne pouvez tout simplement pas éviter de faire sauter les développeurs à travers des cercles brûlants. Certains éléments d'interface vont être difficiles à construire de par leur nature même.

Notez que parfois, vous devez faire un choix entre faciliter la modification d'une solution pour un développeur principal et faire quelque chose d'optimisé.

Les sprites CSS que vous avez cités en sont un bon exemple. Je ne comprends pas comment quelqu'un peut créer un site Web lorsque l'évolutivité et les performances sont importantes et avoir des liens vers 100 images, 5 CSS et 15 fichiers JavaScript de chaque page. En revanche, les sprites CSS ne sont pas faciles à entretenir, et de légères modifications dans la conception peuvent nécessiter beaucoup de travail.

Par exemple, si vous avez trois icônes d'état, l'une en dessous de l'autre, et que vous devez ajouter un quatrième état, ajoutez-vous la quatrième icône au bas de l'image, séparément des trois autres? Ou vous l'ajoutez après la troisième icône, en déplaçant tout le reste vers le bas pour avoir un espace vide pour cela?

La même chose vient avec la combinaison et la réduction des fichiers CSS et JavaScript. Vous devez le faire pour un site Web d'une certaine envergure, mais cela nécessiterait des efforts supplémentaires.

C'est exactement la même chose pour CDN. Vous devez l'utiliser pour les grands sites Web, mais les modifications seraient plus difficiles à effectuer. Par exemple, si vous avez modifié un fichier CSS, vous devez forcer les navigateurs à télécharger le nouveau, en modifiant l'URI du fichier en cdn.example.com/g.css?r=2, puis cdn.example.com/g.css?r=3, etc.

De plus, «plus facile» est relatif . Voir, par exemple, les directives pour écrire du code CSS: personnellement, je préfère un style par ligne, sans espace:

#TopMenu a{text-decoration:none;color:#fff;padding:5px 10px;float:left;}

alors que la plupart des gens détesteraient cette syntaxe, et préféreraient celle que je déteste et que je trouve difficile à lire (non, je ne suis pas fou):

#TopMenu a
{
    text-decoration: none;
    color: #fff;
    padding: 5px 10px;
    float: left;
}

De la même manière, l'utilisation de jQuery ne signifie pas que vous faciliterez la tâche du développeur principal pour modifier vos fichiers, car certains développeurs sont plus expérimentés avec Prototype ou d'autres frameworks.

Dans tous les cas, une documentation détaillée est utile, si le développeur veut la lire (la plupart d'entre eux ne le font pas). Vous pouvez également faciliter la vie d'un développeur en demandant précisément au développeur spécifique comment il préfère les choses à faire, et en travaillant côte à côte au début, tout en construisant un cadre (par exemple en concevant le flux de travail à utiliser pour minimiser et combiner les fichiers).

Le meilleur de tous les mondes est lorsque le concepteur ne lance pas un fichier zip sur un mur et travaille réellement dans le projet en tant que développeur. Nécessite un peu de prise en main pour la configuration, mais c'est vraiment génial quand il n'y a pas de traduction entre la conception et le développement et que tout le monde peut participer aux mêmes itérations. Si vous avez un bon processus agile sans friction, il n'est pas trop difficile de le réaliser.

Je me contenterais dans la plupart des cas pour les concepteurs travaillant d'une manière contrôlée par la version et utilisant cela comme mécanisme de distribution. Je ne veux vraiment pas gérer un gros fichier zip à chaque fois qu'il y a un petit changement.

La flexibilité pour vous est généralement la flexibilité pour eux. Toutes ces meilleures pratiques que vous suivez sont des gains des deux côtés de l'application.

Un point critique et souvent manqué, cependant, est l'écriture d'une interface utilisateur robuste. Beaucoup trop de composants d'interface utilisateur sont trop ancrés dans un contexte ou un ensemble HTML trop exigeant et ils ont mis en place CSS pour échouer.

Si vous avez une liste déroulante, par exemple, il est beaucoup moins difficile pour JS d'ancrer un composant de chute en position absolue à l'intérieur d'un conteneur cliqué de jeu relatif (pas de coordonnées nécessaires) que de retirer le marteau JQuery et d'obtenir les coordonnées pour le survoler. sur l'élément et il suffit de le coller en place. Il est également beaucoup moins susceptible de se briser dans les cas où la page se déplace ou si une nouvelle fonctionnalité de navigateur désactive les informations de positionnement. Plus vous comptez sur les compétences HTML / CSS pour éviter le travail JS, plus votre interface utilisateur sera généralement robuste.

En règle générale, j'essaie de m'assurer que la seule chose dont mes composants d'interface utilisateur ont besoin est une balise HTML pour vivre avec un ID ou une classe appropriée. Plus vous pouvez faire de choses avec ce conteneur sans que l'interface utilisateur ne se casse ou avec le conteneur qui s'adapte comme l'expansion / la réduction pour s'adapter à l'évolution des dimensions du conteneur, plus il peut être facilement implémenté sur n'importe quelle partie de l'application sans avoir besoin d'un côté client expert. Tout ce qu'ils ont à faire, c'est de coller une classe dessus.

Préférez la délégation d'événements sur les conteneurs d'interface utilisateur à l'attribution directe d'écouteurs aux nœuds de point de terminaison comme les boutons. Ce composant d'interface utilisateur peut fonctionner avec du HTML statique maintenant, mais vous ne savez jamais quand quelqu'un voudra pouvoir extraire et réécrire le HTML à l'intérieur avec innerHTML ou quelque chose. Si le conteneur est intact et que tous les événements sont délégués (voir la méthode jquery 'on'), vous n'avez pas à vous en soucier et ils pourraient ne jamais apprendre à la dure que le remplacement de HTML interrompt les écouteurs.

Dans l'intérêt de conserver la délégation en option, n'utilisez stopPropagate que sur les noeuds finaux et envoyez des messages de haine aux développeurs de framework idiots qui les spamment partout.

En ce qui concerne la mise en page, gardez le HTML minimal, sémantique et évitez les wrappers div. Moins il y a de code HTML, plus les problèmes de mise en page sont faciles à diagnostiquer pour les débutants.

Utilisez des noms de classe explicites pour l'utilitaire CSS. Une classe "ligne" est probablement plus claire pour les noobs CSS que "clearfix".

Donnez toujours des éléments sectionnels uniques, des identifiants uniques. Cela permet d'identifier plus facilement où se produisent des éléments spécifiques à une section, il est plus facile de remplacer des éléments, et il peut également s'agir d'une victoire JS de lisibilité et de performances.

De toute évidence, c'est une mauvaise nouvelle d'être excessif avec un schéma de classes, mais plus un développeur principal peut définir simplement en ajoutant les bonnes classes aux choses, plus il sera facile pour eux d'apporter des modifications à la page existante.

Et bien sûr, au début du projet, amenez-les à s'entendre sur au moins cette chose: la connexion arrière et frontale via HTML et JSON uniquement. Ne les laissez pas utiliser des choses qui "écrivent le JavaScript pour vous!" C'est un bordel sanglant et un cauchemar d'entretien.

Comme pour tout ce qui concerne le développement, préférez SEC et minimalisme.

Cela ne me laissera toujours pas commenter (si stupide) mais comme note personnelle, je mentionnerais, je travaille dos à dos avec un codeur PHP tous les jours (ainsi que pour l'aider dans son travail) et l'outil le plus simple que nous ayons trouvé est pour utiliser la boîte à outils de Komodo et répertorier les variables "transférées" de chaque vue / contrôleur / modèle dans la boîte à outilsx, de sorte qu'à tout moment, si je cherche à concevoir une page autour d'un ensemble de données envoyées à cette page, je peut regarder dans la boîte à outils et voir exactement quelles données sont envoyées et quel "type" "elles sont envoyées en tant que, et vice versa de son côté. Juste un conseil.