todos - ¿Hay alguna razón comercial para esforzarse por el diseño puro de CSS?
selectores de presencia y valor (21)
Parece que cada vez que trato de crear un diseño de CSS puro me lleva mucho más tiempo que si utilizara una tabla o dos. Hacer que tres columnas tengan la misma longitud con diferentes cantidades de datos parece requerir hacks especiales, especialmente cuando se trata de problemas entre navegadores.
Mi pregunta:
¿A quién le van a doler estas pocas mesas?
Las tablas parecen funcionar particularmente bien en los datos tabulares: ¿por qué son tan vilipendiados hoy en día? Google.com tiene una tabla en su código fuente, al igual que muchos otros sitios (stackoverflow.com no está por cierto).
Cuando un lector de pantalla lee una página y ve una tabla, le indicará al usuario que es una tabla. Por lo tanto, si usa una tabla para el diseño, se vuelve muy confusa porque el usuario no sabe que el contenido de la tabla es realmente el artículo en lugar de otros datos tabulares
Esto no es verdad en realidad; lectores de pantalla como JAWS, Window Eyes y HAL ignoran las tablas de diseño. Trabajan muy bien al tratar con la web real.
hacer una renovación completa de un sitio web de 15 páginas simplemente actualizando 1 archivo es el cielo.
Esto es verdad. Desafortunadamente, tener un archivo CSS utilizado por 15,000 páginas complejas y muy diferentes es su peor pesadilla hecha realidad. Cambiar algo: ¿rompió mil páginas? ¿Quién sabe?
CSS es una espada de doble filo en grandes sitios como el nuestro.
:: asiente en palmsey y Jon Galloway ::
Estoy de acuerdo con el factor de mantenimiento. Me lleva un poco más de tiempo hacer mis diseños iniciales (ya que todavía soy aprendiz jedi en las artes CSS) pero hacer una renovación completa de un sitio web de 15 páginas simplemente actualizando 1 archivo es una delicia.
Algunas razones adicionales por las cuales esta es una buena práctica:
- Accesibilidad: idealmente, la web debería ser accesible para todos
- Rendimiento: ahorre ancho de banda y cargue más rápido en dispositivos móviles (estos carecen de ancho de banda hasta cierto punto y no pueden distribuir tablas complejas rápidamente). Además de cargar rápido siempre es algo bueno ...
Como muchas cosas, es una buena idea que a menudo se lleve demasiado lejos. Me gusta un diseño impulsado por div + css porque generalmente es bastante fácil cambiar la apariencia, incluso drásticamente, solo a través de la hoja de estilo. También es agradable ser amigable con navegadores de nivel inferior, lectores de pantalla, etc. Pero al igual que la mayoría de las decisiones de programación, el objetivo del sitio y el costo del desarrollo deben tenerse en cuenta al tomar una decisión. Ninguno de los lados es el camino correcto para ir el 100% del tiempo.
Por cierto, creo que todos están de acuerdo en que las tablas se deben usar para datos tabulares.
En el mundo real, sus posibilidades de tomar un diseño y volver a emparejarlo completamente sin tocar el marcado son bastante remotas. Está bien para blogs y demostraciones inventadas como csszengarden, pero es un beneficio falso en cualquier sitio con un diseño moderadamente complejo, realmente. Usar un CMS es mucho más importante.
DIVs más CSS! = Semántica, tampoco. El buen HTML vale la pena para SEO y la accesibilidad siempre, si se usan tablas o CSS para el diseño. Obtiene diseños web realmente eficientes y rápidos combinando tablas realmente simples con algunos buenos CSS.
Los diseños de tabla pueden ser más accesibles que los diseños de CSS, y lo contrario también es cierto: depende TOTALMENTE del orden de origen del contenido, y el hecho de que haya evitado tablas no significa que los usuarios con lectores de pantalla pasen un buen rato en su sitio . Las tablas de diseño son irrelevantes para el acceso al lector de pantalla siempre que el contenido tenga sentido cuando se linealiza, exactamente igual que si hiciera un diseño de CSS. Las tablas de datos son diferentes; son realmente difíciles de marcar correctamente e incluso entonces los usuarios del software lector de pantalla generalmente no conocen los comandos que necesitan usar para comprender los datos.
En lugar de angustiarse por el uso de algunas tablas de diseño, debe preocuparse de que las etiquetas de encabezado y el texto alternativo se usen correctamente y que las etiquetas de formulario estén asignadas correctamente. Entonces tendrás una muy buena puñalada en el acceso al mundo real.
Esto a partir de varios años de experiencia ejecutando pruebas de usuario para la accesibilidad web, especializándose en el diseño de sitios accesibles, y de la consultoría para Cahoot, un banco en línea, sobre este tema durante un año.
Entonces mi respuesta al cartel es no, no hay motivo comercial para preferir CSS sobre tablas. Es más elegante, más satisfactorio y más correcto, pero tú como la persona que lo construye y la persona que tiene que mantenerlo después de que seas las únicas dos personas en el mundo que le dan un grano de rata, ya sea CSS o tablas.
La idea es que los Diseñadores pueden Diseñar y Desarrolladores Web pueden implementar. Este es especialmente el caso en las aplicaciones web dinámicas en las que no desea que sus diseñadores desorienten en su código fuente.
Ahora, aunque hay motores de plantillas, los diseñadores aparentemente simplemente adoran volverse locos y CSS permite realizar más acrobacias que tablas.
Dicho esto: como desarrollador, abandoné CSS Layout principalmente porque mi diseño apesta de todos modos, por lo que al menos puede chupar correctamente :-) Pero si alguna vez contratara un diseñador, le dejaría usar lo que sea que escuche su editor WYSIWYG.
Mantener su diseño y su contenido por separado le permite rediseñar o realizar ajustes y cambios en su sitio fácilmente. Puede llevar un poco más de anticipación, pero la fase más larga de desarrollo de software es el mantenimiento . Un sitio amigable CSS con una clara separación entre contenido y diseño es mejor durante el mantenimiento.
Otra cosa que acabo de recordar, puede asignar una hoja de estilo diferente a una página para imprimir frente a la pantalla.
Además de la definición normal de la hoja de estilo, puede agregar la siguiente etiqueta
<link rel="stylesheet" type="text/css" media="print" href="PrintStyle.css" />
Que renderizará el documento de acuerdo con ese estilo cuando lo envíe a la impresora. Esto le permite eliminar las imágenes de fondo, la información adicional de encabezado / pie de página y simplemente imprimir la información sin crear un módulo por separado.
Razón comercial para el diseño de CSS: puede impresionar a los clientes diciendo "¡nuestro portal es totalmente personalizable / personalizable sin escribir código!"
Por otra parte, no veo ningún mal en el diseño de elementos de bloque con tablas. Por elementos de bloque me refiero a que no tiene ningún sentido separar ese elemento en diferentes diseños.
Por lo tanto, los datos tabulares se presentarán mejor con tablas, por supuesto. El diseño de los principales bloques de construcción (como una barra de menú, marcador de noticias, etc.) dentro de sus propias tablas también debería estar bien. Simplemente no confíes en las tablas para el diseño general de la página y estarás bien, creo.
Soy de la opinión de que el diseño de CSS con la menor cantidad de tablas posible es más limpio y mejor, pero estoy de acuerdo en que a veces solo tienes que usar una tabla.
En lo que respecta a los negocios, generalmente es "lo que hará que se haga de la manera más rápida y confiable". En mi experiencia, usar algunas tablas generalmente entra en esa categoría.
Descubrí que una forma muy efectiva de mitigar las diferencias entre navegadores en la representación de CSS es usar el tipo de documento "estricto" en la parte superior de la página:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
Además, para los temidos problemas de IE6 CSS, puedes usar este truco:
.someClass {
background-color:black; /*this is for most browsers*/
_background-color:white; /*this is for IE6 only - all others will ignore it*/
}
Usar el diseño de HTML semántico es una de esas cosas en las que no sabes lo que te estás perdiendo a menos que practiques. He trabajado en varios sitios donde el sitio fue rediseñado después del hecho con poco o ningún impacto en el código del servidor.
Redefinir sitios es una solicitud muy común, algo que he notado más ahora que puedo decir "sí" en lugar de tratar de salirme.
Y, una vez que haya aprendido a trabajar con el sistema de diseño de página, generalmente no es más difícil que el diseño basado en tablas.
* Le dejaría usar lo que escupe su editor WYSIWYG
Acabo de vomitar un poco ...
* ahh hola? ¿No crees que el diseñador gráfico está escribiendo el CSS a mano, verdad?
Curiosamente, he trabajado con algunos diseñadores y los mejores de ellos hacen manualmente su CSS. El tipo en el que estoy pensando en realidad hace todo su trabajo de diseño como un archivo XHTML con un par de archivos CSS y crea elementos gráficos sobre la marcha cuando los necesita. Él usa Dreamweaver pero solo realmente como una herramienta de navegación. (Aprendí mucho de ese tipo)
Una vez que has hecho una inversión para aprender diseño basado en CSS y has tenido un poco de experiencia (descubrí que IE apesta [para ser justo, está mejorando]), acabo siendo más rápido que he encontrado. Trabajé en Content Management Systems y la aplicación rara vez tuvo que cambiar para que los diseñadores presentaran un aspecto radicalmente diferente.
No creo que haya una razón comercial en absoluto. Razón técnica, tal vez, incluso así, apenas, es un gran error en todo el mundo, y luego lo miras en IE y rompes y lloras.
Como esto es un desbordamiento de pila, te daré la respuesta de mi programador
semántica 101Primero eche un vistazo a este código y piense en lo que está mal aquí ...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
El problema, por supuesto, es que una bicicleta no es un automóvil. La clase de auto es una clase inapropiada para la instancia de bicicleta. El código está libre de errores, pero es semánticamente incorrecto. Se refleja pobremente en el programador.
semántica 102 Ahora aplique esto al marcado de documentos. Si su documento necesita presentar datos tabulares, entonces la etiqueta apropiada sería <table> . Sin embargo, si coloca la navegación en una tabla, está haciendo un uso incorrecto de la finalidad prevista del elemento <table> . En el segundo caso, no está presentando datos tabulares; está (mal) usando el elemento <table> para lograr un objetivo de presentación.
¿A quién le duele? Ninguno. ¿Quién se beneficia si usa el marcado semántico? Tú y tu reputación profesional. Ahora ve y haz lo correcto.
Además de ser fácilmente actualizable y compatible ...
Utilizo para diseñar todos los sitios web basados en tablas y al principio me resistí, pero poco a poco me mudé a CSS. No sucedió de la noche a la mañana, pero sucedió y es algo que debes hacer también.
Hubo algunas noches en las que quise tirar mi computadora por la ventana porque el estilo que estaba aplicando a un div no estaba haciendo lo que quería, pero aprendes de esos obstáculos.
En cuanto a una empresa, una vez que se llega al diseño de sitios web mediante CSS hasta una ciencia, puede desarrollar procesos para cada sitio e incluso utilizar sitios web anteriores y simplemente agregar un gráfico de encabezado diferente, color, etc.
Además, asegúrese de incluir / incluir todas las partes reutilizables de su sitio web: encabezado, subtítulo, pie de página.
Una vez que supere la joroba, todo será cuesta abajo desde allí. ¡Buena suerte!
La razón principal por la que cambiamos nuestras páginas web al diseño basado en DIV / CSS fue la demora en la representación de páginas basadas en tablas.
Tenemos un sitio web público, con la mayoría de sus usuarios en países como India, donde el ancho de banda de Internet sigue siendo un problema (se mejora día a día, pero aún no a la par). En tales circunstancias, cuando utilizamos el diseño basado en tablas, los usuarios tenían que mirar una página en blanco durante un tiempo considerablemente largo. Luego, toda la página se mostrará como un todo en un tic. Al convertir nuestras páginas a DIV, logramos traer algunos contenidos al navegador casi de manera instantánea a medida que los usuarios ingresaban a nuestro sitio web, y esos contenidos eran suficientes para que los usuarios participaran hasta que el navegador descargara todo el contenido de la página.
El principal error con la implementación basada en tablas es que, en el navegador, mostraremos el contenido de la tabla solo después de que se descargue todo el html de esa tabla. El problema explotará cuando tengamos una tabla principal que envuelva todo el contenido de la página y cuando tengamos muchas tablas anidadas. Para las ''tablas flexibles'' (sin ancho fijo), después de descargar toda la etiqueta de la tabla, el navegador debe analizar hasta la última fila de la tabla para conocer el ancho de cada columna, luego debe volver a analizarla para mostrar el contenido . Hasta que todo esto suceda, los usuarios tienen que mirar fijamente una pantalla en blanco, luego todo aparecerá en la pantalla en un tic.
de hecho, puedo ver Tablas en Desbordamiento de pila en la página del usuario.
Incluso tiene montones de estilos en línea ...
En mi experiencia, la única vez que esto realmente agrega valor comercial es cuando hay una necesidad de un 100% de soporte para la accesibilidad. Cuando tiene usuarios con discapacidades visuales y / o usa lectores de pantalla para ver su sitio, debe asegurarse de que su sitio cumpla con los estándares de accesibilidad.
Los usuarios que usan lectores de pantalla tenderán a tener su propia hoja de estilos de gran contraste y gran contraste (si su sitio no proporciona uno) lo que facilita que los lectores de la página analicen la página.
Cuando un lector de pantalla lee una página y ve una tabla, le indicará al usuario que es una tabla. Por lo tanto, si utiliza una tabla para el diseño, se vuelve muy confuso porque el usuario no sabe que el contenido de la tabla es realmente el artículo en lugar de otros datos tabulares. Un menú debería ser una lista o una colección de divs, no una tabla con elementos de menú, de nuevo eso es confuso. Debe asegurarse de usar blockquotes, atributos de título de alt-tags, etc. para hacerlo más legible.
Si usted hace que su diseño sea guiado por CSS, entonces su aspecto y sensación pueden ser eliminados y reemplazados por una vista cruda que sea muy legible para esos usuarios. Si tiene estilos en línea, diseños basados en tablas, etc., entonces hará que sea más difícil para esos usuarios analizar su contenido.
Si bien creo que el mantenimiento es más fácil para algunas cosas cuando su sitio está diseñado exclusivamente con CSS, no creo que sea el caso para todo tipo de mantenimiento, especialmente cuando se trata de CSS entre navegadores, que obviamente puede ser una pesadilla
En resumen, su página debe describir su composición de una manera compatible con los estándares si desea que sea accesible para dichos usuarios. Si no tiene necesidad / requisito y probablemente no lo necesite en el futuro, entonces no se moleste en perder demasiado tiempo tratando de ser un purista de CSS :) Use la combinación de estilos y técnicas de diseño que más le convenga y haga su trabajo más fácil.
¡Aclamaciones!
[EDITAR - tachado agregado a partes equivocadas o engañosas de esta respuesta - ver comentarios]
Definitivamente es. Si todavía estás luchando por ello, no lo estás haciendo bien.
El diseño de DIV + CSS es en realidad mucho más fácil que el diseño de la tabla en términos de mantenibilidad y productividad. Solo sigue practicándolo antes de que sea demasiado temprano para decir eso.
El diseño de la mesa también es bueno, no está diseñado para diseños y tiene desventajas excepcionales cuando se trata de ajustes menores.
Si tiene un sitio web público, el caso comercial real es SEO.
La accesibilidad es importante y mantener la semántica (X) HTML es mucho más fácil que mantener los diseños de la tabla, pero ese n. ° 1 en Google traerá a casa el tocino.
Por ejemplo: Informe web mensual: 127 millones de visitas a la página para julio
Informe web mensual: 127 millones de visitas a la página de julio
...
Latimes.com sigue mejorando en SEO (optimización de motores de búsqueda), lo que significa que nuestras historias están en una posición más alta en Google y en otros motores de búsqueda. También nos estamos desempeñando mejor en sitios como Digg.com. Todo eso se suma a una mayor exposición y más lectores que nunca.
Si miras su sitio, tienen un diseño de CSS bastante decente.
Generalmente, usted encuentra relativamente pocos diseños de tablas funcionando bien en los SERP en estos días.