La tête dans le Flux !

Deux (ah non, cinq) tests de navigation mobile

Très rapidement, voici pour partage et discussion, quelques expériences de menus de navigation adaptés pour le Web mobile (redimensionnez la fenêtre si vous consultez à partir d’un ordinateur de bureau)

1. Premier menu (navigation défilant de la droite vers la gauche) : http://bit.ly/goetter-menu3
2. Deuxième menu (navigation défilant de la gauche vers la droite) : http://bit.ly/goetter-menu3b
3. Troisième menu (navigation défilant du haut vers le bas) :
   http://bit.ly/goetter-menu3c
4. Quatrième menu (navigation sur une ligne apparaissant par en haut) http://bit.ly/goetter-menu4
5. Cinquième menu (le corps de page descend et dévoile le menuà :
   http://bit.ly/goetter-menu5

Objectif et contraintes

Mes contraintes étaient celles ci : n’avoir aucune requête, aucun fichier à télécharger, ni aucun script à faire mouliner (bref : pas d’image, ni JavaScript, ni icon-font)

Compatibilités :

• OK sur iPhone3 Safari, iPhone4 Safari, Android 3, Android 4, Opera mobile
• Pas OK sur Firefox mobile, Opera mini et anciens navigateurs de manière générale

Attention : Ces expériences ont été réalisée rapidement et je n’ai pas testé sur tous les environnements existants. En clair, je ne suis pas responsable si tout explose :) (merci en passant à @walterstephanie pour les tests)

Ma participation à Web Event Lyon 2012

Le vendredi 15 juin prochain, j’aurai l’honneur de participer à la 4è édition du Web Event Lyon, au centre des congrès de Lyon.

J’y présenterai un thème qui me tient à cœur, en rapport avec les CSS, forcément.

Voici le contenu de cette présentation :

Parce qu’un jour CSS nous promet de ne plus avoir à nous torturer avec des bidouilles de positionnement, des bugs d’affichage, des hacks, des flottants mal employés, des position: absolute tordues, des position: relative ou des clear: both sortis de nulle part, du centrage vertical intuitif, toussa.

Un jour vous pourrez dire : j’y étais, c’était le bon vieux temps.
Mais pas encore.

On y parlera de diverses spécifications (en plein brouillon ou non) telles que : inline-block, CSS table, multicolonnes, flexbox, grid layout, float : position, regions, exclusions, CSS4, etc.

J’ai hâte d’y être ;)

Préfixes CSS : le pavé dans la mare

L’ogre WebKit

WebKit est un moteur de rendu libre et ouvert initialement lancé par Apple en 2003 et composé actuellement de nombreux développeurs de Google. Adobe participe aussi activement à Webkit car c’est le moteur de rendu utilisé dans toute leur suite.

Il est le cœur de très nombreux navigateurs de bureau (Chrome, Safari, Konqueror) mais aussi sur mobile (Safari mobile, Android, etc.).

En quelques années, il s’est imposé comme un acteur majeur du Web.

Plus important encore : Webkit va plus vite, plus haut et plus fort que les autres. Et ça excite les webdesigners.

Les préfixes vendeurs CSS

Les composants de CSS3 étant pour la plupart en cours d’élaboration à des stades divers, le souci de l’implémentation dans les navigateurs web devient problématique. En effet, si chaque module est susceptible d’évoluer, voire de changer, dans les mois ou années à venir, il est totalement contre-productif pour un navigateur de tenter d’adapter au jour le jour son traitement de toutes les propriétés fluctuantes.

Que faire alors ? Patienter jusqu’à l’aboutissement de chacun des modules ou modifier ses algorithmes à chaque modification des spécifications d’une propriété ?

Le Consortium W3C propose depuis CSS 2.1 une alternative qui a le mérite de ne pas bloquer l’évolution des agents utilisateurs : à partir des informations dispensées dans les spécifications, chaque navigateur a carte blanche pour construire ses propriétés personnelles dérivées en les faisant précéder d’un préfixe vendeur propriétaire. Lorsque la spécification atteint le stade de Recommandation Candidate (CR), le préfixe doit être supprimé.

Ainsi, Mozilla Firefox a pu développer sa propre variante -moz-border-radius pour permettre d’utiliser la célèbre propriété border-radius (définissant l’arrondi des coins d’un bloc), très récemment finalisée dans la norme CSS 3. L’avantage est que l’un et l’autre isotope de la propriété ont leur propre vie et peuvent être développés indépendamment, voire se distinguer… jusqu’au jour de la reconnaissance officielle de border-radius par le W3C, auquel cas sa copie propriétaire n’a plus de raison d’exister.

Les spécifications recensent une douzaine de préfixes propriétaires (appelés aussi préfixes vendeurs) dont les plus fréquemment rencontrés sont attribués aux navigateurs web principaux, à savoir :

