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

Aquí está mi respuesta del programador de un hilo simliar

Semántica 101

Primero echa un vistazo a este código y piensa 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 coche. La clase de coche es una clase inapropiada para la instancia de moto. El código está libre de errores, pero es semánticamente incorrecto. Se refleja mal en el programador.

Semántica 102

Ahora aplique esto a 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, entonces está haciendo un mal uso del propósito previsto del elemento <table>. En el segundo caso, no estás presentando datos tabulares you estás (mal)usando el elemento <table> para lograr un objetivo de presentación.

Conclusión

¿Se darán cuenta los visitantes? No. ¿A tu jefe le importa? Posiblemente. ¿A veces cortamos esquinas como programadores? Asegúrese. Pero ¿deberíamos? No. ¿Quién se beneficia si utiliza el marcado semántico? Tú reputation y tu reputación profesional. Ahora ve y haz lo correcto.

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) entonces por todos los medios usa 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 tablas lo coloca en la 3ª celda de la 2ª fila de la 2ª tabla anidada en el pagina.

Así que 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.

Vea esta pregunta duplicada.

Un elemento que estás olvidando es la accesibilidad. Los diseños basados en tablas no se traducen tan bien si necesitas usar un lector de pantalla, por ejemplo. Y si usted trabaja para el gobierno, el apoyo a los navegadores accesibles como lectores de pantalla puede ser requerido.

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, puede no tener una apreciación completa de lo bien que separa la presentación del contenido. Pero una vez que entras en una tienda donde hay dos roles distintos, las ventajas comienzan a ser más claras.

Si sabes lo que estás haciendo y tienes 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 las 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 utilizan gráficos para el encabezado de la 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 indescriptible de poner contenido en el diseño. (Si el encabezado de sección en el archivo HTML fuera a cambiar, el encabezado de sección mostrado sería ni).

Lo que solo demuestra que incluso aquellos que defienden la estricta religión DIV & CSS, no pueden seguir sus propias reglas. Usted puede usar eso como una guía en cómo 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 dependiendo del medio, lo que es una buena ventaja. Para una página de impresión, puede suprimir la navegación sin tener que crear una página fácil de imprimir, por ejemplo.

Una tabla para el diseño no sería tan malo. Pero no puede obtener el diseño que necesita con una sola 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. Solo 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 enfocarte en lo que estás haciendo. Mezcla de los dos cables a páginas hinchadas que son difíciles de leer.

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

• Las mesas 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 el diseño un poco aquí y allá. Es mucho más fácil con CSS.

• Las mesas son difíciles de diseñar. No tienes 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 atrás.

Realmente me gustaría sugerir la lectura Dominio 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

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

Es un argumento falaz porque las tablas HTML son layout! El contenido es el datos en la tabla, la presentación es la tabla en sí. 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 un 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 pueden separar completamente. El diseño de la etiqueta en el HTML está estrechamente acoplado con el archivo CSS sin importar lo que hagas.

Creo que las tablas vs 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é días tratando de conseguir que esto funcione cross-browser con CSS y DIVs y fue una pesadilla completa. Cambiamos a tablas y todo simplemente 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 son una preocupación para nosotros. No se por qué los lectores de pantalla no pueden lidiar bien con las tablas, pero supongo que si esa es la forma en que es entonces los desarrolladores tienen que manejarlo.

CSS/DIV - son solo trabajos para los chicos de diseño, ¿no? Los cientos de horas que he pasado depurando problemas DIV/CSS, buscando en Internet para obtener alguna parte del marcado trabajando con un navegador oscuro - me vuelve loco. Usted hace un pequeño cambio y todo el diseño va terriblemente mal-donde en eath es 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 conseguir que todos se alineen. Esto me parece mal de alguna manera. Solo porque usted es un purista y algo "no es lo correcto" no significa que usted debe hacer uso de ella en el grado enésimo y bajo todas las circunstancias, especialmente si hace su vida 1000 veces más fácil.

Así que finalmente he decidido, puramente por motivos comerciales, aunque mantengo el uso al mínimo, si preveo 20 horas de trabajo para obtener un DIV colocado correctamente, me pegaré 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. Me a continuación, puede concentrarse en conseguir que la aplicación funcione como el cliente quiere, en lugar de complacer a los puristas. Ellos pagan las cuentas después de todo y mi argumento a un gerente que hace cumplir el uso de CSS/DIV - Me limitaría a señalar que los clientes pagan su salario también!

