Hanblog - Mot-clé - planetmozfr

Relancer les soirées performances web

Anthony Ricaud — Wed, 11 Jan 2012 02:09:00 +0100

Depuis décembre, j'ai repris l'organisation des soirées parisiennes concernant les performances des sites web. Mon but premier est d'installer un rendez-vous mensuel afin de pérenniser l'événement. Grâce à JF, nous avons un site un peu plus sympa à manipuler que le précédent.

Et la deuxième soirée arrive bientôt.

pdf.js, ça déchire.

Anthony Ricaud — Sat, 07 Jan 2012 01:10:00 +0100

Le projet pdf.js a démarré en mai 2011. Le but est de créer un moteur de rendu de PDF en utilisant simplement les technologies du web.

Normalement, le rendu des PDFs dans les navigateurs est délégué à un autre programme. Que ça soit une application complète comme le lecteur Acrobat ou Aperçu sur Mac ou un programme intégré au navigateur pour Chrome. Cette approche augmente les problèmes de sécurité puisque cela augmente la surface de code attaquable. En n'utilisant que les APIs des navigateurs, on n'augmente pas cette surface. Cela permet aussi de voir ce qu'il est possible de faire avec les technologies web et de les améliorer lorsque quelque chose n'est pas possible.

Le travail est suffisamment avancé aujourd'hui pour avoir une extension Firefox capable de rendre un bon nombre des PDFs dans la nature. Je vous invite à lire l'annonce initiale expliquant les buts du projet et les pointeurs vers tout ce qu'il y a à savoir. La présentation suivante de Julian Viereck est aussi très intéressante.

NSID

Anthony Ricaud — Mon, 02 Jan 2012 22:13:00 +0100

C'est l'acronyme de No Shaving In December, autrement dit "Pas de rasage en décembre". C'est une petite coutume chez Mozilla et je l'ai suivie cette année pour voir.

Du coup, je suis impressionné par la différence de pousse des poils en fonction des personnes. Certains ont en 10 jours ce que j'ai en 30.

C'était rigolo mais demain c'est rasage !

Mes deux premières extensions

Anthony Ricaud — Sun, 18 Dec 2011 22:13:00 +0100

Cet été, j'ai voulu voir un peu ce que donnait la création d'extensions pour Firefox via le Addon SDK.

Longdesk

Stéphane publiait cet été une photo par jour. Il utilise l'attribut longdesc pour décrire la photo. Là où ce jeune est taquin, c'est qu'en plus, il y glissait des explications sur l'origine de la photo, des remarques personnelles, etc. Donc il était indispensable de lire aussi cette page de description. Voici l'origine de cette extension qui rajoute un lien vers la description sous les images.

Et comme Stéphane a bon gout, il utilise cette extension et a même proposé une correction

au-revoir-utm

Là ce sont les multiples liens que l'on voit fleurir via RSS, Twitter ou autres avec des paramètres. Ils sont utilisés par Google Analytics et polluent les URLs. Cette extension ne fait que remplacer l'adresse actuelle, via la méthode history.replaceState() de HTML5. Il n'y a donc aucune perte de performance.

Le code étant disponible, si vous voulez porter ces extensions (très simples) sur d'autres navigateurs, allez-y !

Le cycle accéléré de Firefox

Anthony Ricaud — Wed, 15 Jun 2011 13:29:00 +0200

Avec la sortie de Firefox 4 plus de un an et deux mois après Firefox 3.6, Mozilla a décidé de changer de rythme de sortie de nouveautés. Il était très frustrant d'avoir des nouveautés dans les versions de développement et d'attendre 6 mois ou plus pour les délivrer au grand public.

On peut regarder l'exemple flagrant de WebM. Ce codec vidéo a été annoncé le 19 mai 2010. Nous avons des versions de développement disponible dès le premier jour. Le temps de stabiliser et tester tout ça, il aurait été possible d'avoir une version stable à l'été 2010. C'est d'ailleurs ce qu'ont fait Opera (10.6 le 1er juillet) et Chrome (6 le 2 septembre). Par contre, il faudra attendre le 22 mars 2011 pour voir le support de WebM dans Firefox 4. Frustrant, non ?

Le nouveau cycle

