Em quase todas as versões do Chrome, há um número significativo de atualizações e melhorias no produto, na performance e também nos recursos da plataforma da Web.
No Chrome 49 (Beta, 2 de fevereiro de 2016. Data estimada de lançamento da versão estável: março de 2016) há várias mudanças no Chrome.
O uso do prefixo "css" em getComputedStyle(e).cssX foi descontinuado
TL;DR: o uso do prefixo "css" em
getComputedStyle(e)
foi descontinuado porque não fazia parte da especificação
formal.
getComputedStyle é uma ótima função pequena. Ele vai retornar todos os valores CSS dos estilos do elemento DOM conforme foram calculados pelo mecanismo de renderização. Por exemplo, você pode executar getComputedStyle(_someElement_).height, e ele pode retornar 224,1 px porque essa é a altura do elemento como ele é exibido no momento.
Parece uma API bastante útil. Então, o que estamos mudando?
Antes de o mecanismo de renderização do Chrome mudar para o Blink, ele era alimentado pelo WebKit, que permitia prefixar "css" no início de uma propriedade. Por
exemplo, getComputedStyle(e).cssHeight em vez de getComputedStyle(e).height.
Ambos retornariam os mesmos dados, já que foram mapeados para os mesmos valores subjacentes,
mas é esse uso do prefixo "css" que não é padrão e foi
descontinuado e removido.
Observação: cssFloat é uma propriedade padrão e não é afetada por essa descontinuação.
Se você acessar uma propriedade dessa forma no Chrome 49, ela vai retornar undefined, e será necessário corrigir o código.
O uso de initTouchEvent foi descontinuado
TL;DR:
initTouchEvent
foi descontinuado em favor do
TouchEvent
constructor para melhorar
a conformidade com a especificação e será removido completamente no Chrome 54.
Intenção de remoção Rastreador do Chromestatus Problema do CRBug
Há muito tempo, é possível criar eventos de toque sintéticos no Chrome usando a API initTouchEvent. Eles são usados com frequência para simular eventos de toque em testes ou para automatizar alguma interface no seu site. No Chrome 49, descontinuamos essa API e vamos mostrar o seguinte aviso com a intenção de removê-la completamente no Chrome 53.
Há vários motivos para essa mudança ser boa.
Ela também não está na especificação de eventos de toque. A implementação do Chrome de
initTouchEvent não era compatível com a API initTouchEvent do Safari e
era diferente da do Firefox no Android. Por fim, o construtor TouchEvent é muito mais fácil de usar.
Decidimos seguir a especificação em vez de manter uma API
que não é especificada nem compatível com a única outra implementação.
Por isso, primeiro vamos descontinuar e depois remover a função initTouchEvent
e exigir que os desenvolvedores usem o construtor TouchEvent.
Há uso dessa API na Web, mas sabemos que ela é usada por um número relativamente baixo de sites. Por isso, não a estamos removendo tão rápido quanto faríamos normalmente. Acreditamos que parte do uso está corrompida porque os sites não processam a versão da assinatura do Chrome.
Como as implementações da API initTouchEvent em iOS e Android/Chrome eram muito diferentes, muitas vezes você tinha um código semelhante a (esquecendo o Firefox com frequência).
var event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
}
document.body.dispatchEvent(touchEvent);
Primeiro, isso é ruim porque procura "Android" no user agent, e o Chrome no Android vai corresponder e atingir essa descontinuação. No entanto, ele não pode ser removido ainda porque haverá outros navegadores baseados em WebKit e Blink mais antigos no Android por um tempo, e você ainda precisará oferecer suporte à API mais antiga.
Para processar TouchEvents corretamente na Web, mude seu código para
compatível com Firefox, IE Edge e Chrome. Para isso, verifique a existência de TouchEvent
no objeto window. Se ele tiver um "length" positivo (indicando que é um
construtor que recebe um argumento), use-o.
if('TouchEvent' in window && TouchEvent.length > 0) {
var touch = new Touch({
identifier: 42,
target: document.body,
clientX: 200,
clientY: 200,
screenX: 300,
screenY: 300,
pageX: 200,
pageY: 200,
radiusX: 5,
radiusY: 5
});
event = new TouchEvent("touchstart", {
cancelable: true,
bubbles: true,
touches: [touch],
targetTouches: [touch],
changedTouches: [touch]
});
}
else {
event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches,
changedTouches, 0, 0);
}
}
document.body.dispatchEvent(touchEvent);
Processadores de erros e de sucesso necessários nos métodos RTCPeerConnection
TL;DR:os métodos WebRTC
RTCPeerConnection createOffer()
e createAnswer()
agora exigem um gerenciador de erros e um de sucesso. Antes, era possível chamar esses métodos apenas com um manipulador de sucesso. Esse uso foi
descontinuado.
No Chrome 49, também adicionamos um aviso se você chamar
setLocalDescription()
ou setRemoteDescription()
sem fornecer um manipulador de erros. Esperamos tornar o argumento do manipulador de erros obrigatório para esses métodos no Chrome 50.
Isso faz parte da preparação para a introdução de promessas nesses métodos, conforme exigido pela especificação do WebRTC.
Confira um exemplo da demonstração RTCPeerConnection do WebRTC (main.js, linha 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Observe que setLocalDescription() e setRemoteDescription() sempre tiveram um parâmetro de manipulador de erros. Portanto, basta especificar esse parâmetro para fazer uma mudança segura.
Em geral, para aplicativos WebRTC de produção, recomendamos o uso de
adapter.js, um shim mantido pelo
projeto WebRTC para isolar apps de mudanças de especificação e diferenças de prefixo.
Document.defaultCharset está descontinuado
TL;DR: Document.defaultCharset foi descontinuado para melhorar a conformidade com a especificação.
Intenção de remoção Rastreador do Chromestatus Problema do CRBug
O Document.defaultCharset é uma propriedade somente leitura que retorna a codificação de caracteres padrão do sistema do usuário com base nas configurações regionais. Não foi considerado útil manter esse valor devido à forma como os navegadores usam as informações de codificação de caracteres na resposta HTTP ou na metatag incorporada na página.
Ao usar "document.characterSet", você vai receber o primeiro valor especificado no
cabeçalho HTTP. Se ele não estiver presente, você vai receber o valor especificado no atributo charset do elemento <meta> (por exemplo, <meta charset="utf-8">). Por fim, se nenhum deles estiver disponível, document.characterSet será a configuração do sistema do usuário.
O Gecko nunca ofereceu suporte a essa propriedade, e ela não é especificada de forma clara. Por isso, ela será descontinuada no Blink no Chrome 49 (Beta em janeiro de 2016). O aviso a seguir vai aparecer no console até a remoção da propriedade no Chrome 50:
Para mais informações sobre o motivo de não especificar isso, acesse o GitHub https://github.com/whatwg/dom/issues/58
getStorageUpdates() removido
TL;DR: Navigator.getStorageUpdates() foi removido porque não está mais na
especificação do navegador.
Intenção de remoção Rastreador do Chromestatus Problema do CRBug
Se isso afetar alguém, eu como meu chapéu. getStorageUpdates() quase nunca foi usado na Web.
Para citar a versão (muito antiga) da especificação HTML5:
Parece bem legal, não é? A especificação até usa a palavra "whence" (que, por acaso, é a única instância de "whence" na especificação). No nível da especificação, havia um StorageMutex que controlava o acesso ao armazenamento de bloqueio, como localStorage e cookies. Essa API ajudaria a liberar esse mutex para que outros scripts não fossem bloqueados por esse StorageMutex. No entanto, ele nunca foi implementado, não é compatível com o IE ou o Gecko, e a implementação do WebKit (e, portanto, do Blink) não faz nada.
Ela foi removida das especificações há algum tempo e foi removida completamente do Blink. Há muito tempo, ela não faz nada, mesmo que seja chamada.
No caso improvável de você ter um código que chamou navigator.getStorageUpdates(),
será necessário verificar a presença da função antes de chamá-la.
Object.observe() foi descontinuado
TL;DR: Object.observe() foi descontinuado porque não está mais na faixa de padronização
e será removido em uma versão futura.
Intenção de remoção Rastreador do Chromestatus Problema do CRBug
Em novembro de 2015, foi anunciado que Object.Observe estava sendo retirado do TC39. Ele foi
descontinuado no Chrome 49, e o seguinte aviso vai aparecer no console
se você tentar usá-lo:
Muitos desenvolvedores gostaram dessa API. Se você já fez testes com ela e agora está procurando um caminho de transição, considere usar um polyfill como MaxArt2501/object-observe ou uma biblioteca de wrapper como polymer/observe-js.