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

Parece ser la opinión general de que las tablas no deben usarse para el diseño en HTML.

¿Por qué?

Nunca (o rara vez, para ser sincero) he visto buenos argumentos para esto. Las respuestas habituales son:

• Es bueno separar el contenido del diseño
  Pero este es un argumento falaz; Pensamiento Cliché . Supongo que es cierto que usar el elemento de tabla para el diseño tiene poco que ver con los datos tabulares. ¿Y qué? ¿A mi jefe le importa? ¿Mis usuarios se preocupan?
  
  Quizás yo o mis colegas desarrolladores que tienen que mantener una página web cuidan ... ¿Es una tabla menos mantenible? Creo que usar una tabla es más fácil que usar divs y CSS.
  
  Por cierto ... ¿por qué usar un div o un span no es una buena separación del contenido del diseño y una tabla? Obtener un buen diseño con solo divs a menudo requiere muchos divs anidados.

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

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

• Las mesas son más lentas.
  Se debe insertar un elemento tbody adicional. Esto es maní 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 del diseño es más fácil sin tablas, vea css Zen Garden .
  La mayoría de los sitios web que necesitan una actualización también necesitan nuevo contenido (HTML). No es muy probable que una nueva versión de un sitio web solo necesite un nuevo archivo CSS. Zen Garden es un buen sitio web, pero un poco teórico. Sin mencionar su mal uso de CSS.

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

Revisaré sus argumentos uno tras otro e intentaré mostrar los errores en ellos.

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

No es falaz en absoluto porque HTML fue diseñado intencionalmente. El mal uso de un elemento puede no estar completamente fuera de discusión (después de todo, también se han desarrollado nuevas expresiones idiomáticas en otros idiomas), pero las posibles implicaciones negativas deben ser contrarrestadas. Además, incluso si no hubiera argumentos contra el mal uso del <table>elemento hoy, podría haber mañana debido a la forma en que los proveedores de navegadores aplican un tratamiento especial al elemento. Después de todo, saben que "los <table>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 se <table>comportan y, por lo tanto, rompiendo los casos en los que anteriormente se usaba incorrectamente.

¿Y qué? ¿A mi jefe le importa? ¿Mis usuarios se preocupan?

Depende ¿Tu jefe tiene el pelo puntiagudo? Entonces podría no importarle. Si es competente, entonces se preocupará, porque los usuarios lo harán .

Quizás yo o mis colegas desarrolladores que tienen que mantener una página web cuidan ... ¿Es una tabla menos mantenible? 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 ]} . Es obvio que las tablas son menos mantenibles. Usar tablas para el diseño significa que cambiar el diseño corporativo significará, de hecho, cambiar cada página. Esto puede ser muy costoso. Por otro lado, el 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é usar un div o un span no es una buena separación del contenido del diseño y una tabla? Obtener un buen diseño con solo divs a menudo requiere muchos divs anidados.

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

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

"La mayoría de la gente" no importa. Los profesionales importan. Para los profesionales, los diseños de tabla 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 lo usaría como argumento, pero sería lógico. Los motores de búsqueda buscan datos relevantes . Si bien los datos tabulares pueden 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 en posiciones prominentes similares. 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!) En un factor importante.

Las mesas son más lentas. Se debe insertar un elemento tbody adicional. Esto es maní para los navegadores web modernos.

El elemento extra 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 antes de que pueda comenzar a diseñar el contenido. Además, el almacenamiento en caché del diseño no funcionará (CSS se puede almacenar en caché fácilmente). Todo esto ha sido mencionado antes.

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

Desafortunadamente, no tengo ningún dato de referencia. Me interesaría yo mismo porque es cierto que este argumento carece de cierto rigor científico.

La mayoría de los sitios web que necesitan una actualización también necesitan nuevo contenido (html). No es muy probable que una nueva versión de un sitio web solo necesite un nuevo archivo CSS.

De ningún modo. He trabajado en varios casos donde cambiar el diseño se simplificó mediante una separación de contenido y diseño. A menudo todavía es necesario cambiar algo de código HTML, pero los cambios siempre serán mucho más confinados. Además, los cambios de diseño en ocasiones deben hacerse dinámicamente. Considere motores de plantillas como el que usa el sistema de blogs de WordPress. Los diseños de tabla literalmente matarían a este sistema. He trabajado en un caso similar para un software comercial. Poder cambiar el diseño sin cambiar el código HTML era uno de los requisitos comerciales.

