Freigeben über

Un Web plus stable dans IE10 Release Preview

  • Artikel

Dans le cadre de la planification de Windows 8 Release Preview, nous avons passé en revue l'ensemble des standards W3C en version préliminaire pris en charge par IE10. Nous avons plus particulièrement cherché des spécifications :

  • stables, c'est-à-dire sans ajouts récents ou modifications récentes, pour lesquelles aucun changement de nom ou autre modification majeure n'est attendu ;
  • prises en charge par au moins deux navigateurs en plus d'IE10 ;
  • interopérables sur l'ensemble de ces navigateurs, pour les principaux scénarios d'utilisation des fonctionnalités ;
  • déjà utilisées sur le Web, y compris sous forme non préfixée ;
  • au niveau Candidate Recommendation depuis Windows 8 Consumer Preview ou sur le point d'atteindre ce niveau en 2012.

Les fonctionnalités standard W3C suivantes en version préliminaire répondent à ces critères. IE10 les prend désormais en charge sous forme non préfixée :

Pour des raisons de compatibilité avec les sites et les applications développés à l'aide de Windows 8 Consumer Preview, IE10 prend également en charge ces standards sous leur forme préfixée par l'éditeur, en utilisant les préfixes Microsoft (‑ms‑/ms).

IE10 prend aussi en charge les standards W3C suivants en version préliminaire, sous forme préfixée par l'éditeur. De notre point de vue, ces versions préliminaires ne respectent pas encore les critères détaillés ci-dessus :

Du niveau expérimental au niveau stable

Lorsque des navigateurs Web implémentent des standards émergents, ils ajoutent leur propre préfixe d'éditeur aux nouvelles fonctionnalités : une propriété de style précédée de ‑moz‑ indique une fonctionnalité CSS expérimentale dans Mozilla Firefox. ‑ms‑ est l'équivalent pour Microsoft Internet Explorer, ‑o‑ pour Opera et ‑webkit‑ pour les navigateurs basés sur WebKit, notamment Google Chrome et Apple Safari. Un préfixe est apposé de la même manière aux équivalents du modèle objet des fonctionnalités.

De nouvelles API de plateforme telles que window.requestAnimationFrame() sont également appelées actuellement sous la forme window.mozRequestAnimationFrame(), window.webkitRequestAnimationFrame() ou window.msRequestAnimationFrame().

Les éditeurs des navigateurs suppriment généralement leur préfixe dès lors que la spécification atteint la phase Candidate Recommendation. Cette convention d'affectation des noms a plusieurs objectifs :

  • Permettre l'évolution de la spécification : en l'absence de préfixe, le contenu Web écrit pour les implémentations préliminaires serait susceptible de limiter la marge de manœuvre des éditeurs et de rendre les ajouts et les modifications difficiles, voire impossibles.
  • Isoler les implémentations expérimentales : les bugs et le choix d'une version préliminaire d'un navigateur spécifique n'ont pas d'impact sur les autres navigateurs.
  • Documenter la feuille de style : les dépendances de feuille de style propres à chaque éditeur sont documentées de façon explicite.

D'autres standards ne reposent sur aucun préfixe d'éditeur. Par exemple, les éditeurs de navigateurs n'ont jamais préfixé les nouveaux éléments HTML introduits par la spécification HTML5, par exemple <canvas> et <video>.

Les bonnes pratiques du Web

En pratique, au bout d'un certain temps, plusieurs navigateurs prennent en charge la même fonctionnalité en version préliminaire de façon interopérable. Par conséquent, les développeurs Web se retrouvent à coder des déclarations telles que celle-ci :

-webkit-transform: rotate(30deg);

-moz-transform: rotate(30deg);

-ms-transform: rotate(30deg);

-o-transform: rotate(30deg);

Après avoir copié et collé ce fragment de code un certain nombre de fois, de nombreux développeurs partent du principe que le standard W3C à venir offrira une rétrocompatibilité avec le Web actuel. Afin de « pérenniser » leurs feuilles de style, ils ajoutent une version non préfixée de la propriété :

-webkit-transform: rotate(30deg);

-moz-transform: rotate(30deg);

-ms-transform: rotate(30deg);

-o-transform: rotate(30deg);

transform: rotate(30deg);

Du point de vue du développeur Web, l'ensemble de déclarations ci-dessus est alors prêt à s'adapter aux futurs navigateurs prenant en charge les transformations CSS non préfixées.

Par le passé, les fonctionnalités standard ont en effet validé cette hypothèse pragmatique. Lorsqu'IE9 a ajouté la prise en charge de la propriété border-radius non préfixée dans sa première version Platform Preview, notre équipe a vu la fonctionnalité apparaître sur de nombreux sites, car des feuilles de style pérennes avaient déjà été déployées.

