La tête dans le Flux !

Il y a un peu plus d'un an, je découvrais les Préprocesseurs CSS.

Il y a un an, presque jour pour jour, j'ai confié que je ne trouvais pas vraiment d'intérêt aux Préprocesseurs CSS.

Quelques mois plus tard, j'en tombais amoureux et j'avouais que je commençais à avoir du mal à m'en passer (notamment pour les variables et quelques fonctionnalités pratiques)... KNACSS est à présent principalement construit à partir de LESS, et j'en ai même préfacé un livre.

Aujourd'hui, je trouve les Préprocesseurs toujours très pratiques, mais je rechigne de plus en plus aux nécessaires opérations intermédiaires (nommer ses fichiers en .less ou .scss, les compiler... avec des effets différents selon le type de compileur, etc.). Bref, ce n'est plus l'amour fou.

Nous sommes le 28 mars 2014 et mon intime sentiment est que... dans 6 mois au maximum, je n'utiliserai plus de Préprocesseurs.

Voilà, c'est dit.

Si la notion de "sémantique" peut signifier quelque chose pour des noms de classes CSS, c'est bien de pouvoir être lisible et compréhensible par des êtres humains.

En clair, rédiger des CSS maintenables c'est aussi et surtout se faire comprendre par ses collègues ou le nouveau stagiaire (ou soi-même dans 6 mois).

Bref, des CSS maintenables et sémantiques, c'est surtout ne pas choisir des nommages tels que pure-u-l-1-2 ou encore col-xs-4 col-md-offset-4 par centaines dans une feuille de style.

Un tableau récapitulatif ("cheatsheet") des classes et fonctionnalités de KNACSS vient de voir le jour ce week-end.

Vous y trouverez tout ce dont on a besoin pour se rappeler rapidement : 

des classes de base

des alignements et positionnements

des grilles avec gouttières et les autogrids

des tableaux, formulaires, icones

du responsive web design

des variables de configuration pour LESS et Sass

Attention, certaines parties (notamment les booléens) ne sont pas encore stabilisées et ne le seront que pour la version 3.0 de KNACSS prévue pour le mois de juin.

Vous pouvez récupérer ce PDF dans le tutoriel de KNACSS (ou sur ce billet en cliquant directement sur l'image ci-dessous).

Faites-en bon usage !

J'ai eu très récemment la chance (et un stress immense) de pouvoir présenter une conférence lors des TechDays 2014 de Microsoft.

De prime abord, il est assez difficile de se représenter l'ampleur de cet événement (gratuit) : durant trois journées le Palais des Congrès accueille plus de 19000 personnes (chiffres de l'organisateur ;)) concernés de près ou de loin (souvent assez loin d'ailleurs, vu le nombre de Mac que j'ai croisés) par les technologies ou produits Microsoft.

Pour résumer, on a encore un peu de chemin avec notre KiwiParty ;)

J'y ai donc présenté "Le futur du Responsive Web Design" dans un amphi de plus de 700 spectateurs plein (EDIT : en fait c'était 826), tout en étant filmé et retransmis en live sur internet. Bref, le bon gros stress, les jambes qui tremblent et assez peu d'assurance dans mon discours, mais je pense que ça aurait pu être pire ;)

EDIT : la vidéo de la conf est disponible sur le Replay de la MS Techdays TV.

J'en ai profité pour assister à quelques autres conférences dans le domaine du Web :

"CSS c'est pas si facile !", par Vincent de Oliveira. Un (excellent) remake de sa présentation de la KiwiParty. PAs de conf "waouh", pas de CSS4 qui bouge partout, juste du CSS "normal" que l'on connaît mal. Vincent maîtrise très bien son sujet et je suis prêt à parier que n'importe quel intégrateur, même celui qui pense très bien connaître CSS, va beaucoup apprendre de cette conf.