Avec la nouvelle organisation, une nouvelle version stable (ou finale) est prête toutes les six semaines. Voyons voir comment c'est possible avec les différents parfums de Firefox disponibles.

Nightly (ou trunk ou mozilla-central)

Ici, on trouve le code le plus récent et le moins testé^[1]. C'est là que toutes les nouveautés ajoutées la veille sont disponibles. Pour avoir du code plus récent que ça, il vous faudra compiler vous même Firefox.
Au moment où j'écris ces lignes, la version 7 se prépare dans ce canal.
Où télécharger - Pas très stable, gare aux doigts.

Aurora

Ici, on prend une copie à un instant T de ce qui se passe dans Nightly. Pendant que le développement dans Nightly continue, dans Aurora, on peaufine les nouveautés ou on décide de les enlever. Par contre, on n'ajoute pas de nouveautés. Donc si une fonctionnalité que vous attendez n'est pas dans Aurora, elle ne sera pas ajoutée dans la version finale portant le même numéro de version.
C'est donc plus stable que Nightly mais avec encore quelques aspérités.
Au moment où j'écris ces lignes, la version 6 se prépare dans ce canal.
Où télécharger - Assez stable
On recherche beaucoup d'utilisateurs pour cette version qui est nouvelle.

Beta

Là on prend ce qui était dans Aurora et on l'envoie à tous les bêta-testeurs. Ce qui fait quelques millions de personnes. Ça permet de mettre le dernier coup de polish et d'avoir le plus de retours possibles sur les coins sombres du web. Par exemple les intranet ou les sites bancaires.
C'est du costaud, ça marche très bien, des millions de personnes l'utilisent.
Au moment où j'écris ces lignes, la version 5 se prépare dans ce canal.
Où télécharger - Go les yeux fermés

Finale

Et évidemment, la version finale avec plusieurs centaines de millions d'utilisateurs. Actuellement, c'est la version 4 mais le 21 juin sortira la version 5. Cela signifie que Beta passera en version 6, Aurora en 7 et Nightly en 8^[2]. Il y a en permanence n, n+1, n+2 et n+3 en préparation. Et le changement suivant de n interviendra début août avec la sortie de Firefox 6^[3].

On peut voir tout cela comme un système de filtrage. Nightly a du contenu brut, Aurora est passé à travers un premier tamis pour dégrossir, Beta prend un tamis plus fin et dans Finale, il ne reste que des pépites :)

NB : Pour éviter les trolls, je supprimerai tout commentaire sur les numéros de versions.

Notes

[1] Il est pourtant d'une belle qualité, grâce à de nombreux tests automatisés

[2] pas immédiatement, il faut environ une semaine pour que tout migre

[3] si tout se passe bien

Les formulaires HTML5 dans Firefox 4

Anthony Ricaud — Thu, 19 May 2011 17:37:00 +0200

Firefox 4 est sorti il y a plus d'un mois (et il faut aller le télécharger d'ailleurs !). Parmi la liste des nombreuses améliorations, on trouve un bien meilleur support des formulaires HTML5. De nouveaux champs (email, url, tel, search), de nouveaux attributs (placeholder, autofocus, list), des formulaires découplés et différents mécanismes de validations. On doit principalement remercier Mounir Lamouri pour cela.

Cet article est basé sur celui publié en novembre sur hacks.mozilla.org

Précision: certains exemples fonctionneront dans d'autres navigateurs mais vous aurez besoin de Firefox 4 pour les voir tous.

Nouveaux types de champs

À l'instar des nouveaux éléments, HTML5 introduit de nouveaux types de champs pour mieux exprimer le genre d'informations que l'on souhaite recevoir. Le comportement et l'apparence de la plupart de ces nouveaux champs ne s'éloignent pas beaucoup du champ texte mais ils apportent un nouveau sens. Cela permet aux navigateurs de fournir une meilleure expérience aux utilisateurs. Par exemple, un navigateur mobile pourra fournir un clavier spécial pour certains champs^[1]. Ou alors il pourra pré-remplir les champs téléphoniques en se basant sur votre carnet d'adresses. Et si ce n'est pas le navigateur, des extensions pourront imaginer d'autres usages en s'appuyant sur ces nouveaux champs.

Firefox 4 ajoute quatre nouveaux types de champs :