• -moz- pour le moteur de rendu Gecko de Mozilla Firefox ou Thunderbird ;
• -ms- pour Microsoft Internet Explorer
• -o- pour Opera ;
• -webkit- pour les moteurs WebKit de Safari et Chrome par exemple ;
• -khtml- pour les moteurs KHTML (par exemple Linux KDE).

Cette convention évite les collisions de noms entre les fonctions standards et propriétaires, sans entraver les progrès des constructeurs de navigateurs. Toutefois, dans la pratique, cela contraint les auteurs à multiplier les écritures de déclarations de propriétés pour parvenir à un accord sur tous les navigateurs.

Opera annonce qu’il va supporter le préfixe -webkit-

Nous parvenons enfin au cœur du feuilleton : Opera a annoncé aujourd’hui qu’il allait implémenter très prochainement le préfixe -webkit- initialement “réservé” au moteur de rendu du même nom (sur son navigateur Opera Mobile dans un premier temps, puis sur l’ensemble de ses services).

L’explication est simple : WebKit est devenu l’unique référence pour de nombreux concepteurs web, qui ne prennent plus la peine d’ajouter les préfixes des autres navigateurs.

Pire, ils se contentent parfois de cette seule syntaxe, en occultant la syntaxe officielle finalisée sans préfixe.

L’expérience utilisateur s’en voit bien entendu dégradée sur un grand nombre de navigateurs, qui pourtant sont capables de reconnaître ces fonctionnalités CSS3.

Même dans le marché grandissant du Web mobile, où Opera est très représenté en terme d’usage,… tout le monde développe spécifiquement pour Android ou iOS, et le préfixe -webkit- est roi incontesté.

Opera a donc opté pour une solution radicale : supporter les propriétés préfixées par -webkit-. Cette décision a bien entendu levé un vent de panique dans notre microcosme.

Dans la pratique, Opera ne va pas implémenter les propriétés en triple exemplaire (-webkit-, -o- et sans préfixes) : seules certaines propriétés préfixées seront reconnues, et considérées exactement comme s’il s’agissaient de propriétés préfixées par -o- (un peu comme un alias).

En outre, cela ne concernera évidemment que les fonctionnalités déjà supportées par Opera.

Concrètement ?

En fait le principe est assez simple, le voici illustré par un exemple fictif :

• Chrome et Opera supportent tous les deux la propriété transition (CSS3 actuellement en working draft)
• Chrome (sous Webkit) la supporte avec le préfixe -webkit-transition
• Opera (sous Presto) la supporte aussi, mais avec le préfixe -o-transition

Malheureusement, très (trop) peu de webdesigners se contraignent à ajouter tous les préfixes et se contentent souvent de -webkit-.

Au final, il n’y aura pas de transitions sur Opera, bien que ce navigateur les supporte très bien.

La solution de repli d’Opera est d’interpréter les préfixes -webkit- et de les appliquer quand-même à condition qu’il reconnaisse la propriété concernée. Du coup, les transitions fonctionneront sur Opera… même en se contentant d’un -webkit-transition.

Hey mais les autres s’y mettent aussi ?!

Pour bien se rendre compte que le phénomène est loin d’être anodin, une réunion de discussion autour de ce thème est prévue prochainement.

Il y sera question de l’adoption du préfixe -webkit- par Mozilla Firefox ainsi que d’Internet Explorer, qui semblent très sérieusement envisager cette éventualité.

Ça va changer quoi concrètement ?

Pas mal de choses.

Pour commencer, c’est un aveu de plusieurs dysfonctionnements (notamment du W3C et de sa lenteur), et aveu de faiblesse devant l’ogre WebKit : soit on s’allie, soit on meurt.

Sinon, plus prosaïquement :

• Les concepteurs web auront encore moins besoin de se soucier des navigateurs tels qu’Opera, Firefox ou Internet Explorer
• La maintenance de sites web en production sera facilitée : inutile de devoir reprendre tous ses sites pour y ajouter des préfixes -o-,-moz- et -ms- dès que les mises à jour des navigateurs reconnaîtront une nouvelle fonctionnalité CSS3

Bref, la nouvelle guerre des navigateurs commence maintenant, attachez vos ceintures !

Un polyfill pour background-size cover et contain

CSS3 propose deux valeurs très pratiques pour la propriété background-size : cover et contain.

Ces valeurs permettent de couvrir des surfaces tout en conservant le ratio de l’image de fond, comme le montre ce petit exemple personnel.

Le seul hic de ces valeurs est (un peu de suspense)… le manque de support sur les anciennes versions d’Internet Explorer (IE6 à IE8 inclus).

Louis-Rémi Babé, développeur de talent, s’est amusé à concevoir et mettre en partage une alternative (polyfill) via jQuery que j’ai pu tester avec bonheur.

Le dossier de téléchargement ainsi que la page de démonstration sont en libre service (licence MIT), servez-vous :)

Papa, c’est quoi un mirage ? CSS3 mon fils !

