Geckozone

Ca y est les maj sont à nouveaux actives pour le canal Aurora

Jusqu'à présent, lorsque l'on appelait l'une des trois méthodes setTransform(), bezierCurveTo() ou arcTo() de <canvas> avec un argument invalide, Firefox levait une exception. Or la spécification demandait simplement d'ignorer l'appel.

C'est désormais le cas dans votre prochaine Nightly (et donc dans Firefox 7).

Bug 632486 — Handle non-finite values for bezierCurveTo per spec
Bug 632513 — Handle non-finite values for setTransform per spec
Bug 632482 — Handle non-finite values for arcTo per spec

Les deux interfaces DOM HTMLDelElement et HTMLInsElement, contrôlant les balises HTML <del> et <ins>, ont été remplacés dans DOM1 vers 1998 par un unique HTMLModElement.

Firefox était le seul navigateur a les implémenter. Tous les autres, y compris Firefox, implémentent HTMLModElement.

Dans votre dernière Nightly, et donc dans Firefox 7, ce ne sera plus le cas. Seul le standard HTMLModElement sera supporté.

Bug 587463 — Drop support for HTMLDelElement and HTMLInsElement

Dans votre dernière Nightly (et donc dans Firefox 7), une nouvelle entrée Get More Tools est ajoutée dans le menu Tools > Web Developper:



Cette entrée envoie sur la page de la collection Web Developpper's Toolbox d'AMO qui regroupe plein d'extensions pour les développeurs web.

Bug 655776 — Web Developer > Get More Tools menu item

Les deux propriétés (en lecture seule) x et y de HTMLImageElement étaient non-standard. Ms2ger continuant à faire la chasse à ce genre de différences — celle-ci signalée par Anne von Kesteren d'Opera — par rapport au standard (ici DOM1), elles seront supprimées dans la prochaine Nightly (et donc dans Firefox 7).

Bug 587021 — drop HTMLImageElement.x/.y

Sur Mac OS, comme sur les autres OS mais c'est déjà fait, une application peut indiquer quels types MIME, et extensions au cas où celui-ci n'est pas renseigné, il supporte. Ainsi l'OS peut le proposer pour ouvrir des fichiers locaux.

Sur Mac OS, contrairement à Windows, Firefox ne s'enregistrait pas comme lecteur audio et video. C'est désormais chose faite. Les fichiers audio/ogg (.oga, .ogg) et les fichiers video/ogg (.ogv) ainsi que video/webm (.webm) verront Firefox apparaître comme application d'ouverture potentielle.

Bug 650451 — Associate the application with playable media types on Mac

L'en-tête HTTP Link: a une histoire agitée. Il a été initialement spécifié en 1997 dans le premier RFC de HTTP/1.1, RFC2068 section 19.6.2.4, puis il a été retiré lors de la seconde RFC de HTTP/1.1, RFC 2616, en 1999 car aucun navigateur ne le supportait.

Par la suite, certains navigateurs (dont Opera et Firefox, mais pas IE, Chrome et Safari) l'ont implémenté, et l'utilisent pour définir les feuilles de styles (c'est-à-dire avec rel="stylesheet"), soit l'équivalent de l'élément HTML <link> (avec la particularité de l'émuler même sur des documents non-html, comme des images ou du simple texte!). Une nouvelle norme, plus complète, l'a donc redéfini, RFC 5988 en octobre 2010.

Firefox l'a toujours supporté pour l'indication des feuilles de style (aucun navigateur ne l'utilise pour autre chose), bien qu'il ait quelques limitations par rapport aux nouveautés de 2010. En particulier il permet de spécifier soit des feuilles de styles text/css, soit xslt (avec le type MIME commun mais incorrect text/xsl).

Pour les feuilles de style xslt, il y a une limitation : Fx n'accepte pas le type MIME application/xslt+xml pourtant plus correct que text/xsl qu'il accepte. Ce sera corrigé dans la prochaine Nightly (et donc dans Firefox 7).

Voici une page de test pour l'en-tête Link:.

Bug 655238 — stylesheet link header doesn't support official XSLT media type

Pas mal ce truc, je ne connaissais pas du tout. Dommage que ça ne soit supporté que par Firefox et Opera.

À noter qu'il y a une autre utilité de Link:, c'est pour le prefetching.

La méthode normalizeDocument() de l'objet DOM Document a été supprimée. Ce n'était qu'un alias de normalize() de toute manière.

Bug 641190 — Remove Document.normalizeDocument

Le système de télémétrie, dont je vous avez déjà parlé, a encore quelques défauts: il a été repoussé de Firefox 6 à Firefox 7.

Taras a à nouveau bloggué sur lui: Telemetry Updates.

Le rendu des polices avec l'accélération graphique DirectWrite/Direct2D sous Windows est un peu... différente. Tout le monde n'aime pas. Après avoir mis à disposition quelques propriétés DirectWrite via about:config (dans Firefox 6 si je me rappelle bien), Robert O'Callahan vient de récidiver avec la propriété gfx.font_rendering.cleartype_params.force_gdi_classic_for_families qui force le mode GDI_Classic pour quelques familles de police (Arial, Courier New, Tahoma, Trebuchet MS et Verdana). Il s'avère que ce mode est meilleur avec ces polices.

Le rendu en mode GDI_Classic est limité jusqu'à une taille de caractères de 15 pixels. Après c'est le rendu DirectWrite habituel qui prend le relais. C'est contrôlé par la nouvelle préférence gfx.font_rendering.cleartype_params.force_gdi_classic_max_size.

Dans votre prochaine Nightly... Il est possible que ce soit déjà accepté pour Firefox 5 (ou Firefox 6 au pire).

Bug 661471 — Create preference(s) to allow specific font families to be forced to use GDI Classic rendering

Une jolie nouveauté pour les créateurs d'extensions! Bien souvent celles-ci n'ont besoin que de quelques préférences toutes simples. Un nouveau système vient d'arriver sur Nightly: quelques lignes de xul... Et cela apparaît sous about:addons, dans la page de l'extension. Par exemple:


Sûr que ce sera intéressant.

Bug 653637 — Provide a simple way for addons to have pref

Je viens de vois que -moz-orient était supporté pour Firefox 6 pour l’élément HTML5 <progress> (bien pratique) qui permettra de choisir entre : horizontal et vertical.

Zefling a écrit :Je viens de vois que -moz-orient était supporté pour Firefox 6 pour l’élément HTML5 <progress> (bien pratique) qui permettra de choisir entre : horizontal et vertical.

Yep : http://www.geckozone.org/forum/viewtopi ... 16#p628616