hs0ucy

vanille & font selon-moi une excellente équipe!

hs0ucy

La sortie d'Internet Explorer 8 vue par John Resig

1 min read

En me promenant sur le Web, je suis tombé par hasard sur un billet de blogue de John Resig, le créateur de jQuery, qui commente la sortie du navigateur web Internet Explorer 8. Nous sommes en mars 2008 et tellement de choses ont heureusement changé depuis.

On peut y lire qu'il est content de voir enfin un outil à la «Firebug» faire son entrée dans ; et applaudit l'adoption de  «selectors API» qui permet l'utilisation de querySelector avec . De plus, il est agréablement surpris de voir les spécifications ARIA, SVG et MathML s'inviter dans cette version. Mais il est aussi déçu de voir l'absence de certains : les sélecteurs CSS 3, addEventListener, etc.

Bref, un retour en arrière que j'ai trouvé intéressant et instructif; surtout que c'est une bonne synthèse si vous avez à écrire du JavaScript «vanille» qui doit encore fonctionner sur IE 8 ;)

«JavaScript in Internet Explorer 8», par John Resig : http://ejohn.org/blog/javascript-in-internet-explorer-8/

hs0ucy

«WAI-ARIA 1.0 Authoring Practices» ~ http://www.w3.org/WAI/PF/aria-practices/. Ce document m'est très utile ces temps-ci.

hs0ucy

Quelques bonnes pratiques CSS

5 min read

DRY

Éviter la répétition (DRY). Dans les maquettes visuelles repérez les éléments qui sont communs et qui se répètent de page en page, puis faites-en des modules CSS. Pour être facilement réutilisables, les modules que vous allez créer ne doivent pas être trop complexes: small is beautiful. Ainsi vous pourrez combiner vos modules pour créer votre design. Exemples : OOCSS, Atomic Design.

Une autre façon d'être DRY, c'est d'utiliser des scripts d'automatisation de tâches, tels que Grunt ou Gulp.

Hello my name is...

Dans le CSS je vous suggère de définir des conventions de nommage (namespacing) et les expliquer en commentaire dans le code, afin que les gens qui modifient votre CSS puissent comprendre les objectifs de ces conventions. Exemple : BEM.

Moins de sélecteurs HTML

Dans vos modules CSS éviter le plus possible de mettre directement des sélecteurs HTML dans vos règles. De cette façon, vos styles sont moins dépendant de la structure sémantique du HTML. Il n'y rien de mal à mettre plusieurs classes sur un élément.

Alphabits

Je vous conseille de mettre les propriétés CSS en ordre alphabétique. C'est plus facile comme pour repérer une propriété dans des règles qui sont complexes.

@import

Éviter d'utiliser @import pour un site en production, car cela peut causer des problèmes de performances. On pourrait penser qu'en utilisant @import on réduit le nombre de fichiers chargés par le navigateur web, mais il n'en est rien. Attention, je ne parle pas ici du @import utilisé par SASS, mais celui que l'on retrouve dans le CSS «vanille».

Soyez une personne organisée

Catégorisez les règles CSS. Pour ma part, j'aime ça simple: abstractions/, base/, components/. Chaque composante ou chaque module, peut avoir sa propre feuille de style. Sinon, il y plein de méthodes pour organiser ses styles ITCSS, SMACSS, OOCSS, etc.

En production brocher vos feuilles

En mode développement ça peut être pratique pour classifier les règles CSS et d'avoir plusieurs feuilles de styles, mais en production il ne faut pas oublier de regrouper toutes vos feuilles de styles en une seule afin de réduire votre empreinte HTTP. Si vous utilisez SASS, il est facile d'automatiser la fusion des feuilles de style.

Pas trop d'IDs

Utiliser le moins possible les IDs dans vos règles CSS, utilisez plutôt les classes, elles sont plus facilement réutilisables et modulables. Vous pouvez garder les IDs pour les zones principales de votre document: En-tête, pied de page, contenu principal.

Minimisez les dépendances au HTML

Faire des sélecteurs les plus indépendants possible du contexte afin d'optimiser la réutilisation. Ex.: .h-sub-yellow-bold plutôt que h3. Donc faire des règles qui reflètent plutôt la présentation que la relation sémantique au HTML. De cette façon si la structure du document est modifiée (ce qui a de bonnes chances d'arriver), vos styles ont beaucoup plus de chances de survivre sans besoin d'intervention dans le CSS.

Concision

Écrivez des règles CSS concises. Les règles sont lus de droite à gauche par les navigateurs Web, donc moins vous avez de niveaux dans celles-ci, meilleure sera la performance de votre CSS. Idéalement ne jamais dépasser deux niveaux, mais l'idéal c'est bien sûre, de n'avoir qu'un seul niveau!

Par exemple cette règle est trop verbeuse: .list li .sublist li a {display:block;}. Celle-ci est beaucoup plus facile à lire, tant pour l'humain que pour la machine: .sublist a {display:block;}.

Focalisation et survol

Appliquer les styles de l'état :hover également à l'état :focus, afin d'améliorer l'expérience de l'utilisateur qui navigue à l'aide du clavier.

Encodage dans :after/:before

Dans la propriété content de :after ou de :before, il vaut mieux encoder les caractères spéciaux en hexadécimal pour éviter les problèmes d'affichage. Un outil comme Entity Conversion Calculator peut vous donner un coup de main pour convertir les caractères. Ex.: content:“|”; deviendrait content:“\007C”;.

Pas trop de police

N'ayez pas trop de polices Web sur votre site. La sur-utilisation de @font-face peut vous causer de sérieux problèmes de performances.

!important

Le hack !important ne doit être utilisé qu'en dernier recours. Si elles se retrouvent souvent dans vos règles CSS, c'est peut-être que celles-ci ont besoin d'être repensé.

hs0ucy

FrontendMasters.com : Classes de maîtres en développement web front-end

La liste des cours est attrayante et les tuteurs sont des personnes très compétentes, mais 39$ par mois c'est cher pour un individu.

hs0ucy

hs0ucy

Lecture du moment «Inverted Triangle CSS»

http://www.creativebloq.com/web-design/manage-large-scale-web-projects-new-css-architecture-itcss-41514731

hs0ucy