Aujourd’hui, tout le monde parle de CSS3, tout le monde veut du CSS3, tout le monde s’extasie devant les démos faites en CSS3. Mais pourtant, CSS3 est un parfait mirage des temps modernes.

Voici le support des spécifications “CSS avancées” et CSS3 sur l’ensemble des navigateurs employés aujourd’hui :

Les chiffres sont éloquents : on ne peut raisonnablement pas employer CSS3 massivement en production aujourd’hui. Pour une raison simple : Internet Explorer.

J’ai bien commis un article semblant prôner le contraire, mais le constat est inéluctable : le support de CSS3 est quasi-inexistant sur IE6 à IE8 inclus. Point.

Même si IE6 et IE7 se meurent, leur frère IE8 n’est pas près de disparaître, et tout ce que IE8 sait faire, c’est reconnaître enfin la spécification CSS2 (12 ans après sa finalisation). Pour ce qui est de CSS3, il est dans les choux. Complètement.

De plus en plus de personnes souhaitent suivre mes formations CSS3, mais peu s’attendent à entendre autant de mauvaises nouvelles concernant sa compatibilité en production. Bien sûr il existe des alternatives, des “polyfills” et des bidouilles… mais un bon nombre de mes stagiaires espéraient vraiment pouvoir appliquer mes préceptes dans leur travail d’intégration au quotidien.

Au final (à cause de la “mode” ?), il passent à côté d’une multitude de bonnes pratiques vraiment utiles en production et facilitant la gestion d’un projet en CSS. Des CSS avancées et des bonnes pratiques datant de CSS2 bien entendu.

Je le répète encore : en 2012, il est grand temps d’apprendre… CSS2 !

Ne me faites pas dire ce que je n’ai pas dit : CSS3 est un outil qui s’annonce magnifique, mais en cours de rôdage et quasiment inutilisable en production sans concessions ou dégradation sur les anciens navigateurs.

Allez-y, tapez-moi dessus à grand coup de border-radius, même pas mal ! (PS : border-radius est compatible depuis… IE9)

media queries et performances web mobile

Ce billet fait suite à mes expérimentations continues concernant la performance web pour les mobiles. J’en étais arrivé à un billet nommé “comment cibler les mobiles de manière optimales (bis) ?”.

Voici la suite de mes élucubrations…

Un point sur l’existant

Il existe grosso-modo 6 méthodes d’application des CSS3 media queries :

1. un fichier CSS composé de styles généraux pour tous et de media queries pour mobiles.
   Problème : un navigateur mobile respecte les deux conditions à la fois (les styles globaux et ceux pour pour mobile), il va donc en toute logique charger les ressources… puis les masquer.
2. un élément <link> appelant une feuille CSS globale et une autre feuille CSS pour mobiles (via media queries).
   Problème : identique au précédent.
3. un fichier CSS unique composé de media queries exclusifs, par exemple @media (min-width : 641px) {…} / @media (max-width : 640px) {…}
   Problème : les anciens navigateurs dont Internet Explorer inférieur à IE9 ne reconnaissent pas media queries et n’auront qu’une page HTML brute de styles.
4. un élément <link> appelant des feuille CSS exclusives via media queries (une pour grands écrans et une autre pour mobiles).
   Problème : identique au précédent.
5. appliquer une rustine sous forme de commentaires conditionnels pour cibler les anciennes versions d’Internet Explorer.
   Problème : cette méthode nécessite une requête de fichier CSS supplémentaire, généralement non parallélisée.
6. se baser sur des alternatives JavaScript telles que Respond qui émule les media queries sur les anciennes versions d’Internet Explorer.
   Problème : cette méthode nécessite une requête de fichier JavaScript ainsi que son traitement par le navigateur.

Une méthode pour les réunir toutes ?

Plus j’y réfléchis, plus je suis persuadé qu’une solution intermédiaire est de distinguer 3 parties dans le fichier CSS :

1. les styles de base, qui doivent être affichés sur tous les supports (pas de media query)
2. les ressources lourdes, qui doivent être chargées uniquement sur écrans larges (via media queries)
3. les styles et adaptations spécifiques pour petits écrans (via media queries)

Grâce aux classes conditionnelles, nous pourrons également en faire profiter les anciennes versions d’Internet Explorer sans douleur.

Voici un exemple concret :

/* styles pour tous */
body {width: 960px; background: #fff;}

/* ressources CSS lourdes uniquement */
@media (min-width : 641px) {body {background: url(concombre_big.jpg);}}

/* ressources lourdes aussi pour IE6-IE8 */
.oldie body {background: url(concombre_big.jpg);}

/* styles pour petits écrans */
@media (max-width : 640px) {body {width: auto; background: url(concombre_small.jpg);}}

Au final, il me semble que tous les écueils de performance sont évités, au prix d’une répartition plus réfléchie des ressources.

Cette méthode a actuellement ma préférence car ne nécessite pas de fichier CSS (donc de requête) supplémentaire, ni d’alternative et de traitement via JavaScript.