pantalla - ¿Por qué no usar tablas para maquetar en HTML?
tabla responsive html (30)
Es bueno separar el contenido del diseño
Pero este es un argumento falaz; Pensamiento cliché
¡Es un argumento falaz porque las tablas HTML están diseñadas! El contenido es los 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 una tabla, es solo un conjunto diferente de etiquetas.
El otro problema al separar el HTML del CSS es que necesitan un conocimiento íntimo de los demás, realmente no se pueden separar completamente. El diseño de la etiqueta en el HTML se combina estrechamente con el archivo CSS sin importar lo que haga.
Creo que tables 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 ajustaran dinámicamente a su contenido. Pasé días tratando de hacer que esto funcionara en varios navegadores con CSS y DIV y fue una completa pesadilla. Cambiamos a mesas y todo funcionó .
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 manejar bien las tablas, pero supongo que si es así, entonces los desarrolladores tienen que manejarlo.
Parece ser la opinión general de que las tablas no deben utilizarse para el diseño en HTML.
¿Por qué?
Nunca (o, para ser honesto) 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? ¿A mis usuarios les importa?
Quizás yo o mis colegas desarrolladores que tenemos que mantener el cuidado de una página web ... ¿Es una tabla menos mantenible? Creo que usar una tabla es easier que usar divs y CSS.
Por cierto ... ¿por qué usar una división o una separación de contenido buena de la distribución y una tabla no? 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? ¿O una declaración de Google de que las tablas están desalentadas desde una perspectiva SEO?Las mesas son más lentas.
Se debe insertar un elemento tbody extra. Esto es maní para los navegadores web modernos. Mostrarme 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 contenido nuevo (HTML). Los escenarios donde una nueva versión de un sitio web solo necesita un nuevo archivo CSS no son muy probables. Zen Garden es un buen sitio web, pero un poco teórico. Sin mencionar su misuse de CSS.
Estoy realmente interesado en buenos argumentos para usar divs + CSS en lugar de tablas.
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? ¿A mis usuarios les importa?
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 en un sistema no inteligente.
Aquí está la respuesta de mi programador desde un hilo similar.
Semantica 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 coches es una clase inadecuada para la instancia de bicicleta. El código está libre de errores, pero es semánticamente incorrecto. Se refleja mal en el programador.
Semantica 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 mal uso del propósito del elemento <table> . En el segundo caso, no está presentando datos tabulares: está (mal) utilizando el elemento <table> para lograr un objetivo de presentación.
Conclusión
¿Se darán cuenta los visitantes? No. ¿A tu jefe le importa? Tal vez. ¿A veces cortamos esquinas como programadores? Por supuesto. Pero deberíamos nosotros? No. ¿Quién se beneficia si usas el marcado semántico? Tú y tu reputación profesional. Ahora ve y haz lo correcto.
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 estoy demasiado entusiasta con mi sangría. Estoy seguro de que la sección de contenido tendría otras dos tablas integradas.
Otra cosa para pensar: tamaño de archivo . He encontrado que los diseños basados en tablas suelen ser el doble del tamaño de sus contrapartes de CSS. En nuestra banda ancha de alta velocidad no es un gran problema, pero sí en aquellos con módems de acceso telefónico.
CSS / DIV - son solo trabajos para los chicos de diseño, ¿no es así? Las cientos de horas que pasé depurando problemas de DIV / CSS, buscando en Internet para obtener una parte del marcado que funciona con un navegador oscuro, me vuelve loco. Usted hace un pequeño cambio y todo el diseño va terriblemente mal, donde la lógica está en eso. Pasar horas moviendo algo 3 píxeles de esta manera y luego otra cosa 2 píxeles el otro para que todos se alineen. Esto simplemente me parece mal de alguna manera. El hecho de que sea un purista y que algo "no sea lo correcto" no significa que deba usarlo hasta el noveno grado y en todas las circunstancias, especialmente si hace su vida 1000 veces más fácil.
Así que finalmente decidí, solo por motivos comerciales, aunque me mantengo al mínimo, si anticipo las 20 horas de trabajo para colocar un DIV correctamente, me quedo 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 manejar. Luego puedo concentrarme en hacer que la aplicación funcione como el cliente quiere, en lugar de complacer a los puristas. Después de todo, ellos pagan las facturas y mi argumento a un gerente que impone el uso de CSS / DIV - ¡Simplemente señalaría que los clientes pagan su salario también!
La única razón por la que se producen todos estos argumentos CSS / DIV es debido a la deficiencia de CSS en primer lugar y porque los navegadores no son compatibles entre sí y, de ser así, la mitad de los diseñadores web del mundo no tendrían 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é querrías hacer esto con un formulario web. Simplemente no puedo entender esta lógica. Obtener 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, crear objetos de negocios, implementar reglas de negocios, descubrir cómo se relacionan los bits de datos de los clientes entre sí, y asegurar que todo se encuentre con los clientes. requisitos - ya sabes - como las cosas del mundo real.
No me malinterpretes, ambos argumentos son válidos, pero no critiques a los desarrolladores por elegir un enfoque más sencillo 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 hacer que todo se alinee uno al lado del otro y me rendí. Los TD vuelven en 10 segundos más tarde, funcionan de inmediato en todos los navegadores, no hay nada más que hacer. Por favor, trate de hacerme entender, ¡qué posible justificación tiene para querer que lo haga de otra manera!
De acuerdo con el cumplimiento de la norma 508 (para los lectores de pantalla para visualizaciones de imágenes), las tablas solo deben usarse para guardar datos y no para el diseño, ya que hacen que los lectores de pantalla se vuelvan locos. O eso me han dicho.
Si asigna nombres a cada uno de los divs, puede combinarlos todos usando CSS también. Solo son un poco más de dolor sentarte de la forma en que lo necesitas.
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 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 regularmente comete el PESO INESTABLE 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 haría).
Lo que solo sirve para demostrar que incluso aquellos que abogan por la estricta religión DIV y CSS, no pueden seguir sus propias reglas. Puedes usar eso como una guía en la forma en que los sigues.
El diseño debe ser fácil. El hecho de que hay 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, puedes hacerlo funcionar, pero hay literalmente cientos de artículos en línea sobre cómo hacerlo. Casi no hay artículos de este tipo para un diseño similar con tablas porque es claramente obvio. No importa lo que diga en contra de las tablas y a 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 la ayuda de Kool 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 dinámico de la red. Una forma sencilla de alinear cuadros en ejes múltiples sin conocer primero sus tamaños. No me importa 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 mayor 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. Me encantaría dejar de usar tablas si CSS proporcionara un posicionamiento de cuadrícula multieje decente como básicamente cualquier otro motor de diseño en el mundo. (Se da cuenta de que este problema ya se ha resuelto muchas veces en muchos idiomas por todos, excepto el W3C, ¿verdad? Y nadie más negó que esa característica fuera útil).
Suspiro. Suficiente ventilación. Sigue adelante y mete la cabeza en la arena.
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 que es una buena ventaja. Para una página de impresión, puede suprimir silenciosamente la navegación sin tener que crear una página fácil de imprimir, por ejemplo.
Me gustaría agregar que los diseños basados en div son más fáciles de mantener, evolucionar y refactorizar. Sólo algunos cambios en el CSS para reordenar los elementos y se hace. 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 semantic .
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, por supuesto, use 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 tercera celda de la segunda fila de la segunda tabla anidada en la página.
Así que tus 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.
Una mesa para el diseño no sería tan mala. Pero no puede obtener el diseño que necesita con una sola mesa la mayor parte del tiempo. 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. Simplemente hay más etiquetas anidadas sin marcas de identificación en ellas.
Separar el contenido de la presentación es algo bueno porque le permite centrarse en lo que está haciendo. Mezclar los dos conductores en páginas hinchadas que son difíciles de leer.
CSS for styles permite que su navegador almacene 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 todos necesitan 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 mesas 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 atrás.
Realmente me gustaría sugerir la lectura de la Maestría en CSS por Andy Budd. Es fantástico.
Voy a revisar tus 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 un error 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, los nuevos modismos también se han desarrollado en otros idiomas), pero las posibles implicaciones negativas deben ser compensadas. Además, incluso si no hubiera argumentos contra el uso indebido del elemento <table> 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 elementos <table> son solo para datos tabulares" y podrían usar este hecho para mejorar el motor de renderización, en el proceso cambiando sutilmente el comportamiento de <table> y, por lo tanto, rompiendo los casos en los que anteriormente se usaba incorrectamente.
¿Y qué? ¿A mi jefe le importa? ¿A mis usuarios les importa?
Depende. ¿Es tu jefe de pelo puntiagudo? Entonces puede que no le importe. Si ella es competente, entonces le importará, porque los usuarios lo will .
Quizás yo o mis colegas desarrolladores que tenemos que mantener el cuidado de una página web ... ¿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 ] . Que las tablas sean, de hecho, menos mantenibles debería ser obvio. 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 una división o una separación de contenido buena de la distribución y una tabla no? Obtener un buen diseño con solo divs a menudo requiere muchos divs anidados.
Los <div> profundamente anidados son un antipatrón, al igual que los diseños de tablas. Los buenos diseñadores web no necesitan muchos de ellos. Por otro lado, incluso los 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.
La legibilidad del código creo que es al revés. La mayoría de la gente entiende html, poco entiende css. Es mas sencillo
"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 un argumento, pero sería lógico. Los buscadores buscan datos relevantes . Si bien los datos tabulares, por supuesto, pueden ser relevantes, rara vez es lo que buscan los usuarios. Los usuarios buscan términos utilizados en el título de la página o en posiciones similares prominentes. 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 extra. 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 puede ser fácilmente almacenado en caché). Todo esto ha sido mencionado antes.
Mostrarme 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 me interesaría 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 se simplificó el cambio de diseño por una separación de contenido y diseño. A menudo todavía es necesario cambiar algún código HTML, pero los cambios siempre serán mucho más limitados. 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 tablas literalmente matarían 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 era uno de los requisitos comerciales.
Otra cosa. El diseño de la tabla hace que el análisis automatizado 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? Yo mismo me sorprendí. El rastreo de pantalla puede ayudar mucho si el servicio en cuestión no ofrece una alternativa de servicio web 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 la 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 estas tareas manualmente. Para miles de conjuntos de datos.
Un elemento que estás olvidando allí 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 subestima el impacto de algunas de las cosas que mencionó en la pregunta. Por ejemplo, si usted es el diseñador y el programador, es posible que no tenga una idea completa de lo bien que separa la presentación del contenido. Pero una vez que entras en una tienda en la que hay 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 mientras que cada elemento por sí solo no puede justificar el abandono de las tablas, en general vale la pena.
Flexibilidad de diseño
Imagina que estás haciendo una página con una gran cantidad de miniaturas.
DIV :
si pones cada miniatura en un DIV, flota a la izquierda, quizás 10 de ellas caben en una fila. Haga la ventana más angosta y BAM: es 6 en una fila, o 2, o lo que sea suficiente.
TABLA:
Tienes que decir explícitamente cuántas celdas hay en una fila. Si la ventana es demasiado estrecha, el usuario tiene que desplazarse horizontalmente.
Mantenibilidad
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. Ups! Ahora hay demasiados elementos allí. Cortar algunos de esa fila y ponerlos en la cuarta fila. Ahora hay demasiados elementos allí. Corte algunos de esa fila ... (etc.)
( Por supuesto, si está generando filas y celdas con secuencias de comandos del lado del servidor, esto probablemente no será un problema ) .
Haber tenido que trabajar con un sitio web que involucraba 6 capas de tablas anidadas generadas por alguna aplicación, y haber generado que generara un HTML no válido, de hecho, fue un trabajo de 3 horas para rectificarlo por un cambio menor.
Este es, por supuesto, el caso de borde, pero el diseño basado en la tabla no se puede mantener. Si usa css, separa el estilo para que al corregir el HTML tenga menos de qué preocuparse por romper.
También, intente esto con JavaScript. Mueva una celda de una tabla de un lugar a otro en otra tabla. Más bien complicado de realizar, donde div / span solo funcionaría copiar y pegar.
"A mi jefe le importa"
Si yo fuera tu jefe. Te importaria ;) Si valoras tu vida.
La idea general sobre el marcado semántico es la separación del marcado y la presentación, que incluye el diseño.
Los Div no están reemplazando las tablas, tienen su propio uso para separar el 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 un marcado que implique diseño para que aquellos de nosotros que tenemos las habilidades para presentar el contenido podamos continuar con nuestros trabajos, y los desarrolladores no tienen que volver a su código para hacer cambios cuando las necesidades de presentación cambian.
Me sorprendió ver que algunos problemas no estaban cubiertos, así que aquí están mis 2 centavos, además de todos los puntos válidos que se mencionaron anteriormente:
.1. CSS y SEO:
a) CSS solía tener un impacto muy significativo en SEO al permitir posicionar el contenido en la página donde lo desee. Hace unos años, los motores de búsqueda estaban dando un énfasis significativo a 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. "Principio de la página" para una araña que significa "al principio del código". Usando CSS, puede organizar su contenido rico en palabras clave al principio del código, y aún así posicionarlo 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 un 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 pruebas y cambios, lo que 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 mesa es simple y seguro. Es autónomo 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 a 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 de las razones por las que algunos sitios web muy bien diseñados (SO, por ejemplo) todavía usan diseños de tablas.
Por supuesto, si los resultados se deben aplicar a través de JavaScript, los divs valen la pena.
.3. Prueba de conversión rápida
Cuando descubra 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 hace las cosas considerablemente más fáciles
.4. Diferentes soluciones para diferentes problemas.
Las tablas de diseño se suelen mostrar 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 más robustas que la mayoría de los diseños de CSS. (Sí, CSS puede ser tan robusto, pero una mirada rápida a través de la red en diferentes navegadores y resoluciones de pantalla muestra que no es así a menudo)
Hay muchas desventajas en las mesas, 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 volver a escribir un diseño CSS simple y limpio utilizando tablas porque una parte importante de los usuarios utilizaría una versión anterior de IE con un soporte muy malo para CSS
Yo, por mi parte, estoy harto y cansado de la reacción instintiva "¡Oh no! ¡Mesas para el diseño!"
En cuanto a la multitud "no fue para ese propósito y, por lo tanto, no deberías usarlo de esta manera", ¿no es eso hipocresía? ¿Qué piensas de todos los trucos de CSS que tienes que usar para que la cosa funcione en la mayoría de los navegadores? ¿Estaban destinados a ese propósito?
No hay argumentos en favor de los DIV de mi parte.
Yo diría: si el zapato le queda, úselo.
Vale la pena señalar que es difícil, si no imposible, encontrar un buen método DIV + CSS para representar los contenidos en dos o tres columnas, que sea coherente en todos los navegadores y que se vea exactamente como lo quería.
Esto inclina un poco el equilibrio hacia las tablas en la mayoría de mis diseños, y aunque me siento culpable de usarlas (por qué, la gente solo dice que es malo, así que trato de escucharlas), al final, la visión pragmática es que es simplemente 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í.
Además, no lo olvide, las tablas no se reproducen bien en los navegadores móviles. Claro, el iPhone tiene un navegador genial pero todos no tienen un iPhone. La representación de tablas puede ser un maní para los navegadores modernos, pero es un grupo de sandías para navegadores móviles.
Personalmente he encontrado que mucha gente usa demasiadas <div>etiquetas, pero con moderación, puede ser extremadamente limpia y fácil de leer. Usted menciona que a las personas les cuesta más leer CSS que a las tablas; en términos de ''código'' que tal vez sea cierto; pero en términos de contenido de lectura (ver> fuente) es mucho más fácil de entender la estructura con hojas de estilo que con tablas.
Creo que ese barco ha navegado. 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 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.
Debido a que es HELL mantener un sitio que usa tablas y se demora mucho más en codificar. Si tienes miedo de divs flotantes, toma 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 dolor en el culo (a menos que no los entiendas, pero bueno, bienvenidos al mundo de las computadoras).
Cualquiera que esté considerando hacer su diseño con una mesa mejor no esperará que yo lo mantenga. Es la forma más asquerosa de hacer 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 con herramientas modernas.
El hecho de que esta sea una pregunta muy debatida es una prueba del fracaso del W3C para anticipar la diversidad de diseños de diseño que se intentará. Usar divs + css para un diseño amigable con la semántica es un gran concepto, pero los detalles de la implementación son tan defectuosos que realmente limitan la libertad creativa.
Intenté cambiar uno de los sitios de nuestra compañía de mesas a divs, y fue un dolor de cabeza que deseché por completo las horas de trabajo que había vertido y volví a las mesas. Tratar de luchar con mis divs para obtener el control de la alineación vertical me ha maldecido con los principales problemas psicológicos que nunca sacudiré mientras continúe este debate.
El hecho de que las personas con frecuencia tengan que idear 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 SO) consideran necesario doblar las reglas usando tablas y otras soluciones alternativas?
Las herramientas que usan diseños de tablas 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 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 60 K y tiene siete tablas de profundidad, tres veces dentro de la página. Agregue el Javascript, el uso indebido 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.
Tomarse el tiempo para bajar el peso de la página para que pueda usar su ancho de banda para realizar actividades atractivas con los usuarios merece la pena.
Las tablas no son, en general, más fáciles o más fáciles de mantener que las CSS. Sin embargo, existen algunos problemas de diseño específicos en los que las tablas son 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 diría que las fontetiquetas son mejores que especificar tipografía en CSS, ya que CSS le da el mismo poder que las fontetiquetas, 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 tabla en CSS no es compatible con Microsoft Internet Explorer. Tablas y CSS por lo tanto no son equivalentes en poder. La parte faltante es el comportamiento en forma 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 sea rígido y quebradizo (siempre que tengamos que ser compatible con Internet Explorer, en otros navegadores esto se logra fácilmente mediante el uso display:table-cell).
Por lo tanto, no es realmente una cuestión de si las tablas o CSS son preferibles, sino una cuestión 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 para el Contenido Web http://www.w3.org/TR/WCAG10/ consejos nuevamente utilizando 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, ya que podría requerir más trabajo.
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 solo los lectores de pantalla luchan con los diseños basados en tablas: también hacen que sea más difícil para los navegadores móviles representar una página correctamente.
Además, con un diseño basado en div puede fácilmente hacer cosas geniales 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, hacerlo con una diseño basado en la tabla.
Si está dudando de que la separación del contenido del diseño sea más fácil con divs que con tablas, observe el 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 obtenga 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 esté usando CSS para controlar todo el espaciado y el relleno en las celdas (si lo estuvo, Es casi seguro que, en primer lugar, es más fácil usar divs flotantes, etc. 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 arregla mucho en el HTML.
De manera realista, 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.
Parece que estás acostumbrado a las tablas y eso es todo. Poner el diseño en una tabla te limita solo para ese diseño. Con CSS puede mover bits, visite http://csszengarden.com/ Y no, el diseño no requiere usualmente muchos divs anidados.
Sin tablas para el diseño y la semántica adecuada, el HTML es mucho más limpio y, por lo tanto, más fácil de leer. ¿Por qué debería alguien que no puede entender CSS intentar leerlo? Y si alguien se considera un desarrollador web, la buena comprensión de CSS es una necesidad.
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 contenido / marcado.
Realmente no se trata de si ''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 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 se usa para el propósito para el cual está diseñada. Si alguna vez fue necesario usar tablas para el diseño (debido a las deficiencias del navegador a principios de los 90), ciertamente no lo es ahora.
Vale la pena averiguar 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, solo use la tabla y siga 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 dividir la aplicación para que diferentes tipos de trabajo afecten a diferentes bloques de código. Esto es en realidad sobre 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 a "contenido" siempre está acompañado por un cambio a "presentación", ¿qué tan exitosa es la partición?
Si realmente desea particionar su código de manera productiva, 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 sencilla y cómoda.
- Cumplimiento 508: la capacidad de un lector de pantalla para dar sentido a su marca.
- En espera de procesamiento: las tablas no se procesan en el navegador hasta que llega al final del
</table>elemento.