Pregunta ¿Por qué no usar tablas para el diseño en HTML? [cerrado]


Parece ser el opinión general que las tablas no se deben usar para el diseño en HTML.

¿Por qué?

Nunca (o raramente para ser honesto) he visto buenos argumentos para esto. Las respuestas usuales son:

  • Es bueno contenido separado del diseño
    Pero este es un argumento falaz; Cliche pensamiento. Supongo que es cierto que usar el elemento de la tabla para el diseño tiene poco que ver con los datos tabulares. ¿Y qué? ¿A mi jefe le importa? ¿A mis usuarios les importa?

    Quizás yo o mis compañeros desarrolladores que tienen que mantener un cuidado de página web ... ¿Es una tabla menos sostenible? Creo que usar una mesa es más fácil que usar divs y CSS.

    Por cierto ... ¿por qué está utilizando un div o un tramo una buena separación de contenido del diseño y una tabla no? Obtener un buen diseño con solo divs a menudo requiere una gran cantidad de divs anidados.

  • Legibilidad del código
    Creo que es al revés. La mayoría de las personas entiende HTML, pocos entienden CSS.

  • Es mejor para SEO no usar tablas
    ¿Por qué? ¿Alguien puede mostrar alguna evidencia de que es? ¿O una declaración de Google de que las tablas se desalientan desde una perspectiva SEO?

  • Las tablas son más lentas
    Se debe insertar un elemento extra tbody. Esto es un cacahuete para los navegadores web modernos. Muéstrame algunos puntos de referencia donde el uso de una tabla ralentiza significativamente una página.

  • Una revisión de diseño es más fácil sin tablas, ver css Zen Garden.
    La mayoría de los sitios web que necesitan una actualización también necesitan contenido nuevo (HTML). No es muy probable que existan escenarios en los que una nueva versión de un sitio web solo necesite un nuevo archivo CSS. Zen Garden es un sitio web agradable, pero un poco teórico. Por no mencionar su mal uso de CSS.

Estoy realmente interesado en buenos argumentos para usar divs + CSS en lugar de tablas.


665


origen


Respuestas:


Voy a revisar tus argumentos uno tras otro y tratar de mostrar los errores en ellos.

Es bueno separar el contenido del diseño   Pero este es un argumento falaz; Cliché pensando.

No es falaz en absoluto porque HTML fue diseñado intencionalmente. El uso indebido de un elemento puede no estar completamente fuera de discusión (después de todo, las nuevas expresiones idiomáticas también se han desarrollado en otros idiomas), pero las posibles implicaciones negativas deben contrapesarse. Además, incluso si no hubiera argumentos contra el mal uso del <table> elemento hoy en día, puede haber mañana debido a la forma en que los proveedores de navegadores aplican un tratamiento especial al elemento. Después de todo, ellos saben eso "<table> los elementos son solo para datos tabulares "y podrían usar este hecho para mejorar el motor de renderizado, en el proceso cambiando sutilmente cómo <table>s comportarse y, por lo tanto, interrumpir los casos en los que antes se usaba incorrectamente.

¿Y qué? ¿A mi jefe le importa? ¿A mis usuarios les importa?

Depende ¿Tu jefe es de pelo puntiagudo? Entonces quizás no le importe. Si es competente, entonces le importará, porque los usuarios será.

Quizás yo o mis compañeros desarrolladores que tienen que mantener un cuidado de página web ... ¿Es una tabla menos sostenible? Creo que usar una tabla es más fácil que usar divs y css.

La mayoría de los desarrolladores web profesionales parecen oponerse a ti[cita requerida]. Que tablas son de hecho, menos fácil de mantener debería ser obvio. Usar tablas para el diseño significa que cambiar el diseño corporativo de hecho significará cambiar cada página. Esto puede ser muy costoso. Por otro lado, uso juicioso de HTML semánticamente significativo combinado con CSS podría limitar tales cambios al CSS y las imágenes utilizadas.

