Cette technique a notamment été utilisée par Apple, sur la page de présentation de l’iPhone 5.

Les avantages sont nombreux par rapport à une <video> ou à un GIF :

• Seul le support de <canvas> est nécessaire
• Pas de problème de codecs
• Possibilité de lire ces vidéos sans fullscreen sur iPhone
• Contrôle total sur la vidéo
• Niveaux de transparence (si PNG est utilisé)
• Pas de limitation de couleurs
• Compression sans perte (optionnel)

Évidemment, il ne s’agit pas de l’utiliser pour intégrer de longues vidéos, mais plutôt pour présenter de courtes animations. Les performances sont excellentes, que ce soit en vitesse de rendu ou en temps de téléchargement (dans l’exemple présenté sur cette page, on passe de 7 Mo pour le GIF à 500 Ko).

Faute de mieux, cela permet de combler le manque laissé par les formats APNG ou MNG qui n’ont jamais pu s’imposer. Notre salut viendra peut-être du format WebP proposé par Google qui supporte également les animations, mais que Mozilla refuse d’intégrer à Firefox pour l’instant.

Le script de décompression est open source (licence MIT) et a été publié sur GitHub.

Jon Skinner, l’auteur de l’éditeur Sublime Text, avait proposé une technique similaire pour lire des screencasts. Cette fois, l’outil de compression est libre, multiplateforme (Python) et automatisable.

Saviez-vous que les index de tableaux étaient traités comme des chaînes de caractère en JavaScript ? Et que pour cette même raison, la valeur passée à l’opérateur square brackets ([]) était convertie en chaîne de caractère, ainsi que la première passée à l’opérateur in ? Quelle est la taille maximale d’un tableau ? Et que se passe-t-il lorsque la propriété length est modifiée ?

Pour connaître les réponses à ces questions, foncez lire cet article de Dr Axel Rauschmayer : Arrays in JavaScript.

Je vous invite également également à parcourir l’ensemble du blog, et notamment le guide JavaScript, qui classe et regroupe tous les articles liés au langage.

Dr Axel Rauschmayer (@rauschma sur Twitter) prépare également un livre pour 2013, A programmer’s guide to JavaScript. Il ne fait nul doute que celui-ci s’imposera rapidement comme une référence !

Developer Toolbar

La Developer Toolbar est disponible ! Elle regroupe les outils de développement existants dans Firefox (l’inspecteur, la console Web, le débogueur), auxquels vient s’ajouter une console. Celle-ci peut assez facilement être étendue pour y ajouter de nouvelles commandes : cet outil va certainement se retrouver indispensable d’ici peu de temps.

La nouvelle barre de développement de Firefox 16

HTML

L’élément meter est supporté

Un petit rappel du rôle de cet élément :

The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate. This is also known as a gauge.
— The meter element — HTML5

Traduction :

L’élément meter représente une mesure scalaire à l’intérieur de limites connues, ou une valeur fractionnaire. Par exemple : le niveau d’utilisation d’un disque, la pertinence du résultat d’une requête, ou la fraction de votants ayant sélectionné un candidat. Le mot « jauge » peut également définir cet élément.

Je vous invite également à consulter la documentation de l’élément meter sur le MDN, et l’article de HTML5 Doctor. Un petit exemple :

16/30 <meter value="16" max="30" min="10"></meter>
45/50 <meter value="45" max="50" min="0"></meter>

Rendu : 16/30 (meter n’est pas supporté sur votre navigateur), 45/50 (meter n’est pas supporté sur votre navigateur).

Trois pseudo-classes CSS ont également été ajoutées pour nous permettre de styler cet élément : :-moz-meter-optimum, :-moz-meter-sub-optimum et :-moz-meter-sub-sub-optimum.

L’API HTML Microdata est supportée

Quelques liens de référence :

• Un article d’introduction à Microdata et son API sur Dev.Opera
• L’article Microdota sur HTML5 Doctor
• La spécification Microdata à destination des auteurs

Le champ <input> autorise tous les types MIME

