La réponse à la question de départ dépend du contexte: un site graphiquement simple de 5 pages ne sera pas développé de la même manière qu'un site portail développé par 3 intégrateurs et maintenu par 10 développeurs
Celui qui utilise le Reset CSS d'E. Meyer (
billet de blog de Cygnus qui parle du sujet) fera un copier-coller du fichier reset.css dans son projet et ouvrira une nouvelle feuille de style sans toucher une ligne de reset.css: le jour où il veut modifier 3 lignes de reset.css, il n'aura qu'à remplacer les fichiers par une nouvelle version sans même les ouvrir ... et passer 1 journée à traquer les effets de bord sur ses vieux projets sur 6 navigateurs ... mais c'est une autre histoire
Idem pour les frameworks CSS (Yahoo grid CSS, etc): ils constituent une base de travail appelée en premier puis là-dessus viennent se greffer les CSS du site (un ou plusieurs autres fichiers).
HTML et CSS permettent de séparer contenu et forme; on peut vouloir séparer en plus:
- typographie et design graphique (colonnage, images, couleurs)
- par famille de gabarits (quand on a 30 gabarits à intégrer: la homepage, les pages principales, les pages de contenu, les formulaires complexes, la recherche, les pages bien graphiques qui ressemblent pas aux autres, etc),
- la charte graphique "qui changera jamais" (header, footer, menu de gauche) de ce qui change de temps en temps (une boutique de mode et ses 2 collections annuelles) de ce qui change souvent (site événementiel) de ce qui sera affiché 24H seulement (allociné ou dailymotion qui se mettent aux couleurs de son annonceur pour 24H ou bien 1er avril et jour de noël)
- sur un site archi-modulaire, une feuille de style par bloc ce qui facilite la réutilisation de chaque bloc dans n'importe quel type de page (
exemple d'un client, à voir avec Firebug ou WDT pas dans le code source directement)
- pendant le développement au moins, un fichier par intégrateur minimum vu que les fichiers ouverts simultanément par 2 personnes et sauvegardés tour à tour sont pas gérés par les OS. Du moins si on n'utilise pas Subversion et SVN ou si on se sert de ces derniers comme sauvegarde, pas avec des commits venant de partout toutes les 5 secondes.
- pour la localisation et l'internationalisation, gérer les écritures de droite à gauche et gauche à droite avec ce qui est commun ou différent à ces deux sens d'écritures (mise en forme, images inversées ou pas, fontes, typographie, largeur des colonnes selon les écritures en allemand ou finlandais vs anglais), gérer les différentes langues (fonds avec du texte à traduire ou localiser des éléments nationaux genre un big mac pour les usa et une baguette pour les français
)
Un fichier de plus de 3000 lignes, ça commence à devenir lourd (à gérer) sur la fin d'un projet (autant le découper pendant le développement et réunir les morceaux avant la mise en production) et à l'autre extrême avoir 5, 10, 20 fichiers ouverts c'est pas non plus évident à gérer, non pas quand on intègre mais quand on traque une régression ou que l'on applique une modification sur X anciens gabarits).
Il faut de plus séparer la phase de développement de la phase de production (des outils et scripts persos peuvent concaténer les fichiers automatiquement, les compresser/minifier, etc) et avoir 20 fichiers en dév mais 1 ou 3 en prod.
Il faut donc anticiper autant que possible les besoins: nombre de personnes impliquées et comment elles vont communiquer (le bureau à côté ou des échanges 2 fois par jour), taille et nature du projet, contraintes du CMS, choix d'un framework CSS, 2 manières de faire en dév et prod, etc
