book

CSS maintenables

by Kaelig Deloumeau-Prigent

July 2012

Intermediate to advanced

272 pages

5h 35m

French

Eyrolles

Read now

Unlock full access

Pourquoi ce livre ?À qui est destiné ce livre ?Structure du livreRemerciements
Aux débuts : pas de CSS, ni d’intégrateurs webL’apparition de la feuille de style comme livrableCSS aujourd’hui : l’importance des standards, l’impact des navigateursLe futur des CSSUn web adaptatifLes régions CSSLes exclusionsLa liberté typographiqueNouvelles structures de langage
Apprendre les CSS : l’incontournable théorieComprendre les CSS, c’est comprendre les navigateursUne affaire d’expérienceÊtre en veille constanteLes sites et blogs spécialisésSmashing magazineA list apartAlsacréationsPompage.netOpenWebWeb design friday24 WaysCSS4 designMais aussiAide entre développeursÀ l’aide, j’ai un problème insoluble !Isoler le problèmeOutils, partage et entraideDocumenter son code pour référenceLes logiciels libres : un gisement inépuisable d’exemples

Un <head> à toute épreuveLe doctypeUn élément <html> polyvalent avec modernizrLe mode compatibilité d’internet explorerL’encodage unicodeRécapitulatifreset.css : réinitialisation des stylesLe reset universel : à éviterLes reset.css sélectifsBien ranger ses fichiersUn seul fichier ? attention aux débordementsÀ chaque fichier sa fonctionreset.csstypo.csslayout.cssforms.cssglobal.cssapplication.cssprint.cssÉcrire un code lisibleConventions syntaxiquesNotation multiligne ou monoligne ?Round 1 : lisibilité et maintenabilitéRound 2 : CSS3Round 3 : gérer le suivi des versionsVainqueur du matchL’indentation : la clé de la lisibilitéAu sein d’un sélecteurRelations entre les sélecteursIndenter les valeurs CSS3Classer les propriétésPar ordre alphabétiquePar type de déclarationUtiliser les raccourcisDocumenter son codeAvant même de documenter, écrire un code expliciteSyntaxe des commentaires CSSQuand ne pas (trop) documenter ?Dégradation gracieuse et amélioration progressiveDégradation gracieuse : la tolérance à l’erreurAmélioration progressiveSimplifier un design trop complexeTester, encore et encoreTests d’interopérabilité (multinavigateur)Tests de non-régressionUne page pour tester tous les styles : le pattern portfolio
Mythe n°1 – Pas d’informations de présentation dans le HTMLMythe n° 2 – Ne pas utiliser d’éléments non sémantiquesMythe n° 3 – On ne doit pas créer de classes non sémantiquesMythe n° 4 – Le rendu doit être le même dans tous les navigateursMythe n° 5 – La taille du texte ne doit pas être exprimée en pixels
Pourquoi utiliser un framework CSS ?Ne pas réinventer la roueTravailler en équipePrototyper rapidementDécouvrir pour apprendreQuand ne pas s’en servirFrameworks les plus populairesBlueprint, le « tout-en-un »Twitter bootstrap, adaptatif et responsable960.gs : une simple grille de mise en pageHTML5 boilerplate : un concentré de bonnes pratiquesOOCSS : CSS orientées objetObjets CSSSéparation de la structure et de l’apparenceExemple : boutons d’actionSéparation du conteneur et du contenuExemple : liste d’actualitésDévelopper son propre framework ?Pourquoi posséder son propre framework ?Productivité, capitalisation d’expérienceMaîtrise de la compatibilité FlexibilitéCollaboration
La communication avant toutAvec les graphistesAvec les développeursConventions de codageConventions syntaxiquesInstaller des conventions de nommageUn code accessible aux débutantsLes erreurs à ne pas commettreRéinventer la roue (carrée) Ne pas documenter son code Factoriser prématurément le codeNe pas testerSe laisser tenter par des techniques « dernier cri »Varier les conventions de nommageNe pas communiquerGérer les versions avec GitDe l’intérêt d’un outil de gestion de versionsPrésentation de Git
Un préprocesseur, pour quoi faire ? L’approche DRY : simplicité et élégance du codeÉtendre les possibilités de CSSUn code valide à tout momentFautes de frappe, oublis… l’erreur est humainePréprocesseur = validateur à la voléeLESSSassGoogle closure stylesheetsStylusCSS scaffold
Premiers pas avec SassInterfaces graphiquesCompass.appScoutCodeKitLiveReloadInstallation en ligne de commandeSous Mac OS X et LinuxSi l’opération n’a pas fonctionné sous MacSous WindowsOutil en ligne de commandeConvertir un fichier en Sass Surveiller un dossier : conversion à la volée en temps réelSyntaxe et fonctionnalités de SassSyntaxe de base de SassRègles imbriquéesSélecteurs avancésRéférencer le sélecteur courantRéférencer les sélecteurs parentsCommentairesLes variablesLes mixinsDéfinir un mixin : @mixin Appeler un mixin : @include ArgumentsHéritage de classe : @extendInclure un fichier : @importLe module de couleursNormalisation automatiqueOpérations sur les couleursTransparence, opacitéSaturationVarier la luminositéBonnes pratiques en SassMixins : attention au surpoidsImbrications : la règle de l’inceptionUn problème répanduLe cauchemar de la surimbricationLa règle de l’inceptionPerformances : concaténer et compacter les CSSCompass : un métaframeworkPremiers pas avec CompassCompass dans la pratiqueReset.css en une lignePlus jamais d’images manquantesDes images et des fontes embarquéesDimensions d’une imageDes sprites sans aucun effortRappels sur les sprites CSSPrésentation du module de sprites de CompassCréer un bouton avec CompassCSS3 facile sans préfixeQu’est ce qu’un préfixe constructeur ?Box-shadowBorder-radiusDes dégradés sous tous les navigateursTransformationsTransitions
L’usage des CSS sur le web aujourd’huiLes différents producteurs de feuilles de styleOutils pour diagnostiquerL’inspecteur web et FirebugDiagnostic en ligne avec CSS lintLes styles inline (dans la source du HTML)La guerre des règles !importantLes règles surspécifiéesLa multiplication des propriétés
Étudier le designDéduire des motifs récurrentsDéfinir la base typographiqueCoder la structure généraleCoder les modulesÉtape finale : les exceptions
À partir de quand, et jusqu’à quel point optimiser ?Étape 1 : utiliser les variables à bon escientLes couleursLes jeux de policesLa grille de mise en pageGénérer une grille de mise en page simple et maintenableÉtape 2 : séparation en plusieurs feuilles partiellesÉtape 3 : imbrication des sélecteurs Étape 4 : création de mixinsIdées de mixinsÉtape 5 : extensions de classesExemple : étendre une boîte arrondieExemple : optimiser un mixinBonus : débogagecross-browser sans hacksMéthode 1 : classes et commentaires conditionnelsMéthode 2 : feuilles de style séparées avec SassLe principeEn application

Content preview from CSS maintenables

Les frameworks CSS

Un framework CSS est un ensemble de règles et d’éléments prêts à l’emploi, dont l’intérêt est de faire gagner du temps aux développeurs au démarrage d’un projet. Un excellent point de départ donc, qui ne s’applique toutefois pas à tous les usages, comme nous allons le voir…

Pourquoi utiliser un framework CSS ?

Utiliser un framework CSS n’est pas une évidence dans tous les cas et pour tout le monde. Malgré les réticences de certains développeurs, il est toutefois souvent intéressant d’envisager leur implémentation dans des projets web pour les services qu’ils rendent : rapidité de développement, documentation, robustesse…