Otra cosa. El diseño de tabla hace que el análisis automático de sitios web (raspado de pantalla) 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 pantalla 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 pantalla es la única forma de automatizar el proceso de obtención de datos. No es de extrañar que muchos biólogos sigan realizando tales tareas manualmente. Para miles de conjuntos de datos.

Aquí está la respuesta de mi programador de un hilo similar

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 automóvil es una clase inapropiada para la instancia de bicicleta. El código no contiene errores, pero es semánticamente incorrecto. Se refleja mal 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 mal uso del propósito previsto del <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 hacemos recortes como programadores? Por supuesto. ¿Pero deberíamos? No. ¿Quién se beneficia si usa marcado semántico? Usted y su reputación profesional. Ahora ve y haz lo correcto.

Respuesta obvia: Ver CSS Zen Garden . Si me dice que puede hacer lo mismo fácilmente con un diseño basado en tablas (recuerde, el HTML no está cambiando), entonces utilice tablas para el diseño.

Otras dos cosas importantes son la accesibilidad y el SEO.

A ambos les importa en qué orden 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 la tabla lo coloca en la tercera celda de la segunda fila de la segunda tabla anidada en la página.

Entonces sus respuestas son mantenibilidad, accesibilidad y SEO.

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

Ver esta pregunta duplicada.

Un elemento que está olvidando es la accesibilidad. Los diseños basados ​​en tablas no se traducen tan bien si necesita usar un lector de pantalla, por ejemplo. Y si trabaja para el gobierno, es posible que se requieran navegadores accesibles como lectores de pantalla .

También creo que subestimas el impacto de algunas de las cosas que mencionaste en la pregunta. Por ejemplo, si usted es tanto el diseñador como el programador, es posible que no tenga una apreciación completa de cuán bien separa la presentación del contenido. Pero una vez que ingresa a una tienda donde tienen dos roles distintos, las ventajas comienzan a ser más claras.

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

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

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

Lo que solo demuestra que incluso aquellos que defienden la estricta religión DIV y CSS, no pueden seguir sus propias reglas. Puede usar eso como una guía sobre qué tan de cerca los sigue.

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

Una mesa para el diseño no sería tan mala. Pero no puede obtener el diseño que necesita con solo una tabla la mayor parte del tiempo. Muy pronto tienes 2 o tres mesas anidadas. Esto se vuelve muy engorroso.

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

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

• CSS para estilos permite que su navegador almacene en caché los archivos y las solicitudes posteriores son mucho más rápidas. Esto es ENORME

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

• Las tablas son difíciles de peinar. 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 CSS Mastery 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

Es bueno separar el contenido del diseño
Pero este es un argumento falaz; Pensamiento cliché

¡Es un argumento falaz porque las tablas HTML son diseño! El contenido son los datos en la tabla, la presentación es la tabla misma. Es por eso 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 divisiones anidadas no es diferente a 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 el 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 tablas vs divs se reduce 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 según su contenido. Pasé días tratando de hacer que esto funcionara entre navegadores con CSS y DIV y fue una pesadilla completa. Nos cambiamos a mesas y todo funcionó .

Sin embargo, tenemos una audiencia muy cerrada 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 manejar bien las tablas, pero supongo que si es así, los desarrolladores tienen que manejarlo.

CSS / DIV: son solo trabajos para los muchachos del diseño, ¿no? Los cientos de horas que he pasado depurando problemas de DIV / CSS, buscando en Internet para obtener una parte del marcado trabajando con un navegador oscuro, me vuelve loco. Realizas un pequeño cambio y todo el diseño sale terriblemente mal, ¿dónde está la lógica en eso? Pasar horas moviendo algo 3 píxeles de esta manera y luego algo más 2 píxeles el otro para que todos se alineen. Esto simplemente me parece incorrecto de alguna manera. El hecho de que seas purista y que algo "no sea lo correcto" no significa que debas usarlo en el enésimo grado y en todas las circunstancias, especialmente si te hace la vida 1000 veces más fácil.

