Por que o elemento `html` não aparece com 100% de suporte no caniuse.com

 (anderegg.ca)
2 pontos por GN⁺ 2024-02-03 | 1 comentários | Compartilhar no WhatsApp
  • O CanIUse.com é um site que acompanha a compatibilidade de tecnologias web, mas a taxa de suporte do elemento básico html aparece como 97,34%, o que levanta dúvidas sobre como interpretar esse número
  • Essa taxa de suporte parece estar ligada aos dados de compatibilidade da MDN usados pelo CanIUse.com, e alguns subitens da página do elemento html parecem influenciar o resultado
  • Os itens em questão são o atributo opcional manifest e secure context required, ambos itens que não foram padronizados ou já foram descontinuados
  • Como o tratamento de navegadores sem suporte, com suporte desconhecido e navegadores antigos acaba se misturando, até um elemento básico como html pode aparecer com uma taxa de suporte diferente do que a intuição sugeriria
  • No critério “% of all tracked”, somando também o suporte desconhecido, o número pode ser visto como 99,98%, o que aumenta a possibilidade de erro de arredondamento, mas ainda assim os números do CanIUse.com precisam ser lidos com mais cuidado

A dúvida levantada pelos 97,34% de suporte do html

  • O CanIUse.com acompanha a adoção de navegadores e a compatibilidade de recursos web, mostrando em números o quanto um recurso pode de fato ser usado
  • A taxa de suporte do elemento html aparece como 97,34%
    • Esse número é menor que o do elemento audio
    • Os elementos a e p também aparecem com a mesma taxa de suporte de 97,34%
  • Como se trata de elementos fundamentais da web usados há muito tempo, o fato de não aparecerem com 100% exige uma verificação além de um simples número de compatibilidade

Subitens visíveis na tabela de compatibilidade da MDN

  • Muitos dos dados do CanIUse.com parecem vir da MDN
  • A página do elemento html na MDN tem uma seção de compatibilidade com navegadores
  • Nessa tabela, há dois itens com muitos X vermelhos
  • É verdade que quase todos os navegadores não suportam esses dois itens, mas isso por si só não explica claramente por que a taxa de suporte total do elemento html cairia para 97,34%

Navegadores antigos e possível erro de arredondamento

  • Alguns navegadores aparecem como Support Unknown, e a soma do uso atual deles é de 1,27%
  • O Android Browser 2.1–4.3 aparece como sem suporte ao elemento html, mas sua participação de uso é de 0%
    • É duvidoso que esses navegadores antigos realmente não suportassem o elemento html
    • Também não está claro se um erro de arredondamento poderia inflar 1,27% até 2,66%
  • No canto superior direito do CanIUse.com, ao mudar o critério ao lado de “usage” para “% of all tracked” e somar os navegadores com “support unknown”, o total chega a 99,98%
    • Nesse critério, fica mais fácil ver como o número atual poderia surgir por erro de arredondamento
    • Ainda assim, a forma como navegadores antigos são tratados para um elemento básico como html continua confusa
  • O CanIUse.com continua sendo um recurso útil, mas as taxas de suporte exibidas precisam ser lidas junto com o contexto e o critério de cálculo

Leituras relacionadas