Por cierto ... ¿por qué está utilizando un div o un tramo una buena separación de contenido del diseño y una tabla no? Obtener un buen diseño con solo divs a menudo requiere una gran cantidad de divs anidados.

Profundamente anidado <div>s son un antipatrón como diseños de tabla. Los buenos diseñadores web no necesitan muchos de ellos. Por otro lado, incluso tales divs anidados profundamente no tienen muchos de los problemas de los diseños de tablas. De hecho, incluso pueden contribuir a una estructura semántica al dividir lógicamente el contenido en partes.

Legibilidad del código   Creo que es al revés. La mayoría de las personas entienden html, poco entienden css. Es mas simple

"La mayoría de la gente" no importa. Los profesionales importan Para los profesionales, los diseños de tablas crean muchos más problemas que HTML + CSS. Esto es como decir que no debería usar GVim o Emacs porque el Bloc de notas es más simple para la mayoría de las personas. O que no debería usar LaTeX porque MS Word es más simple para la mayoría de las personas.

Es mejor para SEO no usar tablas

No sé si esto es cierto y no usaría esto como argumento, pero sería lógico. Los buscadores buscan pertinente datos. Si bien los datos tabulares podrían ser relevantes, rara vez es lo que buscan los usuarios. Los usuarios buscan los términos utilizados en el título de la página o posiciones similarmente destacadas. Por lo tanto, sería lógico excluir el contenido tabular del filtrado y, por lo tanto, reducir el tiempo de procesamiento (¡y los costos!) Por un factor importante.

Las tablas son más lentas   Se debe insertar un elemento extra tbody. Esto es un cacahuete para los navegadores web modernos.

El elemento adicional no tiene nada que ver con que las tablas sean más lentas. Por otro lado, el algoritmo de diseño para tablas es mucho más difícil, el navegador a menudo tiene que esperar a que se cargue toda la tabla para poder comenzar a diseñar el contenido. Además, el almacenamiento en caché del diseño no funcionará (CSS se puede almacenar fácilmente en caché). Todo esto ha sido mencionado antes.

Muéstrame algunos puntos de referencia donde el uso de una tabla ralentiza significativamente una página.

Lamentablemente, no tengo ningún dato de referencia. Yo mismo estaría interesado en él porque es correcto que este argumento carezca de cierto rigor científico.

La mayoría de los sitios web que necesitan una actualización también necesitan contenido nuevo (html). Los escenarios donde una nueva versión de un sitio web solo necesita un nuevo archivo css no son muy probables.

De ningún modo. He trabajado en varios casos donde el cambio del diseño se simplificó mediante una separación de contenido y diseño. A menudo sigue siendo necesario cambiar algunos códigos HTML, pero los cambios siempre serán mucho más confinados. Además, los cambios de diseño en ocasiones deben hacerse de forma dinámica. Considere los motores de plantillas como el que usa el sistema de blog de WordPress. Los diseños de tabla matarían literalmente a este sistema. He trabajado en un caso similar para un software comercial. Ser capaz de cambiar el diseño sin cambiar el código HTML fue uno de los requisitos del negocio.

Otra cosa. El diseño de la tabla hace que el análisis automatizado de sitios web (screen scraping) sea mucho más difícil. Esto puede sonar trivial porque, después de todo, ¿quién lo hace? Me sorprendí a mí mismo. El raspado de pantallas puede ayudar mucho si el servicio en cuestión no ofrece una alternativa de WebService para acceder a sus datos. Estoy trabajando en bioinformática donde esta es una triste realidad. Las técnicas web modernas y los servicios web no han llegado a la mayoría de los desarrolladores y, a menudo, el raspado de pantallas es la única manera de automatizar el proceso de obtención de datos. No es de extrañar que muchos biólogos todavía realicen tales tareas de forma manual. Para miles de conjuntos de datos.


497