Así que finalmente he decidido, por razones comerciales, aunque mantengo el uso al mínimo, si anticipo 20 horas de trabajo para colocar un DIV correctamente, 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 hace cumplir el uso de CSS / DIV: ¡simplemente señalaría que los clientes también pagan su salario!

La única razón por la que ocurren todos estos argumentos CSS / DIV 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 del mundo estarían sin trabajo .

Cuando diseñas un formulario de Windows, no intentas mover los controles después de haberlos desplegado, así que creo que es extraño para mí por qué quieres hacer esto con un formulario web. Simplemente no puedo entender esta lógica. Obtenga el diseño correcto para comenzar y cuál es el problema. Creo que es porque a los diseñadores les gusta coquetear con la creatividad, mientras que los desarrolladores de aplicaciones están más preocupados por hacer que la aplicación funcione, crear objetos de negocios, implementar reglas de negocios, averiguar cómo se relacionan entre sí los fragmentos de datos del cliente, asegurando 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 no critiquen a los desarrolladores por elegir un enfoque más fácil y lógico para diseñar formularios. A menudo tenemos cosas más importantes de las que preocuparnos que la semántica correcta de usar una tabla sobre un div.

Caso en cuestión: en base a esta discusión, convertí algunos tds y trs existentes en divs. 45 minutos jugando con eso tratando de hacer que todo se alinee uno al lado del otro y me di por vencido. Los TD regresan en 10 segundos más tarde, funciona de inmediato, en todos los navegadores, nada más que hacer. Por favor, intenta hacerme entender: ¿qué justificación posible tienes para querer que lo haga de otra manera?

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 hacerlo funcionar, pero hay literalmente cientos de artículos en línea sobre cómo hacerlo. Prácticamente no existen tales artículos para un diseño similar con tablas porque es evidentemente obvio. No importa lo que diga 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 el CSS. Ofrece increíbles opciones de estilo y algunas herramientas de posicionamiento interesantes, pero como motor de diseño es deficiente. Tiene que haber algún tipo de sistema de posicionamiento dinámico de la red. Una forma sencilla de alinear cajas en varios ejes sin conocer primero sus tamaños. Me importa un comino si lo llamas <table> o <gridlayout> o lo que sea, pero esta es una característica de diseño básica 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 frenando a CSS de todo lo que podría ser. Me encantaría dejar de usar tablas si CSS proporciona un posicionamiento de cuadrícula multieje decente como básicamente cualquier otro motor de diseño del mundo. (Se da cuenta de que este problema ya ha sido resuelto muchas veces en muchos idiomas por todos excepto el W3C, ¿verdad? Y nadie más negó que tal característica fuera útil).

Suspiro. Suficiente ventilación. Adelante, mete la cabeza hacia atrás en la arena.

De acuerdo con el cumplimiento 508 (para lectores de pantalla para personas con discapacidad visual), las tablas solo deben usarse para contener datos y no para el diseño, ya que hace que los lectores de pantalla se asusten. O eso me han dicho.

Si asigna nombres a cada uno de los divs, también puede pelarlos todos juntos usando CSS. Son un poco más dolorosos para sentarse como lo necesitas.

Aquí hay una sección de html de un proyecto reciente:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

Y aquí está el mismo código que un diseño basado en tablas.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

La única limpieza que veo en ese diseño basado en la tabla es el hecho de que soy demasiado celoso con mi sangría. Estoy seguro de que la sección de contenido tendría otras dos tablas incrustadas.

Otra cosa para pensar: los tamaños de archivo . He descubierto que los diseños basados ​​en tablas son dos veces más grandes que sus equivalentes CSS. En nuestra banda ancha de alta velocidad, eso no es un gran problema, pero sí en aquellos con módems de acceso telefónico.

Me gustaría agregar que los diseños basados ​​en div son más fáciles de mantener, evolucionar y refactorizar. Solo algunos cambios en el CSS para reordenar elementos y ya está. Desde mi experiencia, rediseñar un diseño que usa tablas es una pesadilla (más si hay tablas anidadas).

Su código también tiene un significado desde un punto de vista semántico .

Ningún argumento en DIV me favorece.

Yo diría: si el zapato le queda bien, úselo.