"Tour d'horizon de NodeJS", par Christophe Porteneuve. Excellent showman et trolleur, Christophe est également expert dans son domaine et le laisse transparaître aisément. Conférence claire, démo un peu foireuse au départ mais vite rattrapée. J'ai trouvé la présentation globalement un peu trop théorique, et j'ai bien aimé la question finale d'un spectateur : "mais au fait c'est quoi NodeJS ?", parce que oui, Christophe avait un peu omis ce genre d'introduction :)

"Les nouveautés d'HTML5 et IE11 en action", par Philippe Didiergeorges. Conférence agréable dans l'ensemble, où j'ai pu découvrir pas mal de choses que je ne connaissais pas sur IE11 mobile. Par contre, j'ai trouvé que le choix et l'intérêt des sujets traités était assez mitigé : on est passé de spécifications très techniques (par ex. CSS snap points) à des parties d'ergonomie pure qui ne ciblaient pas forcément le même public (par ex. les live tiles)

"Compatibilité Internet Explorer : pour le meilleur et pour le pire!", par Daouda Ndiaye et Pierre-Louis Coll. Fin de la journée et mal de tête aidants, je n'ai pas été très fan de cette présentation : globalement assez terne, mal rythmée et desservie par des slides souvent imbuvables.

Au final, j'ai des avis schizophréniques au sujet de cet événement :

En tant qu'orateur, c'était un moment exceptionnel à vivre, je le souhaite à tout le monde !

En tant que professionnel, j'ai été globalement satisfait de ce que j'ai pu suivre et apprendre, avec un petit regret de ne pas avoir eu beaucoup de choix de conférences web

En tant que spectateur, j'ai un avis mitigé : l'infrastructure est extraordinaire. Par contre, un gros défaut global de connexion Wi-Fi (voire data), qui s'est révélé désastreux pendant les démonstrations des plénières où tout fonctionne (ou pas) grâce au Cloud. Et quelques petits problèmes d'organisation : retards dans les horaires... dès la première conf, grosses queues en entrées d'amphis, etc.

Le billet est un peu vieux, mais au final rien n'a vraiment changé...

La KiwiParty 2014 aura lieu le 13 juin, c'est à présent officiel.

À l'heure actuelle, l'appel à orateur n'a pas encore été lancé mais ça ne saurait tarder.

