Por qué el elemento html no aparece con 100% de soporte en caniuse.com

 (anderegg.ca)
2 puntos por GN⁺ 2024-02-03 | 1 comentarios | Compartir por WhatsApp
  • CanIUse.com es un sitio que rastrea la compatibilidad de tecnologías web, pero el elemento básico html aparece con un soporte de 97.34%, lo que plantea dudas sobre cómo interpretar esa cifra
  • Ese porcentaje de soporte está vinculado con los datos de compatibilidad de MDN que usa CanIUse.com, y parece estar influido por algunos subelementos de la página del elemento html
  • Los elementos problemáticos son el atributo opcional manifest y secure context required; ambos no están estandarizados o están obsoletos
  • Al mezclarse navegadores sin soporte, navegadores con soporte desconocido y el tratamiento de navegadores antiguos, incluso elementos básicos como html muestran porcentajes de soporte poco intuitivos
  • Según el criterio “% of all tracked”, al sumar los casos de soporte desconocido se obtiene 99.98%, por lo que aumenta la posibilidad de un error de redondeo; aun así, las cifras de CanIUse.com deben leerse con más cuidado

La duda que generó el 97.34% de soporte de html

  • CanIUse.com rastrea la adopción por navegador y la compatibilidad de funciones de tecnologías web, y muestra con cifras qué tan usable es una función en la práctica
  • El soporte del elemento html aparece como 97.34%
    • Es una cifra menor que la del elemento audio
    • Los elementos a y p también aparecen con el mismo soporte de 97.34%
  • Que un elemento básico de la Web usado desde hace mucho tiempo no esté en 100% hace necesario revisar algo más que una cifra simple de compatibilidad

Subelementos visibles en la tabla de compatibilidad de MDN

  • Muchos de los datos de CanIUse.com parecen provenir de MDN
  • La página del elemento html de MDN tiene una sección de compatibilidad de navegadores
  • En esa tabla, los elementos con muchas X rojas son dos
    • El atributo opcional manifest
      • Está obsoleto
      • Nunca fue estandarizado
    • El elemento relacionado secure context required
  • Es cierto que casi todos los navegadores no soportan estos dos elementos, pero eso por sí solo no aclara por qué el soporte total del elemento html baja hasta 97.34%

