La tête dans le Flux !

Prefix-free, pour ou contre ?

Sun, 12 Feb 2012 12:43:00 +0100

Nous avons publié récemment un article sur Alsacréations au sujet de -prefix-free, un outil générant automatiquement des préfixes vendeurs sur les propriétés CSS3, selon nécessité.

Cette ressource a certainement autant d’avantages que d’inconvénients…et donc autant de détracteurs que d’aficionados. Le premier argument, indiscutable, est tout simplement que JavaScript n’a théoriquement rien à faire dans une histoire de CSS pur et que rajouter une couche JS uniquement par flemme est un peu exagéré.

Soit. Mais en ce qui me concerne, je suis tout de même plutôt pour :)

Prenons un exemple simple : il y a quelques années, j’ai conçu un certain nombre de sites web avec des éléments avant-gardistes telles que des animations CSS3 (l’exemple choisi des animations vaut pour un large panel d’effets CSS3).

A cette époque, seul Webkit reconnaissait les animations et j’ai - en toute logique - appliqué uniquement un préfixe -webkit- sur mes propriétés.

Lorsque Firefox 5 a supporté les animations CSS3, j’ai eu deux choix : soit je laissais tous ces sites tels quels, donc sans animations sur Firefox; soit je les reprenais un par un et ajoutais un prefixe -moz- pour rendre mes animations compatibles sur ce navigateur. Les parts de marché de Firefox n’étant pas négligeables, j’ai opté pour la seconde alternative (c’est de l’humour, je l’aurais fait de toute façon, hein).

Le temps passant, j’ai continué à produire des sites web pour moi ou des clients, disposant de fonctionnalités CSS3 avec préfixes.

Puis, au fur et à mesure, Opera et Microsoft se sont mis à supporter toutes ces propriétés, avec leurs propres préfixes bien entendu.

Et là, autant dire que je n’avais pas forcément l’envie ni le temps de reprendre un par un tous les sites produits depuis quelques années.

Est-ce ma faute ? Aurais-je dû dès le départ proposer une demi-douzaine de préfixes sur toutes les propriétés CSS3 de tous les sites conçus depuis plusieurs années ? (au risque de surcharger des styles inutilement).

Je n’ai pas la réponse à cette question… mais en toute honnêteté, Prefix-free est une solution viable à ce problème. Grâce à cet outil, mes sites d’hier et d’aujourd’hui seront toujours, immédiatement et automatiquement supportés par le plus vaste panel de navigateurs possible, et s’adapteront à toute nouvelle version d’un navigateur reconnaissant une propriété avant-gardiste.

Je trouve qu’il s’agit d’une excellente assurance-vie pour mes clients.

Latence et chargement ?

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

Une solution radicale pourrait-elle consister à ne charger -prefix-free que sur écrans larges ?

Cela signifie que les fonctionnalités CSS3 risquent de ne plus être interprétées du tout si elles requièrent un préfixe. C’est jouable s’il s’agit de propriétés de confort ou de décoration, mais bien évidemment pas pour des parties importantes telles que du positionnement.

if(screen.width>640) {
var prefixfree = document.createElement('script');
prefixfree.src = 'https://raw.github.com/LeaVerou/prefixfree/master/prefixfree.min.js';
prefixfree.type = 'text/javascript';
document.getElementsByTagName('head')[0].appendChild(prefixfree);
}

A méditer bien entendu.

Détecter le device-width en JavaScript, mission impossible ?

Fri, 10 Feb 2012 12:34:00 +0100

Suite à un billet récent constatant que le device-width (largeur d’écran d’un périphérique) diffère selon les navigateurs, j’ai souhaité pouvoir proposer un chargement conditionnel de mes feuilles de styles mobile voire de modifier la valeur de mon meta viewport.

Le principe est de détecter en JavaScript la valeur de device-width et de charger une feuille de style adaptée (par exemple : styles320.css, styles640.css, styles800.css, styles1024.css). Attention, je ne dis pas qu’il s’agit d’une bonne pratique, je souhaitais simplement tester cette possibilité d’adaptation.

Et là c’est le drame…

Car au final ni screen.width ni windows.innerWidth de JavaScript ne correspondent à device-width, c’est à dire la valeur indispensable pour s’adapter aux terminaux mobiles.

