La revue de web de Kat
Les feuilles de styles complexes font souvent apparaître des contradictions entre les différentes règles. Cela se produit lorsqu'une propriété reçoit des valeurs différentes, avec des sélecteurs différents mais qui ciblent un ou plusieurs éléments identiques.
Cette page décrit le mécanisme standard de CSS pour résoudre ces conflits. Vous pourrez également vous reporter à la page sur la directive @layer qui permet de mettre en œuvre une autre gestion des priorités : les couches de cascade.
Les règles contradictoires.
Il arrive fréquemment que plusieurs règles CSS soient contradictoires. Cela se produit chaque fois que l'on tente d'affecter des valeurs différentes à une même propriété.
Par exemple, les deux règles CSS suivantes se contredisent sur le premier paragraphe. En effet, la première règle demande que l'élément dont l'identifiant est parag1 soit en rouge, tandis que la deuxième règle demande que les paragraphes soient en bleu. L'élément parag1 étant lui-même un paragraphe, il y a contradiction.
#parag1a {color:red;}
.exemple1 {color:blue;}Voici comment s'affichera le code présenté ci-dessus. On voit que ce n'est pas nécessairement la dernière règle rencontrée qui est prioritaire par rapport aux précédentes. Dans cet exemple on voit que le sélecteur par identifiant ( # ) est prioritaire sur un sélecteur par type d'élément ( p ) : le style appliqué sur l'ID (couleur rouge) est prioritaire sur celui qui est appliqué sur la classe (couleur bleue) bien que ce dernier soit énoncé après.
p id="parag1a" class="exemple1a"
Le premier paragraphe.
/p
p id="parag1b" class="exemple1"
Le deuxième paragraphe.
/p
p id="parag1b" class="exemple1"
Le troisième paragraphe.
/p
Les priorités des sélecteurs.
Rappel : le sélecteur est ce qui détermine sur quel(s) élément(s) une règle CSS s'applique. Dans l'exemple ci-dessous, le sélecteur est .encart. Il désigne tous les éléments comportant l'attribut class="encart".
.encart {border:solid 1px silver;}Tous les sélecteurs n'ont pas la même priorité. En cas de contradiction entre deux règles, celle qui s'applique est celle qui a le sélecteur le plus prioritaire. De façon générale, les sélecteurs ont une priorité d'autant plus grande qu'ils sont plus précis. Le sélecteur très général * a une priorité de 0. A l'inverse, un sélecteur sur un identifiant, qui en principe ne concerne qu'un seul élément de la page, à une priorité de 100.
Pour déterminer la priorité d'un sélecteur, il faut considérer la logique suivante :
Une règle avec la mention !important a une priorité de 10000.
Une règle écrite dans l'attribut style d'une balise HTML a une priorité de 1000.
Une règle avec un sélecteur sur un identifiant ( # ) a une priorité de 100.
Une règle avec un sélecteur sur une classe ( . ) ou des pseudo-classe ( : ) a une priorité de 10.
Une règle avec un sélecteur sur un type d'élément ( p ) ou des pseudo-élément ( :: ) a une priorité de 1.
Le sélecteur étoile ( * ) a une priorité de 0.Les animations sont prioritaires par rapport à toutes les autres déclarations, sauf celles qui sont notées !important. Ce qui est logique sinon les animations ne pourraient jamais s'exécuter. Voir le tutoriel sur les animations en CSS.
Les transitions sont prioritaires par rapport à toutes les autres règles, y compris celles comportant la mention !important. Voir la propriété transition.
Lorsqu'un sélecteur comporte plusieurs parties combinées, les priorités de chacune des parties s'additionnent pour donner la priorité globale du sélecteur.
Une exception cependant : lorsque le sélecteur est composé de plusieurs parties séparées par des virgules, chaque partie est considérée comme un sélecteur à part entière. Chacune des parties peut éventuellement recevoir une priorité différente.
Enfin, lorsque deux règles contradictoires ont un sélecteur de même priorité, la dernière règle rencontrée remplace les valeurs définies par les règles précédentes.
Exemples :
/* Sélecteur sur un identifiant -> priorité = 100 */
#edito {color:blue;}
/* Sélecteur sur une pseudo-classe -> priorité = 10 */
:link {color:inherit;}
/* Sélecteur sur un type d'élément -> priorité = 1. */
p {font-size:1.1em;}
/* Règle comportant la mention !important -> priorité = 10000 */
p {color:silver!important}
/* Sélecteur désignant les images enfants l'élément #edit -> priorité = 101 */
#edit img {width:25%;}
/* Sélecteur désignant les images enfants direct d'une cellule -> priorité = 2 */
td > img {width:100%;}Quelques sélecteurs particuliers.
Les sélecteurs :is() et :has() prennent la priorité du sélecteur le plus sélectif parmi ceux passés en arguments.
:is(#edito, .introduction) /* Priorité = 100 (celle de #edito) */
:has(img) /* Priorité = 1 (celle d'un sélecteur par balise) */Le sélecteur :not() prend la priorité du sélecteur passé en argument.
:not(:first-line) /* Priorité = 10 (celle d'une pseudo-classe) */Le sélecteur :where() a une priorité de 0, bien que ce soit une pseudo-classe.
La valeur !important.
Le mot !important peut être ajouté à n'importe quelle valeur dans une règle CSS. Il rend la règle prioritaire. L'exemple ci-dessous est identique au premier sauf que !important figure dans la deuxième règle. On voit que la priorité des règles a été changée.
Le premier paragraphe.
Le deuxième paragraphe.
Remarque : la mention !important est à utiliser le moins possible.
L'emplacement des styles.
Les choses se compliquent si on considère que :
Plusieurs feuilles de styles peuvent être associées à une même page.
Des styles peuvent être écrits dans la page elle-même (dans la section head) ou dans l'attribut style des balises HTML.
Le navigateur dispose de sa propre feuille de styles, appliquée à toutes les pages qu'il affiche.
L'utilisateur (le lecteur ou l'internaute) peut lui-même définir ses propres styles.
Pour cette raison nous devrons distinguer les styles de l'utilisateur (l'internaute) et les style de l'auteur (celui qui crée le les pages).
Les styles de l'utilisateur sont peu utilisés et ont tendance à disparaître complètement. Voir le paragraphe sur les feuilles de styles utilisateur plus bas dans cette page.Cela fait apparaître trois sortes de styles : les styles du navigateur, ceux de l'auteur (le web designer qui a travaillé sur le site) et ceux de l'utilisateur (l'internaute).
Le traitement de toutes ces feuilles de styles est effectué dans l'ordre suivant :
Le navigateur effectue une première résolution des conflits sur sa propre feuille de styles. Les valeurs obtenues seront utilisées si aucun autre style ne vient les modifier.
Dans un deuxième temps, il résout les conflits éventuels entre les sélecteurs de la feuille de styles de l'utilisateur. Les valeurs obtenues remplacent celles de la feuille de styles du navigateur.
Enfin le navigateur résout les conflits des sélecteurs sur la ou les feuilles de styles jointes à la page (balise link) et sur les styles décrits dans la page elle-même entre les balises style et /style). Les valeurs obtenues seront celles qui seront finalement utilisées.Cependant, comme la possibilité laissée à l'utilisateur de définir ses propres styles est en voie de disparition, nous pouvons simplifier tout ça et considérer que :
Le navigateur affecte les valeurs définies dans sa propre feuille de styles après résolution des conflits éventuels.
Le navigateur résout les conflits de sélecteurs sur les styles de l'auteur et applique les valeurs obtenues à la place de celles de sa propre feuille de styles.Il faut bien noter une chose qui est souvent mal comprise : les styles écrits dans la page elle-même, entre des balises style et /style, dans le section head, sont considérés avec la même priorité que les styles auteur provenant d'une feuille de styles externe. Firefox semble cependant leur donner un petit avantage en les explorant après les styles de la feuilles externe : ils peuvent donc être légèrement prioritaires si toutes les autres règles de priorité sont neutres.
En résumé, voici comment sont gérées les priorités entre les différentes feuilles de styles, en considérant également la valeur !important. La liste ci-dessous est triée du plus prioritaire au moins prioritaire.
Les effets de transition.
Les règles notées !important de la feuille de styles du navigateur.
Les règles notées !important de la feuille de styles de l'utilisateur.
Les règles notées !important de la feuille de styles de l'auteur.
Les animations.
Les règles de la feuille de styles de l'auteur.
Les règles de la feuille de styles de l'utilisateur.
Les règles de la feuille de styles du navigateur.L'inspecteur.
Il existe un outil particulièrement pratique, fourni par la plupart des navigateurs et souvent nommé "l'inspecteur". On l'active en faisant un clic droit sur un des éléments de la page web affichée :
clic droit -> inspecter
L'inspecteur présente des quantités d'informations, aussi bien sur le code HTML, que sur les règles CSS appliquées à l'élément sur lequel on a cliqué. Il montre très bien en particulier la règle qui est active et celles qui ont été surchargées par une autre règle de priorité supérieure : les règles surchargées sont rayées.
L'inspecteur de styles, dans Chrome
Styles définis par l'attribut style de HTML.
Styles définis entre les balises style.../style dans la section head de la page.
Styles définis dans la feuille de styles externes.
Styles définis dans la feuille de styles du navigateur.
La feuille de styles utilisateur.
La feuille de styles utilisateur permet à l'utilisateur, c'est à dire l'internaute, de définir ses propres styles, qui seront appliqués à toutes les pages affichées.
Cette possibilité est peu utilisée et n'est finalement pas très utile car les styles définis par l'utilisateur sont appliqués à toutes les pages, sans qu'il soit possible de faire de différence d'un site à l'autre.
Chrome a désactivé cette possibilité. Firefox ne l'active plus par défaut. Il est cependant possible de l'activer sur Firefox avec le flag toolkit.legacyUserProfileCustomizations.stylesheets (accéder aux flags sur Firefox). Il eput être nécessaire de redémarrer Firefox.
Les styles utilisateur doivent être écrits dans un fichier nommé userContent.css et enregistré dans le dossier de profil. Pour créer ou éditer ce fichier procéder de la façon suivante :
Taper about:support dans la barre d'adresse.
Chercher Profile folder et cliquer sur le bouton Open folder. Le dossier de profil s'ouvre dans l'explorateur Windows.
Créer si nécessaire un sous-dossier nommé chrome en minuscules (oui c'est étonnant, le dossier s'appelle "Chrome").
Créer ou éditer le fichier userContent.css : écrire les styles utilisateur dans ce fichier.
Redémarrer Firefox.Et les attributs HTML ?
A une époque déjà lointaine, il était courant de définir une mise en forme directement par des attributs HTML.
h1font color="blue">Titre de la page/fonth1Les styles CSS sont TOUJOURS prioritaires sur les attributs HTML autres que style. Les attributs tels que color, size, etc. ne devraient d'ailleurs plus être utilisés puisqu'ils ne sont plus standardisés depuis HTML5.
Évolution des règles de priorité.
La gestion des priorités est, pour l'essentiel, resté inchangée depuis la première version du langage CSS. Le niveau 3 a simplement pris en compte les animations et les transitions dans l'ordre des priorités.
Voir aussi, au sujet des priorités.
Les spécifications CSS éditées par le W3C sont organisées en modules. La propriété ref-priorities fait partie du module CSS Cascading and Inheritance. Les définitions suivantes sont également décrites dans ce module.
Propriétés :
all : Initialisation de toutes les propriétés.
Directives :
@import : Importation d'une feuille de styles.
@layer : Définit les couches de cascade (layer) pour faciliter la gestion des priorités entre les règles CSS.
Valeurs:
!important : Rend une règle prioritaire sur toutes les autres.
inherit : Donne à une propriété la même valeur que celle de l'élément parent.
initial : Redonne à une propriété sa valeur initiale.
revert : Donne à une propriété la valeur définie par le navigateur.
revert-layer : Rétablit la valeur d'une propriété à la valeur qu'elle avait à la couche précédente.
unset : Donne à une propriété la valeur qu'elle aurait eu si aucun style ne l'avait changée.
Ce n’est pas forcément la question la plus soulevée dans la sphère SEO, mais nous voulions déterminer dans cet article si le choix de telle ou telle police web pouvait avoir un impact sur votre SEO.
Peut-être vous-êtes-vous déjà demandés si l’utilisation d’une police web personnalisée ou une Google Font, avait une incidence négative comme positive votre visibilité organique. Pour lever le voile sur ce sujet, nous avons décidé de nous replonger dans les déclarations passées de notre ami John Mueller, Webmaster Trends Analyst chez Google.
En d’autres mots, il s’agit de savoir si Google prenait en compte le choix de la police web pour juger de la qualité de votre contenu, par exemple si une police personnalisée conduisait Google à considérer le contenu comme moins pertinent que des qu’un même contenu utilisant d’autres types de web fonts.
Ce que dit Google
Cette question avait été posée à John Mueller en 2017 lors de la vidéo Webmaster Office Hours ci-dessous.
Le cadre de chez Google affirme que le choix de la police d’écriture n’a pas d’impact sur votre référencement. Du moment que Google peut explorer la page et voir le contenu, l’analyse fonctionnera normalement.
La seule situation où John indique que cela pourrait être un peu délicat est si vous utilisez des images au lieu de texte sur une page. Ok, Google fait de l’OCR (Optical Character Recognition : processus de convertir une image en texte) sur les images, mais cela reste un procédé nouveau qui n’est pas pleinement sollicité pour l’indexation des pages web (cela exige beaucoup trop de ressources).
Impact sur le temps de chargement
Le même sujet a été abordé sur Twitter en 2020. Toujours auprès de John Mueller. Cette fois-ci, la question initiale était de savoir si le choix de sa police avait un impact sur les performances de vitesse du site, puis de savoir s’il y avait des polices recommandées par Google.
Les réponses de John Mueller :
1 - Tous les éléments qui composent une page web, comme la police, ont un impact sur la vitesse de chargement.
2 - Le choix de la police n’a pas d’importance pour le SEO.
Ces deux réponses sont contradictoires puisque le temps de chargement est considéré comme un facteur de ranking SEO. Ainsi, si votre police web impacte le temps de chargement, elle influence indirectement votre SEO.
Bon ok, ce n’est pas nouveau que la police impacte le temps de chargement, c’était d’ailleurs un point majeur soulevé dans notre article sur l’optimisation de votre vitesse de site sous WordPress.
Par conséquent, si vous utilisez une police personnalisée parce que vous voulez mettre en avant votre branding, faites attention à ce que cette dernière n’impacte pas trop vos performances. Surtout avec l’introduction des Core Web Vitals en tant que facteurs de positionnement SEO.
Impact sur l’expérience utilisateur
Évidemment, si vous optez pour des polices web personnalisées totalement illisibles, cela aura un réel impact sur la compréhension qu’auront les visiteurs du contenu de votre site. Veuillez donc à ne pas trop en faire et à trouver l’équilibre entre branding et expérience de navigation.
Mais améliorer l’expérience utilisateur signifie aussi que chaque milliseconde compte. De ce fait, il existe de nombreuses façons d’améliorer la vitesse, comme l’optimisation des images et des polices de caractères web.
Commençons par une note positive : il est facile d’adopter une belle typographie gratuitement pour votre site comme vous pouvez en trouver dans les magazines papier. Des sociétés comme Fontawesome, Google et Adobe proposent énormément de polices gratuites qui vous permettront de construire votre site selon votre image. Cependant, un grand nombre auront impact drastique sur la vitesse de vos pages… pouvant vous faire perdre de précieuses secondes et chuter votre score sur PageSpeed Insights.
Voyons donc ensemble comment ces satanés polices web peuvent autant impacter votre temps de chargement en se focalisant sur les polices Google.
Le problème des polices Google
Les Google Fonts peuvent représenter plusieurs problèmes pour vos performances de site. Mais pas que…
Combien de requêtes HTTP les polices effectuent-elles ?
Lorsque votre site est en train de charger sur un navigateur, vous avez peut-être remarqué des messages dans la barre d’état tels que « connecting to fonts.gstatic.com » ou « waiting for fonts.googleapis.com ». Il s’agit du navigateur qui télécharge la police sur laquelle votre site repose à partir de serveurs qui hébergent ces polices.
Pour analyser ce processus de plus près, il suffit de se rendre sur des sites de mesure de vitesse de page tels que GTmetrix ou Pingdom et de tester votre URL. Il y a de fortes chances que vous soyez surpris par le nombre de requêtes que votre site nécessite pour télécharger des fichiers de polices. Mais… attendez deux p’tites secondes… ces polices ne sont-elles pas transférées à partir d’un Google Cloud super méga rapide ?!!
Existe-t-il un CDN pour les polices ?
Oui, les polices web sont fournies par le CDN de Google. Google a optimisé et continue d’optimiser ces fichiers pour un transfert plus rapide. Néanmoins, il s’agit de demandes supplémentaires de données supplémentaires dont la plupart des sites et blogs peuvent se passer. Les néo webmasters commencent souvent avec un hébergement mutualisé chez OVH, et souvent avec un ensemble de plugins redondants qui alourdissent les performances globales de leur site. Dans la plupart des cas, les fichiers de polices web ne font que s’ajouter à la masse.
Quel est le poids des polices web ?
La taille typique d’un fichier de police est de 35-50ko. Cependant, selon la façon dont votre site est développé, il peut nécessiter plusieurs fichiers de polices ou parfois, même un seul fichier de police peut atteindre un poids de quelques mégaoctets. Cela s’explique par le fait qu’un site peut utiliser plus d’une langue, nécessiter plusieurs formats de fichiers ou devoir être disponible en mode hors ligne. Parfois, les thèmes et les plugins qui utilisent les Google Web Fonts font plusieurs demandes pour la même ressource. Pire encore, votre site peut obliger un visiteur à télécharger des éléments qui ne sont jamais utilisés. La plupart du temps, les visiteurs de votre site peuvent se passer de tout cela.
Du coup, une question légitime que l’on pourrait se poser serait de savoir si la mise en cache avait un impact ? Un navigateur ne va-t-il pas stocker ces polices pour une utilisation ultérieure ? La réponse courte : pas tout.
Quid de la mise en cache des polices Google ?
La mise en cache du navigateur ne permet d’accélérer que les visites répétées, et non les premières visites. Pour les visiteurs réguliers, le webmaster du site a le pouvoir de définir la durée pendant laquelle le navigateur doit mettre en cache une ressource localement. Vous pouvez fixer une date d’expiration lointaine (d’un mois ou plus) pour les ressources statiques telles que les images, etc… mais pas pour tout ! En effet, pour les ressources fournies par des tiers, comme Facebook ou Google, le propriétaire du site n’a aucun contrôle. Leur date d’expiration est fixée par les sites qui les fournissent.
Alors que les fichiers de polices de base peuvent avoir une date d’expiration lointaine, les ressources de style liées aux polices ont une date d’expiration de seulement 24h00 en général. Ainsi, lorsqu’un fichier de police a été modifié et qu’un abonné email clique sur le lien d’une newsletter pour lire votre dernier article, ce visiteur fidèle devra télécharger à nouveau toute la police web requise. Inutile de dire que si votre abonné dispose d’une connexion internet pourrie, vous ne l’aidez pas.
Alors, pourquoi ne pas simplement fournir les polices à partir de votre site et de contrôler l’expiration du cache du navigateur ?
Peut-on charger les polices Google en local ?
Les polices web étant OpenSource, vous pouvez les héberger localement sur votre site, réduire le nombre de requêtes HTTP et contrôler l’expiration du cache. Il existe des plugins gratuits pour vous aider à y parvenir. Toutefois, Google déconseille cette pratique. Cela m’amène à poser la question suivante : pourquoi Google adopterait-il une pratique aussi gourmande en termes de ressources, puis déconseillerait dans le même temps une solution permettant de consommer moins et d’optimiser les performances ?
La raison officielle invoquée par la firme de Mountain View est qu’il héberge et fournit les polices afin que vous ayez les plus récentes et les plus optimisées à disposition pour votre site web. Cependant, la vérité se cache peut-être ailleurs…
Les polices Google portent-elles atteinte à la vie privée ?
Quelques pays, comme la Chine, bloquent l’accès à aux serveurs Google, ce qui signifie que les sites utilisant les Google Fonts n’auront pas la même apparence partout dans le monde. De nombreuses autres personnes ont fait part de leurs inquiétudes quant à la confidentialité des données liées aux polices Google, en particulier dans le sillage de la mise en œuvre de la politique européenne RGPD. En effet, en fournissant la police de votre site, Google a un accès direct à ses entrailles. Pour vous faire une idée, jetez un œil à la quantité gargantuesque de données collectées par Google à travers ses polices en consultant les statistiques du site Google Font Analytics.
Les Google Fonts seront-elles toujours gratuites ?
Les polices web représentent un pilier essentiel pour le secteur des éditeurs. La capture à grande échelle des données d’utilisation de ses polices peut potentiellement aider Google à créer un modèle freemium classant les polices gratuites et premium afin de convaincre les navigateurs (tels que Firefox, Safari ou Internet Explorer) d’inclure certaines de ces polices en tant qu’option native dans leurs futures versions. Autre possibilité, l’API Google Fonts pourrait suivre le chemin de l’API de Google Maps, qui exige désormais des propriétaires de sites qu’ils fournissent des informations de carte bancaire pour pouvoir l’utiliser.
Google propose Google Fonts : des polices d’écritures à utiliser pour votre site web, dans le CSS.
Seulement ils sont bien malin : le code CSS prêt-à-utiliser que vous devez mettre dans votre code contient le lien du fichier de la police d’écriture qui se trouve sur leur serveur. Voilà la marche à suivre pour récupérer manuellement le fichier et le placer en local, chez vous.
Je vais faire l’exemple avec une police d’écriture au hasard.
Rendez-vous sur google.com/fonts. Choisissez la police que vous voulez, puis cliquez sur « quick-use » :
Descendez un peu en bas dans la page et récupérez le lien vers le fichier CSS :
Ouvrez ce lien dans votre navigateur.
Vous pouvez déjà copier tout le code dans votre CSS. Il suffit juste de récupérer le lien vers le fichier de la police (fichier .woff).
Téléchargez le fichier .woff et enregistrez le dans votre projet.
Il ne reste alors plus qu’à changer le lien de la police dans le code CSS, pour qu’il utilise le fichier .woff local et pas via le site de Google.
Voilà, c’est tout.
L’avantage d’avoir le fichier de la police chez soi :
Pas de traçage possible par Google
Votre site reste indépendant : si Google ferme son service (il le fera un jour) votre CSS fonctionnera quand même.Désavantages :
Le fichier de la police sera téléchargé depuis votre site, donc consommera votre bande passante.
Si un autre site web quelque part utilise la même police, le navigateur le téléchargera deux fois, alors qu’il ne le fait qu’une seule fois si les deux utilisent le service de Google.
Cette astuce s’inscrit dans ma politique d’un site 100% indépendant sur le plan technique. Il n’y a aucun fichier (image, script…) utilisé dans mes pages qui soit hébergé ailleurs que chez moi.
***Colors in CSS can be specified by the following methods:
Hexadecimal colors
Hexadecimal colors with transparency
RGB colors
RGBA colors
HSL colors
HSLA colors
Predefined/Cross-browser color names
With the currentcolor keyword***Hexadecimal Colors
A hexadecimal color is specified with: #RRGGBB, where the RR (red), GG (green) and BB (blue) hexadecimal integers specify the components of the color. All values must be between 00 and FF.
For example, the #0000ff value is rendered as blue, because the blue component is set to its highest value (ff) and the others are set to 00.
Example
Define different HEX colors:
p1 {background-color: #ff0000;} / red /
p2 {background-color: #00ff00;} / green /
p3 {background-color: #0000ff;} / blue /
Hexadecimal Colors With Transparency
A hexadecimal color is specified with: #RRGGBB. To add transparency, add two additional digits between 00 and FF.
Example
Define different HEX colors with transparency:
p1a {background-color: #ff000080;} / red transparency /
p2a {background-color: #00ff0080;} / green transparency /
p3a {background-color: #0000ff80;} / blue transparency /
RGB Colors
An RGB color value is specified with the rgb() function, which has the following syntax:
rgb(red, green, blue)
Each parameter (red, green, and blue) defines the intensity of the color and can be an integer between 0 and 255 or a percentage value (from 0% to 100%).
For example, the rgb(0,0,255) value is rendered as blue, because the blue parameter is set to its highest value (255) and the others are set to 0.
Also, the following values define equal color: rgb(0,0,255) and rgb(0%,0%,100%).
Example
Define different RGB colors:
p1 {background-color: rgb(255, 0, 0);} / red /
p2 {background-color: rgb(0, 255, 0);} / green /
p3 {background-color: rgb(0, 0, 255);} / blue /
RGBA Colors
RGBA color values are an extension of RGB color values with an alpha channel - which specifies the opacity of the object.
An RGBA color is specified with the rgba() function, which has the following syntax:
rgba(red, green, blue, alpha)
The alpha parameter is a number between 0.0 (fully transparent) and 1.0 (fully opaque).
Example
Define different RGB colors with opacity:
p1 {background-color: rgba(255, 0, 0, 0.3);} / red with opacity /
p2 {background-color: rgba(0, 255, 0, 0.3);} / green with opacity /
p3 {background-color: rgba(0, 0, 255, 0.3);} / blue with opacity /
HSL Colors
HSL stands for hue, saturation, and lightness - and represents a cylindrical-coordinate representation of colors.
An HSL color value is specified with the hsl() function, which has the following syntax:
hsl(hue, saturation, lightness)
Hue is a degree on the color wheel (from 0 to 360) - 0 (or 360) is red, 120 is green, 240 is blue. Saturation is a percentage value; 0% means a shade of gray and 100% is the full color. Lightness is also a percentage; 0% is black, 100% is white.
Example
Define different HSL colors:
p1 {background-color: hsl(120, 100%, 50%);} / green /
p2 {background-color: hsl(120, 100%, 75%);} / light green /
p3 {background-color: hsl(120, 100%, 25%);} / dark green /
p4 {background-color: hsl(120, 60%, 70%);} / pastel green /
HSLA Colors
HSLA color values are an extension of HSL color values with an alpha channel - which specifies the opacity of the object.
An HSLA color value is specified with the hsla() function, which has the following syntax:
hsla(hue, saturation, lightness, alpha)
The alpha parameter is a number between 0.0 (fully transparent) and 1.0 (fully opaque).
Example
Define different HSL colors with opacity:
p1 {background-color: hsla(120, 100%, 50%, 0.3);} / green with opacity /
p2 {background-color: hsla(120, 100%, 75%, 0.3);} / light green with opacity /
p3 {background-color: hsla(120, 100%, 25%, 0.3);} / dark green with opacity /
p4 {background-color: hsla(120, 60%, 70%, 0.3);} / pastel green with opacity /
Predefined/Cross-browser Color Names
140 color names are predefined in the HTML and CSS color specification.
For example: blue, red, coral, brown, etc:
Example
Define different color names:
p1 {background-color: blue;}
p2 {background-color: red;}
p3 {background-color: coral;}
p4 {background-color: brown;}
A list of all predefined names can be found in our Color Names Reference.
The currentcolor Keyword
The currentcolor keyword refers to the value of the color property of an element.
Example
The border color of the following <div> element will be blue, because the text color of the <div> element is blue:
myDIV {
color: blue; / Blue text color /
border: 10px solid currentcolor; / Blue border color /
}
border-style: solid; border-width: 24px 0px; -moz-border-image: url(deco.png) 27 repeat; -webkit-border-image: url(deco.png) 27 repeat; -o-border-image: url(deco.png) 27 repeat; border-image: url(deco.png) 27 repeat;
attention article de 2004 !
En tentant de recréer un design sophistiqué dans un courriel HTML à l'aide de CSS, on se heurte souvent à un mur qui peut se présenter soit sous la forme d'inexplicables mutilations par les clients mail, soit sous celle d'un mail sentencieux de la part d'un administrateur de messagerie, statuant que les CSS sont “contre les règles”. Si vous aussi vous en avez assez de vous taper la tête contre les murs et d'utiliser les balises font, cet article est pour vous.
Contrairement à ce que l'on peut penser, vous pouvez créer en toute tranquillité des courriels HTML avec une bonne vieille CSS façonnée à l'ancienne. Oui, vous avez bien lu. Et même si tous les attributs ne seront pas de la partie, la plupart fonctionneront de manière irréprochable avec cette méthode.
D'abord arrive l'amour : pour le meilleur et pour le pire
Entre des articles sur le web design, des conversations entre professionnels, et des retours d'administrateurs de messagerie, j'ai fini par apprendre que certains clients mail massacraient allégrement les CSS en supprimant les styles ou en tronquant les en-têtes. J'ai également réalisé que si je voulais réellement utiliser des CSS dans mes courriels, j'avais tout intérêt à lier la feuille de style plutôt que de l'encapsuler.
Comme je n'avais encore jamais lu d'ouvrage ou rencontré d'administrateur de messagerie autorisant l'usage de mes CSS sans une guerre en règle, je m'en étais remis à la sagesse populaire. Quelle n'a pas été ma surprise quand je me suis attaqué au sujet et que j'ai décidé d'expérimenter !
Puis vient le mariage : la remise en cause
Le seul moyen de trouver une méthode pour utiliser les CSS dans les courriels HTML était de remettre en cause tout ce que je savais, et de casser toutes les “règles”. Une fois affranchi de celles-ci, il devenait possible d'explorer chacune des techniques recelant la moindre petite promesse. Voici comment cela s'est passé :
J'ai tout d'abord conçu un mail lié à une feuille de style et je l'ai expédié via un serveur d'administration connecté à de multiples adresses, webmails, et clients de messagerie. Je n'ai pas réalisé de tests sur tous les clients mail, mais tous les leaders des marchés Mac, PC et Unix ont pu être testés.
Après plusieurs essais, j'ai réussi à introduire des styles encapsulés. Ce qui s'est révélé être mon premier pas vers la réussite. (Dans le cadre d'une utilisation poussée des styles encapsulés, il est important de noter que les versions 6.0 et supérieures d'AOL rejetteront tout mail lié à des feuilles de style externes. Eh oui ! Rejetés, renvoyés en vous claquant la porte virtuelle au nez virtuel)
J'ai ensuite lu les codes source (ce qui relève de l'exploit en ce qui concerne les webmails) pour voir comment mon courriel avait pu déguster.
Enfin, j'ai utilisé mon expertise sur les styles mutilés pour tester les méthodes qui devaient, en théorie, éviter un tel massacre.Mais quand j'ai vu les codes source, j'ai découvert quelque chose de plus horrible que je ne l'aurais cru. C'était incroyable ! En fait, la plupart du HTML n'en était plus - il n'en restait qu'un bric-à-brac de code et (apparemment) de balises propriétaires.
Enfin l'enfant paraît : mode d'emploi
Chaque client mail a sa propre manière de gérer le balisage, chacun avec ses propres bugs, ses fantaisies, ou ses propres méthodes de prise en charge des feuilles de style. Ce qui suit est la liste des problèmes les plus significatifs et de leurs solutions.
Problème :
L'enveloppe de chaque client basé sur la technologie web repose sur HTML, et il en résulte la présence de deux balises body lors de l'affichage d'un courriel HTML. Certains clients tentent de résoudre le problème en supprimant les deux ocurrences; d'autres y ajoutent un “x,” de sorte que <body> se mue en <xbody>. Dans les deux cas, le style définissant la balise body devient inapplicable.
Solution :
Enveloppez le contenu entier de votre mail dans une balise div et appliquez lui les attributs initialement destinés à body. That's all folks! C'est un remède simple et efficace, faisant uniquement appel à une balise <div> supplémentaire.
Problème :
Certains clients affichent purement et simplement les courriels sans aucun style. J'ai d'abord attribué ceci à la mutilation de mon style, pourtant clairement apparent dans le balisage. J'ai donc passé un temps non négligeable à traquer le coupable, testant une multitude de courriels. Hélas, la solution était en fait juste sous mon nez : les styles n'étaient pas supprimés, mais les points (.) précédant leurs noms, si. En l'occurrence, .DefinitionDeStyle{} se transformait en DefinitionDeStyle{}, provoquant ainsi une définition de style sans aucune portée.
Solution :
J'ai utilisé les sélecteurs de classe, qui assurent que chaque style défini commencera par une lettre plutôt que par un point. Ainsi .DefinitionDeStyle{} peut devenir td.DefinitionDeStyle{} ou div.DefinitionDeStyle{} (le cas échéant). Une solution quelque peu déconcertante, mais qui a le mérite d'être efficace et (une fois de plus) accommodante.
Problème :
Les webmails utilisent leurs propres feuilles de styles, et comme celles-ci précèdent les miennes, l'effet de cascade aboutit à une priorité de mes règles sur celles du webmail. De sorte que mes pseudo-classes et mes définitions d'éléments (tel a:link{} et td{}) altéraient par mégarde le design du webmail lui-même. Fichtre !
Solution :
J'ai paramétré précisément chaque définition. C'est ainsi que a:link{} est devenue à la fois span.DefinitionDeStyle a:link{} et td.Contenu a:link{} pour mettre en forme les liens HTML dans les deux niveaux de l'arbre du document. Cette approche peu orthodoxe alourdit le balisage, mais elle assure que mes styles seront appliqués uniquement aux éléments de mon courriel. Elle établit aussi un respect du travail, pour le designer du webmail comme pour ses utilisateurs. Mais surtout, le code qui en résulte est correct et fonctionne comme prévu.
Problème :
Hotmail : le plus démoniaque de tous. Aucune pitié pour les mails en HTML qui s'appuient sur des CSS. Il ne se contente pas d'éradiquer les styles, mais aussi les balises suivantes des courriels : <head>, <title>, <meta>, et <body>. Dites adieu à votre beau design.
Solution :
Je vous recommande de considérer soigneusement jusqu'où vous voulez vous plier à l'ineptie d'Hotmail, car la méthode suivante va demander du dévouement et de la rigueur. Comme la balise <body> et toutes celles qui précèdent se sont évaporées, la seule option consiste à utiliser les styles CSS en-ligne. Les styles définis en-ligne sont pénibles et peu productifs, et vous préféreriez sans doute ne pas avoir à les utiliser, mais ils fonctionnent tout de même. Si vous prévoyez une utilisation massive d'Hotmail par votre public, vous pouvez vous tourner vers cette méthode. Mais si vous n'avez pas à vous soucier d'Hotmail, sautez donc cette étape et pensez aux choses importantes de la vie, comme manger et dormir.
Remarques
Les attributs
Avant de venir me passer un savon parce que vous avez trouvé un attribut qui échoue en utilisant l'une de ces techniques, gardez à l'esprit le fait que je n'ai pas testé tous les attributs CSS. J'ai testé les attributs les plus courants et ceux que j'utilise fréquemment. Vous découvrirez peut-être que votre attribut favori ne marche guère, et c'est la raison pour laquelle je vous adresse toute ma sympathie, et mes encouragements à tester de nouvelles méthodes.
Clients testés
J'ai testé ces méthodes avec MailApp 1.3.2 (Mac), Squirrel Mail (Mac/Windows), AOL 7.0, 8.0, 9.0 (Mac/Windows), Mozilla Thunderbird 0.5 (Mac/Unix), Yahoo Mail (Mac/Windows), Hotmail (Mac/Windows), et Microsoft Outlook 2001/XP (Windows).
Tenez-moi au courant si ces techniques échouent dans votre configuration. Notez tout de même que les capacités d'Eudora en matière d'HTML sont incroyablement faibles, je l'ai donc exclu définitivement de tout test.
Débuter avec le langage CSS, apprendre pas à pas !
Cours CSS (Cascading Style Sheets ou feuille de style)
Débuter RAPIDEMENT et apprendre le CSS : astuces pour gagner du temps pour votre site !
Line-height et vertical-align sont des propriétés très simples. Tellement simples que la majorité d’entre nous sommes persuadés de savoir comment elles fonctionnent et comment les utiliser. Mais non. Elles sont vraiment tout sauf simples, voire les plus complexes, puisqu’elles ont un rôle important dans la création de l’une des choses les moins connues de CSS : le contexte de formatage inline (inline formatting context)
Par exemple, line-height peut être défini comme une longueur ou comme une valeur sans unité 1, mais la valeur par défaut est normal. OK, mais c’est combien normal ? On lit souvent que c’est (ou que ça devrait être) 1, ou alors 1.2, même la spec CSS n’est pas très claire sur ce point. Ce que l’on sait, c’est que le line-height sans unité est relatif à la propriété font-size, mais le problème c’est que font-size: 100px se comporte différemment entre les polices, donc est-ce que line-height est également différent ? Est-ce vraiment entre 1 et 1.2 ? Et vertical-align, quelles sont ses implications par rapport à line-height ?
...
J'ai souvent eu l'occasion à travers mes divers projets Web mobile (responsive), d'avoir à réduire la taille des polices de titre car même un simple mot ne
Voici un petit script CSS qui permet d’afficher un cadenas sans image, seulement en CSS. Le HTML Le CSS Le Résultat Sur CodePen avec SCSS See the Pen Padlock in…
Here at CSSPortal, we have gathered as much information as possible to try and help you learn CSS and improve your web design skills.
This article was originally published on February 2, 2009 and is now being updated to clarify the concept and update the information for modern browsers. R