Por que você deve se preocupar com o suporte a navegadores mais antigos

Zell Liew Blocked Unblock Seguir Seguindo 11 de janeiro Navegadores internet web design por isromar na pixabay.

Suportando navegadores mais antigos

Você não precisa se preocupar muito com o suporte a navegadores mais antigos hoje. Eles são decentes desde que o Internet Explorer 8 morreu.

Mas a questão permanece: como você deve apoiar o Internet Explorer 9 e outros navegadores? Em primeiro lugar, você deveria estar pensando em dar suporte ao Internet Explorer 9?

Vamos ver algumas coisas que você gostaria de considerar.

Pense em recursos, não em navegadores

Digamos que o mundo contenha apenas dois recursos e dois navegadores.

  1. O navegador A suporta o recurso A, mas não o recurso B.
  2. O navegador B suporta o recurso B, mas não o recurso A.

É possível detectar quais navegadores suportam quais recursos e agir a partir daí.

 // Este é JavaScript 
 if (Navegador A) { 
// Código para A
}
 if (Navegador B) { 
// código para B
}

Mas e se houver mais navegadores? E se o mundo contiver os navegadores C, D e E? É difícil suportar os recursos de que você precisa se estiver pensando em navegadores.

Existe uma maneira melhor: você pode verificar se existe um recurso. Se existir, use-o. Caso contrário, forneça o código de fallback.

O seguinte bloco de código funciona do navegador A para o navegador Z.

 // Este é JavaScript 
 if (feature A) { 
// Código se o navegador contiver o recurso A
} outro {
// Código se o navegador não contiver o recurso A
}

E agora você não precisa se preocupar com navegadores.

Decidindo se usar um recurso

Muitas pessoas decidem se usam um recurso dependendo do número de navegadores que o suportam. Mas, como argumentei acima, os navegadores não importam.

O que importa é: você pode codificar o fallback para o recurso facilmente? Se você pode codificar o fallback facilmente, vá em frente e use o recurso. Se você não pode codificar o fallback facilmente, não use o recurso.

Decidindo quais navegadores suportam

Você ainda precisa de um corte.

Quais navegadores você vai suportar?

Quais navegadores você NÃO vai suportar? Se você não quiser dar suporte ao navegador, não faz sentido escrever código reserva para ele.

Minha melhor resposta é: veja quem está usando seu site. Quais navegadores eles usam? Siga de acordo.

Sim, pode haver outliers que tentam visitar seu website no Internet Explorer 6. Mas há tempo e energia para escrever código extra para um navegador que quase ninguém usa?

Sua energia será melhor aproveitada em outro lugar?

O nível de suporte

Eu diria que existem quatro níveis de suporte:

  1. tudo deve parecer e funcionar da mesma forma em todos os navegadores
  2. o site deve ser o mesmo, mas a funcionalidade pode ser diferente nos navegadores
  3. a funcionalidade deve ser a mesma, mas a aparência pode ser diferente entre os navegadores
  4. aparência e funcionalidade podem diferir entre os navegadores

Que tipo de suporte você está fornecendo para os navegadores mais antigos? Por quê?

Empacotando

Pense nisso:

  1. Por que você está tentando suportar o navegador antigo que você está tentando suportar?
  2. que nível de apoio você está dando?
  3. vale a pena os recursos que você alocou?

Suportando navegadores mais antigos – CSS

Há duas maneiras de fornecer fallbacks para recursos CSS:

  1. fallbacks de propriedade
  2. consultas de recursos

Fallbacks de propriedade

Se um navegador não reconhecer uma propriedade ou seu valor correspondente, o navegador ignorará completamente a propriedade.

Quando isso acontece, o navegador usa – ou retrocede – ao valor anterior encontrado.

Essa é a maneira mais fácil de fornecer um fallback.

Aqui está um exemplo:

 .layout { 
display: bloco;
display: grade;
}

Neste exemplo, os navegadores que suportam CSS Grid usarão display: grid . Um navegador que não suporta CSS Grid irá retroceder para display: block .

