La tête dans le Flux !

Salut Raphaël, selon toi est-ce que CSS3 est une partie de HTML5 ou alors ce sont deux choses bien distinctes ?

Thu, 24 May 2012 23:38:26 +0200

Il s’agit de 2 spécifications complètement différenciées, menées par 2 groupes de travail distincts et dont l’usage est différent : l’un (HTML) donne du sens et une fonction aux élèment de la page, l’autre (CSS) les met en forme et les positionne.
Ce n’est que dans l’inconscient collectif que le terme de HTML5 est devenu un mot-clé marketing regroupant CSS3, JavaScript et autre ARIA.

Deux (ah non, cinq) tests de navigation mobile

Mon, 21 May 2012 18:40:00 +0200

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)

Premier menu (navigation défilant de la droite vers la gauche) : http://bit.ly/goetter-menu3
Deuxième menu (navigation défilant de la gauche vers la droite) : http://bit.ly/goetter-menu3b
Troisième menu (navigation défilant du haut vers le bas) :
http://bit.ly/goetter-menu3c
Quatrième menu (navigation sur une ligne apparaissant par en haut) http://bit.ly/goetter-menu4
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)

The Toolbox

Thu, 17 May 2012 22:49:53 +0200

The Toolbox:

Une impressionnante collection d’outils, de snippets et de ressources pour la conception web.

Unicode c'est fantastique !

Thu, 17 May 2012 14:22:00 +0200

La ruée vers le Web mobile apporte de nouveaux questionnements et de nouvelles techniques de conception web. Notamment de performances web et d’adaptation des images aux écrans haute-définition.

Le sujet des pictogrammes, icônes et autres petites images décoratives est à la mode et un bon nombre de techniques existent pour cumuler le maximum d’avantages à la fois :

le moins de requêtes serveur possible, voire aucune
format le plus léger possible
pas de dégradations visuelles lors de l’agrandissement
pas de dégradations visuelles sur écrans “rétina”

Le format Unicode, via l’encodage Utf-8 permet d’afficher un nombre (presque) incalculable de caractères dont la plupart sont totalement inconnus.

Et pourtant, beaucoup de ces caractères sont parfaitement capables de remplir un rôle parfait de pictogramme… sans avoir à charger de fichier puisqu’il existe déjà dans les polices de caractères classiques.

Tous les avantages sont réunis… à condition que tous les navigateurs les interprètent correctement, ce qui n’est pas toujours le cas (à vous de vérifier au cas par cas). Ce serait trop simple sinon.

A des fins personnelles, je me suis construit une petite base de pictogrammes qui me semblent intéressants pour illustrer des sites web.

Vous la trouverez à l’adresse http://goetter.fr/unicode/

Et pour rappel, j’avais déjà fait quelques tests sur le sujet, visibles ici : http://www.ie7nomore.com/css2only/characters/

EDIT : puisque j’ai de nombreux retours et commentaires (justifiés) concernant l’accessibilité de ces pictogrammes, je vous renvoie vers un article récent : “Icônes @font-face et accessibilité”. J’y décris différentes méthodes pour résoudre les gênes pour lecteurs d’écrans.

Github.com Styleguide.

Wed, 09 May 2012 22:46:56 +0200

Github.com Styleguide. :

La (superbe) convention d’intégration interne de Github : HTML, CSS, JavaScript et icônes (@font-face). De bonnes idées à piocher pour ne pas réinventer la roue.

WebSafe Fonts Cheatsheet

Sun, 06 May 2012 13:54:24 +0200

WebSafe Fonts Cheatsheet:

Récapitulatif très détaillé des fameuses polices dites “websafe” (utilisables partout)

Conditional CSS

Sun, 29 Apr 2012 22:53:19 +0200

Conditional CSS:

Ingénieuse utilisation des Media Queries pour piloter JavaScript selon certaines conditions.

Ma participation à Web Event Lyon 2012

Sun, 29 Apr 2012 21:43:51 +0200

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 ;)

Le saviez-vous ? display est inutile sur un élément flottant

Sat, 28 Apr 2012 17:27:00 +0200