Vale la pena señalar que es difícil, si no imposible, encontrar un buen método DIV + CSS para representar el contenido en dos o tres columnas, que sea consistente en todos los navegadores, y aún se ve de la manera que pretendía.

Esto inclina un poco el equilibrio hacia las tablas en la mayoría de mis diseños, y aunque me siento culpable de usarlos (maldita sea, la gente simplemente dice que es malo, así que trato de escucharlos), al final, la visión pragmática es que es solo más fácil y rápido para mí usar TABLEs. No me pagan por hora, así que las mesas son más baratas para mí.

Los diseños CSS son generalmente mucho mejores para la accesibilidad, siempre que el contenido venga en un orden natural y tenga sentido sin una hoja de estilo. Y no son solo los lectores de pantalla los que luchan con los diseños basados ​​en tablas: también hacen que sea mucho más difícil para los navegadores móviles renderizar una página correctamente.

Además, con un diseño basado en div, puede hacer cosas interesantes muy fácilmente con una hoja de estilo de impresión, como excluir encabezados, pies de página y navegación de páginas impresas; creo que sería imposible, o al menos mucho más difícil, hacerlo con un diseño basado en tablas.

Si duda de que la separación del contenido del diseño sea más fácil con divs que con tablas, eche un vistazo al HTML basado en div en CSS Zen Garden , vea cómo cambiar las hojas de estilo puede cambiar drásticamente el diseño y piense si podría lograr la misma variedad de diseños si el HTML estaba basado en tablas ... Si está haciendo un diseño basado en tablas, es poco probable que use CSS para controlar todo el espaciado y el relleno en las celdas (si lo fuera, usted es casi seguro que sería más fácil usar divs flotantes, etc. en primer lugar). Sin usar CSS para controlar todo eso, y debido al hecho de que las tablas especifican el orden de las cosas de izquierda a derecha y de arriba a abajo en el HTML, las tablas tienden a significar que su diseño se vuelve muy fijo en el HTML.

Siendo realistas, creo que es muy difícil cambiar completamente el diseño de un diseño basado en div y CSS sin cambiar un poco los divs. Sin embargo, con un diseño basado en div y CSS, es mucho más fácil ajustar cosas como el espacio entre varios bloques y sus tamaños relativos.

El hecho de que esta sea una pregunta muy debatida es un testimonio del fracaso del W3C en anticipar la diversidad de diseños de diseño que se intentarían. Usar divs + css para un diseño semánticamente amigable es un gran concepto, pero los detalles de la implementación son tan imperfectos que en realidad limitan la libertad creativa.

Traté de cambiar uno de los sitios de nuestra empresa de tablas a divs, y fue un dolor de cabeza que eliminé totalmente las horas de trabajo que había invertido en él y volví a las tablas. Intentar luchar con mis divs para obtener el control de la alineación vertical me ha maldecido con importantes problemas psicológicos que nunca sacudiré mientras este debate continúe.

El hecho de que las personas frecuentemente presenten soluciones complejas y feas para lograr objetivos de diseño simples (como la alineación vertical) sugiere que las reglas no son lo suficientemente flexibles. Si las especificaciones SON suficientes, ¿por qué los sitios de alto perfil (como SO) consideran necesario doblar las reglas usando tablas y otras soluciones?

Supongo que es cierto que usar el elemento de tabla para el diseño tiene poco que ver con los datos tabulares. ¿Y qué? ¿A mi jefe le importa? ¿Mis usuarios se preocupan?

A Google y otros sistemas automatizados les importa, y son igual de importantes en muchas situaciones. El código semántico es más fácil de analizar y procesar para un sistema no inteligente.

Habiendo tenido que trabajar con un sitio web que involucraba 6 capas de tablas anidadas generadas por alguna aplicación, y haber tenido que generar HTML no válido, de hecho fue un trabajo de 3 horas rectificarlo rompiendo por un cambio menor.

Por supuesto, este es el caso límite, pero el diseño basado en tablas no se puede mantener. Si usa CSS, separa el estilo para que al arreglar el HTML tenga menos de qué preocuparse.

Además, intente esto con JavaScript. Mueva una sola celda de la tabla de un lugar a otro en otra tabla. Más bien complicado de realizar donde div / span solo funcionaría con copiar y pegar.

"¿A mi jefe le importa"