Pour parvenir à mes fins, j’ai rapidement créé une page HTML de test à laquelle il est possible d’accéder ici : http://bit.ly/device-width

Voici le contexte :

application d’une meta viewport de valeur “width=device-width”
détection du device-width à l’aide de CSS mediaqueries (@media (device-width) {})
détection de screen.width ou windows.innerWidth via JavaScript et chargement d’une feuille de style correspondante (styles320.css, styles640.css, styles800.css ou styles1024.css)

J’ai pu constater que selon les terminaux, leur orientation et le navigateur employé, les deux valeurs ne coïncident pas ! Testez chez vous et n’hésitez pas à me faire vos retours.

Et si vous avez une solution magique, je suis preneur !

EDIT : Un nouveau challenger : window.matchMedia

Suite à la proposition d’Anthony, j’ai rajouté un troisième test dans la page : celui de window.matchMedia qui paraît prometteur puisqu’il correspond exactement à la valeur recherchée.

Le test en résumé ressemble à ça :

if (window.matchMedia("(min-width: 640px)").matches) {
document.write("device-width > 640px (window.matchMedia OK)");
}

Aux dernières nouvelles, les navigateurs mobiles Safari, Firefox et Android 3+ semblent supporter window.matchMedia, ce qui n’est pas le cas d’Opera (ni mobile ni mini). Pour IE mobile, je n’ai pas encore de retours.

Conférence MSTechDays : Trois avancées majeures en CSS3

Thu, 09 Feb 2012 14:15:49 +0100

J’ai été invité hier à parler de CSS3 lors du cycle de conférences Microsoft TechDays au Palais des Congrès de Paris.

Mon exposé s’est concentré sur 3 modules CSS3 que je considère majeurs : les Media Queries, le Grid Layout et les Animations.

C’était d’ailleurs assez pittoresque de dévoiler des technologies qui ne fonctionnent pas du tout sur les versions encore actuelles d’Internet Explorer (Grid et Animations ne sont supportées qu’à partir d’IE10 actuellement en beta), notamment dans un amphi dévoué à Microsoft… Mais le principe était de constater (avec raison) que la dernière mouture Internet Explorer était un excellent navigateur et que l’on pourrait enfin appréhender des positionnements intuitifs et pratiques sans avoir à bidouiller.

Vous pourrez visualiser mes diaporamas sur Slideshare et un article complet et détaillé sur le module Grid Layout sur Alsacréations (fini ce matin pour l’occasion).

Cahnory: UTF-8, comment ça marche �

Mon, 06 Feb 2012 14:43:56 +0100

Cahnory: UTF-8, comment ça marche �:

cahnory:

L’UTF-8 est un encodage permettant de gérer bien plus de caractères que l’ISO, limité à seulement 256. Il est universel et couvre aussi bien les caractères latins que cyrilliques, arabes, japonais… à titre personnel, il m’est nécessaire pour afficher mon prénom ;).

Si l’UTF-8 est très utile, il…

MS TechDays 2012

Sun, 05 Feb 2012 11:16:24 +0100

MS TechDays 2012:

Dans 3 jours, je serai aux Microsoft TechDays 2012 en tant qu’orateur.
J’y présenterai une conférence sur trois avancées majeures en CSS3 : MediaQueries, Animations et Grid Layout.

Fluid grids, orientation & resolution independence

Sat, 04 Feb 2012 21:53:52 +0100

responsivenews:

If you’ve spent any time building responsive websites with fluid grids, you will have encountered the shock of seeing your beautiful portrait layout distort when viewed in landscape mode (or vice-versa.)

Read More

Les mobiles nous mentent !

Fri, 03 Feb 2012 10:29:00 +0100

Vous le savez sans doute : les périphériques mobiles disposent de trois types de largeurs différentes :

screen width : largeur physique de l’écran
device-width : largeur déclarée par le périphérique
viewport : largeur de fenêtre du navigateur

Ces données ne concernent que la largeur mais sont transposables pour la hauteur, et sont bien-sûr susceptibles de changer selon l’orientation !

