Pourquoi est-il (ou était-il) important de séparer CSS de HTML?
Intro
J'ai récemment regardé les diapositives de React: CSS in JS et j'aime vraiment l'idée d'avoir CSS appliqué en utilisant JS (et avec JSX, cela signifierait avoir tout le HTML, JS et CSS dans un seul fichier, ce qui est parfait pour les petits composants réutilisables); Cependant, je m'inquiète des problèmes possibles avec la sémantique/les performances/peu importe, ce qui m'amène à ...
La question
Pourquoi est-il important de séparer CSS de HTML?
Les raisons évidentes auxquelles je peux penser sont d'éviter la duplication et de garder le HTML purement sémantique tout en laissant CSS gérer le style. Je peux faire les deux en JS. Y a-t-il d'autres raisons pour lesquelles je manque?
Edit : J'ai raté une chose très importante ici - je conçois une architecture pour un grand application web, pas un petit truc de blog. Il aura son propre pipeline de construction, avec pratiquement toutes les configurations possibles.
Edit # 2 : Je vois beaucoup d'arguments sur la séparation des préoccupations, dont la plupart sont (à ma connaissance) basés sur l'hypothèse que c'est plus souvent pour changer simplement HTML ou simplement CSS et une fois au lieu de modifier HTML et CSS en parallèle. Bien que cela puisse être le cas pour les petits sites Web, mon historique de validation me montre le contraire - je modifie généralement HTML et CSS ensemble. Donc, au lieu de séparer tout HTML de tout CSS, je séparerais chaque composant les uns des autres.
Je ne vois toujours aucun inconvénient sérieux à faire cela.
- La mise en cache? Chaque fichier de composant peut être mis en cache.
- Sémantique? Je pourrais encore avoir la sémantique en HTML et les styles en CSS, juste dans un seul fichier.
- Réutilisation et maintenabilité? Ce sera encore plus facile avec des composants séparés au lieu d'un tas de fichiers HTML et CSS avec des relations peu claires.
- MVC? Je pourrais avoir mon mini MVC à l'intérieur de chaque composant.
Edit # 3 : FYI all: @keithjgrant a écrit un excellent article de suivi sur cette question: http://keithjgrant.com/ posts/contre-css-in-js.html
1. Pourquoi était est-il important de séparer CSS du HTML?
À l'origine, JavaScript était utilisé pour des animations fantaisistes (et extrêmement ennuyeuses) et les sites Web n'étaient globalement qu'un tas de code HTML et CSS. Côté serveur, les frameworks n'étaient pas aussi nombreux et puissants qu'aujourd'hui.
Cela signifiait que vous aviez le choix:
Soit vous faites une bonne séparation entre le contenu (HTML) et le style (CSS),
Ou vous mélangez les deux, soit en mettant du code CSS dans des fichiers HTML, soit simplement en utilisant des analogues HTML (
<div color="red">I'm red.</div>).
La première alternative vous a apporté deux avantages importants:
Pas de duplication de code, ce qui devient précieux lorsque vous changez la couleur d'un élément couramment utilisé du rouge au violet sur chaque page du site Web, apportant des centaines de changements dans votre base de code au lieu de simplement une,
Utilisation réduite de la bande passante (extrêmement important là où la plupart de vos visiteurs ont 56 Kbps connexion Internet), grâce au cache client,
Capacité hypothétique de changer de style sans toucher au contenu: un point que je discuterai dans la partie 3.
ce qui explique également pourquoi tant de sites Web personnels utilisaient <div color="red">I'm red.</div> style à leurs débuts, et en devenant plus grand et plus populaire, ont été obligés de migrer vers du CSS pur.
2. Pourquoi est est-il important de séparer CSS du HTML aujourd'hui?
Supposons que nous ne sommes pas légalement tenus de rendre notre application Web accessible (car l'accessibilité conduirait inévitablement à une version sans JavaScript), et que l'application utilise déjà largement JavaScript pour ses fonctionnalités principales.
Au niveau du développement:
Séparer contenu de style peut toujours être utile pour la même raison que ci-dessus: duplication de code. Si deux éléments partagent le même style, vous ne devez pas écrire le style deux fois: vous devez le définir une fois, puis le réutiliser. L'écrire deux fois entraîne des problèmes de maintenance trop évidents pour être expliqués.
Notez que peu importe comment stockez-vous le contenu et comment stockez-vous les styles. Le contenu serait en général généré par l'application Web sur la base (1) des données de la base de données et (2) de la logique métier, tandis que le style serait défini sous une forme statique, serait-ce un fichier CSS, XAML ou quelque chose de complètement différent.
Cela conduit au deuxième point: comment ce contenu et ce style sont servis.
Au niveau du client:
Servir du contenu et du style et appliquer du style au contenu peut prendre différentes formes: peut-être un HTML/CSS ordinaire, peut-être une solution complexe impliquant AJAX requêtes, DOM, etc. L'argument précédent de la bande passante n'est pas pertinent ici: non seulement la plupart des utilisateurs ont des connexions 8 Mbps ou plus rapides, mais les requêtes AJAX peuvent également être mises en cache.
Au lieu de cela, le choix de l'alternative serait plutôt basé sur la facilité d'utilisation d'une solution spécifique fournie par un cadre spécifique et sur la facilité avec laquelle le développeur délègue cette tâche au cadre.
Voici une histoire.
Une version d'ASP.NET MVC a ajouté une fonctionnalité appelée bundles. Au lieu de servir vous-même les fichiers CSS et JavaScript, vous avez simplement alimenté le cadre avec ces fichiers et le cadre a fait tout le travail pour vous: il a réduit les fichiers et les a envoyés en tant que fichier unique - un fichier CSS et un fichier JavaScript.
Mais comme tout outil magique, il avait ses limites. Cela a bien fonctionné pour les petits sites Web, et si un jour, ma grand-mère commence à programmer en C # et décide de créer son site Web personnel, je serais la première à la convaincre qu'elle devrait utiliser des bundles.
L'histoire était différente pour les plus complexes. Que faire si je souhaite inclure MOINS de fichiers? Eh bien, il y avait¹ une possibilité de le faire, grâce à l'excellente architecture d'ASP.NET MVC, mais cela signifiait la lecture de dizaines de pages de documentation et la création de dizaines de classes. Je ne sais pas pourquoi je voudrais faire cela, alors qu'une solution bundle-lessn from scratch peut être effectuée en moins d'une demi-heure avec moins de code à écrire.
Même chose pour JavaScript. Puis-je demander à ASP.NET MVC d'utiliser Google Closure Compiler pour réduire les fichiers? Probablement pas facilement, ou du moins pas dans les versions antérieures d'ASP.NET MVC.
Les fonctionnalités du framework sont excellentes et peuvent vous simplifier la vie, mais elles peuvent également être une limitation. Les petits projets personnels peuvent en bénéficier beaucoup. Les grands projets ont tendance à s'appuyer davantage sur des solutions sur mesure, qui sont plus faciles et plus rapides à développer que pour étendre le cadre.
Imaginez que j'ai un excellent cadre qui fait un excellent travail de génération de styles pertinents pour chaque page, de gestion des styles mis en cache, etc. C'est génial, car:
Cela peut réduire encore plus la bande passante: si j'ai 600 styles mais seulement 30 sont utilisés sur la page d'accueil, cela signifie 570 styles de moins à envoyer via le fil et à traiter par le client; les chances sont, ma page d'accueil apparaîtra quelques secondes plus vite.
Cela peut simplifier ma vie et mon code, par exemple en supprimant l'état global. Par exemple, si je sais qu'un style spécifique ne doit apparaître que sur cette page, je peux laisser le framework déterminer quel sélecteur doit être utilisé, sans prendre le risque d'en choisir un qui peut être utilisé sur une autre page.
Maintenant, personnellement, je n'ai jamais vu un cadre qui puisse faire cela, et ceux que j'ai vus semblent trop limités sans me simplifier la vie.
L'écriture de CSS simple est-elle plus facile? Je dirais que oui. CSS a ses points faibles, mais nombre d'entre eux sont résolus par des préprocesseurs tels que LESS et Sass. Pouvoir utiliser les fonctionnalités de LESS/Sass tout en laissant le framework traiter le code en CSS minifié est formidable. Mais je ne suis pas sûr que les outils d'aujourd'hui soient suffisamment mûrs pour passer de cette façon de travailler à quelque chose de plus puissant et abstrait.
3. Séparation des problèmes. C'est ça?
Vous avez mentionné la séparation des préoccupations dans votre question, alors je voudrais souligner cet aspect particulier séparément.
Je vois beaucoup d'arguments sur la séparation des préoccupations, dont la plupart sont (à ma connaissance) basés sur l'hypothèse qu'il est plus souvent de changer uniquement HTML ou simplement CSS et une fois plutôt que de modifier HTML et CSS en parallèle. Bien que cela puisse être le cas pour les petits sites Web, mon historique de validation me montre le contraire - je modifie généralement HTML et CSS ensemble. Donc, au lieu de séparer tout HTML de tout CSS, je séparerais chaque composant les uns des autres.
Lorsque vous changez HTML, vous changez nécessairement CSS dans la plupart des cas. Ce n'est pas comme DAL/BL/PL, où vous pouvez, par exemple, échanger la couche de base de données sans affecter quoi que ce soit d'autre. Si vous changez de contenu, la présentation devra souvent changer.
Par exemple, vous ajoutez un nouveau bouton à un élément. Sans surprise, l'élément est maintenant trop petit, vous devez donc ajuster sa largeur.
En théorie, l'inverse n'est pas vrai: on s'attend à ce que vous puissiez jeter tout votre code CSS et faire quelque chose de complètement différent. Même contenu, présentation différente.
Lorsque Microsoft a publié WPF (une technologie qui alimente les interfaces de certaines applications Windows, ce qui facilite la conception des interfaces et leur applique des styles) et le XAML sous-jacent (un langage utilisé pour décrire à la fois le contenu de l'interface - boutons , listes, zones de liste modifiable - et le style - coins arrondis, polices, transitions), l'un des avantages mis en évidence dans toutes les annonces était la possibilité de styliser l'application indépendamment du contenu.
Microsoft a même créé un outil pour cela. Cela s'appelle Microsoft Blend. Le workflow théorique d'une équipe est le suivant:
Les concepteurs d'interaction réalisent une représentation filaire d'une application sur un morceau de papier.
Les développeurs de logiciels choisissent cette feuille de papier et créent, dans Visual Studio (l'outil de développement numéro un dans le monde de Microsoft), les différentes fenêtres de l'application, en mettant des boutons, des listes et des combos.
Ils donnent ensuite l'application inachevée aux concepteurs graphiques et d'interaction qui ouvrent le code source non pas dans Visual Studio - ce sont des concepteurs, ils n'utilisent pas d'IDE - mais dans Microsoft Blend, qui leur montre non pas le code source, mais une jolie interface où ils peuvent changer visuellement les aspects visuels de l'application: déplacer les contrôles, définir la couleur et la police, ajouter des transitions et des animations, etc. Pendant ce temps, les développeurs finissent d'implémenter les fonctionnalités derrière les boutons, les listes et les zones de liste déroulante.
Nous avons ici:
La même exigence initiale: pouvoir changer de style indépendamment du contenu, avec la possibilité de remplacer complètement la présentation actuelle par une autre.
Même contrainte: si le contenu change, la présentation sera affectée dans la plupart des cas et nécessitera également des modifications.
Bien que Microsoft ait fait un excellent travail avec WPF et XAML, il y a toujours un petit problème: de temps en temps, lorsque vous devez changer de style, vous devez également changer le contenu, ce qui signifie que le flux de travail de l'équipe est plutôt :
Les concepteurs d'interaction réalisent le filaire d'une application sur un morceau de papier.
Les développeurs de logiciels choisissent cette feuille de papier et créent, dans Visual Studio, les différentes fenêtres de l'application, en mettant des boutons, des listes et des combos.
Les concepteurs graphiques et d'interaction et les développeurs de logiciels travaillent côte à côte sur l'interface de la future application, assurant une communication constante, des réunions régulières, etc.
C'est exactement ce qui se passe avec HTML et CSS. En théorie, vous ne devez pas toucher au HTML lorsque vous travaillez sur le style. En pratique, vous ajustez constamment le balisage lorsque vous travaillez sur CSS, car:
Soit un style spécifique est impossible avec le balisage actuel,
Ou le faire avec le balisage actuel nécessiterait trop de code CSS ou produirait un code très sale et difficile à maintenir.
Lorsque vous changez HTML trop souvent lorsque vous travaillez sur CSS, cela peut être un signe que:
Le code HTML n'était pas bien fait en premier lieu.
Le code HTML a été créé "sans style". Les programmeurs expérimentés qui connaissent bien CSS produiront du code HTML qui sera plus facile à styliser. Les programmeurs qui maîtrisent le HTML mais ne connaissent rien au CSS écriront du code qui nécessitera une énorme quantité de changements.
À titre d'exemple extrême, CSS Zen Garden est un cas d'étude intéressant de ce qui peut être fait avec du CSS pur, basé sur un code HTML inchangé qui était à l'origine bien fait.
Dans la pratique, la plupart des sites Web et applications Web sont de l'autre côté: chaque site que je connais qui a été "repensé" visuellement a été complètement changé: CSS différent, HTML différent, JavaScript différent, code-behind différent.
¹ Je pense que le support LESS est automatique dans les nouvelles versions d'ASP.NET MVC.
Le point clé est séparation des préoccupations :
Lisibilité:
Il est certainement plus facile d'ouvrir simplement le fichier qui contient les règles css au lieu de votre énorme fichier HTML à la recherche du coupable. Ainsi, il est plus facile de maintenir votre site Web.
Cachabilité:
Puisque votre code HTML sera différent pour toutes les pages de votre site, mais pas votre CSS, et il serait idiot de les recharger pour chaque page. La séparation des styles CSS dans des fichiers séparés rend le cachable. Ainsi, cela affecte également le temps de chargement de la page (diminuez également le plus de temps de chargement de la page en réduisant le CSS).
Il s'agit de séparation. La séparation de HTML, CSS et JS est nécessaire pour la lisibilité et la maintenabilité. Alors que vous POURRIEZ les mailler tous ensemble pour un petit site, vous ne devriez certainement pas. Lors de la conception, vous devez toujours essayer de rendre le site aussi maintenable et extensible que possible (dans des limites raisonnables).
JS est également trop lourd pour être utilisé régulièrement pour le balisage et les styles. Pour les grands sites, cela réduirait considérablement vos performances.
On pourrait dire que la séparation des codes HTML, CSS et JS conforme le développement Web au modèle-vue-contrôleur-modèle.
De plus, le html, le css et le js sont souvent très enchevêtrés, donc les regarder dans différentes fenêtres peut être assez pratique de temps en temps.