La única razón por la que todos estos argumentos CSS/DIV ocurren es debido a 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 el mundo se quedaría sin trabajo.

Cuando diseñas un formulario de Windows no intentas mover los controles después de haberlos distribuido, así que creo que es extraño para mí por qué querrías hacer esto 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 coquetear con la creatividad, mientras que los desarrolladores de aplicaciones están más preocupados por hacer que la aplicación funcione, creando objetos de negocio, implementar reglas de negocio, averiguar cómo los bits de datos de los clientes se relacionan entre sí, garantizar que la cosa cumpla con los requisitos de los clientes, ya sabes, como las cosas del mundo real.

No me malinterprete, ambos argumentos son válidos, pero por favor no critique 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 - basado en esta discusión convertí algunos tds y trs existentes a divs. 45 minutos jugando con él tratando de que todo se alinee uno al lado del otro y me rendí. TDs de vuelta en 10 segundos más tarde-funciona - de inmediato-en todos los navegadores, nada más que hacer. Por favor, trata de hacerme entender - ¿qué posible justificación tienes para querer que lo haga de cualquier 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 pobre. Por supuesto, puedes hacer que funcione, pero hay literalmente cientos de artículos en línea sobre cómo hacerlo. Prácticamente no hay tales artículos para un diseño similar con tablas porque es claramente obvio. No importa lo que digas en contra de las tablas y a favor de CSS, este hecho lo deshace todo: un básico de tres el diseño de columna en CSS a menudo se llama "El Santo Grial".

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

Me encanta CSS. Ofrece increíbles opciones de estilo y algunas herramientas de posicionamiento geniales, pero como motor de diseño es deficiente. Tiene que haber algún tipo de sistema de posicionamiento de red dinámico. Una forma sencilla de alinear cajas en múltiples ejes sin conocer primero sus tamaños. Me importa un bledo si lo llamas

De acuerdo con el cumplimiento 508 (para lectores de pantalla para visualmente impared), 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 se asignan nombres a cada uno de los divs, se puede skin todos juntos usando CSS también. Son un poco más de un dolor para llegar a sentarse de la manera que los necesita.

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 tabla.

<?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 tablas es el hecho de que soy demasiado entusiasta con mi sangría. Estoy seguro de que la sección de contenido tendría otras dos tablas incrustadas.

Otra cosa en la que pensar: filesizes. He encontrado que los diseños basados en tablas son el doble del tamaño de sus contrapartes CSS por lo general. En nuestra alta velocidad banda ancha que no es un gran problema, pero es en aquellos con módems de acceso telefónico.

Me gustaría añadir 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 los elementos y se hace. Desde mi experiencia, rediseñar un diseño que utiliza 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.

No hay argumentos a favor de DIVs de mí.

Yo diría: Si el zapato te queda bien, úsalo.

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 todavía se ve de la manera que pretendía.

Esto inclina el equilibrio un poco hacia las tablas en la mayoría de mis diseños, y aunque me siento culpable de usarlos (dunny por qué, la gente simplemente dice que es malo, así que trato de escucharlos), al final, la visión pragmática es que es más fácil y más rápido para mí usar tablas. 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 tienen problemas con los diseños basados en tablas: también hacen que sea mucho más difícil para los navegadores móviles representar una página correctamente.