1 comentários

 
GN⁺ 2024-02-03
Opiniões no Hacker News

  • No CanIUse, há a opção "% of all" logo acima da porcentagem Global. Ao abrir a engrenagem na página do recurso, aparece com mais detalhes como o uso é calculado. O padrão é All Users, que considera como sem suporte todo o uso de navegadores que o caniuse não rastreia; se mudar para All tracked users, ele calcula apenas os navegadores rastreados e chega a 98,71%. A soma dos navegadores cujo suporte aparece como Unknown no gráfico é 1,27%; somando 1,27% a 98,71%, dá 99,97999…, então parece haver efeito de arredondamento. O problema real é que esses navegadores aparecem como Unknown e, na prática, acho que dá para considerar que eles dão suporte ao elemento ``.

    • Olhando as strings de User-Agent “não identificadas como algo específico” que aparecem nos logs de requisições do nosso SaaS de API, parece bem provável que uma boa parte desses 1,27% de “navegadores” seja formada por vários scrapers de propósito especial que acabaram entrando por acaso fora de sua área de especialidade. Então não dá para presumir que eles necessariamente saibam fazer parsing de ``. Talvez sejam scrapers de JSON.
    • Uso bastante wget, e, se ele estiver incluído, a conversa muda. Conferi src/html-url.c e, na prática, ele não dá suporte algum a ``; trata como tag desconhecida.

  • Fiquei encucado com o fato de MDN antes ser a sigla de Mozilla Developer Network e agora ser apenas MDN, então fui procurar, mas eu também não consegui encontrar o nome completo.

    • Essa mudança foi feita por volta de 2017. O nome Mozilla Developer Network era um tanto ambíguo, e também havia confusão em pesquisas e entrevistas com usuários. Desenvolvedores web achavam que era material exclusivo para desenvolvedores Mozilla, e, no começo, de fato tinha bastante esse caráter, então não estava completamente errado. Por um tempo, além da documentação da plataforma web, a MDN tinha muita documentação relacionada à Mozilla, mas, em 2017, a documentação da plataforma web já respondia por 95% do tráfego da MDN, e recursos para desenvolvedores Mozilla já não eram mais sua identidade principal. Por isso o nome foi mudado para MDN Web Docs, para deixar clara a mudança de foco.
    • Essa mudança aconteceu por volta de 15 de agosto de 2017. Sei disso porque por acaso vi o momento em que a marca tinha mudado, mas o conteúdo da página ainda não. O relatório de bug que enviei na época está aqui: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Gosto de chamar esse tipo de coisa de anachronym. É como uma sigla anacrônica. Tecnicamente, neste caso é mais um inicialismo do que um acrônimo, mas também escrevi um texto relacionado: https://simpsonian.ca/blog/anachronyms/
    • Ainda restam algumas ocorrências em páginas secundárias e códigos de exemplo, mas foi só isso que encontrei: “will soon be a proud part of the Mozilla Developer Network (MDN)” — https://developer.mozilla.org/en-US/blog/mdn-observatory/ “Their brilliant but offbeat idea grew into today's Mozilla Developer Network” — https://developer.mozilla.org/en-US/docs/MDN/At_ten const heading = Mozilla Developer Network; — https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
    • Lembro que, alguns anos atrás, a documentação da Microsoft começou a apontar para a documentação da Mozilla. Talvez isso tenha feito parte do rebranding do Edge. Se, durante esse processo de acordo, eles mudaram o nome para MDN, talvez fosse para evitar confusões do tipo “isso é M(ozilla)DN ou M(icrosoft)DN?”, mas não sei ao certo.

  • Curiosamente, ouvi dizer que os elementos e também mostram exatamente a mesma taxa de suporte de 97,34%. Esses dois elementos também usam dados vindos da MDN, assim como o elemento ``: https://caniuse.com/mdn-html_elements_a e https://caniuse.com/mdn-html_elements_p Atualizei o texto para refletir isso.

  • Acho que seria bom o CanIUse separar html-manifest como um recurso à parte. E também quero reforçar que a MDN é uma fonte realmente excelente.

  • A primeira página da web não usa o elemento html. http://info.cern.ch/hypertext/WWW/TheProject.html

  • Isso tem relação com HTML mínimo válido? Nele não há tag HTML.

    • Não parece ter muita relação. `` também aparece com quase a mesma porcentagem: https://caniuse.com/mdn-html_elements_title Parece mais uma questão de como contabilizar navegadores cujo uso é conhecido, mas cujo suporte não foi verificado. Além disso, esse HTML na verdade não é válido e é tratado como tendo um título vazio, e título vazio não é válido. Se trocar por algo como ., deve passar sem erros.
    • Mesmo assim, não há uma tag ali? Ela só não está explícita, então é inferida. Em qualquer navegador em que você abra, essa página terá uma tag.
    • Dentro de um protocolo que consegue transmitir o título por outro meio, como o cabeçalho Subject de um e-mail, é opcional. Por isso, o HTML válido mais curto é apenas; só que ele é válido apenas em um contexto específico.

  • A frase “muitos dados do site vêm da MDN” é um pouco ambígua. A matriz de suporte a recursos vinculada ao CanIUse vem do repositório browser-compat-data da MDN. Os dados originais dos elementos HTML estão aqui: https://github.com/mdn/browser-compat-data/blob/main/html/el... Só que ali não há os testes e as informações de uso que o CanIUse cita para calcular a taxa de suporte; há apenas quais versões de quais navegadores incluíram quais recursos. O CanIUse também aponta para seu próprio repositório, que tem muitos dados: https://github.com/fyrd/caniuse Mas não encontrei um ponto de entrada que permita descobrir facilmente de onde vêm os números de um elemento específico. Os dados lá também parecem ser principalmente por recurso. A pergunta mais precisa é de onde o CanIUse obtém os testes de elementos HTML e os números de uso, e esse parece ser o ponto central.

  • A taxa de suporte do elemento `` não deveria ser, no mínimo, menor ou igual à de qualquer outro elemento?

    • Não. O elemento não significa “HTML inteiro”; é apenas mais um elemento, que representa o **elemento raiz do documento**. Como outra pessoa escreveu, ele nem é realmente necessário para criar um documento HTML válido sem erros; o necessário nesse caso é e um corpo válido. Fazendo uma analogia, a capacidade de entender e analisar corretamente a palavra “English” no título de uma redação é independente de conhecer o significado da palavra inglesa “fustigate”.

  • “Portanto, não há uma resposta clara. Se você souber, me conte!”