<input type="search">
<input type="tel">
<input type="url">
<input type="email">

Parmi ces quatre champs, url et email valideront aussi leur contenu. Mais on en parlera plus en détails plus loin.

Il y a aussi une nouvelle sorte de champ:

<output for="i1 i2">

Vous pouvez utiliser cet élément pour représenter une partie de la page qui réagit aux interactions avec le formulaire. Pensez au prix total dans un panier d'achats après avoir changé la quantité d'articles ou les options d'envoi. Ce champ ne calculera rien de lui-même, il faudra le faire avec JavaScript, mais cela donnera des indications aux technologies d'assistance. L'attribut for est la liste des ID des éléments qui ont participé au calcul.

Les champs textes ont été améliorés par le support de <datalist>. Cela permet de fournir une liste de suggestions à l'utilisateur pendant qu'il tape. On associe le champ et les suggestions en utilisant l'attribut list. Et pour les navigateurs qui ne supportent pas ce mécanisme, ils afficheront le contenu de l'élément <datalist>. Donc n'oubliez pas d'y mettre un balisage correct afin d'avoir une bonne dégradation.

Entrez une ville : ou choisissez-en une

<label>Entrez une ville : <input list="cities"></label>
<datalist id="cities">
  ou
  <label>choisissez-en une
    <select>
      <option value="Paris">Paris</option>
      <option value="Londres">Londres</option>
      <option value="Berlin">Berlin</option>
      <option value="New York">New York</option>
      <option value="Tokyo">Tokyo</option>
      <option value="Sydney">Sydney</option>
      <option value="Johannesburg">Johannesburg</option>
      <option value="Melun">Melun</option>
    </select>
  </label>
</datalist>

Nouveaux attributs

Autofocus

Avec cet attribut sur un élément, il recevra le focus dès que possible. L'avantage direct pour l'utilisateur c'est que tous les sites utiliseront le même algorithme pour l'autofocus plutôt que d'avoir un bout de JavaScript différent sur chaque site. Et des navigateurs ou des extensions pourront facilement désactiver ce comportement si cela gêne l'utilisateur.

<input autofocus>

Placeholder

La valeur de cet attribut sera affichée lorsque le champ est vide et qu'il n'a pas le focus. Cela permet de donner un exemple de valeur attendue.

Telephone: Comments:

<label>Telephone: <input placeholder="+33 1 16 64 33 42"></label>
<label>Comments: <textarea placeholder="Dites nous ce que vous pensez de ce service…"></textarea></label>

Formulaires découplés^[2]

Vous avez de nouvelles options pour configurer l'interaction entre les champs et les formulaires.

Attribut form

Les éléments <input> ne doivent plus obligatoirement être des enfants d'un élément <form>. Vous pouvez les définir où vous souhaitez et les rattacher à un formulaire en utilisant l'attribut form. Sa valeur est l'ID du formulaire auquel il doit se rattacher.

Voyons un exemple. Disons que vous travaillez sur un moteur de recherche pour un outil de blog. Vous voulez un formulaire très simple pour le cas général et quelques options avancées si l'utilisateur a besoin de plus de contrôle.

En haut de votre page, vous pouvez placer:

<input type="search" name="search_field" form="search_form">

Et plus bas:

<form id="search_form" action="http://hanblog.info/blog/post/2011/05/search.php" method="post">
  <fieldset>
    <legend>Options avancées</legend>
    <input type="checkbox">Inclure les articles privés
    <!-- Autres options -->
  </fieldset>
</form>

Tout ceci se comportera comme si le champ de recherche faisait partie du formulaire. Mais vous avez la flexibilité de le placer où bon vous semble.

Les options de formulaires pour chaque champ

Toutes les options pouvant être définies au niveau du formulaire peuvent être redéfinies au niveau du champ. Tous les champs de soumissions (<button> et <input type="submit">) acceptent quatre nouveaux attributs : formenctype, formaction, formmethod et formtarget.

On peut imaginer les utiliser pour un formulaire avec des boutons publier et aperçu. Chacun a besoin des informations complètes du formulaire mais ils effectuent une action très différente.

<form action="http://hanblog.info/blog/post/2011/05/new_post.php" method="post">
<label>Titre: <input type="text"></label>
<label>Contenu: <textarea></textarea></label>
<input type="submit" formaction="http://hanblog.info/blog/post/2011/05/preview.php" formmethod="get" value="Aperçu">
<input type="submit" value="Publier">
</form>