Omitir valores padrão

Se o elemento que você está usando usar como padrão display: block , você pode omitir a display: block declaração de display: block . Isso significa que você pode suportar CSS Grid com uma linha de código:

 .layout { 
display: grade;
}

Os navegadores que suportam CSS Grid poderão ler outras propriedades CSS, como grid-template-columns . Navegadores que não suportam CSS Grid não podem.

Isso significa que você pode escrever propriedades adicionais do CSS Grid sem se preocupar com valores de fallback.

 .layout { 
display: grade;
grid-template-columns: 1fr 1fr 1fr 1fr;
intervalo de grade: 1em;
}

Consultas de recursos, ou @supports , informam se uma propriedade CSS ou seu valor correspondente é suportado é suportado pelo navegador.

Você pode pensar em consultas de recurso CSS como instruções if/else em JavaScript. Eles se parecem com isso:

 @supports (property: value) { 
/ * Código quando propriedade ou valor é suportado * /
}
 @supports not (property: value) { 
/ * Código quando a propriedade ou valor não é suportado * /
}

@supports é útil se você quiser que os navegadores leiam CSS apenas se eles suportarem uma propriedade específica.

Para o exemplo CSS Grid que tivemos acima, você pode fazer isso:

 @supports (display: grid) { 
.layout {
display: grade;
grid-template-columns: 1fr 1fr 1fr 1fr;
intervalo de grade: 1em;
preenchimento esquerdo: 1em;
padding-right: 1em;
}
}

Neste exemplo, padding-left e padding-right serão lidos apenas por navegadores que suportam @supports e CSS Grid.

Jen Simmons tem um exemplo melhor de @supports no trabalho. Ela usa consultas de recursos para detectar se os navegadores suportam uma propriedade como -webkit-initial-letter .

 @supports (initial-letter: 4) ou (-webkit-initial-letter: 4) { 
p :: primeira letra {
-webkit-initial-letter: 4;
letra inicial: 4;
cor: # FE742F;
intensidade da fonte: Negrito;
margem-direita: 0,5em;
}
}

O exemplo de Jen nos leva a uma pergunta: os sites devem ter a mesma aparência nos navegadores? Nós vamos ver isso depois. Mas primeiro, mais sobre as consultas de recursos.

Suporte para consultas de recursos

Consultas de recursos ganharam grande suporte . Todos os principais navegadores atuais suportam consultas de recursos.

E se um recurso for suportado, mas as consultas de recursos não forem?

Isso costumava ser a parte complicada. Jen Simmons e outros especialistas nos alertaram sobre essa possibilidade. Você pode ler como lidar com isso neste artigo .

Aqui está minha opinião: eu não suporte mais o IE 11, então eu uso as consultas de recursos da maneira que mencionei acima.

Usando fallbacks de propriedades e consultas de recursos ao mesmo tempo

Observe o seguinte código. Quais valores de preenchimento os navegadores aplicam?

 @supports (display: grid) { 
.layout {
display: grade;
grid-template-columns: 1fr 1fr 1fr 1fr;
intervalo de grade: 1em;
preenchimento esquerdo: 1em;
padding-right: 1em;
}
}
 .layout { 
preenchimento esquerdo: 2em;
preenchimento-direita: 2em;
}

A resposta é: Todos os navegadores aplicarão 2 2em de preenchimento à esquerda e à direita.

Por quê?

Isso acontece porque padding-left: 2em e padding-right: 2em foram declarados posteriormente no arquivo CSS. As propriedades que foram declaradas posteriormente substituem as propriedades que foram declaradas anteriormente.

Se você quiser padding-left: 2em e padding-right: 2em para aplicar somente a navegadores que não suportam CSS Grid, você pode trocar a ordem de propriedade.

 .layout { 
preenchimento esquerdo: 2em;
preenchimento-direita: 2em;
}
 @supports (display: grid) { 
.layout {
display: grade;
grid-template-columns: 1fr 1fr 1fr 1fr;
intervalo de grade: 1em;
preenchimento esquerdo: 1em;
padding-right: 1em;
}
}

