www3 w3school tutorial form coding code html xml xhtml coding-style

html - w3school - Espacio antes de cerrar Slash?



text box html (9)

¿Siguen siendo relevantes esos problemas o aún estamos agregando espacios adicionales por el solo hecho de, digamos, la compatibilidad con IE3?

Estuviste cerca, es para Netscape 4.

Es interesante ver otras racionalizaciones, pero para eso está destinado.

Con frecuencia he visto un espacio antes de la barra de cierre en las etiquetas XML y HTML. El salto de línea XHTML es probablemente el ejemplo canónico:

<br />

en lugar de:

<br/>

El espacio parece superfluo. De hecho, creo que es superfluo.

¿Cuál es el motivo para escribir este espacio?

He leído que el espacio resuelve algunos "problemas de compatibilidad con versiones anteriores". ¿Qué problemas de compatibilidad con versiones anteriores? ¿Siguen siendo relevantes esos problemas o seguimos agregando espacios adicionales para, digamos, la compatibilidad con IE3? ¿Existe alguna especificación con la respuesta definitiva sobre esto?

Si no es compatible con versiones anteriores, ¿se trata de un problema de legibilidad? ¿Similar al debate sobre el Gran Abrazo Curly Abierto?

void it_goes_up_here() { int no_you_fool_it_goes_down_there() {

Ciertamente puedo respetar diferentes opiniones estilísticas, así que estaré encantado de saber que escribir el espacio es simplemente una cuestión de gusto.

¿Qué pasa si hay un escritor html muy vago por ahí o tal vez tenía miedo a las comillas? Considera lo siguiente si fueras su rastreador de páginas robot ...

<img src=http://myunquotedurl.com/image.jpg />

versus

<img src=http://myunquotedurl.com/image.jpg/>

Esto puede parecer pequeño, pero mira lo que puede hacer si el espacio no está allí. El robot no sabrá si la barra es parte de la url o parte de la etiqueta de cierre.

Creo que el espacio en blanco es una forma de reforzar la idea de que esta etiqueta está vacía y se cierra sola.

Hoy ya no uso el espacio en blanco porque nunca tuve un problema sin espacio en blanco.

El espacio solo hace que las etiquetas sean más legibles. Soy un gran defensor del formato para un código más legible. Pequeñas cosas como esa van un largo camino. Sin el espacio, la etiqueta de cierre se mezcla con la etiqueta de apertura. Solo necesito un instante más para procesarlo ya que estoy leyendo rápidamente el código.

En XHTML, las etiquetas br deben estar cerradas, pero el espacio no es necesario . Es una cosa estilística. En HTML, las etiquetas br no se pueden cerrar, por lo que ambas son incorrectas.

La respuesta es que las personas desean adherirse al Apéndice C de la especificación XHTML1.0 . Lo cual solo necesita hacer si está sirviendo XHTML como texto / html . Lo que hace la mayoría de las personas, porque el tipo MIME real de XHTML (application / html + xml) no funciona en Internet Explorer.

Ningún navegador actual se preocupa por el espacio. Los navegadores son muy tolerantes con estas cosas.

El espacio solía ser necesario para garantizar que los analizadores HTML trataran la barra inclinada final como un atributo no reconocido.

No, el espacio no es obligatorio, pero es necesario que algunos navegadores antiguos muestren esas etiquetas correctamente. La forma correcta de hacerlo es sin espacio adicional, ya que es algo que XHTML heredó de XML.

Para mí, depende de lo que haga Visual Studio con mi HTML / XML :-) No es consistente, pero no importa desde una vista funcional (es solo cuestión de estilo).

Compatible con la respuesta de Bobince con una captura de pantalla de Netscape 4.80 mostrando documentos

data:text/html,<title>space</title>foo<br />bar

(arriba a la izquierda, linebreak renderizado) y

data:text/html,<title>no space</title>foo<br/>bar

(abajo a la izquierda, linebreak ignorado).

Publicar como respuesta para mostrar la imagen

Tangencialmente relacionado: de hecho, tuve una larga respuesta para identificar la causa de la mala conducta de navegadores antiguos (y la recomendación resultante de incluir espacio) en especificaciones SGML incomprendidas, a saber SGML Etiqueta nulo final ( NET ) (donde 1<tag/2/3 2/3 es igual 1<tag>2</tag>3 por lo que 1<tag/>2 significaría en realidad 1<tag>>2 ), pero no solo no pude encontrar una buena prueba y una versión concreta del estándar, ni siquiera pude para comprender el comportamiento adecuado de cumplimiento de normas. Muy pocos enlaces crudos para referencia:

(No se puede reproducir allí ahora, pero admite la declaración de Lee Kowalkowski sobre varios navegadores afectados por esto).