Quand l'utilisateur clique sur le bouton Aperçu, ces attributs écraseront ceux du formulaire. Dans ce cas, au lieu d'une requête POST vers new_post.php, la totalité du formulaire sera soumise au script preview.php avec une méthode GET.

Mécanismes de validation

La validation est l'une des grandes améliorations des formulaires. Afin de fournir la meilleure expérience, il est de bon ton de donner un retour dès que possible à l'utilisateur. Du coup, chacun écrit beaucoup de JavaScript pour gérer cela. Ne serait-ce pas mieux que les navigateurs se débrouillent tous seuls ?

Depuis la parution de l'article original en novembre dernier, le style par défaut des champs invalides a été modifié et de nouvelles pseudo-classes ::-moz-ui-valid et ::-moz-ui-invalid ont été introduites. Du coup, les exemples ne sont plus aussi pertinents qu'à l'époque. Heureusement, Mounir a expliqué tous les changements.

required

Avec cet attribut, vous indiquez que ce champ est obligatoire. Pour les champs textes, cela signifie qu'ils ne doivent pas être vides. Pour les boutons checkbox, ils doivent être cochés. Et pour les boutons radios, l'un des boutons d'un groupe doit être sélectionné.

Essayez les exemples suivants pour voir les changements d'états.

<input type="text" required>

<input type="checkbox" required>

<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>
<input type="radio" name="radiogroup" required>

url

Les champs URLs sont automatiquement validés.

<input type="url" value="mozilla">
<input type="url" value="http://mozilla.org">

email

Les emails sont aussi validés automatiquement. En passant l'attribut multiple (utilisable sur type="file" aussi), il validera une liste d'emails séparés par des virgules.

<input type="email" value="foo">
<input type="email" value="foo@bar.org">

<input type="email" multiple value="foo@bar.org, spongebob">
<input type="email" multiple value="foo@bar.org, spongebob@squarepants.org">

pattern

Les URLs et les emails ne sont pas les seuls types de données que vous voulez valider. Pour cela, vous pouvez fournir une expression rationnelle JavaScript à l'attribut pattern. Elle sera utilisée pour valider la valeur d'un champ. Il est aussi conseillé de fournir un attribut title pour expliquer le type de contenu demandé.

Dans l'exemple suivant, survolez le champ. Vous devriez voir une aide vous expliquant comment remplir le champ.

<input pattern="[0-9][A-Z]{3}" title="A part number is a digit followed by three uppercase letters.">

L'API de validation des contraintes.

Si vous avez besoin d'encore un peu plus de contrôle sur la validation, vous pouvez utiliser la méthode setCustomValidity. Si vous l'appelez avec une chaîne vide, l'élément sera considéré comme valide. Sinon, il sera marqué invalide et la chaîne sera utilisée dans l'aide apparaissant pour l'utilisateur.

<label>Mot de passe : <input type="password" id="password1" oninput="checkPasswords()"></label>
<label>Confirmer mot de passe : <input type="password" id="password2" oninput="checkPasswords()"></label>
<script>
function checkPasswords() {
  var password1 = document.getElementById('password1');
  var password2 = document.getElementById('password2');
  if (password1.value != password2.value) {
    password2.setCustomValidity('Les mots de passe ne sont pas identiques');
  } else {
    password2.setCustomValidity('');
  }
}
</script>

Mot de passe : Confirmer mot de passe :

Si l'un des champs dans un formulaire est invalide, la soumission du formulaire sera bloquée et le premier champ invalide sera mis en avant avec un message expliquant le problème. Si vous ne désirez pas ce comportement, vous pouvez ajouter l'attribut novalidate sur le formulaire ou l'attribut formnovalidate sur l'un des boutons de soumission.

Pour plus de détails sur le mécanisme de validation, je vous recommande l'article de Mounir.

Nouveaux sélecteurs CSS

Pour accompagner toutes ces magnifiques nouveautés, quelques nouveaux sélecteurs ne seront pas de trop.

:required, :optional

Tous les champs sont marqués :optional par défaut. S'ils ont l'attribut required, alors ils répondront à la pseudo-classe :required.