Si yo fuera tu jefe. Te importaría ;) Si valoras tu vida.

Flexibilidad de diseño
Imagine que está haciendo una página con una gran cantidad de miniaturas.
DIV :
si coloca cada miniatura en un DIV, flotando a la izquierda, tal vez 10 de ellas encajen en una fila. Haga que la ventana sea más estrecha y BAM: es 6 en una fila, o 2, o como muchos quepan.
TABLA:
Debe decir explícitamente cuántas celdas hay en una fila. Si la ventana es demasiado estrecha, el usuario debe desplazarse horizontalmente.

Mantenibilidad La
misma situación que la anterior. Ahora desea agregar tres miniaturas a la tercera fila.
DIV: agréguelos
. El diseño se ajustará automáticamente.
TABLA: Pegue las nuevas celdas en la tercera fila. ¡Uy! Ahora hay demasiados artículos allí. Corta algunos de esa fila y ponlos en la cuarta fila. Ahora hay demasiados artículos allí. Corte algunos de esa fila ... (etc.)
( Por supuesto, si está generando las filas y celdas con secuencias de comandos del lado del servidor, esto probablemente no será un problema ) .

Creo que ese barco ha navegado. Si observa la dirección que ha tomado la industria, notará que CSS y estándares abiertos son los ganadores de esa discusión. Lo que a su vez significa para la mayoría del trabajo html, con la excepción de los formularios, los diseñadores usarán divs en lugar de tablas. Me cuesta mucho hacerlo porque no soy un gurú de CSS, pero así es.

Además, no olvide que las tablas no se reproducen bien en los navegadores móviles. Claro, el iPhone tiene un navegador increíble, pero no todos tienen un iPhone. El renderizado de tablas puede ser un maní para los navegadores modernos, pero es un montón de sandías para navegadores móviles.

Personalmente descubrí que muchas personas usan demasiadas <div>etiquetas, pero con moderación, puede ser extremadamente limpio y fácil de leer. Usted menciona que la gente tiene más dificultades para leer CSS que las tablas; en términos de 'código' que tal vez sea cierto; pero en términos de lectura de contenido (ver> fuente) es mucho más fácil entender la estructura con hojas de estilo que con tablas.

Parece que estás acostumbrado a las mesas y eso es todo. Poner el diseño en una tabla te limita solo para ese diseño. Con CSS puede mover bits, eche un vistazo a http://csszengarden.com/ Y no, el diseño no suele requerir muchos divs anidados.

Sin tablas para el diseño y la semántica adecuada, HTML es mucho más limpio, por lo tanto, más fácil de leer. ¿Por qué alguien que no puede entender CSS intenta leerlo? Y si alguien se considera a sí mismo desarrollador web, entonces es necesario tener una buena comprensión de CSS.

Los beneficios de SEO provienen de la capacidad de tener el contenido más importante en la parte superior de la página y tener una mejor relación de contenido a marcado.

http://www.hotdesign.com/seybold/

• Conformidad 508: la capacidad de un lector de pantalla de dar sentido a su marcado.
• Esperando el procesamiento: las tablas no se procesan en el navegador hasta que llega al final del </table>elemento.

La idea general del marcado semántico es la separación del marcado y la presentación, que incluye el diseño.

Los Div no reemplazan las tablas, tienen su propio uso para separar el contenido en bloques de contenido relacionado (,). Cuando no tiene las habilidades y depende de las tablas, a menudo tendrá que separar su contenido en celdas para obtener el diseño deseado, pero no necesitará tocar el marcado para lograr la presentación cuando use el marcado semántico. Esto es realmente importante cuando se genera el marcado en lugar de páginas estáticas.

Los desarrolladores deben dejar de proporcionar marcas que impliquen diseño para que aquellos de nosotros que tenemos las habilidades para presentar contenido podamos continuar con nuestros trabajos, y los desarrolladores no tienen que volver a su código para hacer cambios cuando la presentación necesita cambios.