Avant cette version, seules ces valeurs étaient disponibles :

<input type="file" accept="audio/*">
<input type="file" accept="video/*">
<input type="file" accept="image/*">

Il est maintenant possible d’être plus précis :

<input type="file" accept="audio/mpeg">
<input type="file" accept="video/*,image/*">
<input type="file" accept="image/*,.autre-extension">

Pardonnez-moi, mais je me sens obligé de rappeler qu’aucune validation dans le navigateur n’est destinée à remplacer une validation côté serveur. Ça va mieux, merci !

CSS

Adieu préfixes

Beaucoup, beaucoup de préfixes ont été supprimés. Voyez :

Les animations : animation, animation-delay, animation-direction, animation-duration, animation-iteration-count, animation-name, animation-play-state, animation-timing-function, animation-fill-mode.

Les transformations : transform-origin, transform.

Les dégradés : linear-gradient, radial-gradient, repeating-linear-gradient, repeating-radial-gradient.

La fonction calc(). Le potentiel de cette fonction CSS est énorme (documentation MDN), et une version non préfixée facilitera son utilisation. Seul Opera supporte pas calc() aujourd’hui.

Animations CSS : reverse

Il est maintenant possible d’utiliser les valeurs reverse et alternate-reverse pour la propriété animation-direction (documentation MDN).

Si vous vous souhaitez voir en quoi ces nouvelles valeurs de direction influent sur une animation CSS, je vous ai concocté une petite démonstration. Allez-donc y jeter un œil avec votre Firefox flambant neuf !

box-sizing sur les cellules de tableaux

Cette propriété, devenue récemment assez populaire (voir l’article de Paul Irish), s’applique maintenant correctement aux cellules de tableaux.

Media queries

Le type de donnée resolution (documentation MDN) permet d’utiliser une nouvelle unité, le dppx (dots per CSS pixel). Il s’agit du nombre de points (sur l’écran) par pixel CSS (virtuel).

Les unités dppx, dpi, et dpcm font maintenant référence à des valeurs CSS (virtuelles), et non plus à des valeurs physiques.

Flex Layout

Il est maintenant possible d’utiliser la valeur auto pour les propriétés min-width et min-height (voir la spécification CSS3 Flexbox : Implied Minimum Size of Flex Items).

DOM : adieu préfixes

• IndexedDB n’est plus préfixé (documentation MDN)
• L’API Battery n’est plus préfixée (documentation MDN)
• L’API Vibration n’est plus préfixée (Mozilla Hacks: Using the Vibration API)

JavaScript

Trois nouvelles méthodes ont été ajoutées sur l’objet Number : isFinite(), toInteger() et isInteger().

L’opérateur Spread

Il est maintenant possible de convertir un tableau en paramètres de fonction, à l’aide de l’opérateur spread du projet Harmony.

Évidemment, n’utilisez pas cette fonctionnalité pour l’instant pour du Web, c’est totalement incompatible avec les autres navigateurs. Mais si vous développez une commande pour la nouvelle Developer Toolbar de Firefox, il serait dommage de vous en priver !

Un exemple :

// Pour appeler cette fonction
function nousIrons(a, b, c, lieu) {
  var str = a + ', ' + b + ', ' + c + ', nous irons ' + lieu;
  return str;
}

// Avec ce tableau
var data = [1, 2, 3];

// Et ce lieu
var lieu = 'au bois';

// Avant, nous devions faire
nousIrons(data[0], data[1], data[2], lieu);

// Ou encore, avec Array.apply()
nousIrons.call(this, data.concat(lieu));

// Mais maintenant, avec la syntaxe spread
nousIrons(...data, lieu);

// Cool non ?

La conclusion ! La conclusion !

Pour cet article, j’ai essayé prendre les notes de version de Firefox et d’y ajouter, en vrac, des informations complémentaires, quelques démos, et mes réactions. J’espère que le résultat sera plus digeste qu’une simple liste : n’hésitez pas à me faire part de vos impressions dans les commentaires !

