Desenvolvendo a Web estável no IE10 Release Preview

  • 發行項

Como parte do planejamento do Windows 8 Release Preview, revisamos todos os padrões W3C de rascunho aceitos pelo IE10. Em particular, procuramos pelas especificações que:

  • são estáveis, ou seja, não houve adições ou alterações recentes e nenhuma renomeação ou alterações importantes são esperadas;
  • são aceitas por pelo menos dois navegadores diferentes do IE10;
  • são interoperáveis entre todos esses navegadores para os casos de uso principais dos recursos;
  • são usadas na Web, incluindo em seu formulário sem prefixo; e
  • são Candidatas à Recomendação desde o Windows 8 Consumer Preview ou têm possibilidades de se tornarem Candidatas à Recomendação em 2012.

Os seguintes recursos padrão de rascunho W3C correspondem a esses critérios e o IE10 agora os aceita em seu formato sem prefixo:

Para compatibilidade com sites e aplicativos desenvolvidos por meio do Windows 8 Consumer Preview, o IE10 também oferece suporte a padrões em seu formato com prefixo de fornecedor por meio de prefixos de fornecedor da Microsoft (‑ms‑/ms).

O IE10 também oferece suporte aos seguintes padrões de rascunho W3C em formado com prefixo de fornecedor. Acreditamos que esses rascunhos ainda não atendem aos critérios listados acima:

De experimental a estável

Quando os navegadores da Web implementam padrões emergentes, eles fazem isso marcando os novos recursos com seu próprio prefixo de fornecedor: um prefixo de propriedade de estilo com ‑moz‑ indica um recurso CSS experimental no Firefox da Mozilla, ‑ms‑ significa o mesmo para o Internet Explorer da Microsoft, ‑o‑ para Opera, e ‑webkit‑ para navegadores baseados em WebKit, incluindo o Chrome do Google e o Safari da Apple. Os equivalentes do modelo de objeto do recurso são semelhantemente prefixados.

Novas APIs de plataforma, tais como window.requestAnimationFrame() são igualmente invocadas no momento como window.mozRequestAnimationFrame(), window.webkitRequestAnimationFrame() ou window.msRequestAnimationFrame().

Os fornecedores de navegador geralmente perdem seu prefixo quando a especificação correspondente alcança o estágio Candidata à Recomendação. Essa convenção de nomeação possui inúmeros objetivos, entre os quais:

  • Permitir que a especificação evolua: sem prefixos, o conteúdo da Web escrito para as primeiras implementações poderia limitar o(e) editor(es) e tornar adições úteis ou alterações difíceis ou até mesmo impossíveis, e
  • Separar implementações experimentais: os bugs ou a escolha da versão de rascunho de um navegador específico não tem impacto em outros navegadores.
  • Documentação da folha de estilo: as dependências específicas do fornecedor de uma folha de estilo são explicitamente documentadas

Nossos padrões podem não contar com prefixos de fornecedor. Por exemplo, os fornecedores de navegador prefixaram os novos elementos HTML introduzidos pela especificação HTML, tais como <canvas> e <video>.

As práticas recomendadas da Web

Na prática, há um momento em que vários navegadores oferecem suporte ao mesmo recurso de rascunho de uma forma interoperável. Consequentemente, os desenvolvedores da Web acabam escrevendo declarações como:

-webkit-transform: rotate(30deg);

-moz-transform: rotate(30deg);

-ms-transform: rotate(30deg);

-o-transform: rotate(30deg);

Depois de copiar e colar esse padrão inúmeras vezes, muitos desenvolvedores presumem que o próximo padrão W3C terá compatibilidade com a versão anterior da Web atual. Eles prosseguem preparando suas folhas de estilo para o futuro, adicionando uma versão sem prefixo da propriedade:

-webkit-transform: rotate(30deg);

-moz-transform: rotate(30deg);

-ms-transform: rotate(30deg);

-o-transform: rotate(30deg);

transform: rotate(30deg);

Do ponto de vista de um desenvolvedor da Web, o conjunto de declarações acima agora está pronto para navegadores futuros que oferecem suporte a Transformações CSS sem prefixo.

Recursos padrão antigos validaram de fato essa presunção pragmática. Quando o IE9 adicionou suporte à propriedade border-radius sem prefixo em seu primeiro Platform Preview, nossa equipe viu o recurso “brilhar” entre muitos sites devido às folhas de estilo preparadas para o futuro já implantadas.

Inúmeros recursos estão seguindo a mesma evolução agora. Não somente existem muitas páginas de demonstração de Transições CSS preparadas para o futuro – consulte o efeito paralaxe de Paul Hayes ou a galeria animada de Lea Verou – mas projetos de código-fonte aberto, tais como html5slides do Google, home pages de designers, logotipos de site e tutoriais rotineiramente incluem declarações transition sem prefixo.