J’ai toujours cru que la valeur de device-width était fixée pour chaque périphérique, par exemple que le device-width sur iPhone 3 et 4 était tout le temps de 320 pixels. Mais ça c’était avant d’avoir fait quelques tests utilisateurs.

En bas de cet article, vous trouverez l’ensemble des données récoltées.

Ces tests n’ont rien de scientifiques ni de révolutionnaires, mais ils m’ont permis de comprendre que device-width ne dépend pas forcément que du périphérique, mais également du navigateur utilisé.

En résumé, si vous appliquez le désormais célèbre , votre base de travail sera non seulement différente selon les différents périphériques (pas de surprise jusque là), mais elle sera aussi différente sur un même périphérique selon votre navigateur !

(Et si vous n’utilisez pas la valeur “width=device-width”… c’est pire !)

Trois points me semblent essentiels :

iPhone 3 et iPhone 4 ont le même device-width, malgré leur densité de pixels différente
Le device-width sur Safari est identique en portrait qu’en paysage (!)
Un device-width (en portrait) peut globalement varier de 240px à 640px selon les terminaux mobiles

De ce dernier point découle une conséquence logique : votre design, parfaitement affiché et votre navigation idéalement proportionnée pour iPhone (device-width 320px) seront comparativement deux fois plus réduits et donc potentiellement moins ergonomiques - voire inaccessibles - sur certains autres smartphones (device-width 480 à 640px).

Les données collectées

Apple iPhone 3GS

Safari (portrait + paysage) : >180dpi / ratio >0.7 / device-width >320

Apple iPhone 4

Safari (portrait + paysage) : >320dpi / ratio >2 / device-width >320
Opera mini (portrait) : (NR resolution et ratio) / device-width >320
Opera mini (paysage) : (NR resolution et ratio) / device-width >480
iCab (portrait + paysage) : >320dpi / ratio >2 / device-width >320
Dolphin (portrait + paysage) : >320dpi / ratio >2 / device-width >320

Apple iPad 2

Safari (portrait + paysage) : >180dpi / device-width >640
Dolphin (portrait + paysage) : >180dpi / device-width >640
iCab (portrait + paysage) : >180dpi / device-width >640

HTC Sensation

IE mobile : >220dpi / ratio >1.1 / device-width >480

HTC HD7

IE mobile : (NR resolution et ratio) / device-width >480

HTC Incredible S

Android : >250dpi / ratio >1.5 / device-width >640

HTC Desire HD

Navigateur intégré (portrait + paysage) : >250dpi / ratio >1.5 / device-width >600
Firefox (portrait) : >220dpi / ratio >1.1 / device-width >480
Firefox (paysage) : >220dpi / ratio >1.1 / device-width >640
Android (portrait) : >250dpi / ratio >1.5 / device-width >320
Opera mini (portrait) : >220dpi / ratio >1.1 / device-width >380
Opera mobile (portrait) : >220dpi / ratio >1.1 / device-width >320
Opera mobile (paysage) >220dpi / ratio >1.1 / device-width >480

Galaxy Nexus

Android (portrait) : >320dpi / ratio >2 / device-width >640

Galaxy Note

Android (portrait) : >320dpi / ratio >2 / device-width >640
Firefox (portrait) : >320dpi / ratio >2 / device-width >640
Opera mobile (portrait) : >320dpi / ratio >2 / device-width >320

Samsung Nexus S

Android (portrait) : >250dpi / ratio >1.5 / device-width >480
Android (paysage) : >250dpi / ratio >1.5 / device-width >640
Firefox (portrait) : >220dpi / ratio >1.1 / device-width >480
Firefox (paysage) : >220dpi / ratio >1.1 / device-width >640

LG GT540

Android (portrait) : >180dpi / ratio >0.7 / device-width >640

LG Optimus One

Navigateur intégré (portrait) : >180dpi / ratio >0.7 / device-width >320

LG 2X

Navigateur intégré (portrait) : >250dpi / ratio >1.5 / device-width >640
Firefox (portrait) : >220dpi / ratio >1.1 / device-width >480

Nokia N8

Symbian (portrait) : >220dpi / ratio >1.1

Motorola Milestone

Android (portrait) : >250dpi / ratio >1.5 / device-width >640

Samsung Omnia 7