Aquí está mi respuesta del programador a partir de una hilo simliar

Semántica 101

Primero eche un vistazo a este código y piense en lo que está mal aquí ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

El problema, por supuesto, es que una bicicleta no es un automóvil. La clase de auto es una clase inapropiada para la instancia de bicicleta. El código está libre de errores, pero es semánticamente incorrecto. Se refleja pobremente en el programador.

Semántica 102

Ahora aplique esto al marcado de documentos. Si su documento necesita presentar datos tabulares, entonces la etiqueta apropiada sería <table>. Sin embargo, si coloca la navegación en una tabla, está haciendo un uso indebido del fin previsto de la <table> elemento. En el segundo caso, no está presentando datos tabulares; está (mal) usando el <table> elemento para lograr un objetivo de presentación.

Conclusión

¿Los visitantes lo notarán? No. ¿A tu jefe le importa? Tal vez. ¿A veces cortamos esquinas como programadores? Por supuesto. Pero deberíamos? No. ¿Quién se beneficia si usa el marcado semántico? Tú y tu reputación profesional. Ahora ve y haz lo correcto.


290



Respuesta obvia: ver CSS Zen Garden. Si me dices que puedes hacer lo mismo fácilmente con un diseño basado en tablas (recuerda, el HTML no está cambiando), utiliza tablas para el diseño.

Otras dos cosas importantes son accesibilidad y SEO.

Ambos se preocupan por el orden en que se presenta la información. No puede presentar fácilmente su navegación en la parte superior de la página si su diseño basado en tablas lo coloca en la tercera celda de la segunda fila de la segunda tabla anidada en la página.

Entonces tus respuestas son mantenibilidad, accesibilidad y SEO.

No seas perezoso Hacer las cosas de la manera correcta y adecuada, incluso si son un poco más difíciles de aprender.


104



Vea esta pregunta duplicada. 

Un elemento que te olvidas de que hay accesibilidad. Los diseños basados ​​en tablas tampoco se traducen si necesita usar un lector de pantalla, por ejemplo. Y si trabajas para el gobierno, puedes apoyar navegadores accesibles como lectores de pantalla. necesario.

También creo que subestimas el impacto de algunas de las cosas que mencionaste en la pregunta. Por ejemplo, si usted es el diseñador y el programador, es posible que no tenga una apreciación completa de lo bien que separa la presentación del contenido. Pero una vez que ingresas a una tienda donde tienen dos funciones distintas, las ventajas comienzan a aclararse.

Si sabes lo que estás haciendo y tienes buenas herramientas, CSS realmente tiene ventajas significativas sobre las tablas para el diseño. Y aunque cada elemento en sí mismo puede no justificar el abandono de las tablas, en conjunto, por lo general vale la pena.


91



Desafortunadamente, CSS Zen Garden ya no se puede usar como un ejemplo de buen diseño de HTML / CSS. Prácticamente todos sus diseños recientes usan gráficos para encabezado de sección. Estos archivos gráficos están especificados en el CSS.

Por lo tanto, un sitio web cuyo propósito es mostrar la ventaja de mantener el diseño fuera de contenido, ahora regularmente comete el PECADO INIGUALABLE de poner contenido en el diseño. (Si el encabezado de la sección en el archivo HTML cambiara, el encabezado de la sección que se muestra no).

Lo cual solo demuestra que incluso aquellos que defienden la estricta religión de DIV y CSS no pueden seguir sus propias reglas. Puede usar eso como una guía en cuanto a la manera en que los sigue.


54



Este no es el argumento definitivo, de ninguna manera, pero con CSS puede tomar el mismo marcado y cambiar el diseño dependiendo del medio, lo cual es una buena ventaja. Para una página de impresión, puede suprimir silenciosamente la navegación sin tener que crear una página para imprimir, por ejemplo.


48