J’ai envie aujourd’hui de revenir sur une idée reçue de longue date : le mélange du positionnement flottant (float) et de la propriété display.

Associer float et display: block (ou inline)

C’est parfaitement inutile.

Tout simplement parce que les deux schémas de positionnement ne peuvent pas cohabiter : un seul sera interprété, le flottant.

Pourtant, bon nombre de feuilles de styles cumulent les deux propriétés sur le même élément, sous prétexte de pouvoir lui attribuer une largeur width ou une hauteur height.

Eh ben non, c’est inutile.

La seule exception acceptable est celle d’employer display: inline pour corriger un bug identifié sur IE6 sous le nom de double-float margin bug.

Ah mais oui puisqu’un flottant devient un élément de rendu block !

Non.

Float n’a aucune influence sur la valeur de display d’un élément. Pour preuve, un élément qui sort du flux de quelque manière que ce soit (float, position: absolute ou fixed) occupe par défaut la largeur de son contenu et non la largeur de son parent. Donc pas du tout le comportement d’un bloc.

Par contre, un élément qui sort du flux bénéficie d’un avantage commun aux display block : celui de pouvoir supporter les propriétés de dimensionnement (largeur, hauteur).

Cumul des mandats ?

Les spécifications W3C admettent l’éventualité de cumuler différents schémas de positionnement.
Voici exactement comment cela se passe pour éviter les règles contradictoires :

Si display: none est appliqué, alors l’élément ne crée pas de boîte et les propriétés position et float ne sont pas employables.
Sinon, si une propriété position est appliquée et a pour valeur absolute ou fixed, ce schéma devient prioritaire, la valeur de la propriété float est forcée à none (elle devient inutile) et l’élément est placé selon les éventuelles valeurs de top, right, bottom et left.
Sinon, si une propriété float est appliquée avec la valeur left ou right, l’élément devient flottant et display devient inutile
Sinon, l’élément est disposé selon son mode de rendu par défaut inhérent à la propriété display (inline, block, list-item, etc.).

En résumé : si les propriétés float et display apparaissent au sein du même bloc de déclarations, alors display (à l’exception de display none) doit être purement et simplement ignorée par les navigateurs. Elle devient inutile.

De même, si position absolute, float et display cohabitent, ces deux dernières doivent être ignorées par les navigateurs.

Pour élargir le débat, je vous invite à consulter cet article dédié au positionnement flottant : http://www.alsacreations.com/article/lire/972-float-le-grand-bluff.html

Préfixes CSS : le pavé dans la mare

Wed, 25 Apr 2012 20:17:00 +0200

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 !

(source de l’illustration : http://gohelrakesh.wordpress.com/)

Charte d'intégration HTML / CSS de Google

Wed, 25 Apr 2012 11:27:00 +0200

Charte d'intégration HTML / CSS de Google:

Important : il s’agit bien d’une convention interne à Google, pas de bonnes pratiques universelles. N’appliquez pas toutes les recommandations à la lettre, car elles ne vous concernent pas forcément toutes.

Bref, Darklg a intégré un site

Tue, 24 Apr 2012 15:36:17 +0200

Bref, Darklg a intégré un site:

kaelig:

Suite à la publication de l’article intitulé “Bref, j’ai intégré un site”, plusieurs intégrateurs se sont manifestés pour partager leur méthodologie d’intégration.

Darklg a décidé d’en faire un billet complet pour y détailler toutes les étapes qui composent son travail d’intégration. Merci beaucoup à lui pour ce partage autour de son process d’artisanat 2.0.

Un polyfill pour background-size cover et contain

Fri, 20 Apr 2012 20:59:25 +0200

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 :)

destroy/dstorey: Responsive viewport units

Tue, 17 Apr 2012 23:16:02 +0200

destroy/dstorey: Responsive viewport units:

dstorey:

With all this new fangled talk of responsive web design, its about time that we had a poster child CSS unit to go with it. So move over em, CSS3 Values and Units introduces a bunch of new viewport units that are getting ready for their time in the limelight.

Motorola recently implemented…