:valid, :invalid

Ces pseudos-classes représentent l'état de validation d'un champ. Vous pouvez utiliser :invalid pour redéfinir le style par défaut que Firefox 4 fournit.

Voici un exemple de champ avec le style par défaut modifié.

:-moz-placeholder

Cette pseudo-classe sélectionne les champs affichant un "placeholder". Ce n'est pas encore défini par CSS donc vous aurez besoin d'utiliser un pseudo-élément pour les navigateurs basés sur WebKit.

<style>
#selectors2 :-moz-placeholder {
  font-style: italic;
}
#selectors2 ::-webkit-placeholder {
  font-style: italic;
}
</style>
<form id="selectors2">
  <input placeholder="Donnez moi du style !">
</form>

Conclusion

Les fonctionnalités HTML5 des formulaires sont très récentes et il y a encore de grandes différences entre les navigateurs. Opera a implémenté une partie de la spécification (elle s'appelait encore Webforms2 à l'époque) donc le support est plutôt bon même si vous trouverez des différences étant donné que la spécification a évolué depuis. Les navigateurs basés sur WebKit sont actuellement en train d'implémenter donc vous trouverez un peu de support de ce côté là aussi.^[3]

Il n'y aura pas d'autres nouveautés concernant les formulaires dans Firefox 4. Mais il y a encore beaucoup à faire pour avoir un support complet: de nouveaux types de champs (number, color, date), de nouveaux attributs (step, min, max), etc. Cela viendra dans de prochaines versions.

Ceci n'est qu'une vague introduction. Pour tous les détails, je recommande la documentation sur le Mozilla Developer Network.

Notes

[1] Voir mon article sur le comportement de l'iPhone. D'ailleurs, Firefox 4 aussi s'adapte.

[2] Je n'ai pas trouvé mieux pour exprimer cette idée.

[3] Honnêtement, c'est implémenté n'importe comment mais je ne vais pas m'étendre.

Que se passe-t-il un 1er février ?

Anthony Ricaud — Wed, 02 Feb 2011 00:19:00 +0100

1er février 2007 : je commence mon stage (qui est devenu un CDI) chez Skyrock.
1er février 2010 : mon dernier jour de travail chez Skyrock.
1er février 2011 : j'apprends que je vais devenir employé de Mozilla dans l'équipe de développement web.

En tout cas pour moi, ce sont plutôt des événements positifs qui se déroulent les 1er février.

Remettre en place le bouton RSS avec Firefox 4

Anthony Ricaud — Wed, 19 Jan 2011 19:06:00 +0100

Vous en avez peut-être entendu parler, Firefox 4 n'aura plus de boutons pour signaler la présence de flux RSS dans la barre d'adresses. La fonctionnalité de détection n'a pas disparu, elle est toujours disponible dans le menu Bookmarks. Et si vous souhaitez avoir un bouton toujours visible pour vous signaler la présence de RSS, il suffit de personnaliser votre barre d'outils en quelques clics. Les Orchard résume bien comment faire ça donc je ne vais pas le répéter ici.

Par contre, vous voulez peut-être retrouver ce bouton à son emplacement précédent, dans la barre d'adresses ? Pas de problème, il y a une l'extension "RSS icon in Awesombar". Et hop, tout va bien, vous avez retrouvé le bouton comme vous l'aimiez avec Firefox 3.6.

Hanblog - Mot-clé - planetmozfr

Relancer les soirées performances web

pdf.js, ça déchire.

NSID

Mes deux premières extensions

Longdesk

au-revoir-utm

Le cycle accéléré de Firefox

Le nouveau cycle

Nightly (ou trunk ou mozilla-central)

Aurora

Beta

Finale

Notes

Les formulaires HTML5 dans Firefox 4

Nouveaux types de champs

Nouveaux attributs

Autofocus

Placeholder

Formulaires découplés[2]

Attribut form

Les options de formulaires pour chaque champ

Mécanismes de validation

required

url

email

pattern

L'API de validation des contraintes.

Nouveaux sélecteurs CSS

:required, :optional

:valid, :invalid

:-moz-placeholder

Conclusion

Notes

Que se passe-t-il un 1er février ?

Remettre en place le bouton RSS avec Firefox 4

Formulaires découplés^[2]