Nota : É sempre uma boa prática declarar o código de fallback primeiro no CSS devido à sua natureza em cascata.

Isso também significa que, se você estiver usando @supports e @supports not , você deve declarar @supports not primeiro. Isso torna seu código consistente.

 / * Sempre escreva " @suporte não" primeiro se você usá-lo * / 
@supports não (display: grid) {
.layout {
preenchimento esquerdo: 2em;
preenchimento-direita: 2em;
}
}
 @supports (display: grid) { 
.layout {
display: grade;
grid-template-columns: 1fr 1fr 1fr 1fr;
intervalo de grade: 1em;
preenchimento esquerdo: 1em;
padding-right: 1em;
}
}

Agora vamos falar sobre se os sites devem ter a mesma aparência nos navegadores.

Os sites devem ter a mesma aparência nos navegadores?

Algumas pessoas acreditam que os sites devem ter a mesma aparência nos navegadores. Eles acham que a marca é importante e enfatizam que os sites devem ser consistentes para preservar a marca.

Outras pessoas dizem que não. Eles acreditam que devem abraçar o espírito de aprimoramento progressivo. Eles podem dar aos usuários melhores navegadores mais amor.

Ambas as visões estão certas, mas elas vêm de diferentes ângulos.

O ponto de vista mais importante vem dos usuários. Seu site é capaz de fornecer aos usuários o que eles procuram?

Se sim, você não precisa ser muito rigoroso na consistência. Vá em frente e dê aos usuários melhores navegadores experiências ainda melhores!

Empacotando

Para fornecer suporte para recursos CSS, você pode usar:

  1. Fallbacks de propriedade
  2. Consultas de recursos

Quando você escreve CSS, certifique-se de declarar primeiro o código de fallback antes do outro conjunto de códigos para navegadores com melhor suporte.

Suportando navegadores mais antigos – JavaScript

É fácil fornecer suporte a JavaScript para navegadores mais antigos. Na maioria das vezes você só precisa usar um polyfill.

Mas há mais coisas que você pode fazer.

O que é um polyfill?

Um polyfill é um trecho de código que informa aos navegadores como implementar um recurso JavaScript. Depois de adicionar um polyfill, você não precisa mais se preocupar com suporte. Vai funcionar.

Veja como funciona um Polyfill:

  1. ele verifica se o recurso é suportado
  2. se não, adiciona código para suportar o recurso

Aqui está um exemplo de um polyfill no trabalho. Ele verifica se o navegador suporta Array.prototype.find . Se o navegador não suportar Array.prototype.find , ele informa ao navegador como suportá-lo.

Você pode encontrar este código no MDN .

 if (! Array.prototype.find) { 
Object.defineProperty (Array.prototype, 'find', {
valor: função (predicado) {
// 1. Deixe O ser? ToObject (este valor).
if (isto == null) {
throw new TypeError ('' this 'é nulo ou não definido');
}
 var o = Objeto (isto); 
 // 2. Seja len? ToLength (? Get (O, "comprimento")). 
var len = o.length >>> 0;
 // 3. Se IsCallable (predicado) for falso, lance uma exceção TypeError. 
if (tipo de predicado! == 'função') {
throw new TypeError ('predicado deve ser uma função');
}
 // 4. Se thisArg foi fornecido, seja T thisArg; mais deixe T ser indefinido. 
var thisArg = argumentos [1];
 // 5. Seja k como 0. 
var k = 0;
 // 6. Repetir, enquanto k <len 
while (k <len) {
// uma. Deixe Pk ser! ToString (k).
// b. Seja kValue? Obter (O, Pk).
// c. Seja testResult toBoolean (? Call (predicado, T, «kValue, k, O»)).
// d. Se testResult for true, retorne kValue.
var kValue = o [k];
if (predicate.call (thisArg, kValue, k, o)) {
return kValue;
}
// e. Aumente k por 1.
k ++;
}
 // 7. Retorna indefinido. 
retornar indefinido;
}
configurável: true
gravável: true
});
}