En attendant, je me prends à rêver des personnes que je souhaiterais vivement voir venir lors de notre petit événement strasbourgeois. (Je sais, je ne devrais pas faire le difficile : on a déjà eu énormément de chance d'avoir de grands orateurs les années précédentes).

Ma liste-cadeau côté orateurs (oui il y en a plein, mais on peut bien rêver, non ?) :

Thierry Koblenz

Mathieu Nebra

Stéphane Deschamps

Nicole Sullivan

Kaelig Deloumeau-Prigent

Corinne Schillinger

Jonathan Verrechia

Lea Verou

Stéphanie Walter

Ethan Marcotte

Paul Irish

Tim Berners-Lee

Chris Coyier

Vitaly Friedman

Et ma liste-cadeau côté sujets de conférences :

Des outils d'automatisation des tests et régressions en développement (par exemple CasperJS)

Une conf un peu "technique" en accessibilité (par exemple les rôles / landmarks ARIA)

La typographie (par exemple si quelqu'un arrive enfin à m'expliquer clairement ce qu'est le line-height en CSS !)

Le Responsive Web Design côté serveur (RESS)

Yeoman, Grunt, Gulp pour les nuls

Un aspect de la gestion de projet web

Et pourquoi pas une ou deux conférences en anglais ? ;)

Il existe aujourd'hui des dizaines et des dizaines de solutions pour servir les bons formats d'image selon les types de périphériques, leurs tailles et leur densité de pixels.

Face à toutes ces bidouilles plus ou moins tordues (car aucune n'est parfaite), je me fais la réflexion que l'on se complique peut-être la vie pour pas grand chose au final.

Une histoire de concombre

Pour illustrer ma réflexion, mettons-nous dans une situation concrète : je souhaite afficher une image de concombre adaptée à tous les périphériques et ne pas charger inutilement un fichier trop lourd sur un device qui n'en aurait pas besoin.

Je prévois donc deux formats d'image (tailles et poids différents) :

concombre-mini.jpg

concombre-big.jpg

Et c'est parti !

Approche mobile-first

Mobile-first, c'est la Performance avant tout. En clair, le principe est de ne pas charger de ressources inutiles sur les devices les moins puissants ou de petite taille.

La démarche est donc la suivante :

Smartphone : je veux que concombre-mini.jpg soit chargé

Tablette : je veux que concombre-big.jpg soit chargé

Écran de bureau : je veux que concombre-big.jpg soit chargé

Démo : chargement conditionnel d'image selon la largeur de fenêtre

Approche Haute Densité ("Retina")

Dans cette approche, la qualité d'image prime : il s'agit de servir les images de taille plus grande aux écrans à haute densité de pixels (pixel-ratio).

Écran HD : je veux que concombre-big.jpg soit chargé

Écran non HD : je veux que concombre-mini.jpg soit chargé

Démo : chargement conditionnel d'image selon la densité de pixels

Approche Connexion

Troisième paramètre de l'équation, le type de connexion internet et sa rapidité : l'idée est de ne charger de grosses ressources que si le réseau est bon.

Bonne connexion (Wi-Fi, ADSL, etc.)  : je veux que concombre-big.jpg soit chargé

Mauvaise connexion (2G, edge, 3G) : je veux que concombre-mini.jpg soit chargé

Démo : chargement conditionnel d'image selon la qualité du réseau 

On remixe tout ça, la formule magique !

En reprenant ensemble les trois critères, et de manière totalement subjective (car c'est mon avis), j'obtiens cette formule :

Bon débit ET (Grand écran OU Haute densité) = concombre-big.jpg

Le problème est qu'il est complexe de détecter la connectivité de manière fiable, en attendant un bon support de l'API Navigation Timing.

Démo : chargement conditionnel d'image selon les 3 critères cumulés 

Conclusion

En attendant, les implémentations W3C de picture ou de srcset (ou encore de image-set), on va sans-doute se consoler avec les "Compressive Images" qui me paraissent être une bonne stratégie pour allier à la fois "Mobile-first" et "Retina".

Pour ce qui est de la connectivité, c'est une autre histoire...

Le problème implique à présent une notion supplémentaire, celle du choix : en tant qu'utilisateur, je peux très bien être en 3G et vouloir une qualité retina. Ou pas. Mais c'est mon choix.

Ce n'est pas un scoop, les choix techniques de navigations mobile sont loin d'être évidents : JavaScript ? Pas JavaScript ? CSS pur ? jQuery ? 

Si l'on est tenté de s'abstenir complètement de JavaScript, les solutions CSS pures sont une alternative intéressante mais pas dénuée d'inconvénients non plus (manque de compatibilité, comportements hasardeux), d'autant plus que les événements "classiques" tels que :hover doivent être proscrits.

Les événements restants se comptent sur les doigts d'une main : :focus, :target, :checked, :valid et peut-être encore l'un ou l'autre qui me serait sorti de l'esprit.

Chacune de ces solutions a son pendant :

:focus sur mobile ne permet pas de fermer le menu de navigation simplement en re-cliquant sur le bouton

:target, outre le souci identique à :focus, "casse" l'historique de la navigation et impose d'actionner plusieurs fois sur le bouton Précédent pour revenir à la page précédente

:checked et :valid sont moins compatibles et nécessitent d'ajouter des éléments HTML de formulaires (label + input checkbox) au sein du menu pour le rendre fonctionnel, ce qui peut heurter les plus puristes d'entre-nous.

Vous pouvez constater ces comportements sur la page des snippets de navigation responsive que j'ai concoctée.

Retour sur :focus

Suite à de nouveaux tests, je viens de publier aujourd'hui une variante de ma navigation au :focus.

Cette variante bénéficie d'un avantage indéniable : celui de pouvoir refermer le menu en re-cliquant sur le bouton.

L'astuce est finalement assez simple : lors du focus sur le bouton d'ouverture (symbole "≡"), celui-ci disparaît (opacity: 0), mais génère en CSS via :before - sur l'élément qui lui succède - un bouton de fermeture (symbole "✖") qui s'affiche par-dessus.

En cliquant sur ce bouton de fermeture, le bouton initial perd donc le focus et le menu de navigation se referme.

Cette solution me paraît plutôt encourageante, même si je reste frustré de ne pas avoir pu atteindre le même objectif en employant tout simplement pointer-events: none; encore trop peu compatible.

Un avis sur cette variante ? 

NOTE : le menu est prévu pour fonctionner sur smartphone, pas sur tablette.

Depuis hier, une amélioration notable vient d'être apportée à Schnaps.it : la récupération automatique des dernières versions de KNACSS (fichiers CSS et LESS).

Schnaps.it est un outil de génération de templates HTML5 basé sur KNACSS et réalisé par Laetitia dans le cadre de son stage chez Alsacréations.

Dorénavant, il n'est plus nécessaire de procéder à la tâche fastidieuse de vérifier si sa version de KNACSS est à jour, cette mission est réalisée de manière automatique : grâce à Guillaume, lorsque vous téléchargerez votre template HTML5 Schnaps.it, ce sera forcément avec la dernière mouture de KNACSS CSS et LESS !

Cette fonctionnalité fait de Schnaps.it un véritable "starter kit" pour débuter tous vos projets web.

Pour faire suite à un billet précédent à propos des plugins et raccourcis de mon éditeur fétiche Sublime Text, je continue sur ma lancée en mettant à disposition mon lot de snippets personnalisés (que j'utilise quotidiennement).

Les snippets sont des bouts de code HTML/CSS/JS/etc qui fonctionnent sous forme d’autocomplétion avec la touche “tab”.

Où les trouver ?

Ma liste de snippets (mis à jour régulièrement) à télécharger ici : http://kiwi.gg/snippets

Comment les installer ?

Copiez les fichiers sur votre disque à cet endroit : C:\Users\*****\AppData\Roaming\Sublime Text 2\Packages\User

Comment s'en servir ?

Voici la liste, non exhaustive, des raccourcis existants (fonctionne avec touche Tab) :

@media → @media (max-width: 640px) {}

media → @media (max-width: 640px) {}

content → du contenu-type HTML (titre, navigation, paragraphes)

css → <link rel="stylesheet" href="styles.css" media="all">

doctype → feuille HTML5 de base

doctypemini → feuille HTML5 miniature de base

ie → <!--[if IE]> <![endif]-->

ie7 → <!--[if lte IE 7]> <![endif]-->

knacss → version complète et à jour de KNACSS.css

list → crée une liste ul/li de 5 éléments

lorem → crée du texte schnapsum

loremp → crée 3 paragraphes de schnapsum

navi → crée une navigation HTML5

noie → <!--[if !IE]><!--> <!--<![endif]-->

unicode → affiche une liste de caractères unicode utiles

viewport → <meta name="viewport" content="width=device-width,initial-scale=1.0">

Le concept de "survol" d'élément sur mobiles (périphériques "touch") a toujours été assez incongru.

Pourtant l'événement CSS :hover, que l'on retrouve historiquement sur un grand nombre de menus déroulants par exemple, est plutôt bien  supporté par les périphériques mobiles.

En effet, les "touch devices" reconnaissent :hover lors du tap au doigt sur l'événement, un peu comme s'il s'agissait d'un clic (malgré un délai d'attente de 300ms).

Mais tout ça risque de se compliquer dans les prochains temps...

Il se trouve que certains périphériques ont d'ores et déjà laissé tomber cette mauvaise interprétation de :hover et ne le supportent plus comme on pouvait l'espérer jusque là.

C'est le cas par exemple, les derniers smartphones et tablettes sur Windows 8 : un menu déroulant basé sur CSS :hover ne fonctionnera plus puisqu'il se refermera dès que vous décollerez le doigt.

En clair, vous pouvez ouvrir le menu global, mais ne pourrez pas atteindre les liens qu'il contient.

Alors que faire ?

Détecter le touch (modernizr, zeptoJS), ou au pire employer d'autres événements (JS onclick, CSS :focus, :target, :checked),

Utiliser des événements appropriés tels que Pointer Events,

Employer des alternatives pour les vieux navigateurs tels que HandJS

On le sait depuis un certain temps, Windows Phone 8 (et IE10) supporte désormais CSS @viewport. Et on sait également que ce support est buggué et à présent corrigé.

Mais, je viens de constater un nouveau problème de viewport, provenant cette fois de la meta HTML <viewport> et qui remet en question la conclusion de mon article "Viewport : adieu width=device-width ?".

Le constat est celui-ci : sur un smartphone Windows Phone 8.0 / Internet Explorer 10 en orientation Paysage, la valeur "initial-scale=1.0" est buggée et ne permet pas de s'adapter à la valeur réelle du viewport : la valeur reste identique à celle en portrait.

En clair, il s'agit du bug inverse de celui constaté sur iOS ! Sur iOS, initial-scale corrige un bug dû à width=device-width; sur WP8 width=device-width corrige un bug dû à initial-scale.

Conclusion (spoiler) : il semble que la combinaison parfaite soit finalement la meta suivante :

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Captures d'écran sur un Nokia Lumia 1020 / Winphone 8 (avec IE10 mobile, UCbrowser et Maxthon) :

1- Format Portrait

Tout est OK, quelles que soient les valeurs dans la meta <viewport>. La valeur de viewport correspond à 320px :

2- Paysage et initial-scale=1.0 seul

Le périphérique conserve la valeur de 320px alors qu'elle devrait être de 480px, d'où le zoom global d'affichage :

3- Paysage et width=device-width seul

La valeur de viewport passe, comme souhaité, à 480px :

Attention, cette déclaration (width=device-width seul) est buguée sur iOS paysage.

4- Paysage et with=device-width, initial-scale=1.0

Là aussi, le viewport passe à 480px, comme espéré :

Cette dernière combinaison semble finalement la plus robuste sur l'ensemble des périphériques puisqu'elle est également satisfaisante sur iOS iPhone, iPad et Android.

Parce que tous les intégrateurs sont aussi très joueurs, je vous propose un petit quiz rapide.

La question est simple : pouvez-vous me dire, sans tricher bien entendu, quelle est la taille du div dont les propriétés CSS sont indiquées ci-dessous ?

div { background: pink; min-width: 600px; max-width: 200px; width: 400px; }

Nous partons du principe que seuls ces propriétés s'appliquent, que le div contient du contenu et qu'il dispose de toute la place nécessaire au sein de son parent.

Je précise que l'ordre des déclarations CSS ne change rien à la solution !

Je donnerai la solution (et les explications) dans une paire de jours...

Note : la réponse n'est pas "ça dépend" ;)

EDIT 16/10/2013 :

Merci à tout le monde d'avoir participé. La réponse n'était pas aussi évidente qu'on peut le croire puisque beaucoup se sont trompés.

La réponse est : ... 600px.

Il suffit de se référer à l'algorithme de calcul dans les spécifications (merci Stéphanie Walter) :

s'il n'y a pas min/max, c'est width qui gagne

si width est plus grand que max-width, c'est max-width qui gagne

si width est plus petit que min-width, c'est min-width qui gagne

L'ordre d'exécution est important, c'est l'ordre de la liste, donc 1 puis 2 puis 3. Au final,  c'est min-width qui l'emporte.