Il est même possible de styler ce texte sur la plupart des navigateurs, si l’on veut bien concéder l’utilisation de sélecteurs quelque peu pimpants :

::-webkit-input-placeholder{}
:-ms-input-placeholder{}
:-moz-placeholder{}

Le comportement est simple : un texte d’aide apparaît dans le champ de texte, lorsque celui-ci est vide. Ce libellé disparaît dès que le focus est placé dans le champ.

Cet attribut n’a pas vocation à remplacer l’élément <label>. Il s’agit d’un indice, d’une aide supplémentaire, et pas d’un intitulé :

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. […] For a longer hint or other advisory text, the title attribute is more appropriate. The placeholder attribute should not be used as an alternative to a label.
— Common input element attributes — HTML5

Traduction (rapide) :

L’attribut placeholder représente un indice (mot ou phrase courte) dont le but est d’aider l’utilisateur à entrer ses données. Cet indice peut être une valeur d’exemple ou une brève description du format attendu. […] Pour un texte d’aide plus long, ou toute autre indication, l’attribut title sera plus approprié. L’attribut placeholder ne devrait pas être utilisé comme alternative à l’élément label.

Sur iOS et OS X (depuis 10.7), une petite variante a été introduite, qui me semble tout à fait intéressante. Le libellé reste affiché au focus, jusqu’au premier caractère tapé. Ce comportement est visible sur Firefox, Chrome et Safari (pas Opera, qui semble implémenter ses propres widgets).

L’attribut placeholder sur OS X

Je trouve ce nouveau comportement intéressant. Il permet d’afficher l’aide plus longtemps, et le risque de confondre le placeholder avec la valeur du champ est le même que sans focus, puisqu’ils sont censés être clairement distingués visuellement.

Seulement voilà : chaque projet est particulier, et une solution, même élégante, ne correspond pas toujours aux besoins du moment. Il peut arriver, par exemple, que le comportement du système ne soit pas celui qui est désiré. Nous avons tous connu ce problème n’est-ce pas ?

Prenons un champ dont le texte est centré. Regardez comme le curseur se faufile, l’air de rien, au beau milieu d’un caractère :

Placeholder centré

Mais enfin Curseur, tu fais n’importe quoi ! La solution est simple, la décision est prise : il faut revenir à l’ancien comportement. Mais il va falloir trouver une ruse, car il est hors de question de revenir à une solution basée sur l’attribut value, avec des classes pour distinguer le focus.

La solution à deux francs

Une solution pourrait être de modifier dynamiquement l’attribut placeholder au focus, à l’aide d’un script. Et pourquoi pas en CSS ? En combinant :focus et :-xx-input-placeholder, il devrait être possible de modifier la couleur du placeholder pour qu’elle corresponde à celle du fond ! Voyons cela :