IE mobile (portrait) : (NR resolution et ratio) / device-width >480

Samsung 5800 GT

IE mobile (portrait) : >180dpi / ratio >0.7 / device-width >240

Vous voulez un exemplaire du livre "CSS avancées" dédicacé ?

Tue, 31 Jan 2012 13:46:00 +0100

Vous le savez peut-être déjà : la 2è édition de mon livre “CSS avancées - vers HTML5 et CSS3” va sortir dans quelques jours, le 3 février exactement.

Certains m’ont dit être intéressés pour recevoir un exemplaire dédicacés par l’auteur.

Ça tombe bien, c’est possible. Je dispose d’une vingtaine d’exemplaires que je peux vous dédicacer et envoyer personnellement.

Vous aurez même droit à une réduction et si vous habitez en France, je me chargerai des frais de port.

Voici les ouvrages qu’il me reste (stock mis à jour régulièrement) :

8 exemplaires de la 2è édition (2012), à 35€ au-lieu de 38€
5 exemplaires de la 1ère édition (2011), bradés à 25€ au-lieu de 38€

Voici la marche à suivre pour obtenir ces livres dédicacés :

Aller sur Amazon.fr, rubrique “chèque cadeau”.
Vous identifier avec votre compte Amazon ou en créer un en 1 minute
Accédez au formulaire d’envoi de chèques cadeaux par mail
Choisissez le montant correspondant à l’édition souhaitée.. ou plus si vous le souhaitez
Compléter les cases “Pour” et “De” telles que vous aimeriez qu’elles soient sur le chèque-cadeau.
Quelle est l’adresse e-mail du destinataire ? Ne vous trompez pas, il s’agit de raphael@goetter.fr
Message à l’attention du destinataire : notez ici impérativement votre adresse postale, sans quoi je ne pourrai pas vous envoyer le livre !
(attention c’est limité en taille et les guillemets doubles ne sont pas pris en compte).
Si vous souhaitez une dédicace particulière sur le memento, notez-là ici.

Et voilà ! Y’a plus qu’à attendre le facteur : j’effectuerai la première livraison ce vendredi 3 février (jour de la sortie officielle de la 2è édition).

N’hésitez pas à laisser un commentaire s’il y a le moindre problème ou pour toute question.

Je tiendrai à jour ce billet pour correspondre au stock de livres restants.

Our Mobile Planet

Mon, 30 Jan 2012 15:50:13 +0100

Our Mobile Planet:

Statistiques détaillées sur l’utilisation des smartphones (sources Google, Ipsos et la MMA sur une période récente). Le gros avantage est qu’il est possible de créer ses propres graphiques selon des critères souhaités (taux de pénétration, usages, géographie, etc.)

Adaptation du menu de goetter.fr sur mobiles

Mon, 30 Jan 2012 10:37:00 +0100

Moyennement fan des menus de navigation occupant toute la place de nos chers petits écrans de mobiles, je me suis amusé ce week-end à concevoir un menu coulissant pour mon site perso Goetter.fr, ainsi l’espace demeure dédié au contenu.

Le principe est que le menu est hors du champ visuel (en haut) et seul une barre et un bouton “menu” permet de le repérer.

En appuyant sur le bouton “menu”, le menu coulisse vers le bas et apparaît.

Le menu a été testé sur Android, Windows Phone 7.5 et iOS (aussi avec l’outil de lecture vocale VoiceOver). Il ne fonctionne pas sur Opera Mini et n’a pas été testé sur Opera Mobile et Blackberry, mais vu les technologies CSS3 employées il ne fonctionnera que sur des smartphones récents.

Menu rétracté :

Menu déroulé :

Qu’en pensez-vous (principe, ergonomie, accessibilité, compatibilité) ?

zomigi.com » Essential considerations for crafting quality media queries

Sat, 28 Jan 2012 22:12:50 +0100

zomigi.com » Essential considerations for crafting quality media queries

Le mythe de l'élément H1 unique en HTML

Sat, 28 Jan 2012 14:12:00 +0100

Depuis quelques jours, on voit se diffuser un peu partout une infographie concernant les bases du référencement naturel. Comme dans beaucoup de document vulgarisés, il y a de bonnes choses dans cette ressources, … mais aussi de grosses bêtises basées sur des rumeurs.