Una mesa para el diseño no sería tan mala. Pero la mayoría de las veces no puedes obtener el diseño que necesitas con solo una mesa. Muy pronto tienes 2 o tres tablas anidadas. Esto se vuelve muy engorroso.

  • ES MUCHO más difícil de leer. Eso no depende de la opinión. Solo hay más etiquetas anidadas sin marcas de identificación.

  • Separar el contenido de la presentación es algo bueno porque te permite concentrarte en lo que estás haciendo. Mezcla los dos cables con páginas hinchadas que son difíciles de leer.

  • CSS for styles le permite a su navegador guardar en caché los archivos y las solicitudes posteriores son mucho más rápidas. Esto es ENORME

  • Las tablas te bloquean en un diseño. Claro, no todos necesitan la flexibilidad de CSS Zen Garden, pero nunca he trabajado en un sitio donde no necesite cambiar el diseño un poco aquí y allá. Es mucho más fácil con CSS.

  • Las tablas son difíciles de diseñar. No tiene mucha flexibilidad con ellos (es decir, aún necesita agregar atributos HTML para controlar completamente los estilos de una tabla)

No he usado tablas para datos no tabulares en probablemente 4 años. No he mirado hacia atrás.

Realmente me gustaría sugerir leer Dominio de CSS por Andy Budd. Es fantástico.

Imagen en ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg


45



Es bueno separar el contenido del diseño
  Pero este es un argumento falaz; Cliche pensamiento

Es un argumento falaz porque las tablas HTML son de diseño. El contenido es el datos en la tabla, la presentación es la tabla misma. Esta es la razón por la que separar CSS de HTML puede ser muy difícil a veces. ¡No estás separando el contenido de la presentación, estás separando la presentación de la presentación! Una pila de divs anidados no es diferente de una tabla; es solo un conjunto diferente de etiquetas.

El otro problema con la separación del HTML del CSS es que necesitan un conocimiento íntimo del uno del otro: realmente no se puede separar por completo. El diseño de la etiqueta en el HTML está estrechamente relacionado con el archivo CSS sin importar lo que haga.

Creo que las tablas y los divs se reducen a las necesidades de su aplicación.

En la aplicación que desarrollamos en el trabajo, necesitábamos un diseño de página donde las piezas se dimensionaran dinámicamente a su contenido. Pasé varios días intentando que esto funcionara entre navegadores con CSS y DIV, y fue una pesadilla completa. Cambiamos a tablas y todo solo trabajó.

Sin embargo, tenemos un público muy cerrado para nuestro producto (vendemos una pieza de hardware con una interfaz web) y los problemas de accesibilidad no nos preocupan. No sé por qué los lectores de pantalla no pueden lidiar bien con las tablas, pero supongo que si así son las cosas, los desarrolladores deben manejarlas.


36



CSS / DIV: solo son trabajos para los chicos del diseño, ¿verdad? Los cientos de horas que he dedicado a la depuración de problemas DIV / CSS, la búsqueda en Internet para obtener una parte del marcado trabajando con un navegador oscuro - me vuelve loco. Haces un pequeño cambio y todo el diseño se vuelve horrendo y equivocado, donde en realidad es la lógica en eso. Pasar horas moviendo algo 3 píxeles de esta manera luego algo más 2 píxeles el otro para que todos se alineen. Esto me parece completamente incorrecto de alguna manera. El hecho de que seas purista y de que algo "no sea lo correcto" no significa que debas utilizarlo en enésimo grado y en todas las circunstancias, especialmente si te hace la vida 1000 veces más fácil.

Así que finalmente decidí, solo por razones comerciales, aunque mantengo el uso al mínimo, si preveo 20 horas de trabajo para colocar correctamente una DIV, me quedaré en una mesa. Está mal, molesta a los puristas, pero en la mayoría de los casos cuesta menos tiempo y es más barato de administrar. Entonces puedo concentrarme en hacer que la aplicación funcione como el cliente quiere, en lugar de complacer a los puristas. Después de todo, pagan las facturas y mi argumento a un gerente que impone el uso de CSS / DIV: ¡simplemente señalaría que los clientes también pagan su salario!

