Qual é o motivo para colocar prefixos em novos recursos CSS?


10

Existe uma razão válida para que os navegadores prefixem novos recursos CSS, em vez de permitir que os webmasters usem a versão não prefixada?

Por exemplo, um código de exemplo para o gradiente de fundo é semelhante a:

#arbitrary-stops {
  /* fallback DIY*/

  /* Safari 4-5, Chrome 1-9 */
  background: -webkit-gradient(linear, left top, right top, from(#2F2727), color-stop(0.05, #1a82f7), color-stop(0.5, #2F2727), color-stop(0.95, #1a82f7), to(#2F2727));

  /* Safari 5.1+, Chrome 10+ */
  background: -webkit-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Firefox 3.6+ */
  background: -moz-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* IE 10 */
  background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

  /* Opera 11.10+ */
  background: -o-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
}

Qual o sentido de forçar os webmasters a copiar e colar o mesmo código quatro vezes para obter o mesmo resultado?


Nota: um dos motivos frequentemente citados é que os estilos prefixados devem ser temporários, enquanto o navegador não implementa a especificação corretamente ou a especificação não é definitiva .

IMO, esse motivo é um absurdo:

  • Se o mecanismo do navegador não implementar as especificações corretamente, o navegador não será compatível, independentemente de não ser implementado em um formato não prefixado ou não em um formato prefixado.
  • Se a especificação não for definitiva, pode ser importante quando houve implementações anteriores com o mesmo nome. Por exemplo, se o CSS2 tivesse linear-gradient, mas o CSS3 pretendesse se estender linear-gradientcom recursos adicionais, seria inteligente prefixar temporariamente a nova implementação de rascunho e -css3-<style>diferenciação entre o CSS2 em funcionamento e o CSS3 experimental. Na prática, o CSS2 não possui linear-gradientou outras novidades do CSS3.

Eu também entenderia se navegadores diferentes tinham formatos de implementação diferentes : por exemplo, digamos que o Firefox seja necessário, para sombra de texto <weight-of-shadow distance-x distance-y color>, enquanto o Chrome seja necessário <distance-x distance-y weight-of-shadow color>. Mas, na verdade, este não é o caso; pelo menos todos os novos recursos do CSS3 que eu usei até agora tinham o mesmo formato.


2
If the browser engine does not implement the spec correctly, the browser will not be compliant- Bem-vindo ao mundo real. ™
Robert Harvey

Eu vi variantes das bordas arredondadas entre os navegadores - especialmente ao tentar atribuir um canto específico. Nesse caso, acho que as implementações específicas do navegador estavam em vigor antes que a especificação fosse escrita para bordas mais arredondadas.
HorusKol 02/09/11

Respostas:


9

De acordo com esta nota do W3C :

Para evitar conflitos com os recursos futuros do CSS, a especificação CSS2.1 reserva uma sintaxe prefixada para extensões proprietárias e experimentais do CSS.

Antes de uma especificação atingir o estágio Recomendação do Candidato no processo W3C, todas as implementações de um recurso CSS são consideradas experimentais. O CSS Working Group recomenda que as implementações usem uma sintaxe prefixada pelo fornecedor para esses recursos, incluindo aqueles nos Working Drafts do W3C. Isso evita incompatibilidades com futuras alterações no rascunho.


Você pode acompanhar o estado do CSS aqui e aqui .


4

Eu também entenderia se navegadores diferentes tinham formatos de implementação diferentes ... [b] ut, na verdade, esse não é o caso; pelo menos todos os novos recursos do CSS3 que eu usei até agora tinham o mesmo formato.

Isso me diz que você não joga esse jogo há tempo suficiente.

O problema é que os navegadores da Web nunca implementam novos recursos da mesma maneira. É comum ver um navegador implementar recursos que não foram padronizados e o resultado é que tudo age de maneira diferente em diferentes navegadores.

Além disso, os novos recursos costumam ter erros (evitaremos chamar o IE pelo nome) e, mesmo que a sintaxe para vários elementos seja a mesma, o resultado é diferente.

Isso causa uma dor de cabeça para os desenvolvedores que estão tentando usar novos recursos. Depois que terminam de escrever sua folha de estilo, eles rapidamente percebem que é renderizada de maneira diferente em navegadores diferentes por razões inexplicáveis.

Antes do surgimento dos prefixos, os desenvolvedores eram obrigados a confiar nas diferenças detectáveis ​​entre os navegadores, geralmente explorando erros no analisador de CSS. Isso resultou em abominações como esta:

padding: 10px;
width: 200px;
w\idth: 180px;
height: 200px;
heigh\t: 180px;

Esses tipos de hacks foram o resultado da tentativa de um desenvolvedor de personalizar sua folha de estilo para cada navegador, usando qualquer tipo de método estranho que eles pudessem encontrar.

Ao padronizar prefixos, ele permite que os desenvolvedores usem recursos que não são estáveis ​​em diferentes navegadores. Os prefixos -moz-e -webkit-deixam bem claro que o autor está tentando fornecer um estilo que deve ser aplicado apenas em determinados navegadores da web.

Quando os recursos se tornarem estáveis ​​e os navegadores começarem a agir da mesma forma, você poderá remover o prefixo e declarar o recurso uma vez.

Eu acho que é importante perceber que os prefixos NÃO significam que você deve declarar estilos uma vez para cada navegador. Prefixos significam que deve declarar estilos adicionais sempre que você encontrar um navegador da Web que não esteja em conformidade com um padrão. Por exemplo, em vez do código acima, você deve começar com:

 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

Se você perceber repentinamente que a Microsoft não consegue calcular corretamente um gradiente linear, adicione um prefixo para corrigir o problema no IE:

 /* Friggin IE */
 background: -ms-linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);
 background: linear-gradient(left, #2F2727, #1a82f7 5%, #2F2727, #1a82f7 95%, #2F2727);

De repente, sua página parece a mesma em todos os navegadores, apesar de um deles ter feito as coisas de maneira diferente.

Você descobrirá que isso foi abordado de maneira muito abrangente neste artigo em A List Apart .


2

Se o mecanismo do navegador não implementar as especificações corretamente, o navegador não será compatível, independentemente de não ser implementado em um formato não prefixado ou não em um formato prefixado.

A diferença é que o navegador não irá quebrar a compatibilidade quando se tornou complacente. Se o comportamento do navegador for diferente da especificação, eles não quebrarão o código antigo quando o alterarem, porque ele está listado com um novo nome.


Então, você está dizendo que, no caso de não ser compatível (ou se tornar não compatível), o fornecedor o deixa como está e faz outra versão prefixada compatível? Eu pensei que as versões prefixadas deveriam desaparecer quando se tornassem compatíveis / oficiais?
Jacob Schoen

@jschoen: Isso nunca pode acontecer, porque você quebraria o código legado que depende dele.
DeadMG 01/09/11
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.