¿Por qué tenemos que usar divs?

13

Esta mañana, mientras escribía algunos html y haml, se me ocurrió que la forma en que se usan los divs es ridícula. ¿Por qué no están implicados los divs? Imagina si esto:

<div class="hero-img">
   <img src="http://whatever.com/this.jpg">
</div>

era esto:

<hero-img>
   <img src="http://whatever.com/this.jpg">
</hero-img>

Si se supusiera la parte de "clase div" del elemento, el HTML sería más semántico e infinitamente más legible con las etiquetas de cierre coincidentes.

Esto es similar a HAML, donde tenemos:

.content Hello, World!

Que se convierte en:

<div class='content'>Hello, World!</div>

Me parece que lo único que tendría que suceder para que esto funcione en los navegadores es que los navegadores podrían comenzar a interpretar cada elemento sin una definición de elemento html existente que implique <div class="<element name>">.

Esto podría ser completamente compatible con versiones anteriores; para los selectores CSS y jQuery, etc., "div.hero-img" aún podría funcionar, y sería la sintaxis necesaria para seleccionar los elementos.

Sé sobre la nueva especificación de componentes web, pero eso es significativamente más complicado de lo que se sugiere aquí. ¿Te imaginas lo agradable que sería mirar la fuente de un sitio web y ver html que se parece a eso?

Entonces, ¿por qué tenemos que usar divs?

Si nos fijamos en la lista de elementos html5 de Mozilla , cada elemento tiene un significado semántico, y luego llegamos <div>y dice:

"Representa un contenedor genérico sin significado especial".

..y luego enumeran los elementos arbitrarios que están agregando a html5 como <details>.

Por supuesto, si este concepto de divs implícitos se agregara a la especificación html, tomaría diez años convertirse en estándar, que es un millón de años en el tiempo web.

Así que me imagino que debe haber una buena razón para que esto no haya sucedido todavía. ¡Por favor, explícamelo!

Jordan Davis
fuente
En realidad, hay dos contenedores no semánticos: div y span
Lie Ryan,

Respuestas:

7

Problema 1: espacios en blanco

Creo que esto no ha surgido en general. Aunque, una buena razón por la que esto no ha sucedido y probablemente no debería suceder es porque white-spacesen CSS classesdefinen varias clases para el elemento, mientras que en HTML definen attributes.

Explique (o solicite a un navegador que analice) el siguiente código:

<pet family style=" ... ">
  <img src="my-pets-family.jpg"/>
</pet family>

¿Es familyla definición de una segunda clase o un atributo del elemento HTML? Como probablemente vea en el analizador de este sitio, cree que es un atributo.

Entonces, si quiero <div class="pet family">, no hay forma de definir realmente dos clases, que es una de las dos razones principales por las que usaría una clase en lugar de una identificación, de todos modos.

Problema 2: ¡compatibilidad directa!

Usar <div>s en este momento, nos obliga (al menos algunos de nosotros) a sangrar y comentar adecuadamente nuestro código, lo cual es una buena práctica para todos los lenguajes de programación.

En cambio, convertir los bloques HTML en variables causaría una gran confusión a los nuevos programadores sobre qué es y qué no está haciendo algo específico en HTML .

Además, causará el gracioso efecto secundario de que deberías comenzar a comparar tu código anterior con las nuevas etiquetas HTML5, solo para asegurarte de que no tengan el mismo nombre que hiciste para las clases de tu div ...

El mismo problema se aplica al variablesuso reserved wordsen algunos idiomas. PHP lo resolvió con un signo de dólar, por lo que un enfoque similar en HTML resultaría en algo no mucho mejor que el uso actual de <div class="something">.