cssarrowplease

Mon, 16 Apr 2012 07:57:30 +0200

cssarrowplease:

Un générateur d’infobulles sans images

À propos de rétina et d'images floues

Sat, 14 Apr 2012 20:40:00 +0200

“Rétina”, “retina display” et “retina HD”, sont de bien jolis mots marketing que personne ne saurait définir exactement.

De manière très succincte, parce que je n’ai aucune envie de m’attarder sur ce point, disons tout simplement que “retina” a commencé par désigner la génération iPhone 4 aux résolutions de 960×640px au lieu de 480×320px dans les modèles précédents. Le terme désigne aujourd’hui tout périphérique nomade (tablette ou smartphone) doté d’un écran haute résolution.

Toujours est-il que pour le quotidien d’un développeur web mobile, les différences de rendu selon les résolutions sont loin d’être une partie de plaisir. D’autant plus que les terminaux Apple (iPhone, iPod et iPad) ont la fâcheuse habitude de mentir sur leurs résolutions en mentant sur leur device-width.

Prenons un exemple courant: l’iPhone4 ou 4S. Sa largeur physique est de 640px, mais il déclare un device-width de 320px (en largeur et en hauteur).
En lui appliquant - avec raison - une balise meta viewport de valeur “width=device-width”, il se prend pour un écran de 320px de large… tout en conservant sa précision de 640px.

Les contenus affichés, surtout les images, sont alors interpolées et interprétées comme “doublées”. Un peu comme un large écran de bureau auquel vous imposeriez une résolution de 800x600px : l’interpolation est parfois hasardeuse et manque de précision. Disons-le franchement, c’est parfois un peu flou.

Pour mieux comprendre, voyons le phénomène à travers plusieurs exemples concrets. Des vraies images HTML (img) pour commencer, puis des images d’arrière-plan.

Cas des images HTML

Cas des arrière-plans CSS

Alors, on peut y faire quelque chose ?

Pour contrer ce souci de finesse dans le rendu, les solutions ne sont pas si évidentes car il ne suffit pas de détecter les résolutions HD ou les pixel-ratios.

Voici les hypothèses que j’entrevois :

Ne rien faire.
En toute honnêteté, ce n’est pas une catastrophe d’afficher des images classiques sur un écran haute définition, mais c’est un peu dommage car l’avenir appartient aux mobiles “rétina”.
Servir des images “un peu plus grandes” que la largeur finale affichée.
Par exemple, pour un picto de largeur 32px, afficher une image de 64px. Idem pour les images d’arrière-plan, en pensant à préciser un background-size de 100% auto. C’est une bonne solution intermédiaire à condition de ne pas en abuser car le poids des images aura une incidence non négligeable sur le temps de chargement et d’affichage sur anciennes générations non rétina.
Servir des images différentes selon la définition d’écran des mobiles.
Cela peut se faire du côté client ou serveur et c’est forcément la meilleure solution… et la plus contraignante. Tournez-vous par exemple du côté du script “Retina Images”, de RetinaJS ou celui de adaptive-images.com.

Et vous, vous avez d’autres pistes ? Des solutions ?

Noms de couleurs web originaux

Wed, 11 Apr 2012 10:04:00 +0200

Noms de couleurs web originaux:

Une belle liste illustrée de couleurs hexadécimales aux noms évocateurs : #0ff1ce, #facade, #fe55e5, #BADA55, …

De quoi procrastiner un moment et agrémenter ses wireframes pour les clients !

(Autre liste ici : http://nedbatchelder.com/text/hexcolors.html)

CharBase

Wed, 11 Apr 2012 09:41:49 +0200

CharBase:

Une base de données visuelle de caractères unicodes.
Parfait pour illustrer ses pages web (pictos, décos, flèches,…) sans recourir à des images.

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

Sun, 08 Apr 2012 20:14:50 +0200

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)

CSS peut-il être orienté objet ? Nicole Sullivan durant...

Sat, 07 Apr 2012 20:40:10 +0200

CSS peut-il être orienté objet ?

Nicole Sullivan durant Paris-Web 2009.