CSS : même nom de classe et nom d'identifiant

zarathoustra

Membre actif
2 Avril 2007
851
7
Borobodur
bonjour à tous

savez-vous (d'après les règles édictées par le W3C) si l'on peut écrire dans la feuille de styles CSS une classe .probleme alors qu'on a un identifiant #probleme dans la feuille?

Cdlt,

Z.
 
Quel est le .#problème ? :D

Sachant que l'une (.probleme) est une classe et l'autre (#probleme) une ID.

Un petit topo sur ce sujet sur Alsacréations… :p

Tu peux avoir sans souci ce genre de code :

<div id="probleme"><span class="probleme">POPOL</span></div>

Un élément spécifié avec une ID et l'autre une classe, si tu ne sais pas si c'est possible c'est que les notions CSS (parentés, associations, combinaisons&#8230;) sont encore très floues&#8230; non ?

On peut même avoir :
<div id="probleme" class="probleme"> </div>

Si on utilise la classe "probleme" par ailleurs dans la page (autre balise avec cette classe).
 
Dernière édition:
  • J’aime
Réactions: zarathoustra
Quel est le .#problème ? :D

Sachant que l'une (.probleme) est une classe et l'autre (#probleme) une ID.
C'est juste une question que je me posais : est-ce que ca pose des problèmes si la suite des caractères qui composent le nom d'une classe est la même que la suite des caractères qui composent le nom d'un identifiant.
Alors, selon toi, ca ne poserait pas de problème si j'ai bien compris?


Merci pour ce lien très intéressant.

Quel est le .#problème ? :D
Tu peux avoir sans souci ce genre de code :

<div id="probleme"><span class="probleme">POPOL</span></div>

Un élément spécifié avec une ID et l'autre une classe, si tu ne sais pas si c'est possible c'est que les notions CSS (parentés, associations, combinaisons…) sont encore très floues… non ?
Lol, justement je pensais que mes notions étaient de moins en moins floues. Apparemment non.... Pourtant, d'après le site W3school et ses questionnaires en ligne, je suis même confirmé , il paraît....
Trève de plaisanterie, sans être une fusée en CSS je pensais quand même avoir compris les bases.
Que veux tu dire par un élément spécifié avec une ID et l'autre une classe? L'autre quoi tu veu dire?
Tu ne pourrais pas l'écrire en code stp?

Quel est le .#problème ? :D
On peut même avoir :
<div id="probleme" class="probleme"> </div>

Si on utilise la classe "probleme" par ailleurs dans la page (autre balise avec cette classe).
Ton "Si" de la deuxième phrase il assure la liaison avec la phrase précédente?

Merci pour tes explications en tout cas...

Cdlt,

Z.
 
La manipulation de l'ID (id en code) est surtout intéressante avec du javascript ou des formulaires, de l'Ajax aussi, elle sert aussi à hiérarchiser ton squelette si tu le désire (vu que normalement les contenants principaux sont uniques), après si un élément est "tagué" avec un id="probleme" c'est lui qui sera la cible d'un appel et non un élément portant une classe multiple CSS (class="probleme").

C'est marrant que tu me parles de Raphaël là dessus. ;)

Quand je te parle d'un élément c'est un élément HTML, une balise quoi (div, p, a, etc…), un élément peut avoir une id ET une class (et même un style en complément local mais à éviter).

Est-ce plus clair comme ça ?

Si Raphaël Goetter n'est pas clair essaye de lire les livres d'Eric Meyer c'est la bible. :D
 
La manipulation de l'ID (id en code) est surtout intéressante avec du javascript ou des formulaires, de l'Ajax aussi, elle sert aussi à hiérarchiser ton squelette si tu le désire (vu que normalement les contenants principaux sont uniques), après si un élément est "tagué" avec un id="probleme" c'est lui qui sera la cible d'un appel et non un élément portant une classe multiple CSS (class="probleme").

Quand je te parle d'un élément c'est un élément HTML, une balise quoi (div, p, a, etc…), un élément peut avoir une id ET une class (et même un style en complément local mais à éviter).

Est-ce plus clair comme ça ?
Salut Momo;

Alors là, c'est méchamment clair. C'est clair que tu es bon très bon pédagogue. Merci.

Quand tu dis qu'elle est intéressante avec les formulaires, tu veux parler de l'attribut href= qui permet de nous ramener vers l'id ou ancre?
et pour le javascript c'est la fonction a href=document.getElementById()si j 'ai bien compris le post de Raphael.....
Quand je te parle d'un élément c'est un élément HTML, une balise quoi (div, p, a, etc…), un élément peut avoir une id ET une class (et même un style en complément local mais à éviter).
et un élément, si j'ai bien compris, peut avoir un seul ID et plusieurs classes ?

C'est marrant que tu me parles de Raphaël là dessus. ;)

Oui, en fait, c'était un de ses exemples qui m'avait fait bugé. Pour être précis, c'est un exemple avec #kiwi et .kiwi

Si Raphaël Goetter n'est pas clair essaye de lire les livres d'Eric Meyer c'est la bible. :D
Merci, je vais me pencher dessus.

Néanmoins, j'ai pris conscience du fait que, dans cette discipline, la connaissance des règles est essentielle, mais il faut se lancer dans la conception et là ca permet aux concepts de mieux rentrer. Si on reste dans la théorie sans la pratique, on peut tourner en rond très longtemps.

Qu'en penses-tu toi qui a de l'expérience dans ce domaine?

Cdlt,

Z.
 
Quand tu dis qu'elle est intéressante avec les formulaires, tu veux parler de l'attribut href= qui permet de nous ramener vers l'id ou ancre?
L'attribut href ne s'utilise qu'avec la balise de lien "a", quand j'ai supputé que tes bases étaient flouent… hein… :p

et un élément, si j'ai bien compris, peut avoir un seul ID et plusieurs classes ?
Oui, c'est un des intérêt des classes, elles peuvent être combinées :

Un exemple : class="menu droite fin" pour un élément de menu à droite et en fin de menu, avec 3 classes combinées .menu{}, .droite{} et .fin{}.

Note bien que si l'élément a une ID la définition cette id peut avoir des attributs particuliers qui s'ajoutent à ceux des classes que tu lui appliques, et ainsi de suite, soit des milliards de combinaisons CSS.


Qu'en penses-tu toi qui a de l'expérience dans ce domaine?
Mon expérience c'est le dur de suite en copiant du code ça et là j'ai monté mes premières pages… il y a 7 ans. :rateau:

Aujourd'hui je préconise au débutants et néophytes l'utilisation d'une extension propre à Firefox (présente mais moins complète dans safari et out navigateur moderne) : Firebug

Avec ce module tu accèdes à toute la structure CSS et HTML d'une page (sites en consultation ou sites en dev), et le point le plus intéressant dans la partie CSS c'est la présentation des attributs et les parentés entre éléments, ainsi tu comprends comment sont stylés les éléments.

Ce que j'ai appris avec mon expérience, comme en PHP, chaque développeur code à sa façon, avec son approche des styles et des imbrications, j'ai voulu, un temps, pousser très en amont l'intégration des styles, pour finalement revenir à quelque chose de plus naturel qui reste basé sur la construction de mon squelette, de plus, aujourd'hui je travaille dans 85 % des cas sur des bases CMS et je m'adapte aux feuilles proposées par les dev.

C'est là que l'on apprécie un webdesigner qui code proprement et commente ses feuilles de styles, ça aide.
 
L'attribut href ne s'utilise qu'avec la balise de lien "a", quand j'ai supputé que tes bases étaient flouent… hein… :p
lol
Exact, mais c'était par abus de langage, je voulais écrire
<a href="#top">aller en haut</a> (de Goetter)
Oui, c'est un des intérêt des classes, elles peuvent être combinées :

Un exemple : class="menu droite fin" pour un élément de menu à droite et en fin de menu, avec 3 classes combinées .menu{}, .droite{} et .fin{}.

Note bien que si l'élément a une ID la définition cette id peut avoir des attributs particuliers qui s'ajoutent à ceux des classes que tu lui appliques, et ainsi de suite, soit des milliards de combinaisons CSS.
C'est très intéressant. Et quand on a un id combiné avec des classes, c'est l'id qui a le plus grand poids sur la meme propriété? (si j'ai bien compris).
Mon expérience c'est le dur de suite en copiant du code ça et là j'ai monté mes premières pages… il y a 7 ans. :rateau:
=> donc après avoir vu les grandes lignes, il faut arrêter la pratique, et se mettre en pratique. Et quand on a des problèmes on retourne à la théorie?
Aujourd'hui je préconise au débutants et néophytes l'utilisation d'une extension propre à Firefox (présente mais moins complète dans safari et out navigateur moderne) : Firebug
Avec ce module tu accèdes à toute la structure CSS et HTML d'une page (sites en consultation ou sites en dev), et le point le plus intéressant dans la partie CSS c'est la présentation des attributs et les parentés entre éléments, ainsi tu comprends comment sont stylés les éléments.
Ah oui, ca a l'air très pratique pour les débutants comme outils. Merci bcp. Si j'ai bien compris, on peut comprendre notamment plus facilement l'arborescence du document?
Ce que j'ai appris avec mon expérience, comme en PHP, chaque développeur code à sa façon, avec son approche des styles et des imbrications,
ok, il y a un processus d'imitation au départ, et ensuite il faut "développer son propre style"....

j'ai voulu, un temps, pousser très en amont l'intégration des styles, pour finalement revenir à quelque chose de plus naturel qui reste basé sur la construction de mon squelette, de plus, aujourd'hui je travaille dans 85 % des cas sur des bases CMS et je m'adapte aux feuilles proposées par les dev.

C'est là que l'on apprécie un webdesigner qui code proprement et commente ses feuilles de styles, ça aide.
tu entends quoi par "pousser très en amont l'intégration des styles?

Merci en tout cas pour tes précieux conseils.... :up:
 
C'est très intéressant. Et quand on a un id combiné avec des classes, c'est l'id qui a le plus grand poids sur la meme propriété? (si j'ai bien compris).
Pas tout à fait, tout ce qui touche au HTML et au CSS est régi par l'ordre de lecture ou d'écriture du code. Pour le HTML c'est les premières lignes les plus importantes, soit :
Ouverture <html>
Règles, balises d'encodage et autres codes script <head>
Corps de la page <body>

Pour les CSS c'est l'ordre d'écriture des règles, soit :
Une classe id sera la parente en général puisque qu'attribuée à un contenant, elle peut donc donner des règles aux classes multiples qu'elle contient, n'oublie pas que l'écriture d'une classe peut être ciblée, par exemple : #menu .final a:link {} ou encore pour une image #menu .final img {}, l'écriture des styles est primordiale, tu obtiens des choses très spécifiques si tu définis correctement et/ou précisément une règle.

Ainsi tu vas donner des attributs génériques à un contenu (dimensions et comportement en général) et souvent laisser les styles enfant au contenu s'occuper du reste mais ça peut s'appliquer au contenu (la typographie par exemple).

Tu peux trouver des choses comme cela par exemple :
#menu {} <- attributs du conteneur unique
#menu ul {} <- attributs de la liste à points (comportement et dimensions du menu)
#menu ul li {} <- attributs des lignes de la liste (qui servent au menu)
#menu ul li a {} <- attributs des liens du menu (styles des "boutons")
#menu ul li a:hover {} <- attributs du survol des liens du menu (effet rollover)

On reste dans le contenant #menu, je peux toujours écrire une règle pour ul générique (ul {}) mais si je l'écris dans la feuille de styles après celle du #menu elle ne prendra pas le pas sur cette dernière sauf si j'ai oublié un attribut donné à la générique et pas défini à celle du #menu.

Par contre si j'indique une couleur de texte rouge à #menu {} et que en dessous j'indique une couleur de texte bleue à #menu li {}, le texte hors contexte de liste à points sera rouge et celui dans les listes à points sera bleu. Rien de mieux que la pratique et surtout découvrir les astuces CSS qui sont sous ton nez dans chaque page que tu visites&#8230; ;) :D

De manière naturelle on écrit les styles dans l'ordre de création soit :

Reset si besoin

Body/html

Structure (du plus grand au plus petit : container, header, menu, contenu, colonne, etc&#8230;)

Le reste par poste (menu, titrage, liens, tableaux, formulaire, etc).


D'où l'importance des termes utilisés pour les styles et les commentaires qui aident la lecture des styles.

Avec Firebug les styles sont affichés dans l'ordre hiérarchique de leur application à l'élément inspecté et tu as le n° de ligne dans la feuille de styles.

Attention à ne pas oublier les standards qui agissent par défaut sur l'affichage si tu n'indiques pas de règles dans tes styles (les marges et interligne notamment), j'utilise souvent un "reset" CSS pour partir sur des bases saines (important avec Explorer et Opéra sur certains points).

=> donc après avoir vu les grandes lignes, il faut arrêter la pratique, et se mettre en pratique. Et quand on a des problèmes on retourne à la théorie?
Tout à fait&#8230; au boulot. :up:

Ah oui, ca a l'air très pratique pour les débutants comme outils. Merci bcp. Si j'ai bien compris, on peut comprendre notamment plus facilement l'arborescence du document?
L'arborescence je la vois plutôt en affichant le code source (pom + Alt + U en général), Firebug c'est l'étude des styles et leur action, tu verras que l'on peut saisir des styles temporairement et voir leur action, de même tu peux désactiver temporairement un style, c'est vraiment le truc indispensable pour comprendre les CSS.

tu entends quoi par "pousser très en amont l'intégration des styles?
Une certaine école pousse à structurer les styles comme on le ferrait pour le code HTML, on part du principe des poupées Russes et j'ai réalisé des sites avec une dizaine de feuilles différentes (structure, textes et typo, menus, blocs génériques, etc), après tu peux les combiner selon les pages. Aujourd'hui je travaille pratiquement que sur des sites dynamiques et hors système de gestion des styles en Php (fusion de feuilles dans un appel de head) je n'utilise pas cette façon de faire. Bon ça c'est plus technique.
 
Je l'ai peut-être raté dans cette conversation très fournie mais je voulais rappeller qu'un ID doit être unique dans la page. Perso je les réserve aux zones principales (voir tutoriel dans ma signature ou ceux chez alsacréations).
 
Merci pour ce post complet et très riche !

Quand tu écris
Une certaine école pousse à structurer les styles comme on le ferrait pour le code HTML, on part du principe des poupées Russes et j'ai réalisé des sites avec une dizaine de feuilles différentes (structure, textes et typo, menus, blocs génériques, etc), après tu peux les combiner selon les pages. Aujourd'hui je travaille pratiquement que sur des sites dynamiques et hors système de gestion des styles en Php (fusion de feuilles dans un appel de head) je n'utilise pas cette façon de faire. Bon ça c'est plus technique.

Je dois etre bete mais je n'ai pas tres bien compris.

le principe des poupées russes
=> c'est par exemple, on met du général dans le body, et apres si on veut différencier, on le précise, c'est ca les poupées russes?
=> tu n'utilises pas ce moyen?

Aujourd'hui je travaille pratiquement que sur des sites dynamiques et hors système de gestion des styles en Php (fusion de feuilles dans un appel de head) je n'utilise pas cette façon de faire.
=> tu veux dire que tu n'appelles pas de feuilles externe avec link rel?

Cdlt,

Zarathoustra.
 
le principe des poupées russes
=> c'est par exemple, on met du général dans le body, et apres si on veut différencier, on le précise, c'est ca les poupées russes?
=> tu n'utilises pas ce moyen?
Dans ce principe tu créés un fichier de styles pour les balises génériques, un autre pour la structure, un autre pour les titrages et typo, un autre pour les formulaires, un autre pour&#8230; etc.

L'idée serait de ne charger que les styles qui sont utilisés dans les pages, ainsi la page de contact ne chargera pas tout les styles de la page produit ou plan du site ou autre chose, avec ce genre de base on peut utiliser des feuille d'agrégation avec du @import (je l'ai vu mais ça m'a semblé bien compliqué pour au final gagner quelques dizaines de Ko !!

La chasse au poids reste un réflexe pour moi (j'ai commencé à coder avec des débit de 128 Ko), quand je vois une page d'accueil de plus de 150 Ko je frémis et pourtant des pages de 1 Mo cela devient courant (avec tout le javascript qu'on y trimbale).

Tout cela pour dire qu'effectivement, aujourd'hui c'est plus une pratique intellectuelle que quelque chose d'efficace, mais certains y trouve une sérénité pour travailler car les styles se complexifient.

Aujourd'hui je travaille pratiquement que sur des sites dynamiques et hors système de gestion des styles en Php (fusion de feuilles dans un appel de head) je n'utilise pas cette façon de faire.
=> tu veux dire que tu n'appelles pas de feuilles externe avec link rel?
Les styles sont toujours appelé quelque part dans le <head>sinon comment les rendre actifs ?
Si tu es curieux regardes le code source des sites que tu visites, on trouve parfois des appel du genre :
<link rel="stylesheet" type="text/css" media="screen" href="/themes/VirtualCommon/consolidated-screen-0.css" />
Ici un système Php qui écrit à la volée un fichier CSS combinant les styles, c'est parfois illisible car compacté, ce qui peut donner un code comme suit :
blockquote,q{quotes:none}blockquote:before,blockquote:after,q:before,q:after{content:'';content:none}:focus{outline:0;-moz-outline-style:none}ins{text-decoration:none}del{text-decoration:line-through}html{width:100%;height:100%}body{width:100%;height:100%;color:#545454}br{margin:0;padding:0}img{border:0}.image-left{float:left;margin:3px 3px 3px 0;padding:3px 12px 3px 0}.image-right{float:right;margin:3px 0 3px 3px;padding:3px 0 3px 12px}a,a:link,a:visited{text-decoration:none}a:hover,a:active{text-decoration:underline}.clearer{clear:both}h1{margin:0;padding:0;font-size:30px;line-height:32px}h2{margin:0;padding:0;font-size:24px;line-height:26px}h3{margin:0;padding:0;font-size:18px;line-height:22px}h4{margin:0;padding:0;font-size:14px;line-height:16px}#backgroundFade{background:none 0 top;width:100%;height:100%}html>body #backgroundFade{background:url(images/bkg_fade_tile.png) repeat-x 0 top;width:100%;height:100%}#backgroundOverlay{background:none left top;width:100%;height:100%}html>body #backgroundOverlay{background:url(images/overlay_circles.png) no-repeat left top;width:100%;height:100%}

Sur de gros frameworks on rencontre parfois une gestion avec proxy pour les styles, cela donne des appels de ce genre :
<link rel="stylesheet" type="text/css" href="/themes/virtual/proxy.php?c=text/css&f=Accordion.css,Cart-Account-Order.css,Common.css,ContactForm.css,QuoteForm.css,adminStats.css,DMessagesPanel.css,HomeP_Box.css,Layout_boxes.css,LoginBox.css,modalbox.css,Products-View-Search.css,SiteMap.css,Slider.css,Suppliers-View-Search.css,tooltip.css,TTabbed.css,Why.css,XUPBtn.css,XGrid.css,admin-supplier-catalog.css" media="screen" />
Tu peux voir qu'ici on est en présence d'un paquet de fichiers CSS appelés via un proxy (qui accélère le traitement), le tout pèse, dans cet exemple, 242 Ko.

Pour ce qui est du traitement des fichiers CSS un petit compacteur ici.

Un dossier sur Alsacréations sur la gestion des CSS en php.

N'oublies pas l'écriture des CSS peut être simplifiée.

Voilà de quoi t'occuper les neurones&#8230; non ? :D :p :rateau: :cool:
 
Dernière édition:
Dans ce principe tu créés un fichier de styles pour les balises génériques, un autre pour la structure, un autre pour les titrages et typo, un autre pour les formulaires, un autre pour… etc.
=>Ce n'est pas bizarre de créer plusieurs fichiers de styles différents comme ca?
Bon, moi, je me suis formé sur la "méthode Goetter", et si j'ai bien compris, il conseille de faire un fichier unique CSS, non?

=>L'avantage serait de gagner quelques kilos, mais quand tu modifies les pages, ca ne causerait pas de gros soucis? par exemple si on rajoute des éléments dont on n'a pas appelé les styles correspondant?
Par exemple, si tu rajoutes un formulaire dans une page (qui n'en avait pas avant) , alors il faudrait rajouter l'appel de la feuille css pour le formulaire?
La chasse au poids reste un réflexe pour moi (j'ai commencé à coder avec des débit de 128 Ko), quand je vois une page d'accueil de plus de 150 Ko je frémis et pourtant des pages de 1 Mo cela devient courant (avec tout le javascript qu'on y trimbale).
Pour le mobile, c'est super important la question du poids, non? et comme tout va basculer sur le mobile, ton réflexe serait ainsi le bon?

Ici un système Php qui écrit à la volée un fichier CSS combinant les styles, c'est parfois illisible car compacté, ce qui peut donner un code comme suit :
Un avantage de compacter (autre que le poids) ca ne serait pas aussi de masquer ta "création"? (étant donné que c'est illisible)?

N'oublies pas l'écriture des CSS peut être simplifiée.
=> oui , ca , Goetter le rappelle en permanence, merci.

Voilà de quoi t'occuper les neurones… non ?


oui, la c'est clair. Mais ce qui est bien, c'est que l'on a l'impression de les occuper pour quelque chose de constructif.

Merci !
 
Ce n'est pas bizarre de créer plusieurs fichiers de styles différents comme ca ?
Non, c'est une façon de faire, elle fait partie des bonnes pratiques à l'origine pour éviter de charger tous les styles d'un coup pour une page d'index qui peut n'en utiliser que 10 %, mais comme tout ce qui touche au web l'évolution technique met à plat, en grande partie, ce que l'on apprend tout les 4 / 5 ans.

Bon, moi, je me suis formé sur la "méthode Goetter", et si j'ai bien compris, il conseille de faire un fichier unique CSS, non ?
Un pour l'écran, un pour l'impression, un pour les mobiles, etc…

L'avantage serait de gagner quelques kilos, mais quand tu modifies les pages, ca ne causerait pas de gros soucis ?
Par exemple si on rajoute des éléments dont on n'a pas appelé les styles correspondant ?
Le cahier des charges doit t'indiquer, grosso-modo, comment répartir tes styles, mais bien entendu si tu ajoutes de nouveaux éléments il faudra compléter les feuilles de styles qui correspondent.

Par exemple, si tu rajoutes un formulaire dans une page (qui n'en avait pas avant) , alors il faudrait rajouter l'appel de la feuille css pour le formulaire ?
Rien de compliqué… non ?

Pour le mobile, c'est super important la question du poids, non? et comme tout va basculer sur le mobile, ton réflexe serait ainsi le bon ?
Si c'était si simple oui… mais ce n'est aussi simple, d'abord tout ne va pas basculer sur le mobile, il faut dissocier smartphone et tablettes, ensuite effectivement on peut garder 2 feuilles de styles ou tester les solutions du responsive design (frameless), c'est avant tout la conception de ta structure qui reste importante, elle doit "coller" au plus prêt du contenu, sachant que sur smartphone on ne passe de longues minutes à lire un contenu il faut hiérarchiser l'accès au contenu en fonction du support. Actuellement c'est le gros souci du moment, comment gérer "à priori" l'accès au contenu pour éviter de tout charger et de trier une fois dans le navigateur… mais on parle de la future 4G qui va débloquer pas mal de choses à ce niveau.

Pour faire bref on va avoir à l'avenir ce que l'on a aujourd'hui dans l'Internet fixe : une ligne de fracture entre le vrai haut débit et les débit très faibles en rase campagne (parfois du 128/256 Ko). J'ai eu l'occasion de voir ça dans une PME/PMI très mal desservie où les débits de surf sont terriblement lents.

Mon conseil c'est toujours de créer un design au rapport attrait/poids le plus intéressant, un joli calque transparent en .png qui te bouffe 250 Ko pour un effet très discret en fond de page -> Poubelle.
Dans ce genre de chose les visiteurs de site dédiés à la photographie sont très souvent bien pourvu en débit et taille d'écran, on peut leur balancer des choses plus lourdes, alors qu'une boutique en ligne peut s'adresser à tout le monde, du coup je soigne le poids des pages (pas toujours au mieux c'est vrai).


Un avantage de compacter (autre que le poids) ca ne serait pas aussi de masquer ta "création"? (étant donné que c'est illisible)?
Arf, ne rêve pas, tout ce que l'on essaye de cacher sur le web est "trouvable", une page de CSS "compactée" est présentée bien indentée en 1 seconde avec Dreamweaver par exemple.

Ensuite la "création" en CSS c'est plutôt du pipo… non ? :p :siffle:
 
On est tous confronté aux mêmes dilemnes concernant les feuilles de style :), soit j'en fais une grosse un peu lourde certes mais une seule requête et à la limite c'est chargé dans le cache pour le reste de la visite, soit j'en fais plusieurs plus légères mais alors multiplication des requètes (em plus de toutes les requêtes pour les js...) les bonnes pratiques changent en permanence... les @import sont assez souvent déconseillés à cause des politiques de chargement des navigateurs.

Bref chacun se débrouille, évolue... en plus maintenant débarque en force les "framewoks" css genre less qui soit disant simplifient le dev... pas super convaincu mais va falloir que je m'y colle car imposé ...

on apprend tous les jours