La única razón por la que todos estos argumentos CSS / DIV ocurren es por la deficiencia de CSS en primer lugar y porque los navegadores no son compatibles entre sí y, si lo fueran, la mitad de los diseñadores web en el mundo quedarían sin trabajo. .

Cuando diseñas un formulario de Windows, no tratas de mover los controles después de que los hayas distribuido, así que creo que es extraño para mí por qué quieres hacerlo con un formulario web. Simplemente no puedo entender esta lógica. Obtenga el diseño correcto para empezar y cuál es el problema. Creo que es porque a los diseñadores les gusta flirtear con la creatividad, mientras que los desarrolladores de aplicaciones se preocupan más por lograr que la aplicación funcione, crear objetos comerciales, implementar reglas comerciales, averiguar cómo se relacionan los bits de los datos de los clientes, asegurar que la cosa se encuentre con los clientes requisitos, ya sabes, como las cosas del mundo real.

No me malinterpreten, ambos argumentos son válidos, pero por favor no critiquen a los desarrolladores por elegir un enfoque más fácil y más lógico para diseñar formularios. A menudo tenemos cosas más importantes de qué preocuparse que la semántica correcta de usar una tabla sobre un div.

Un ejemplo: basado en esta discusión, convertí unos pocos tds y trs existentes a divs. 45 minutos jugando con eso tratando de hacer que todo se alinee uno al lado del otro y me di por vencido. TDs en 10 segundos más tarde - funciona - de inmediato - en todos los navegadores, nada más que hacer. Por favor, intenta hacerme entender: ¡qué posible justificación tienes para querer que lo haga de otra manera!


23



El diseño debe ser fácil. El hecho de que haya artículos escritos sobre cómo lograr un diseño dinámico de tres columnas con encabezado y pie de página en CSS muestra que es un sistema de diseño deficiente. Por supuesto, puede hacer que funcione, pero hay literalmente cientos de artículos en línea sobre cómo hacerlo. No hay prácticamente tales artículos para un diseño similar con tablas porque es evidentemente obvio. No importa lo que digas en contra de las tablas y en favor de CSS, este hecho lo deshace todo: un diseño básico de tres columnas en CSS a menudo se llama "El Santo Grial".

Si eso no te hace decir "WTF", entonces realmente necesitas dejar el kool-aid ahora.

Amo CSS. Ofrece sorprendentes opciones de diseño y algunas herramientas de posicionamiento geniales, pero como motor de diseño es deficiente. Es necesario que haya algún tipo de sistema de posicionamiento dinámico de la red. Una forma sencilla de alinear cajas en múltiples ejes sin conocer primero su tamaño. Me importa un bledo si lo llamas <table> o <gridlayout> o lo que sea, pero esta es una característica básica de diseño que falta en CSS.

El problema más grande es que al no admitir que faltan características, los fanáticos de CSS han estado reteniendo CSS de todo lo que podría ser. Estaría perfectamente feliz de dejar de usar tablas si CSS proporcionara un posicionamiento de cuadrícula de varios ejes decente, como básicamente cualquier otro motor de diseño en el mundo. (Te das cuenta de que este problema ya ha sido resuelto muchas veces en muchos idiomas, excepto en el W3C, ¿no? Y nadie más negó que tal característica fuera útil).

Suspiro. Suficiente ventilación Adelante, vuelve a meter la cabeza en la arena.


21



De acuerdo con el cumplimiento 508 (para los lectores de pantalla para personas con problemas visuales), las tablas solo se deben usar para almacenar datos y no para el diseño, ya que hace que los lectores de pantalla se vuelvan locos. O eso me han dicho.

Si asigna nombres a cada uno de los divs, también puede desollarlos usando CSS. Son un poco más dolorosos sentarse de la manera en que los necesitas.


19