otra - etiquetas html5 ejemplos
¿Es necesario que los símbolos comerciales aún estén codificados en URL en HTML5? (1)
Aprendí recientemente (de these questions ) que en algún momento era recomendable codificar ampersands en los parámetros href . Es decir, en lugar de escribir:
<a href="somepage.html?x=1&y=2">...</a>
Uno debe escribir:
<a href="somepage.html?x=1&y=2">...</a>
Aparentemente, el ejemplo anterior no debería funcionar, pero la recuperación de errores del navegador significa que sí funciona.
¿Sigue siendo este el caso en HTML5?
Ya pasamos la era de los requisitos draconianos de XHTML. ¿Era este un requisito del manejo estricto de XHTML, o es realmente algo que debería tener en cuenta como desarrollador web?
Es cierto que una de las diferencias entre HTML5 y HTML4, citada en la página de diferencias del W3C , es:
El símbolo comercial (&) se puede dejar sin escapar en más casos en comparación con HTML4.
De hecho, la especificación de HTML5 hace un gran esfuerzo para describir los algoritmos reales que determinan lo que significa consumir (e interpretar) los caracteres.
En particular, en la sección sobre tokenización de referencias de caracteres del Capítulo 8 en la especificación de HTML5, vemos que cuando estás dentro de un atributo, y ves un carácter "y" comercial seguido de:
- una pestaña, LF, FF, espacio,
<,&, EOF, o el carácter adicional permitido (a"o''si el valor del atributo está entre comillas o si no) ===> entonces el signo y es solo un signo, no preocupaciones; - un signo de número ===> luego el tokenizer HTML5 pasará por los muchos pasos para determinar si tiene una referencia de entidad de carácter numérico o no, pero tenga en cuenta que en este caso uno está sujeto a errores de análisis (lea la especificación)
- cualquier otro carácter ===> el analizador intentará encontrar una referencia de carácter nombrada, por ejemplo, algo como
∉.
El último caso es el que le interesa, ya que su ejemplo tiene:
<a href="somepage.html?x=1&y=2">...</a>
Tienes la secuencia de caracteres
- AMPERSAND
- LATINA PEQUEÑA LETRA Y
- SIGNO IGUAL
Ahora aquí está la parte de la especificación HTML5 que es relevante en su caso, porque y no es una referencia de entidad con nombre:
Si no se puede hacer una coincidencia, no se consumen caracteres y no se devuelve nada. En este caso, si los caracteres después del carácter AMPERSAND U + 0026 (&) consisten en una secuencia de uno o más caracteres ASCII alfanuméricos seguidos de un carácter SEMICOLON U + 003B (;), esto es un error de análisis.
No tiene un punto y coma allí, por lo que no tiene un error de análisis.
Ahora supongamos que tuviste, en cambio,
<a href="somepage.html?x=1é=2">...</a>
que es diferente porque é es una referencia de entidad nombrada en HTML. En este caso, la siguiente regla entra en juego:
Si la referencia de caracteres se consume como parte de un atributo, y el último carácter coincidente no es un ";" (U + 003B), y el siguiente es un carácter "=" (U + 003D) o un carácter ASCII alfanumérico, luego, por razones históricas, todos los caracteres que coincidieron después del carácter U + 0026 AMPERSAND (& ) debe ser sin consumir, y no se devuelve nada. Sin embargo, si este siguiente carácter es en realidad un carácter "=" (U + 003D), entonces este es un error de análisis, ya que algunos agentes de usuario heredados interpretarán mal el marcado en esos casos.
Entonces, el = hace que sea un error, porque los navegadores heredados pueden confundirse.
A pesar del hecho de que la especificación de HTML5 parece ir muy lejos para decir "bueno, este signo no está comenzando una referencia de entidad de carácter, por lo que no hay ninguna referencia aquí", el hecho de que pueda encontrarse con URL que tienen referencias de nombre (por ejemplo, isin , part , sum , sub ) lo que daría como resultado errores de análisis, entonces en mi humilde opinión es mejor que esté con ellos. Pero, por supuesto, solo preguntas si las restricciones se relajaron en los atributos, no en lo que deberías hacer, y parece que sí lo fueron.
Sería interesante ver qué pueden hacer los validadores.