J'ai vu beaucoup d'introductions aux frameworks CSS récemment. J'ai dit quelque chose il y a quelques jours : « Dans mon champ de vision limité, je n'ai rien vu qui puisse vraiment être appelé un framework CSS~ ». C'est peut-être le mien. Le champ de vision est trop petit ou le monde est trop grand. J'ai toujours l'impression qu'il y a encore beaucoup de choses que je ne peux pas voir.
Examinons d’abord un concept avec lequel je suis d’accord :
Le framework peut être divisé en deux types : White-Box et Black-Box.
Les frameworks basés sur l'héritage sont appelés frameworks boîte blanche. La soi-disant boîte blanche est visible et les détails d'implémentation internes de la classe parent héritée sont connus de la sous-classe. Les développeurs d'applications qui utilisent des frameworks en boîte blanche développent des systèmes en dérivant des sous-classes ou en remplaçant les méthodes membres des classes parentes. L'implémentation d'une sous-classe dépend fortement de l'implémentation de la classe parent, et cette dépendance limite la flexibilité et l'exhaustivité de la réutilisation. Mais la façon de résoudre cette limitation peut être d’hériter uniquement de la classe parent abstraite, car les classes abstraites ne fournissent fondamentalement pas d’implémentation concrète. Le cadre de boîte blanche est un squelette de programme et les sous-classes dérivées de l'utilisateur sont des accessoires de ce squelette.
Un framework basé sur l'assemblage de composants d'objets est un framework de boîte noire. Les développeurs d'applications obtiennent la mise en œuvre du système en triant et en assemblant des objets. Les utilisateurs doivent uniquement comprendre l'interface externe du composant et n'ont pas besoin de comprendre l'implémentation interne spécifique. De plus, l'assemblage est plus flexible que l'héritage et peut être modifié de manière dynamique. L'héritage n'est qu'un concept statique au moment de la compilation.
Dans une situation idéale, toute fonctionnalité requise peut être obtenue en assemblant des composants existants. En fait, les composants disponibles sont loin de répondre aux besoins. Il est parfois plus facile d'obtenir de nouveaux composants par héritage que d'assembler de nouveaux composants à l'aide de composants existants. la boîte blanche et la boîte noire seront utilisées simultanément dans le développement du système. Cependant, les frameworks de boîte blanche ont tendance à évoluer vers des frameworks de boîte noire, et les frameworks de boîte noire sont également les objectifs idéaux que le développement de systèmes espère atteindre.
Revenons sur les nombreux frameworks CSS sur Internet aujourd'hui (YUI est appelé « YUI Library CSS Tools » plutôt que « YUI CSS Frameworks »). Combien d'entre eux sont réellement écrits avec le concept de framework, et combien d'entre eux. définissez simplement les classes de base de style. Bien sûr, la compréhension du cadre par chacun n’est peut-être pas la même et vous n’êtes peut-être pas d’accord avec ce que je dis.
Parlons à nouveau du framework CSS. Ce n'est pas que je ne reconnaisse pas l'existence de cette chose, j'essaie de telles choses depuis un an ou deux. Pour les grands sites Web, le développement front-end nécessite une solution. Le cadre est naturellement le premier choix. C'est dommage que ce soit trop loin de moi et que je sois trop faible T_T. Je n'ai besoin que de deux choses :
De quoi gérer le contenu ci-dessous
Classe/Composant
Évidemment, le premier point est que CSS ne peut pas le faire, et le deuxième point est qu’il est très faible par rapport aux autres langages.
Lorsque je travaillais sur un site Web de taille moyenne il y a environ un an, pour être paresseux, j'ai pensé à modulariser le contenu et à laisser les programmeurs assembler les pages. L'orientation générale est d'encapsuler un bloc fonctionnel après l'autre. Les programmeurs n'ont besoin d'utiliser le HTML et le CSS correspondants que lorsqu'ils souhaitent utiliser quel élément de contenu est pratique pour tout le monde. pas besoin de répéter le code Bonjour à tous.
Sur le même site Web, il est normal que des blocs de contenu similaires soient utilisés plusieurs fois. Cela permet également une modularisation, comme une liste d'images, une liste d'avatars d'utilisateurs ou une liste d'icônes de groupe. l'écrire ? Faut-il écrire les mêmes mots comme ça ?
.photoListUesr,.photoListGroup{ /*_*/ }
Cela ne veut pas dire que c’est impossible, mais que se passe-t-il si vous souhaitez soudainement en ajouter un similaire à ce stade, vous devrez peut-être ajuster le style ? Et moi ? J'ai essayé de l'utiliser comme ceci :
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
Dans ce cas, nous séparons les expressions courantes depuis le début, utilisons .photoList comme prototype et traitons les détails via des classes supplémentaires. Il y a quelques jours, j'ai écrit sur la programmation XHTML et CSS orientée objet. En fait, je n'en ai écrit que la moitié. L'autre moitié était constituée d'exemples détaillés, mais je ne l'ai pas terminé car je devais faire trop d'exemples. core a déjà été écrit ^^ Bien sûr, cela pose également certains problèmes, c'est-à-dire que la définition du prototype initial doit être très prudente et essayer de garantir que même s'il est révisé à l'avenir, il n'aura peut-être pas besoin de l'être. modifié. Avec CSS, un framework ne peut s'adapter qu'à un seul site Web au maximum. Bien sûr, si le site Web est suffisamment grand, il est logique de l'utiliser de cette façon.
Plus HTML et CSS deviennent modulaires, plus les fichiers sont fragmentés et plus ce problème devient grave. Le HTML est facile à gérer, puisque l'application finira par fusionner et produire une copie, mais le CSS est généralement ignoré et utilisé directement. Si dans l'exemple de tout à l'heure, la façon d'importer du CSS dans la page Web est la suivante :
@import url(/xxx/photoList.css);
@import url(/xxx/UserCt.css);
@import url(/xxx/GroupCt.css);
Vous pouvez même envisager d'utiliser un programme pour combiner des pages, mais il est simple à utiliser et proportionnel au nombre de requêtes. Généralement, tout le monde choisira de fusionner les fichiers manuellement. Bien que le cerveau humain soit plus intelligent qu’un ordinateur, dans de nombreux cas, sa puissance de calcul n’est pas aussi bonne que celle d’un ordinateur. J'ai eu une fois l'idée d'utiliser un programme côté serveur pour gérer le mécanisme de publication CSS. L'orientation générale est d'analyser l'utilisation de différentes pages de l'ensemble du site via les journaux d'accès au site Web et d'utiliser le programme pour calculer les utilisations publiques. doivent être fusionnés. L'ordre (l'ordre des fichiers CSS affectera la priorité), etc. Divers calculs et sortie compressée.
Malheureusement, un programme aussi complexe peut ne convenir qu'à une seule station ou à un groupe de stations d'une même série. Bien que ce soit un peu difficile à faire, je pense qu'il est nécessaire d'utiliser cette méthode pour les sites Web au niveau du portail. Bien entendu, le principe est que toute l'équipe doit utiliser le même modèle de conception.
PS : Le programme de publication CSS ci-dessus n'est que mon fantasme. Je ne l'ai pas encore essayé. Les amis intéressés peuvent l'essayer. En cas d'accident, je ne serai pas responsable.
Bien sûr, ce qui précède ne peut pas être appelé CSS Frameworks, peut-être ne peut-il être appelé qu'une solution au niveau du système. Après tout, CSS n'est qu'un langage descriptif.
Hier soir, lorsque je mangeais du canard rôti avec Yueying, nous en avons parlé et il m'a demandé si j'avais une solution frontale intégrée. Le même problème se posera lorsque JS sera composant, et des mécanismes de publication similaires devraient également être applicables à JS. Mais je n'ai pas encore pensé à une solution complètement intégrée. Peut-être que Yueying m'offrira encore quelques fois du canard rôti et que je pourrai le comprendre.