input:focus::-webkit-input-placeholder { color: #fff; }
input:focus:-moz-placeholder           { color: #fff; }

Placeholder blanc

Ce comportement peut être observé avec Firefox et Safari. La couleur du curseur clignotant correspond à la couleur du champ, ici un gris foncé. Mais pour permettre une bonne lisibilité du texte, ces deux navigateurs vont faire en sorte d’inverser la couleur du texte à l’endroit où se trouve le curseur :

Placeholder blanc, agrandi

Ce qui est tout à fait indésirable dans notre cas.

La solution à trois francs

La solution est maintenant évidente, et permet également d’obtenir une meilleure portabilité, puisqu’elle ne dépend plus de la couleur du fond. Il s’agit de la couleur spéciale transparent.

input:focus::-webkit-input-placeholder { color: transparent; }
input:focus:-moz-placeholder           { color: transparent; }

Placeholder transparent

Accessibilité

Si vous avez pour habitude de traquer les problèmes d’accessibilité, cette technique devrait vous déranger un peu : rendre un texte transparent en CSS, voilà qui sonne faux. Mais n’oublions pas qu’il ne s’agit, encore une fois, que d’un placeholder, une invitation à entrer une valeur, rien d’autre. Ce n’est pas un title, et encore moins un <label>.

Le seul problème que je vois serait plutôt d’ordre ergonomique : un utilisateur d’iOS ou OS X s’attend à voir le placeholder au focus, jusqu’au premier caractère tapé.

Démonstration

Vous pouvez retrouver ces tests sur la page dédiée :

Démonstration

Cette page inaugure également un nouvel espace, code.lesintegristes.net, sur lequel nous publierons désormais nos démonstrations. Ce sous-domaine est hébergé par GitHub, et son contenu est bien entendu sous licence libre.

L’ensemble de nos discussions se fait en public, sur GitHub. Nous utilisons le tag « question » pour lancer des sujets dans les issues, et lorsqu’une décision est prise, nous la reportons sur le wiki.

Nous sommes évidemment ouverts à toutes vos remarques et contributions, c’est même le but de notre démarche. Passez donc mettre votre grain de sel !

Je pense qu’il s’agit là d’un signe intéressant, qui montre qu’avec l’accélération des sorties de versions de navigateurs, il faut également adapter les stratégies de support. Internet Explorer 8 a déjà plus de 3 ans, c’est un navigateur dépassé dont il faut se débarrasser au plus vite !

Le but est avant tout de faciliter nos contributions (l’équipe s’agrandit !), et de pouvoir mettre en pratique les sujets qui sont évoqués ici. Cela pourrait nous permettre, entre autres, de prêcher le responsive design sans avoir à affronter le regard de nos lecteurs lorsqu’ils tentent de redimensionner leur navigateur…

J’espère qu’il sera également utile à d’autres, mais plus tard, après un petit rafraîchissement : le thème a très peu évolué depuis sa sortie, et il commence à prendre un sacré coup de vieux !

Un petit mot sur git : pour faciliter les contributions, le méthodologie choisie est la suivante : chaque push dans la branche master du dépôt GitHub est instantanément mis en production (grâce aux Post-Receive Hooks de GitHub). Cela nous permettra, je l’espère, de mettre à jour le thème plus régulièrement, de faire progresser différentes fonctionnalités dans des branches (ou forks) séparés, et d’en discuter à l’aide de pull requests !

Le thème sur GitHub :
https://github.com/lesintegristes/lesintegristes-theme

Reporter un problème sur le site :
https://github.com/lesintegristes/lesintegristes-theme/issues

Les intégristes sur GitHub :
https://github.com/lesintegristes

(Mise à jour) Nous avons également publié le plugin WordPress nous permettant de synchroniser le dépôt local avec GitHub :
https://github.com/lesintegristes/wp-github-sync

Le problème consistait à définir un padding précis sur la droite d’un élément en display:inline. En dehors des détails techniques, ma solution est la suivante :

• Utiliser un border-left padding-left sur le conteneur, dont la largeur correspond au double du padding désiré.
• Décaler d’autant l’élément sur la gauche, à l’aide d’un position:relative, et d’un left négatif.

La démonstration sur jsFiddle : http://jsfiddle.net/Ch7bL/35/

N’hésitez pas à améliorer cette solution, ou à proposer une autre approche dans les commentaires de l’article !

La chaîne des prototypes, le contexte d’exécution, l’objet d’activation, le scope, les closures, tout y est expliqué de manière précise et exacte, ce qui est malheureusement assez rare quand il s’agit de JavaScript.

C’est ici : Voyage au coeur de JavaScript.

Et si l’anglais ne vous rebute pas, je vous invite également à lire l’ensemble de la série ECMA-262-3 in detail (autrement dit ECMAScript 3) par Dmitry Soshnikov.

Comme le nom l’indique, il y sera question de traiter de la qualité web, selon plusieurs points de vue : webdesign, accessibilité, développement front-end, suivi de qualité web, etc.

Pour commencer, plusieurs intervenants tentent de définir ce qu’est la qualité web, et c’est déjà pas mal !

À suivre ici : http://w3qualite.net/

(enfin, dès qu’un flux RSS sera disponible ;-)