width = largeur du contenuwidth = largeur de la boîte entièrePour supporter tous les navigateurs, la seule solution était d'utiliser des hacks CSS, c'est-à-dire d'exploiter des bugs d'implémentation pour que tel navigateur ignore telle propriété (e.g., le fameux box model hack)
D'autre part, la compétition fait que chaque navigateur implémente des fonctionnalités spécifiques ⇒ peut entraîner des problèmes de standardisation ensuite
Pour éviter ce genre de problème, le W3C demande que les navigateurs utilisent des préfixes pour leurs implémentations de fonctionnalités CSS non standard
Le principe général : les propriétés et mots-clefs commençant par un trait d'union sont réservés pour l'expérimentation
-webkit- pour WebKit (Safari ; Chrome et Opera avant 2013)-moz- pour Gecko (Firefox)-ms- pour Trident (Internet Explorer)-o- pour Presto (Opera avant 2012)Lorsqu'une spécification est suffisamment mature (statut candidate recommendation), les navigateurs sont censés supporter les propriétés sans préfixe, et progressivement arrêter de supporter les versions avec préfixe
Le principe des préfixes est de faciliter le test à grande échelle des nouvelles spécs, et de permettre à ceux qui le désirent de les utiliser, mais seulement à leurs risques et périls (puisqu'il n'y a aucune garantie que la syntaxe ne changera pas)
.box {
-webkit-border-radius: 5px;
-moz-border-radius: 5px;
-o-border-radius: 5px;
border-radius: 5px;
}
Quand on se rend compte que la syntaxe doit changer avant qu'une propriété n'arrive en CR, il faut de toute façon la rendre incompatible avec la précédente, sous peine de casser les sites utilisant l'ancienne syntaxe préfixée
Processus de normalisation très lent ⇒ les développeurs prennent l'habitude d'utiliser des préfixes et oublient leur aspect expérimental
problèmes quand la syntaxe change, surtout que…
Le début de la fin : en 2012, Opera, Mozilla et Microsoft ont commencé à envisager de reconnaître le préfixe -webkit-…
On rencontre à peu près les mêmes problèmes que s'il n'y avait pas de préfixes…
… sauf qu'il y en a d'autres en plus…
.box {
background: #1e5799; /* Old browsers */
background: -moz-linear-gradient(top, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: linear-gradient(to bottom, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */
}La leçon sur laquelle tout le monde s'accorde : les fonctionnalités expérimentales ne doivent pas être utilisables en prod
Depuis 2012, (source) Firefox ne rend plus les nouvelles fonctionnalités accessibles par défaut
Il faut modifier la configuration pour pouvoir les essayer (et elles n'utilisent pas de préfixe)
On peut toujours tester les fonctionnalités expérimentales, mais pas les utiliser sur un vrai site
Les moteurs Blink (créé en 2013, utilisé par Chrome et Opera) et EdgeHTML (créé en 2015 pour Microsoft Edge) fonctionnent de la même façon, et n'ont même pas de préfixe attribué
En outre, les navigateurs et le W3C sont d'accord pour que les nouvelles fonctionnalités soient livrées sans préfixe lorsque les spécs semblent suffisamment interopérables, sans attendre des tests formels.
Les préfixes sont donc a priori voués à disparaître… mais en attendant, nombre sont encore nécessaires.
Autoprefixer est un post-processeur de CSS : il prend un fichier CSS normal et génère du CSS avec les bons préfixes
Il contient la base de données de caniuse.com, et sait donc quels préfixes sont vraiment utiles
Il gère aussi les différences de syntaxe (gradients, flexbox)
Le principe est de passer les CSS à Autoprefixer avant chaque déploiement (facilement automatisable)
Un tutoriel (CSS-Tricks)
@supportsRemplacement des hacks CSS pour tester si une fonctionnalité est implémentée
@supports (display: flex) {
.conteneur { display: flex; }
}
@supports not (display: flex) {
.conteneur div { float: left; }
}
@supports (column-width: 20rem) and (column-span: all) {
div { column-width: 20rem; }
div h2 { column-span: all; }
}Supportée par tous les navigateurs récents ; les autres ignorent la règle
complètement utilisable en prod, à condition
de ne pas compter pour l'instant sur @supports not pour les fallbacks
(regarder l'exemple au-dessus :
que se passe-t-il pour un navigateur qui supporte flexbox mais pas @supports ?)
En attendant que @supports soit supportée partout,
Modernizr est une librairie JavaScript pour détecter les fonctionnalités (CSS, mais aussi HTML et JavaScript)
implémentées par le navigateur
Elle ajoute des classes à l'élément html pour indiquer les fonctionnalités supportées.
glossy :
.no-js .glossy,
.no-cssgradients .glossy {
/* Modernizr indique que le navigateur
* n'implémente pas les gradients
* (ou n'exécute pas le JavaScript) */
background: url("images/glossybutton.png");
}
.cssgradients .glossy {
/* Modernizr indique que le navigateur comprend les gradients */
background-image: linear-gradient(top, #555, #333);
}Il permet aussi facilement de charger des polyfills JavaScript pour implémenter les fonctionnalités manquantes
Fondamental pour obtenir relativement facilement un résultat identique partout — mais ne dispense pas de faire attention à l'accessibilité et aux clients sans JavaScript !
Le principe de CSS est de modifier le style par défaut du HTML
Mais les navigateurs ont des styles par défaut différents, et les internautes peuvent les avoir modifiés
Idée des CSS resets : partir d'un CSS unifié, en particulier avec la plupart des marges et paddings à 0
/* http://meyerweb.com/eric/tools/css/reset/
* v2.0 | 20110126
* License: none (public domain)
*/
html, body, div, span, applet, object, iframe,
h1, h2, h3, h4, h5, h6, p, blockquote, pre,
a, abbr, acronym, address, big, cite, code,
del, dfn, em, img, ins, kbd, q, s, samp,
small, strike, strong, sub, sup, tt, var,
b, u, i, center,
dl, dt, dd, ol, ul, li,
fieldset, form, label, legend,
table, caption, tbody, tfoot, thead, tr, th, td,
article, aside, canvas, details, embed,
figure, figcaption, footer, header, hgroup,
menu, nav, output, ruby, section, summary,
time, mark, audio, video {
margin: 0;
padding: 0;
border: 0;
font-size: 100%;
font: inherit;
vertical-align: baseline;
}
/* HTML5 display-role reset for older browsers */
article, aside, details, figcaption, figure,
footer, header, hgroup, menu, nav, section {
display: block;
}
body {
line-height: 1;
}
ol, ul {
list-style: none;
}
blockquote, q {
quotes: none;
}
blockquote:before, blockquote:after,
q:before, q:after {
content: '';
content: none;
}
table {
border-collapse: collapse;
border-spacing: 0;
}L'idée est d'adapter son CSS reset à ses préférences. On peut ainsi repartir d'un style de base bien connu, sans surprise.
Le projet normalize.css est une alternative aux CSS resets
Au lieu d'effacer les styles par défaut des navigateurs, les conserve mais les rend cohérents
une page avec pour seule feuille de style normalize.css
s'affichera de la même façon sur tous les navigateurs
Corrige quelques bugs et incohérences par rapport aux spécs
Code modulaire, très clair et lisible (notamment pratique dans les outils de développement du navigateur)
Pas de JavaScript, simplement une feuille de style
Vivement conseillé !
(Une alternative : sanitize.css reprend les mêmes principes,
mais inclut aussi des décisions plus pragmatiques bien que non standard
(ex. : box-sizing:border-box
et background-repeat:no-repeat par défaut pour tous les éléments)
Pour diverses raisons, la syntaxe CSS est très limitée
il y manque des choses basiques auquel toute personne qui programme un peu est habituée : variables, fonctions/macros, imbrication du code…
Les pré-processeurs les plus utilisés sont SASS et LESS
La syntaxe SASS, appelée SCSS, est assez élégante et est une extension de CSS (càd que tout CSS valide est aussi du SCSS valide)
En CSS, on se retrouve souvent à réécrire le même genre de code : les designs changent superficiellement, mais la plupart des éléments restent fondamentalement les mêmes
On finit souvent par avoir un ou plusieurs projets-types dont on repart pour tout nouveau travail
Certain·e·s s'efforcent de rendre ces « modèles » les plus généraux et simples à utiliser possibles, et les diffusent. On parle de frameworks CSS
Il y en a de nombreux, plus ou moins complets et lourds ; les plus connus et utilisés sont Bootstrap et Foundation. Parmi les plus récents on peut citer Semantic UI
Autre exemple : Skeleton, qui est beaucoup plus léger (presque plutôt un reset qu'un framework)
Il y a encore de nombreuses choses dans le CSS que ce cours n'a pas mentionnées ou à peine survolées
Les navigateurs implémentent sans cesse de nouvelles propriétés, un exemple récent est le blending d'images en CSS (ne fonctionne que sous les versions récentes de Chrome, Firefox et Opera)
il faut faire un minimum de veille technologique
Liste de flux RSS sur le dév front-end avec de bonnes ressources (en anglais…) qu'il est intéressant de suivre (pas mise à jour depuis longtemps, mais la section « Must Read » est toujours valide et déjà suffisante). Même chose, plus récent, et carrément exhaustif (mais format moins agréable à lire « à l'œil nu »)