mavrosxristoforos
fuente
¿Habría habido algún problema con el tipo que inventó la "clase" especificando que <z:name1 attr1=foo attr2=bar> ... <z/name2 attr3=boz ... </z>sería semánticamente equivalente <div class="name1" attr1="foo" attr2="bar">...</div><div class="name2" attr1="boz"> ... </div>pero que tomaría mucho menos tiempo enviar un módem de 14.4K?
supercat
Supongo que no. Pero esta sería una sintaxis diferente para escribir exactamente lo mismo, sin mejorar el concepto de <div class="">ninguna manera. Por otra parte, ¿por qué definir eso z:name1o z/name2son las etiquetas HTML classy no las suyas id? Y el problema del espacio en blanco aparece de nuevo aquí. Por lo tanto, tendría que ser z:"name1 name2"para declarar dos clases, que prácticamente se convierte en la misma cosa nuevamente.
mavrosxristoforos
Hay muchas posibilidades de sintaxis. Mi punto fue que en una era en la que muchas personas usaban módems 14.4K o más lentos, debería haber una forma que al menos tuviera en cuenta los problemas de ancho de banda.
supercat
Definitivamente lo entiendo. Como desarrollador web, todavía trato de minimizar cualquier cosa para producir sitios web más rápidos y más. Sin embargo, creo que es un buen enfoque en muchos aspectos, como lo es.
mavrosxristoforos
5

Usamos en <div>lugar de cualquier cosa que le guste porque hace que el procesamiento y la representación por parte del navegador sean más fáciles de realizar.

Como contraejemplo, XML permite la creación de cualquier nombre de etiqueta que desee. La capacidad de crear nombres de etiquetas arbitrarios conlleva un costo de procesamiento. Los analizadores XML deben crear un diccionario de las etiquetas utilizadas en un documento como parte de / mientras analiza el documento.

Al usar los <div>navegadores, sepa que hay un contenedor allí y que puede ignorar el contenedor o pasarlo a alguna otra herramienta en la cadena que pueda hacer algo con el contenedor.


fuente
Estoy bastante seguro de que si los navegadores solo usaran el método div implícito mencionado, el costo de procesamiento sería muy pequeño. Y los beneficios para la lectura y la capacidad de escritura serían enormes.
Jordan Davis
3
<div>significa menos complejidad, lo que siempre es algo bueno. HTML en su núcleo está construido de dos tipos de construcciones: nivel de bloque y marcado en línea. Tener más formas de expresar lo mismo solo se suma al desorden que es HTML.
" hace que el procesamiento y la representación por el navegador sean más fáciles de lograr " . Esto no es realmente cierto. Se requiere que los navegadores analicen etiquetas no reconocidas, y todos los métodos DOM y selectores CSS todavía tienen que trabajar en ellas como esperaba, y los navegadores aún aplicarán CSS a elementos no reconocidos. Lo único que el navegador no hace con etiquetas no reconocidas es aplicar los estilos y comportamientos predeterminados (estilos de agente de usuario).
Mentira Ryan
3

Usted sugiere permitir que los autores web agreguen nombres de elementos arbitrarios a HTML para fines privados (no estandarizados). Esto tiene un gran problema: hará que sea peligroso agregar nuevos elementos al estándar HTML, ya que varios autores ya pueden estar usando el mismo nombre de elemento para fines privados, lo que cambia la semántica de la página de manera retroactiva. La gente no se alegra cuando las nuevas versiones de los navegadores rompen las páginas web existentes, por lo que no se puede.

El mismo problema es con el uso de nombres de atributos arbitrarios para fines privados. Es por eso que HTML5 exige el prefijo "datos-" para los atributos de uso privado, por lo que no colisionarán con los nuevos atributos en el estándar.

Div y span se definen como elementos semánticamente neutros, lo que significa que puede usarlos para fines privados sin temor a que la semántica cambie en futuros navegadores. Claro, se requieren algunos caracteres más para agregar un nombre de clase, pero la compatibilidad hacia adelante hace que valga la pena.

JacquesB
fuente
2

Su propio ejemplo muestra una propiedad por la cual los divs no son tan ridículos.