Différentes fonctionnalités suivent actuellement la même évolution. Non seulement les pages de démonstration de nombreuses transitions CSS sont pérennes (consultez l'effet de parallaxe de Paul Hayes ou la galerie animée de Lea Verou), mais en plus certains projets open source tels que Google html5slides, la page d'accueil de ces concepteurs, des logos de site et des didacticiels intègrent de façon systématique des déclarations transition non préfixées.

De nombreux effets de transition impliquent des transformations CSS, et des didacticiels à ce sujet déclarent également très souvent des propriétés transform non préfixées.

Peaufiner les spécifications

Même si les développeurs Web anticipent la convergence des navigateurs dans leur code, le processus de standardisation est bien plus conservateur. Alors que border-radius fonctionnait de façon suffisamment interopérable pour des milliers de sites Web, les membres du groupe de travail CSS se sont chargés de définir le rendu de cas plus complexes, par exemple l'apparence d'un coin arrondi entre deux bordures adjacentes de largeurs et de couleurs différentes. De même, les équipes travaillant sur les transitions, les animations et les transformations CSS cherchent à spécifier des conditions d'erreur, à corriger des erreurs ou à éclaircir certains scénarios peu courants.

Si ces problèmes doivent être résolus pour garantir un niveau d'interopérabilité optimal et atteindre le statut Recommendation, relativement peu d'entre eux affecteront les contenus actuels et futurs. Une fois qu'une spécification est stable et interopérable, le Web ne doit pas être freiné par les derniers cas extrêmes restant à résoudre. Cela n'a pas été nécessaire pour les nouveaux éléments HTML5, ni pour finaliser la spécification CSS2.1, qui n'ont nécessité aucun préfixage.

Des spécifications solides appuyées par des séries de tests publics exhaustifs sont indispensables, mais le fait d'obliger les développeurs Web à répéter les mêmes déclarations plusieurs fois jusqu'à ce qu'une spécification Candidate Recommendation soit publiée revient à privilégier l'exhaustivité des spécifications au détriment de la stabilité du contenu.

Il est très fastidieux de peaufiner une spécification. Pour prendre un exemple, les dégradés CSS ont émergé en 2008, la première version préliminaire (Working Draft) spécifiant une solution interopérable en 2009 et la version Candidate Recommendation a été publiée en avril 2012. Entre-temps, la syntaxe standardisée est devenue incompatible avec la syntaxe préfixée déployée sur de nombreux sites Web. La Release Preview d'IE10 constitue la première implémentation publique non préfixée de la dernière spécification. (IE10 prend également en charge la version préfixée, plus interopérable, par le biais du préfixe d'éditeur ‑ms‑.)

Les conséquences pour votre code

Dégradés CSS

Bien que largement interopérable, la syntaxe de dégradé préfixée prise en charge par tous les navigateurs récents correspond à une version préliminaire et désormais obsolète de la spécification. Cette syntaxe préliminaire est incompatible avec la version Candidate Recommendation actuelle. Par exemple, si vous aviez déclaré le dégradé suivant :

background: -ms-linear-gradient(left, yellow, red);

Pour produire l'équivalent non préfixé, il ne suffit pas de supprimer le préfixe ‑ms‑. Comme la fonction de dégradé linéaire non préfixée d'IE10 respecte la spécification la plus récente, le nouveau code doit être le suivant :

background: linear-gradient(to right, yellow, red);

Nous étudierons plus en détail la prise en charge des dégradés CSS dans IE10 dans un prochain billet de blog.

Cascades et modèle d'objet CSS

La cascade résout les propriétés CSS préfixées comme attendu, selon la règle suivante (vous remarquerez que l'angle de rotation est plus élevé dans la déclaration non préfixée) :

-ms-transform: rotate(30deg);

transform: rotate(60deg);

Votre élément pivotera de 60 degrés : les deux propriétés sont traitées comme des alias l'une de l'autre et la dernière déclaration est prise en compte. Leurs propriétés CSSOM correspondantes sont également des alias : si vous demandez la valeur calculée des propriétés de style transform et msTransform, elles reflèteront toutes les deux la transformation de 60 degrés prise en compte.

De même, la définition de element.style.transform définit également element.style.msTransform, et inversement.

Sérialisation des noms de propriétés

Les propriétés telles que transition-property acceptent comme valeur une liste de noms de propriétés CSS. Par exemple, pour que la transition de la propriété transform dure deux secondes dans IE10 Consumer Preview, le développeur doit la coder comme suit :

-ms-transition-property: -ms-transform;

-ms-transition-duration: 2s;

IE10 Release Preview sérialisera la valeur de style.msTransitionProperty et style.transitionProperty sous la forme « transform ». Vous remarquerez que le préfixe d'origine n'est pas conservé.

C'est également le cas pour la propriété propertyName des événements de transition.

Noms des types d'événements Animation et Transition

IE10 Release Preview permet d'inscrire des détecteurs d'événements Animation et Transition en utilisant aussi bien des noms préfixés que non préfixés. Les éléments suivants sont donc équivalents :

element.addEventListener("MSTransitionEnd", myHandler, false);

element.addEventListener("transitionend", myHandler, false);

Dans tous les cas, IE10 Release Preview renverra un nom non préfixé dans la propriété type de l'objet événement.

Prochaines étapes

Nous transmettrons de nouveaux scénarios de test au W3C pour toutes les fonctionnalités qu'IE10 prend maintenant en charge sans préfixe. En tant que membres et co-éditeurs du groupe de travail, nous travaillerons main dans la main avec nos collègues pour faire passer ces spécifications au niveau Candidate Recommendation.

N'hésitez pas à laisser des commentaires sur la façon dont nous prenons en charge ces fonctionnalités et sur leur compatibilité entre les navigateurs.

—Sylvain Galineau, chef de projet, Internet Explorer