Además, con un diseño basado en div puede hacer cosas interesantes con una hoja de estilo de impresión, como excluir encabezados, pies de página y navegación de las páginas impresas, creo que sería imposible, o al menos mucho más difícil, hacer eso 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 estuviera basado en tablas... Si estás haciendo un diseño basado en tablas, es poco probable que estés usando CSS para controle todo el espaciado y el relleno en las celdas (si lo estuviera, seguramente le resultarí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 izquierda a derecha y de arriba a abajo de las cosas 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 los divs un poco. 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 cuestión muy debatida es un testimonio del fracaso del W3C para anticipar la diversidad de diseños de maquetación que se intentaría. El uso de divs + css para un diseño semánticamente amigable es un gran concepto, pero los detalles de la implementación son tan defectuosos que en realidad limitan la libertad creativa.

He intentado cambiar nuestros sitios entre tablas, divs, y fue un dolor de cabeza que estoy totalmente desguazado las horas de trabajo que había vertido en ella y volvió a las mesas. Tratar de luchar con mis divs para ganar el control de la alineación vertical me ha maldecido con problemas psicológicos importantes que nunca sacudiré mientras este debate siga.

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

Supongo que es cierto que el uso del elemento table para el layout tiene poco que ver con los datos tabulares. ¿Y qué? ¿A mi jefe le importa? ¿A mis usuarios les importa?

Google y otros sistemas automatizados se preocupan , 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 habiendo tenido que generar HTML no válido, de hecho fue un trabajo de 3 horas para rectificarlo rompiendo por un cambio menor.

Este es, por supuesto, el caso edge, 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 por romperlo.

También, prueba esto con JavaScript. Mover una sola celda de una tabla colocar en otro lugar en otra mesa. Bastante complicado de realizar donde div / span solo funcionaría copy-paste-wise.

" A mi jefe le importa "

Flexibilidad de diseño
Imagina que estás haciendo una página con un gran número de miniaturas.
DIVs :
Si pones cada miniatura en un DIV, flotando a la izquierda, tal vez 10 de ellos caben en una fila. Haga la ventana más estrecha, y BAM-es 6 en una fila, o 2, o como muchos caben.
CUADRO:
Tienes que decir explícitamente cuántas celdas hay en una fila. Si la ventana es demasiado estrecha, el usuario tiene que desplazarse horizontalmente.

Capacidad de mantenimiento
La misma situación como arriba. Ahora desea agregar tres miniaturas a la tercera fila.
DIVs:
Añádelos. El diseño se ajustará automáticamente.
CUADRO: Pegue las nuevas celdas en la tercera fila. Oops! Ahora hay demasiados elementos. Cortar algunos de esa fila y ponerlos en la cuarta fila. Ahora hay demasiados artículos allí. Corta un poco de esa fila... (etc)
( Por supuesto, si está generando las filas y celdas con scripting del lado del servidor, esto probablemente no será un cuestión.)

Creo que ese barco ha zarpado. Si observa la dirección que ha tomado la industria, notará que CSS y los Estándares Abiertos son los ganadores de esa discusión. Lo que a su vez significa que para la mayoría del trabajo html, con la excepción de los formularios, los diseñadores usarán divs en lugar de tablas. Tengo un tiempo difícil con eso porque no soy un gurú de CSS, pero así es como es.

Además, no olvide que las tablas no se renderizan bien en los navegadores móviles. Claro, el iPhone tiene un navegador kick-ass, pero todo el mundo no tiene un iPhone. La representación de tablas puede ser un maní para los navegadores modernos, pero es un montón de sandías para los navegadores móviles.

Personalmente he encontrado que muchas personas usan demasiadas etiquetas <div>, pero con moderación, puede ser extremadamente limpio y fácil de leer. Mencionas que a la gente le cuesta más leer CSS que las tablas; en términos de 'código' que tal vez 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 tablas y eso es todo. Poner diseño en una tabla te limita solo por ese diseño. Con CSS puedes mover bits, echa un vistazo a http://csszengarden.com / Y no, el diseño no suele requerir una gran cantidad de divs anidados.

Sin tablas para el diseño y semántica adecuada HTML es mucho más limpio, por lo tanto, más fácil de leer. ¿Por qué alguien que no entiende CSS debería intentar leerlo? Y si alguien se considera ser webdeveloper entonces el bien comprensión de CSS es una necesidad.

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

Http://www.hotdesign.com/seybold /

• 508 Compliance - la capacidad de un lector de pantalla para dar sentido a su marcado.
• Esperando el renderizado - las tablas no se renderizan en el navegador hasta que llega al final del elemento </table>.

Toda la idea en torno al marcado semántico es la separación del marcado y la presentación, que incluye el diseño.

Los Div no están reemplazando tablas, tienen su propio uso para separar contenido en bloques de contenido relacionado (, ). Cuando no tiene las habilidades y confía en 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 nuestro trabajo, y los desarrolladores no tienen que volver a su código para hacer cambios cuando la presentación necesita cambiar.

Esto no se trata realmente de si 'los divs son mejores que las tablas para el diseño'. Alguien que entiende CSS puede duplicar cualquier diseño usando 'tablas de diseño' bastante directamente. La verdadera victoria es usar elementos HTML para lo que están allí. La razón por la que no usaría tablas para datos no tablulares es la misma razón por la que no almacena 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 utilizar tablas para el diseño (debido a las deficiencias del navegador en la década de 1990) ciertamente no lo es ahora.

Las herramientas que usan diseños de tabla pueden llegar a ser extraordinariamente pesadas debido a la cantidad de código requerido para crear el diseño. El Portal Netweaver de SAP de forma predeterminada utiliza la TABLA 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 va siete tablas de profundidad, 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 demasiado pesado, etc., y la página pesa más de 5 MB.

Tomarse el tiempo para reducir el peso de la página para que pueda usar su ancho de banda para realizar actividades atractivas con los usuarios vale la pena el esfuerzo.

Vale la pena averiguar CSS y divs para que la columna de contenido central se cargue y renderice antes de la barra lateral en un diseño de página. Pero si usted está luchando para utilizar divs flotantes para alinear verticalmente un logotipo con un poco de patrocinio de texto, solo tiene que utilizar la tabla y seguir adelante con la vida. La religión del jardín Zen no da mucho por el dinero.

La idea de separar el contenido de la presentación es particionar la aplicación para que diferentes tipos de trabajo afecten a diferentes bloques de código. Este 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 una 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 a través de silos verticales. Si un cambio a" contenido "siempre va acompañado de un cambio a" presentación", ¿qué tan exitoso es el particionamiento?

Si realmente desea particionar su código de forma productiva, use Subversion y revise sus registros de cambios. A continuación, utilice las técnicas de codificación más simples div divs, tablas, JavaScript, includes, funciones, objetos, continuaciones, lo que sea to para estructurar la aplicación de modo que los cambios encajen de una manera sencilla y cómoda.

Porque es un 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 un dolor en el culo (a menos que no los entiendas but pero bueno, bienvenido al mundo de las computadoras).

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

Es aterrador que algunas personas no sean 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 mantenibles que CSS. Sin embargo, hay algunos problemas de diseño específicos donde las tablas son de hecho la solución más simple y flexible.

CSS es claramente preferible en los casos en que el marcado presentacional y CSS soportan el mismo tipo de diseño, nadie en su sano juicio argumentaría que font-etiquetas son mejores que especificar tipografía en CSS, ya que CSS le da el mismo poder que font-etiquetas, pero en un manera.

El problema con las tablas, sin embargo, es básicamente que el modelo de diseño de tabla en CSS no es compatible con Microsoft Internet Explorer. Las tablas y CSS son por lo tanto no equivalentes en potencia. La parte que falta es el comportamiento de cuadrícula de las tablas, donde los bordes de las celdas se alinean vertical y 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 rígido y quebradizo (siempre y cuando tengamos que soportar Internet Explorer - en otros navegadores esto se logra fácilmente usando display:table-cell).

Así que no se trata realmente de si las tablas o CSS son preferibles, sino 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 Web http://www.w3.org/TR/WCAG10 / asesoramiento contra 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 puede siempre crear el mismo diseño con CSS que con las tablas, puede que solo requiera más trabajo.

Me sorprendió ver que algunos temas no estaban ya 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 el SEO al permitir posicionar el contenido en la página donde quieras. Hace unos años, los motores de búsqueda estaban dando un énfasis significativo a los factores "on-page". Algo en la parte superior de la página se consideró más relevante para la página que algo ubicado en inferior. "Arriba de la página" para una araña significaba "al principio del código". Usando CSS, puedes organizar tu contenido rico en palabras clave al principio del código, y aún colocarlo donde quieras en la página. Esto sigue siendo algo relevante, pero los factores de la página son cada vez menos importantes para el ranking de la página.

B) Cuando el diseño se mueve a CSS, la página HTML es más ligera 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 css externo file). Páginas de carga rápida es una consideración importante de clasificación para varios motores de búsqueda, incluyendo Google

C) El trabajo de SEO a menudo requiere probar y cambiar las 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 sencillo y seguro. Es autónomo y se integra bien dentro de cualquier plantilla. A hacer lo mismo con CSS es considerablemente más difícil y puede no ser de ningún beneficio: es difícil editar la hoja de estilos 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), por lo que es igual de fácil de modificar.

Esta es una de las razones por las que algunos sitios web muy bien diseñados (por ejemplo) todavía usan tabla diseños.

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

.3. Prueba rápida de conversión

Al averiguar qué funciona para un público específico, es útil poder cambiar el diseño de varias maneras para averiguar qué obtiene los mejores resultados. Un diseño basado en CSS hace las cosas considerablemente más fáciles

.4. diferentes soluciones para Diferentes problemas

Las tablas de diseño generalmente se dissed porque "todo el mundo sabe que 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 son 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 es a menudo el caso)

Hay muchas desventajas de las tablas, incluyendo el mantenimiento, la falta de flexibilidad... pero no tiremos al bebé con el agua del baño. Hay un montón de usos profesionales para una solución rápida y fiable.

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

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

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