Chaque navigateur possède son propre champ de <input type="file">, ce dernier n’est pratiquement pas modifiable en CSS. C’est fort dommage car d’une part, chaque navigateur possède son propre design de ce type de input, ce qui ne permet pas d’avoir une homogénéité entre les navigateurs, et d’autre part, cette impossibilité de le modifier via CSS ne permet pas d’adapter ce dernier au design de notre site. Notre objectif est donc de palier à cette lacune.

Exposons un cas concret : vous avez un site dynamique, et vous avez besoin de deux versions de la même image, l’originale, et une version floutée, plus sombre… que vous appliquerez par exemple au survol de la souris. Premièrement, ceci est une affaire de client-side ! Et celà a de multiples avantages :

• Si les images sont ajoutées dynamiquement, on évite un traitement supplémentaire gourmand en ressource (flou, sépia…)
• On évite de prendre plus de place sur le disque dur avec deux images alors qu’une seule peut suffire
• On évite aussi la consommation de plus de bande passante et un temps de chargement supplémentaire pour le client

Enfin, vous comprenez qu’il n’y a que des avantages à déporter le traitement des images côté client. On pense évidemment à JavaScript pour faire ce boulot. Oui… pourquoi pas… Mais sachez que les filtres de CSS permettent d’en faire autant, le tout dans une extrême simplicité. Pour vous mettre l’eau à la bouche, voici les effets qu’il est possible d’appliquer :

• flou,
• luminosité,
• saturation,
• contraste,
• teinte,
• inversion,
• nuances de gris,
• sépia.

Ça ouvre quand même pas mal de possibilités ! Pour en savoir plus, je vous invites à aller jetez un œil à la traduction de l’article de Johnny Simpson sur Développez.com.

L’emailing est un sujet assez vaste. Je l’avais déjà abordé au travers d’un article plutôt axé marketing, qui traitait des meilleurs jours et plages horaires d’envoi. Dans un autre article, toujours orienté webmarketing, j’avais expliqué les différentes notions à bien appréhender pour construire une landing page efficace.

Qu’il s’agisse d’un emailing de prospection, d’une newsletter ou encore d’un email transactionnel (confirmation d’inscription, confirmation de commande etc) si vous désirez envoyer autre chose que du texte brut, il va falloir adapter vos pratiques au media email. Sans quoi vos destinataires ne recevront rien d’autre qu’une bouillie de mise en page, s’ils reçoivent quelque chose tout court d’ailleurs. Allez, c’est parti !

Le HTML est un terme qui regroupe de nombreuses fonctionnalités. Les balises HTML5 évidemment, mais aussi les nouvelles API du DOM et aussi pour certains les nouvelles moutures du JS, a.k.a ECMAScript.

La première version de ce micro article (2012) parlait du WebGL, de microdonnées, du dragNdrop. Mais bien d’autres choses ont fait leur apparition depuis: le WebGL2, la push api, les web workers etc.

Pour tout développeur soucieux de l’avancement des technos front et de l’état des navigateurs, trois ressources permettent de savoir si vous pouvez utiliser telle ou telle techno en prod ou non :

• Le très connu Can I Use qui permet d’afficher le support d’une api précise ;
• HTML5test qui donne une note à votre navigateur et présente les différentes technos supportées (ou non) et fourni les liens vers la doc W3C, Whatwg ou MDN ;
• Enfin le test ECMAScript qui présente une synthèse de l’implémentation des différentes versions de JavaScript par les principales plateformes.

Bon dev !

Le web et les polices, ou fontes, c’est une histoire passionnelle. Avant le CSS3 et son @font-face, il n’était pas possible d’embarquer une police sur le web. On devait donc se contenter des polices sytème… Autant dire que le choix était limité, d’autant plus que tous les systèmes n’embarquent pas les mêmes jeux de polices.

Bref, ça, c’était avant. Aujourd’hui, deux questions se posent : quelle(s) police(s) choisir pour une expérience cohérente ? et comment garantir une expérience performante sur tous les devices ?