Nota : Um polyfill é um subconjunto de um shim. Um shim é uma biblioteca que traz uma nova API para um ambiente mais antigo.

Usando polyfills

Existem duas maneiras de usar polyfills:

  1. polyfill manualmente, como no exemplo acima
  2. adicionando muitos polyfills ao mesmo tempo através de uma biblioteca

Polyfilling manualmente

Primeiro, você precisa procurar pelo polyfill que você precisa. Você deve ser capaz de encontrar um se você pesquisar no Google. Desenvolvedores inteligentes criaram polyfills para quase tudo que você precisa.

Depois de encontrar o polyfill, use o processo acima para criar suporte a navegadores mais antigos.

Adicionando muitos polyfills de uma só vez

Algumas bibliotecas contêm muitos polyfills. ES6-shim é um exemplo de tal biblioteca. Ele fornece suporte para todos os recursos do ES6 em navegadores mais antigos.

Usando recursos JavaScript de ponta

Se você quiser usar recursos JavaScript de ponta, considere adicionar o Babel ao seu processo de criação.

O Babel é uma ferramenta que compila o JavaScript. Durante este processo de compilação, pode:

  1. adicione qualquer calço / polyfill que você precisa
  2. compilar pré-processadores em JavaScript

Mais sobre o segundo ponto:

Babel trabalha offline no seu processo de criação. Ele pode ler arquivos que você passa para ele e, em seguida, converter esses arquivos em JavaScript que o navegador pode ler.

O que isto significa é que você pode usar recursos de ponta como o Flow, o TypeScript e outras tecnologias interessantes de que você já ouviu falar. Todos eles funcionam em navegadores, desde que você os passe primeiro por Babel!

E se os polyfills não forem suficientes?

Se os polyfills não forem suficientes para suportar o recurso, convém reconsiderar a quantidade de suporte que você fornece para o navegador em questão.

Você precisa fornecer a mesma funcionalidade em diferentes navegadores? Talvez você deva considerar aprimoramento progressivo.

Talvez você possa codificar de uma forma que não use o recurso?

Muitos talvez, mas você começa a deriva.

Como saber se um navegador suporta o recurso?

Primeiro, eu verifico caniuse.com . Escreva o nome do recurso JavaScript desejado e você poderá ver os níveis de suporte do navegador.

Aqui está um exemplo com o Abort Controller

Se caniuse.com não me der nenhuma informação, eu verifico o MDN. Você encontrará suporte ao navegador na parte inferior da maioria dos artigos.

Aqui está o exemplo com Abort Controller novamente:

Cuidado com o custo do JavaScript

Quando você usa polyfills, adiciona mais código JavaScript.

O problema com a adição de mais JavaScript é, bem, há mais JavaScript. E com mais JavaScript vem mais problemas:

  1. navegadores mais antigos geralmente vivem em computadores mais antigos. Eles podem não ter poder de processamento suficiente.
  2. Pacotes JavaScript podem atrasar o carregamento do site. Mais sobre isso em " O custo do JavaScript " de Addy Osmani

Empacotando

É fácil adicionar suporte para recursos JavaScript. Na maioria das vezes, você adiciona um polyfill e o chama um dia. Mas esteja ciente do custo do JavaScript quando você faz isso!

Às vezes, pode ser bom abandonar completamente o recurso.

Por que apoiar navegadores mais antigos?

Por que você precisa se preocupar com navegadores antigos?

Quem usa navegadores antigos? Provavelmente, usuários com computadores antigos?

Se eles usam computadores antigos, talvez não tenham dinheiro para comprar um novo.

Se eles não tiverem dinheiro para comprar um novo computador, provavelmente não comprarão nada de você também.

Se eles não comprarem nada de você, por que você precisa se preocupar com o suporte a seus navegadores?

Para uma pessoa de negócios, esse é um trem perfeitamente razoável de pensamento. Mas por que nós, desenvolvedores, ainda insistimos em apoiar navegadores mais antigos?