L’un des points évoqués qui me dérange le plus est “N’utilisez qu’un seul élément

dans la page”

Et comme j’adore les trolls, j’avais envie de décortiquer la question :)

1- Ce que dit le W3C

Selon les spécifications HTML4, les éléments h1, h2, … h6 servent à décrire le sujet de la section qu’ils introduisent. Un agent utilisateur doit pouvoir s’en servir pour construire le sommaire (table des matières) du document.

Cette définition est illustrée par la règle suivante :


Forest elephants
In this section, we discuss the lesser known forest elephants.
...this section continues...

En clair, aucune spécification officielle W3C HTML n’interdit l’usage de plusieurs éléments

et d’ailleurs le code d’exemple ci-dessous tend à montrer que plusieurs

apparaîtraient s’il y avait d’autres sections dans la page.

Note : selon les spécifications, le titre de page est bien et non <h1>.</i></p> <h4>2- Le cas HTML5</h4> <p>Selon les cas de figure, HTML5 prône l’emploi d’un niveau de titre <h1> au sein de chaque nouvelle section. <br/> Cela a rapidement été interprété en “HTML5 autorise plusieurs H1” en sous-entendant que ce n’était pas le cas avant, ce qui est faux.</p> <h4>3- Ce que dit le dieu Google</h4> <p>De très nombreuses rumeurs ont de tous temps couru sur la puissance de <h1> dans l’algorithme de Google. Ces expectatives ont mené à ce qui semble être devenu une “bonne pratique SEO” : ne surtout pas avoir plusieurs <h1> dans une page.</p> <p>Pour couper court à ces rumeurs, Matt Cuts de Google s’est exprimé en 2009 dans une vidéo devenue célèbre : <a href="http://www.youtube.com/watch?v=GIn5qJKU8VM"><a href="http://www.youtube.com/watch?v=GIn5qJKU8VM">http://www.youtube.com/watch?v=GIn5qJKU8VM</a></a></p> <p>Voici ce que dit exactement Matt Cuts dans cette vidéo : </p> <ul><li><b>On peut parfaitement avoir plusieurs <h1> dans la page,</b></li> <li>Mais il faut que ça ait du sens, et ne pas en abuser,</li> <li>Il n’est pas normal qu’il y en ait partout,</li> <li>Certains ont essayé (d’en mettre partout)… et se sont fait sanctionner par Google</li> </ul><p>Quelle surprise, n’est-ce pas ? Bref, rien de nouveau, ni de contraire aux spécifications et au bon sens.</p> <h4>(EDIT) 4- Ce que disent les expert en SEO <blockquote style="margin-top: 24px;">Il est préférable de n’utiliser qu’un seul H1</blockquote> </h4><p>Je ne peux pas infirmer ou confirmer cette expérience, n’ayant pas trouvé encore de source d’explication fiable.</p> <h4>Conclusion</h4> <p>Pour commencer, je n’ai aucun conseil à vous donner : puisqu’il est possible de faire comme bon nous semble tant que cela est porteur de sens, j’aurais tendance à faire… comme bon me semble.</p> <p>En tout cas, ne prenez pas cet article comme une incitation à mettre plusieurs <h1> dans vos pages web, sinon vous aller m’attaquer en justice pour avoir perdu votre positionnement chez Google (alors qu’à mon avis ce sera pour bien d’autres raisons).</p> <p>Bref, faites ce que vous voulez, mais vous connaissez maintenant mon point de vue sur la question ;)</p> <h4>Quelques sources pour aller plus loin :</h4> <ul><li><a href="http://www.nethik.fr/blog/2010/09/plusieurs-h1-sur-une-page-web/">Utiliser plusieurs H1 sur une page web</a></li> <li><a href="http://www.pitstopmedia.com/sem/h1-heading-seo">H1 and SEO : Myths and Facts</a></li> <li><a href="http://css4design.com/html-5-outline-page-web-section-h1">HTML 5 Outline — Quelques notes sur la structure des pages Web avec h1 et section</a></li> <li><a href="http://html5doctor.com/html5-seo-search-engine-optimisation/">HTML5 and Search Engine Optimisation (SEO) </a></li> </ul> </article> <article> <h1>fredericguerrier: Colonnes, marges et nth-child en CSS3 http://ow.ly/8H0E6 WebDesign CSS</h1> <p>Fri, 27 Jan 2012 21:27:41 +0100</p> <p><a href="http://fredericguerrier.tumblr.com/post/16523272151" class="tumblr_blog">fredericguerrier</a>:</p> <blockquote><p>Colonnes, marges et nth-child en CSS3 <a href="http://ow.ly/8H0E6"><a href="http://ow.ly/8H0E6">http://ow.ly/8H0E6</a></a> WebDesign CSS</p></blockquote> </article> <article> <h1>"Float, ça pue du flux !"</h1> <p>Wed, 25 Jan 2012 19:54:21 +0100</p> “Float, ça pue du flux !”<br/><br/> - <em>Moi</em> </article> <article> <h1>Bonjour, je cherche un livre pour graphiste qui aimerait apprendre le CSS et le HTML que me conseillez vous ?</h1> <p>Tue, 24 Jan 2012 18:52:32 +0100</p> <p>Bonjour,</p> <p>L’univers littéraire de l’intégrateur HTML / CSS s’est considérablement étoffé depuis quelques années.</p> <p>On est passé de quelques livres “de base” expliquant les rudiments à des thèmes extrêmement variés : </p> <ul><li>Apprentissage pour débutant (ex. livre “Réalisez votre site web avec HTML5 et CSS3” de Mathieu Nebra <i>- que je n’ai pas pu lire encore, donc pas d’avis</i>)</li> <li>Apprentissage avancé / expert (ex. mon livre “CSS avancées - Vers HTML5 et CSS3”)</li> <li>Gestion de projet CSS (ex. livre “SMACSS” de Jonathan Snook)</li> <li>Livres exclusivement sur CSS3 (ex. livre “CSS3 pour les web designers” de Dan Cederholm)</li> <li>Livres exclusivement sur HTML5 (ex. livre “HTML5” de Rodolphe Rimelé ou “HTML5 : De la page web à l’application web” de Jean-Pierre Vincent et Jonathan Verrecchia)</li> <li>Livres dédiés au Webdesign (ex. livre “Transcender CSS” de Andy Clarke <i>- qui a un peu vieilli à mon goût</i>)</li> <li>Livres sur le Webdesign pour mobiles (ex. livre “Responsive Web Design” d’Ethan Marcotte, ou “Mobile First” de Luke Wroblewski)</li> <li>Des aide-mémoires (ex. mes Mémentos CSS2 et CSS3)</li> <li>etc.</li> </ul><p>Au final, le choix est bien vaste et il est difficile de conseiller un bouquin plutôt qu’un autre. Pour information, sur Alsacréations nous tenons à jour <a href="http://www.alsacreations.com/livres/">une liste de livres</a> commentés et critiqués.</p> </article> <article> <h1>Connais-tu des podcasts (audio) sur le monde merveilleux du webdesign (en français)? Si non, à quand des podcasts "made in" alsacreations? :)</h1> <p>Tue, 24 Jan 2012 18:24:19 +0100</p> <p>Bonjour,</p> <p>Comme toi, je n’ai jamais vraiment trouvé de podcast de webdesign en français intéressant. Et pourtant j’ai un peu cherché et le sujet m’intéresse.</p> <p>Du côté d’Alsacréations, ça ne fait pas partie de nos projets à venir pour le moment, c’est tout ce que je peux dire sinon on va me fjqflihap*^^cù$</p> </article> <article> <h1>HTML5please</h1> <p>Mon, 23 Jan 2012 18:48:27 +0100</p> <a href="http://html5please.us/">HTML5please</a>: <p>Un rapide mais complet aperçu de tout ce qui est aujourd’hui exploitable en HTML5 (et CSS3) : supports navigateurs, conseils d’utilisation, pré-requis, etc.<br/> Très visuel et très clair.</p> </article> <article> <h1>Quel type de navigation pour les sites mobiles ?</h1> <p>Sun, 22 Jan 2012 21:41:00 +0100</p> <p>Les menus de navigation sont vraiment une plaie pour les périphériques mobiles, à commencer par le menu horizontal, et - le plus vicieux d’entre tous -, le menu déroulant…<i> (même si nous proposons <a href="http://www.alsacreations.com/tuto/lire/1267-un-menu-deroulant-adapte-au-web-mobile.html">une solution pertinente</a> sur Alsacréations.)</i></p> <p>En y réfléchissant bien, chaque type de navigation est problématique dès lors que l’écran commence à se réduire : il faut non-seulement tenter de tout afficher sur une colonne, mais également agrandir la surface cliquable de chaque lien.</p> <p>Et quand tout cela est enfin optimisé, il reste un dernier problème, et non des moindres : votre menu occupe à présent toute la taille de l’écran visible de votre page d’accueil !</p> <p>Forcément, le menu de navigation parfait pour mobile n’existe pas, ou plutôt : il sera différent selon les cas de figure et besoins.</p> <p>J’ai regroupé ici quelques idées de navigation “responsive” qui pourraient bien s’adapter à nos smartphones. Ils ont sans-doute chacun des avantages et des inconvénients…</p> <h4>Simple adaptation visuelle</h4> <p></p> <h5>Principe :</h5> <p>Adaptation d’un menu classique pour le Web mobile pour obtenir un affichage sous forme de colonne avec grands boutons.</p> <h5>Réalisation :</h5> <p>Les CSS3 Media Queries sont nos amis pour appliquer une feuille de styles lorsque la taille d’écran se réduit.</p> <h5>Exemple en ligne : </h5> <p>Il y en a un peu partout, dès lors que le webdesigner a fait un premier effort de “responsive design”.</p> <h4>Menu poussé en bas de page</h4> <p></p> <h5>Principe :</h5> <p>La navigation est non seulement adaptée aux petits écrans, mais par un stratagème magique, elle est déplacée en bas du document. L’objectif d’afficher le contenu principal en priorité est atteint.</p> <h5>Réalisation :</h5> <p>Les techniques pour modifier l’ordre d’affichage des éléments HTML relèvent soient de spécifications en brouillon (CSS3 Flexible Model ou Grid Layout), ou de “bidouilles” telles que d’afficher un bloc comme un <i><tfoot></i> pour le reléguer en bas.</p> <h5>Exemple en ligne :</h5> <p>C’est cette dernière technique que nous avons utilisée pour <a href="http://www.alsacreations.fr"><a href="http://www.alsacreations.fr">http://www.alsacreations.fr</a></a></p> <h4>Menu remplacé par une liste select</h4> <p></p> <h5>Principe :</h5> <p>Le site CSS Tricks propose une idée intéressante : remplacer le menu classique par un élément HTML <select>. Ce type d’élément est généralement très ergonomique sur les smartphones.</p> <h5>Réalisation :</h5> <p>La page HTML contient les deux types d’éléments, tour à tour masqués en <i>display none</i> selon la largeur d’écran. Un coup de JavaScript est nécessaire pour lien les options du select aux pages correspondantes lors du pointage.</p> <h5>Exemple en ligne :</h5> <p>Un tutoriel de CSS Tricks dévoile cette technique : <a href="http://css-tricks.com/convert-menu-to-dropdown/"><a href="http://css-tricks.com/convert-menu-to-dropdown/">http://css-tricks.com/convert-menu-to-dropdown/</a></a></p> <h4>Menu rétractable</h4> <p></p> <h5>Principe :</h5> <p>Une des solutions adaptée aux menus déroulants, l’idée est d’afficher le menu contracté par défaut, puis lors du clic sur un élément, de dévoiler les sous-menus afférents.</p> <h5>Réalisation :</h5> <p>Il est possible de réaliser ce type de comportement exclusivement en CSS (pour éviter une requête JavaScript ?) à l’aide de la pseudo-classe <i>:target</i></p> <h5>Exemple en ligne :</h5> <p>Je me suis amusé à réaliser cet exemple : <a href="http://ie7nomore.com/fun/responsive-menu/"><a href="http://ie7nomore.com/fun/responsive-menu/">http://ie7nomore.com/fun/responsive-menu/</a></a></p> <h4>Menu coulissant latéral</h4> <p></p> <h5>Principe :</h5> <p>La navigation est masquée (placée en haut ou sur le côté). Un bouton “menu” permet de faire apparaître en glissant la navigation vers la partie visible de l’écran.</p> <h5>Réalisation :</h5> <p>Le bloc de menu peut simplement être positionné en absolu ou relatif avec un décalage. Le clic sur le bouton “menu” modifie la valeur du décalage. Un petit coup de transition CSS3 et le tour est joué.</p> <h5>Exemple en ligne :</h5> <p>Voilà un exemple concret : <a href="http://ie7nomore.com/fun/responsive-menu/menu2.html"><a href="http://ie7nomore.com/fun/responsive-menu/menu2.html">http://ie7nomore.com/fun/responsive-menu/menu2.html</a></a></p> <h4>Menu coulissant vertical (ajout du 30 janvier)</h4> <p></p> <h5>Principe :</h5> <p>Une des (sans-doute) nombreuses variantes de la version précédente : la navigation est placée en haut de page. Seul un bandeau est visible et fixé en haut. Un bouton “menu” permet de faire apparaître en glissant la navigation vers la partie visible de l’écran.</p> <h5>Réalisation :</h5> <p>Le bloc de menu doit avoir une hauteur connue et positionné en “fixed”, puis décalé de sa hauteur. Le clic sur le bouton “menu” modifie la valeur du décalage. </p> <h5>Exemple en ligne :</h5> <p>J’ai appliqué ce principe sur mon site personnel <a href="http://www.goetter.fr/">Goetter.fr</a></p> <h4>Et sinon ?</h4> <p>Cette liste des “bonnes idées” de menus pour mobiles est certainement loin d’être exhaustive.<br/>Je suis preneur d’autres bonnes suggestions, et surtout de vos retours d’expériences, notamment en ce qui concerne la compatibilité ou l’accessibilité (ARIA ?) de toutes ces techniques.</p> </article> <article> <h1>Layer Styles</h1> <p>Sat, 21 Jan 2012 08:08:35 +0100</p> <a href="http://layerstyles.org/">Layer Styles</a>: <p>Un générateur automatique d’effets graphiques CSS3 (ombrages, arrondis, dégradés, bordures)</p> </article> <article> <h1>fredericguerrier: HTML5 Reset v2.0 Website Templates http://ow.ly/8yRf8 WebDesign #WebDev</h1> <p>Thu, 19 Jan 2012 18:51:20 +0100</p> <p><a href="http://fredericguerrier.tumblr.com/post/16119452524" class="tumblr_blog">fredericguerrier</a>:</p> <blockquote><p>HTML5 Reset v2.0 Website Templates <a href="http://ow.ly/8yRf8"><a href="http://ow.ly/8yRf8">http://ow.ly/8yRf8</a></a> WebDesign #WebDev</p></blockquote> </article> </main></body></html>

