Blueprint et 960 Grid System sont deux frameworks CSS que j’ai utilisés parmi les 25 que j’ai recensés et survolés dans Choisir un framework CSS. J’ai ainsi pu me faire une idée plus précise de leurs qualités respectives. Je ne me suis pas attardé sur les aspects typographiques — même s’ils ont leur importance : j’ai préféré faire l’analyse du système de grille de mise en page (grid.css et 960.css). Pourquoi comparer ces deux frameworks ? Tout simplement parce qu’ils proposent pratiquement les mêmes «fonctionnalités» avec quelques différences dans la mise en oeuvre. Après une rapide introduction sur Blueprint et 960 Grid System, vous trouverez dans la suite de cet article une comparaison et une explication de code. →
CSS3, Please! Générateur de CSS3 Cross-Browser
CSS3, Please! — Une belle page éditable avec l’essentiel des propriétés CSS3 : border-radius, box-shadow, Gradient, RGBa(), Transition, @font-face, etc. avec les filtres Microsoft pour IE6/7 et IE8 qui vont bien (ou mal). Un bloc de contenu reflète automatiquement les changements apportés aux déclarations avec la possibilité de désactiver les effets les uns après les autres pour mieux les percevoir. CSS3, Please! est certainement l’un des meilleurs générateurs de CSS3 disponibles. →
Générateurs de CSS3 pour tous les navigateurs (ou presque)
Même si tous les navigateurs ne prennent pas en charge les spécifications CSS3, il est intéressant de se pencher dessus, d’autant plus de que nombreux générateurs en ligne sont là pour adoucir la courbe d’apprentissage. Au menu : des générateurs de propriétés CSS3 comme border-radius, gradient, box-shadow, text-shadow, RGBa, @font-face, Multiple Columns, etc. ; des effets de texte et une palanquée de ressources complémentaires. →
Navigateurs «modernes» vs «actuels»
Ne cibler que les navigateurs modernes grâce aux sélecteurs avancés — Astuce très intéressante de Raphaël Goetter pour cibler les navigateurs «modernes» ou les navigateurs «actuels». Les «modernes» sont les navigateurs qui prennent en charge les CSS3 ; les «actuels» (opposés à anciens) sont surtout Internet Explorer 7 et 8. Idéal pour mettre en oeuvre l’amélioration progressive sur votre site web. →
HTML5 — Repenser le découpage des pages web et des contenus
Derrière les nouvelles balises proposées par HTML5 se cache un nouveau modèle de structuration. Jusqu’à présent, on rencontre souvent la structure suivante : un niveau de titre `h1` pour le nom du site et ça continue avec `h2` pour le titre des articles ; reste `h3` — `h6` pour structurer la prose, ce qui est suffisant ou pas. HTML5 introduit la notion de Sectioning Content (cf. le concept d’outline) de manière explicite avec les balises `section`, `nav`, `article` et `aside` ou de manière implicite a chaque utilisation d’un niveau de titre `h1`. →
html5media — Les balises HTML5 audio et video sans contrainte
Les balises HTML5 `video` et `audio` permettent d’incorporer du son ou de la vidéo dans une page web aussi simplement que s’il s’agissait d’une image. Mais comme le roi et la reine ne le veulent pas tous les navigateurs ne prennent pas en charge ces charmantes nouveautés, html5media a eu la bonne idée de rendre possible l’utilisation des balises `audio` et `video` sans se soucier de la compatibilité : le script se charge de fournir un player Flash (flowplayer) pour les navigateurs à la traine ! →
Ajouter une classe CSS dans BODY ou HTML pour Internet Explorer (IE6 — IE9)
Toujours dans ma recherche de solution pour servir des déclarations CSS uniquement à Internet Explorer, je suis tombé sur une technique que j’appellerais «classification» sélective du `body` (ou de la balise `html`) en fonction du navigateur. Une fois encore, les commentaires conditionnels serviront à détecter Internet Explorer pour ajouter une classe à la balise `html` pour éviter de créer une feuille de style dédiée à IE. →
HTML5 — Et si on évitait la balise «section» dans une balise «article» ?
Ce billet fait partie d’une série de notes rapides prises lors de ma lecture des spécifications HTML5. Aujourd’hui, c’est le commentaire de Romy qui me donne l’occasion de rebondir sur le découpage d’une page web avec HTML5 et plus particulièrement la balise `section`. Dans ce billet, je m’éloigne un peu du commentaire de Romy et je voudrais souligner qu’elle a parfaitement raison quand elle dit que le rôle des balises `header` et `footer` est clair mais que leur traduction en En-tête et Pied de page prête à confusion ; il faudrait peut-être introduire la notion de meta information. →
HTML5 — Pourquoi «header» et «footer» ne créent pas de «sections»
Les nouvelles balises introduites par HTML5 ne sont pas très évidentes à utiliser. Plus que jamais, le contenu est roi et tout dépend de lui. Les notions de Sectioning Content implicites ou explicites risquent de se transformer en poil à gratter pour les intégrateurs web. Pour commencer, notre balise `div` préférée devra laisser du terrain à la balise `section` quand on pourra justifier d’un `h1` à l’intérieur. →
HTML5 — Pas de balise aside dans un hgroup ?
Après Une orientation encore trop « littéraire » et pas assez « web » je m’interroge aujourd’hui sur un autre aspect des spécifications HTML5 : cette tendance à dire aux éditeurs de contenus comment il doivent écrire ou mettre en forme leurs documents. Aujourd’hui, j’ai eu la surprise de voir une page rejetée par le validateur au motif qu’un Element aside not allowed as child of element hgroup in this context
. Autrement dit, un élément aside n’est pas autorisé à être enfant d’un élément hgroup. C’est agaçant parce que je trouvais que mon marquage en avait sous la santiag : →