<div class="hero-img">
  <img src="http://whatever.com/this.jpg">
</div>

Usted, correctamente, no ha cerrado la imgetiqueta. Algunas etiquetas, tales como img, br, hr, y otros no tienen ningún contenido, y son, por tanto, no se cerrarán. El analizador lo sabe.

La divetiqueta, por otro lado, se supone que está cerrada, ya que contiene contenido. Si acaba de crear su propia etiqueta, el analizador no tendría idea de si debería esperar que la etiqueta se cierre o no.

La razón por la cual algunos elementos se deben cerrar y otros no se debe a la herencia de SGML, que esta publicación de blog describe muy bien: http://www.colorglare.com/2014/02/03/to-close-or-not- to-close.html

Pete
fuente
2

Es una cuestión de definición. Si usa XHTML, que es XML puro, por lo tanto, completamente definido, entonces podría usar su propio espacio de nombres, aquí, por ejemplo, a través de un prefijo q::

<q:hero-img>
    <img src="http://whatever.com/this.jpg">
</q:hero-img>

Si utilizara XML para convertir a (X) HTML, sería completamente libre de generar desde su HTML real "HTML" de etiqueta libre con <div class="hero-img">.


En alguna etiqueta, un atributo de espacio de nombres con su propia URL (ficticia):

xmlns:q="http://..."
Joop Eggen
fuente
1
+1 para la solución simple. Ni siquiera tiene que incluir un prefijo de espacio de nombres, y simplemente puede declarar un NS predeterminado para el documento general y proporcionar un XSLT para transformarlo en (X) HTML.
DougM
1
El espacio de nombres XML no está definido por el prefijo, sino por el valor de la declaración xmlns de ese prefijo. qaquí hay un prefijo completamente sin sentido (y es XML no válido) a menos que haya declarado los xmlns en algún lugar del documento. También puede volver a declarar el mismo espacio de nombres con prefijos diferentes o establecer el espacio de nombres predeterminado para una determinada sección del documento, y siempre que los valores de xmlns sean iguales, esos prefijos diferentes se tratarán por igual al aplicar CSS o en el DOM.
Lie Ryan
@LieRyan un buen punto. Debería haberlo mencionado. Supongo que el hecho era conocido. Añadido
Joop Eggen,
0

Uno de los elementos clave de HTML es tener elementos de etiqueta predefinidos. Es por eso.

La clase div = es una forma de sortear esta "limitación".

Y es por eso que no ves esas construcciones "implícitas".

Pieter B
fuente
Dígale eso a todos los ingenieros de Google que definan las nuevas especificaciones de componentes web ... Entiendo lo que quiere decir, pero en los próximos años habrá una explosión de elementos generados por el desarrollador. Mi idea es simplemente más fácil de usar. Punto tomado sin embargo.
Jordan Davis
0

El propósito de un elemento div es la estructura sola. Le permite agrupar elementos bajo un elemento común. No tiene nada que ver con espacios en blanco, velocidad, renderizado, semántica o cualquier otra cosa. Le ayuda con CSS en términos de estilo y javascript en términos de selectores. Si lo cambia a cualquier otro elemento, entonces cambia el propósito.

Para crear su propio elemento con nombre, como muestra, tiene un problema porque los motores de búsqueda y otras herramientas no sabrían lo que significan sus elementos. ¿Qué es un "hero-img" y en qué se diferencia de mi "imagen de héroe" y cómo debe manejarlo mi API cuando visito su página? ¿Cómo debe un navegador manejar ese elemento? ¿Es bloque de nivel o en línea? Demasiadas preguntas.

Robar
fuente
0

En general, las etiquetas div son útiles para aplicar división o sección en una página web. Puede usar una etiqueta div como contenedor en el que se pueden aplicar otros elementos. También ayudará a aplicar CSS y algunos scripts en un elemento en particular.

Ishan Shah
fuente