VENTICINQUE, MAURO

Quise poner las notas al margen de este sitio con CSS anchor positioning, que es la propiedad con mayor crecimiento de uso interanual y la respuesta obvia: anclás la nota a su párrafo y listo.

No funciona, por tres razones que se acumulan.

Una nota anclada tiene que estar absolutamente posicionada. Las cajas absolutas no son items de flex ni de grid, así que reading-flow —que es la propiedad nueva para ordenar el recorrido de teclado y de lector de pantalla— no las puede reordenar. La promesa de accesibilidad se cae sola.

Anchor positioning no resuelve colisiones entre hermanos. Dos marcadores separados por tres líneas producen dos bloques absolutos superpuestos, y no hay arreglo en CSS: hay que medir con JavaScript.

Y todavía no es baseline, así que hace falta un segundo layout completo bajo @supports.

La alternativa es más vieja y mejor: declarar una pista para la marginalia en la grilla del documento y poner cada nota en flujo en esa pista, en la misma fila que su párrafo, con subgrid. La fila crece si la nota es más alta, así que nunca se superponen. El orden del DOM ya es el orden de lectura, sin un solo tabindex. Imprime bien. Y funciona en todos los navegadores sin fallback.

La propiedad más nueva no era la correcta. Sirve para lo que fue diseñada —tooltips y popovers anclados a un disparador— y no para una columna de notas.

Este sitio publica cada cifra con su método al lado. Y publicó 5.7 donde debía decir 5.700, en la ficha de un proyecto y en /llms.txt, durante un día.

La causa es de una capa más abajo de donde miré. En el frontmatter escribí:

metricas:
  - label: Líneas
    valor: 5.700

En YAML eso no es el texto «5.700»: es el número de punto flotante 5.7. El punto es el separador decimal, no el de miles. Mi schema tenía z.coerce.string() en ese campo —lo había puesto para que valor: 391 no obligara a acordarse de las comillas— y String(5.7) devuelve "5.7" sin protestar. Validación que pasa, dato corrupto.

Lo que hace este error difícil de ver es que la portada mostraba 5.700 correctamente, porque ahí la cifra sale de perfil.ts, donde está escrita como 5700. Sólo el archivo y la ficha, que leen el frontmatter, mostraban el valor roto. Dos caminos hacia el mismo número, uno sano y uno enfermo.

El arreglo no fue poner comillas

Poner comillas arregla ese archivo. El campo seguía aceptando cualquier float en silencio.

Ahora el schema acepta texto o un entero, y rechaza todo otro número con el mensaje que explica qué pasó:

valor: 5.7 se parsea como el número 5,7, no como texto.
Si querías un separador de miles, escribilo entre comillas: valor: "5.700"
— o sin separador: valor: 5700.

valor: 391 sigue funcionando, porque un entero no tiene separador que perder. Un no-entero en un campo de métrica en español casi siempre significa que alguien escribió un punto de miles.

La lección no es sobre YAML. Es que coerce es una instrucción para dejar de validar, y yo la usé justo en el campo cuya corrección es la premisa del sitio.