La tête dans le Flux !

Prefix-free, pour ou contre ?

Détecter le device-width en JavaScript, mission impossible ?

EDIT : Un nouveau challenger : window.matchMedia

Conférence MSTechDays : Trois avancées majeures en CSS3

Cahnory: UTF-8, comment ça marche �

MS TechDays 2012

Fluid grids, orientation & resolution independence

Les mobiles nous mentent !

Les données collectées

Apple iPhone 3GS

Apple iPhone 4

Apple iPad 2

HTC Sensation

HTC HD7

HTC Incredible S

HTC Desire HD

Galaxy Nexus

Galaxy Note

Samsung Nexus S

LG GT540

LG Optimus One

LG 2X

Nokia N8

Motorola Milestone

Samsung Omnia 7

Samsung 5800 GT

Vous voulez un exemplaire du livre "CSS avancées" dédicacé ?

Our Mobile Planet

Adaptation du menu de goetter.fr sur mobiles

Menu rétracté :

Menu déroulé :

zomigi.com » Essential considerations for crafting quality media queries

Le mythe de l'élément H1 unique en HTML

dans la page” Et comme j’adore les trolls, j’avais envie de décortiquer la question :)

1- Ce que dit le W3C

Forest elephants

et d’ailleurs le code d’exemple ci-dessous tend à montrer que plusieurs

dans la page”

Et comme j’adore les trolls, j’avais envie de décortiquer la question :)