Vamos dividi-lo

Há tantas camadas de suposições no processo original de pensamento.

“Quem usa navegadores antigos? Provavelmente, usuários com computadores antigos? Se eles usam computadores antigos, talvez não tenham dinheiro para comprar um novo ”.

Embora seja verdade que as pessoas usem navegadores antigos porque usam computadores antigos, não podemos presumir que as pessoas não podem comprar novas.

  • Talvez a empresa deles não queira comprar um.
  • Talvez eles estejam felizes com o seu computador e não querem atualizar.
  • Talvez eles não tenham conhecimento para atualizar seus computadores.
  • Talvez eles não tenham acesso a novos computadores.
  • Talvez eles estejam ligados a celulares que não tenham bons navegadores.

Não assuma.

Se eles não tiverem dinheiro para comprar um novo computador, provavelmente não comprarão nada de você também. Se eles não comprarem nada de você, por que você precisa se preocupar com o suporte a seus navegadores?

Temos que diminuir o zoom em outras áreas para falar sobre esse ponto.

Acessibilidade para cadeiras de rodas

Se você esteve em Cingapura, notará que há uma rampa ou um elevador ao lado de quase todas as escadas.

Mas por que? Por que o governo e empresas privadas gastam dinheiro em elevadores e rampas? Por que construí-los quando as escadas são suficientes para levar as pessoas de uma elevação mais baixa a uma mais alta?

Acontece que algumas pessoas não são capazes de usar escadas. Eles não podem andar com os pés. Eles têm que se sentar em cadeiras de rodas, e não podem subir uma escada. Os elevadores e rampas atendem a essas pessoas.

E acontece que mais pessoas se beneficiam de elevadores e rampas.

  1. Pessoas que têm joelhos mais fracos.
  2. Pessoas que têm uma bicicleta ou scooter com eles.
  3. Pais que estão empurrando um carrinho de bebê.

Se você estiver empurrando qualquer coisa com rodas, você usará a rampa ou o elevador sem pensar duas vezes. Você se beneficia também.

Mas o problema é: ninguém ganha um único centavo operando as rampas ou os elevadores? Então, por que construí-los?

Porque vale a pena.

E o valor nem sempre significa dinheiro.

Considere o aquecimento global

Você mora na terra. O que você acha do aquecimento global?

Algumas pessoas não se importam. Tudo bem se as florestas se queimarem. Tudo bem se as empresas poluem rios e liberam toneladas de dióxido de carbono no ar. Isso não os afeta.

Mas há um grupo de pessoas que se importam. Eles amam o planeta em que estamos vivendo. Eles querem dar a seus filhos um lugar melhor para viver. Há muitas razões pelas quais eles se importam. E eles provavelmente querem economizar tantos recursos quanto possível.

Aonde você fica?

Você daria dinheiro para uma empresa que destrói a terra enquanto opera?

Talvez você vá. Talvez você não vá. Talvez você não se importe. Todas as três opções são válidas.

E mais uma vez, você vê, nem sempre é sobre o dinheiro.

A web é para todos

O sonho por trás da Web é um espaço de informação comum no qual nos comunicamos através do compartilhamento de informações.

– Tim Berners-Lee

Nós desenvolvedores frontend são os guardiões da web. Como a teia é nossa. Não podemos obrigar todos a construir rampas e elevadores, mas podemos garantir que os construímos sozinhos.

A escolha é sua, realmente.

Você não precisa se importar se não quiser.

A maioria dos bons desenvolvedores frontend que eu conheço? Eles se importam. Eles escolhem ser inclusivos. É o que nos faz desenvolvedores frontend.

Nós nos importamos.

Mas às vezes também temos restrições e limites. E nós trabalhamos com esses limites.

Este artigo foi originalmente publicado em meu blog.
Inscreva-se no meu boletim informativo se quiser mais artigos para ajudá-lo a se tornar um melhor desenvolvedor de front-end.