No se trata realmente de si 'los divs son mejores que las tablas para el diseño'. Alguien que entienda CSS puede duplicar cualquier diseño usando 'tablas de diseño' de manera bastante directa. La verdadera victoria es usar elementos HTML para lo que están ahí. La razón por la que no usaría tablas para datos no tablulares es la misma razón por la que no almacena números enteros como cadenas de caracteres: la tecnología funciona mucho más fácilmente cuando la usa para el propósito para el que está diseñada. Si alguna vez fue necesario usar tablas para el diseño (debido a las deficiencias del navegador a principios de la década de 1990), ciertamente no lo es ahora.

Las herramientas que usan diseños de tabla pueden volverse extraordinariamente pesadas debido a la cantidad de código requerido para crear el diseño. El portal Netweaver de SAP utiliza de forma predeterminada TABLE para diseñar sus páginas.

El portal de producción de SAP en mi concierto actual tiene una página de inicio cuyo HTML pesa más de 60K y abarca siete tablas, tres veces dentro de la página. Agregue el Javascript, el mal uso de 16 iframes con problemas de tabla similares dentro de ellos, CSS excesivamente pesado, etc., y la página pesa más de 5 MB.

Vale la pena tomarse el tiempo para reducir el peso de la página para que pueda usar su ancho de banda para realizar actividades interesantes con los usuarios.

Vale la pena descubrir CSS y divs para que la columna de contenido central se cargue y se muestre antes de la barra lateral en un diseño de página. Pero si está luchando por usar divs flotantes para alinear verticalmente un logotipo con algún texto de patrocinio, simplemente use la tabla y continúe con la vida. La religión del jardín zen simplemente no da mucho por el dinero.

La idea de separar el contenido de la presentación es dividir la aplicación para que diferentes tipos de trabajo afecten a diferentes bloques de código. En realidad, se trata de la gestión del cambio. Pero los estándares de codificación solo pueden examinar el estado actual del código de manera superficial.

El registro de cambios para una aplicación que depende de los estándares de codificación para "separar el contenido de la presentación" mostrará un patrón de cambios paralelos en los silos verticales. Si un cambio en el "contenido" siempre va acompañado de un cambio en la "presentación", ¿qué tan exitosa es la partición?

Si realmente desea particionar su código productivamente, use Subversion y revise sus registros de cambios. Luego use las técnicas de codificación más simples (divs, tablas, JavaScript, incluye funciones, objetos, continuaciones, lo que sea) para estructurar la aplicación de modo que los cambios se ajusten de una manera simple y cómoda.

Porque es INFIERNO mantener un sitio que usa tablas y toma MUCHO más tiempo codificar. Si tienes miedo de los divs flotantes, ve a tomar un curso en ellos. No son difíciles de entender y son aproximadamente 100 veces más eficientes y un millón de veces menos dolorosas (a menos que no las entiendas, pero bueno, bienvenido al mundo de las computadoras).

Cualquiera que esté considerando hacer su diseño con una tabla mejor no espera que lo mantenga. Es la forma más retrasada de representar un sitio web. Gracias a Dios tenemos una alternativa mucho mejor ahora. Nunca volvería.

Da miedo que algunas personas no estén conscientes de los beneficios de tiempo y energía de crear un sitio utilizando herramientas modernas.

Las tablas no son en general más fáciles o más fáciles de mantener que CSS. Sin embargo, hay algunos problemas de diseño específicos en los que las tablas son de hecho la solución más simple y flexible.

CSS es claramente preferible en los casos en que el marcado de presentación y CSS admiten el mismo tipo de diseño, nadie en su sano juicio argumentaría que font-tags es mejor que especificar la tipografía en CSS, ya que CSS le da el mismo poder que font-tags, pero en Una forma mucho más limpia.

Sin embargo, el problema con las tablas es básicamente que el modelo de diseño de tablas en CSS no es compatible con Microsoft Internet Explorer. Las tablas y CSS, por lo tanto, no son equivalentes en potencia. La parte que falta es el comportamiento en forma de cuadrícula de las tablas, donde los bordes de las celdas se alinean tanto vertical como horizontalmente, mientras que las celdas aún se expanden para contener su contenido. Este comportamiento no es fácil de lograr en CSS puro sin codificar algunas dimensiones, lo que hace que el diseño sea rígido y quebradizo (siempre que tengamos que admitir Internet Explorer; en otros navegadores esto se logra fácilmente mediante el uso display:table-cell).