Navegadores antiguos y posible error de redondeo

  • Algunos navegadores aparecen como Support Unknown, y la suma de uso actual de esos navegadores es 1.27%
  • Android Browser 2.1–4.3 aparece como si no soportara el elemento html, pero su cuota de uso es 0%
    • Resulta dudoso que esos navegadores antiguos realmente no hayan soportado el elemento html
    • Tampoco queda claro si un error de redondeo podría hacer crecer ese 1.27% hasta 2.66%
  • En la esquina superior derecha de CanIUse.com, si se cambia el criterio junto a “usage” a “% of all tracked” y se suman las cifras de navegadores con “support unknown”, se obtiene 99.98%
    • Con este criterio, es más fácil ver la posibilidad de que la cifra actual se deba a un error de redondeo
    • Aun así, la forma de tratar navegadores antiguos en elementos básicos como html sigue siendo confusa
  • CanIUse.com sigue siendo un recurso útil, pero los porcentajes de soporte que muestra deben revisarse junto con el contexto y el criterio de cálculo

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-02-03
Opiniones de Hacker News

  • CanIUse tiene una opción “% of all” justo arriba del porcentaje Global. Si abres el engrane en la página de la funcionalidad, aparece con más detalle cómo se calcula el uso. El valor predeterminado es All Users, que considera como no soportado todo el uso de navegadores que caniuse no rastrea; si lo cambias a All tracked users, calcula solo los navegadores rastreados y da 98.71%. En la gráfica, los navegadores cuyo soporte aparece como Unknown suman 1.27%; si sumas 1.27% a 98.71%, da 99.97999…, así que parece haber un efecto de redondeo. El verdadero problema es que esos navegadores aparecen como Unknown, y en la práctica parece razonable asumir que soportan el elemento ``.

    • Al ver las cadenas User-Agent “no identificadas como nada en particular” que aparecen en los logs de solicitudes de nuestro SaaS de API, parece muy probable que una buena parte de ese 1.27% de “navegadores” sean distintos scrapers de propósito especial que llegaron por casualidad fuera de su área de especialidad. Así que no necesariamente se puede asumir que sepan parsear ``. Podrían ser scrapers de JSON.
    • Uso mucho wget, y si se incluye, la historia cambia. Revisé src/html-url.c y en realidad no soporta `` en absoluto: lo trata como una etiqueta desconocida.

  • Me quedé pensando en que MDN antes era la sigla de Mozilla Developer Network y ahora simplemente es MDN, así que lo busqué, pero tampoco pude encontrar el nombre completo.

    • Ese cambio se hizo alrededor de 2017. El nombre Mozilla Developer Network era algo ambiguo, y también generaba confusión en encuestas y entrevistas con usuarios. Los desarrolladores web pensaban que era material exclusivo para desarrolladores de Mozilla, y al inicio efectivamente tenía mucho de eso, así que tampoco estaban del todo equivocados. Durante un tiempo, MDN tenía mucha documentación relacionada con Mozilla además de la documentación de la plataforma web, pero para 2017 la documentación de la plataforma web ya representaba el 95% del tráfico de MDN, y el material para desarrolladores de Mozilla ya no era su identidad principal. Por eso se cambió el nombre a MDN Web Docs, para reflejar ese cambio de enfoque.
    • Ese cambio ocurrió alrededor del 15 de agosto de 2017. Lo sé porque por casualidad vi el momento en que el branding ya había cambiado, pero el contenido de la página todavía no. Aquí está el reporte de bug que abrí entonces: https://bugzilla.mozilla.org/show_bug.cgi?id=1390381
    • Me gusta llamar a estas cosas anachronym, porque se siente como una sigla anacrónica. Estrictamente hablando, esto es más bien un inicialismo que un acrónimo, pero también escribí un artículo relacionado. https://simpsonian.ca/blog/anachronyms/
    • Todavía queda en algunos lugares de páginas laterales y código de ejemplo, pero esto es más o menos lo que encontré: “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...
    • Recuerdo que hace algunos años la documentación de Microsoft empezó a apuntar a la documentación de Mozilla. Tal vez fue parte del rebranding de Edge. Si durante ese acuerdo se cambió el nombre a MDN, quizá fue para evitar confusiones tipo “¿esto es M(ozilla)DN o M(icrosoft)DN?”, aunque no lo sé con certeza.

  • Curiosamente, escuché que los elementos y también muestran exactamente el mismo 97.34% de soporte. Estos dos elementos también usan datos provenientes de MDN, igual que el elemento ``: https://caniuse.com/mdn-html_elements_a y https://caniuse.com/mdn-html_elements_p Actualicé el artículo para reflejar esto.

  • Creo que en CanIUse estaría bien separar html-manifest como una funcionalidad aparte. Y también quiero reiterar que MDN es un recurso realmente excelente.

  • La primera página web no usa el elemento html. http://info.cern.ch/hypertext/WWW/TheProject.html

  • ¿Esto tiene que ver con el HTML mínimo válido? Ahí no hay etiqueta HTML.

    • No parece estar muy relacionado. `` también aparece con casi el mismo porcentaje: https://caniuse.com/mdn-html_elements_title Más bien parece un problema de cómo calcular los navegadores de los que se conoce el uso, pero cuyo soporte no se pudo verificar. Además, ese HTML en realidad no es válido y se trata como un título vacío, y un título vacío no es válido. Si se cambiara por algo como ., debería pasar sin errores.
    • Pero ¿no hay una etiqueta ahí? Solo que no está escrita explícitamente, así que se infiere. Si abres esa página en cualquier navegador, tendrá una etiqueta.
    • Dentro de protocolos que pueden transmitir el título de otra forma, como el encabezado Subject de un correo, es opcional. Por eso el HTML válido más corto es simplemente y nada más, aunque solo es válido en un contexto específico.

  • La frase “muchos de los datos del sitio vienen de MDN” es un poco ambigua. La matriz de soporte de funcionalidades enlazada en CanIUse viene del repositorio browser-compat-data de MDN. Los datos originales de los elementos HTML están aquí: https://github.com/mdn/browser-compat-data/blob/main/html/el... Pero ahí no están las pruebas ni la información de uso que CanIUse cita para calcular el porcentaje de soporte; solo indica qué versiones de qué navegadores incluyeron qué funcionalidades. CanIUse también apunta a su propio repositorio, que contiene muchos datos: https://github.com/fyrd/caniuse Pero no pude encontrar un punto de entrada que permita ver fácilmente de dónde salen las cifras de un elemento específico. Esos datos también parecen estar organizados principalmente por funcionalidad. La pregunta más precisa es de dónde obtiene CanIUse las pruebas de elementos HTML y las cifras de uso, y eso parece ser el problema central.

  • ¿No debería el porcentaje de soporte del elemento `` ser al menos menor o igual que el de cualquier otro elemento?

    • No. El elemento no significa “todo HTML”; es simplemente otro elemento que representa el **elemento raíz del documento**. Como escribió otra persona, ni siquiera es realmente obligatorio para crear un documento HTML válido y sin errores; lo que se necesita en ese caso es y un cuerpo válido. Como analogía, la capacidad de entender y parsear correctamente la palabra “English” en el título de un ensayo es independiente de saber qué significa la palabra inglesa “fustigate”.

  • “Así que no hay una respuesta clara. Si alguien la sabe, ¡que la cuente!”