Muitos efeitos de transição envolvem Transformações CSS, cujos tutoriais também declaram frequentemente propriedades transform sem prefixo.

Finalizando as especificações

Mesmo quando os desenvolvedores da Web antecipam a convergência do navegador em sua nova marcação, o processo de padronização é muito mais conservador. Enquanto border-radius funcionou interoperacionalmente o suficiente para milhares de sites da Web, os membros do Grupo de Trabalho de CSS estiveram ocupados definindo a renderização de casos mais complexos, tais como a aparência de um canto arredondado entre duas bordas adjacentes de larguras e cores variáveis. Igualmente, os editores de Transições, Animações e Transformações CSS estão trabalhando para especificar condições de erro, corrigir erros ou esclarecer cenários menos comuns.

Embora esses problemas devam ser resolvidos para garantir um alto nível de interoperabilidade e para alcançar o status Recomendação, relativamente poucos deles afetarão o conteúdo atual e futuro. Quando uma especificação se torna estável e interoperável, a Web não deve ser impedida pelos últimos casos de cantos. Isso não era necessário para novos elementos HTML5 ou para finalizar a especificação CSS2.1, nenhum deles requeria prefixação.

Embora especificações sólidas apoiadas por suítes de teste públicos sejam críticas, exigindo que todos os desenvolvedores da Web repitam as mesmas declarações várias vezes até que uma Candidata à Recomendação seja publicada prioriza a conclusão de especificação sobre a estabilidade do conteúdo.

Concluir uma especificação é um esforço lento. Para usar um exemplo, os gradientes CSS surgiram em 2008, o primeiro Rascunho de Trabalho especificando uma solução interoperável em 2009 e a Candidata à Recomendação foram publicados em abril de 2012. No meio tempo, a sintaxe padronizada se tornou incompatível com a sintaxe prefixada implantada em muitos sites da Web. O Release Preview do IE10 é a primeira implantação sem prefixo pública da especificação mais recente. (O IE10 também oferece suporte à versão prefixada interoperável com o prefixo de fornecedor ‑ms‑).

O que isso significa para o seu código

Gradientes CSS

Embora amplamente interoperável, a sintaxe de gradiente prefixada aceita por todos os navegadores modernos reflete uma versão de rascunho agora obsoleta da especificação. Essa sintaxe anterior é incompatível com a Candidata à Recomendação atual. Por exemplo, se você declarou o gradiente seguinte:

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

Então, produzir o equivalente sem prefixo não é simplesmente uma questão de remover o prefixo ‑ms‑. Como a função gradiente linear sem prefixo do IE10 está em conformidade com a especificação mais recente, ela deve se tornar:

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

Uma postagem de blog futura abordará em mais detalhes o suporte do IE10 a gradientes CSS.

Modelo de objeto em cascata e CSS

A cascata resolverá as propriedades CSS prefixadas como o esperado; dada a regra seguinte (observe o ângulo de rotação maior na declaração sem prefixo):

-ms-transform: rotate(30deg);

transform: rotate(60deg);

Seu elemento irá girar em 60 graus: as duas propriedades são tratadas como alias uma da outra e a última declaração ganha. Suas propriedades CSSOM correspondentes também são alias: se você solicitou o valor computado das propriedades de estilo transform e msTransform, ambas refletirão a transformação de 60 graus vencedora.

Igualmente, configurar element.style.transform também definirá element.style.msTransform e vice-versa.

Serialização de nomes de propriedade

Propriedades tais como transition-property usam uma lista de nomes de propriedade CSS. Por exemplo, para fazer a transição da propriedade transform em mais de 2 segundos no IE10 Consumer Preview, um desenvolvedor escreveria:

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

-ms-transition-duration: 2s;

O IE10 Release Preview serializará o valor de style.msTransitionProperty e style.transitionProperty como ‘transform’. Observe que o prefixo original não é preservado.

Isso também é verdadeiro para a propriedade propertyName de eventos de transição.

Nomes de tipo de evento de Animação e Transição

O IE10 Release Preview permite o registro de ouvintes de evento de Animação e Transição através de nomes prefixados e sem prefixo, ou seja, os seguintes são equivalentes:

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

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

Mas o IE10 Release Preview sempre retornará um nome sem prefixo na propriedade type do objeto de evento.

O que está por vir

Enviaremos novos casos de teste para o W3C de todos os recursos que o IE10 agora aceita sem um prefixo. Como membros do Grupo de Trabalho e co-editores, trabalharemos com nossos colegas para mover essas especificações para Candidata à Recomendação.

Damos boas-vindas aos comentários que você tenha sobre nosso suporte a esses recursos e sua compatibilidade de navegador cruzado.

—Sylvain Galineau, gerente de programas, Internet Explorer