Por lo tanto, no se trata realmente de si las tablas o CSS son preferibles, sino que se trata de reconocer los casos específicos en los que el uso de tablas puede hacer que el diseño sea más flexible.

La razón más importante para no usar tablas es la accesibilidad. Las Pautas de Accesibilidad al Contenido en la Web http://www.w3.org/TR/WCAG10/ consejos sobre el uso de tablas para el diseño. Si le preocupa la accesibilidad (y en algunos casos puede estar legalmente obligado a hacerlo), debe usar CSS incluso si las tablas son más simples. Tenga en cuenta que siempre puede crear el mismo diseño con CSS que con las tablas, puede que solo requiera más trabajo.

Me sorprendió ver que algunos problemas aún no estaban cubiertos, así que aquí están mis 2 centavos, además de todos los puntos muy válidos hechos anteriormente:

.1. CSS y SEO:

a) CSS solía tener un impacto muy significativo en SEO al permitir colocar el contenido en la página donde lo desee. Hace unos años, los motores de búsqueda estaban haciendo un énfasis significativo en los factores "en la página". Algo en la parte superior de la página se consideró más relevante para la página que algo ubicado en la parte inferior. "Parte superior de la página" para una araña significa "al principio del código". Usando CSS, puede organizar su contenido rico en palabras clave al comienzo del código, y aún así colocarlo donde quiera en la página. Esto sigue siendo algo relevante, pero los factores en la página son cada vez menos importantes para la clasificación de la página.

b) Cuando el diseño se mueve a CSS, la página HTML es más clara y, por lo tanto, se carga más rápido para una araña de motor de búsqueda. (Las arañas no se molestan en descargar archivos CSS externos). Las páginas de carga rápida son una consideración importante para varios motores de búsqueda, incluido Google.

c) El trabajo de SEO a menudo requiere probar y cambiar cosas, lo cual es mucho más conveniente con un diseño basado en CSS

.2. Contenido generado:

Una tabla es considerablemente más fácil de generar programáticamente que el diseño CSS equivalente.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

Generar una tabla es simple y seguro. Es independiente y se integra bien dentro de cualquier plantilla. Hacer lo mismo con CSS es considerablemente más difícil y puede no ser beneficioso en absoluto: es difícil editar la hoja de estilo CSS en el vuelo, y agregar el estilo en línea no es diferente de usar una tabla (el contenido no está separado del diseño).

Además, cuando se genera una tabla, el contenido (en variables) ya está separado del diseño (en código), lo que facilita su modificación.

Esta es una razón por la que algunos sitios web muy bien diseñados (SO, por ejemplo) todavía usan diseños de tabla.

Por supuesto, si es necesario actuar sobre los resultados a través de JavaScript, los divs valen la pena.

.3. Prueba de conversión rápida

Al determinar qué funciona para una audiencia específica, es útil poder cambiar el diseño de varias maneras para descubrir qué obtiene los mejores resultados. Un diseño basado en CSS facilita las cosas considerablemente

.4. Diferentes soluciones para diferentes problemas.

Las tablas de diseño generalmente se omiten porque "todo el mundo sabe divs y CSS" son el camino a seguir.

Sin embargo, el hecho es que las tablas son más rápidas de crear, más fáciles de entender y más robustas que la mayoría de los diseños CSS. (Sí, CSS puede ser tan robusto, pero un vistazo rápido a través de la red en diferentes navegadores y resoluciones de pantalla muestra que no suele ser el caso)

Las mesas tienen muchos inconvenientes, incluido el mantenimiento, la falta de flexibilidad ... pero no arrojemos al bebé con el agua del baño. Hay muchos usos profesionales para una solución que es rápida y confiable.

Hace algún tiempo, tuve que reescribir un diseño CSS limpio y simple usando tablas porque una porción significativa de los usuarios usaría una versión anterior de IE con muy mal soporte para CSS

Yo, por mi parte, estoy enfermo y cansado de la reacción instintiva "¡Oh, no! ¡Mesas para el diseño!"

En cuanto a la multitud "no fue diseñada para ese propósito y, por lo tanto, no deberías usarla de esta manera", ¿no es hipocresía? ¿Qué opinas de todos los trucos de CSS que tienes que usar para que la maldita cosa funcione en la mayoría de los navegadores? ¿Estaban destinados para ese propósito?