¿CSS fácil de mantener o HTML liviano?

Question

Estoy a cargo de supervisar todo el lado de TI de un sitio web (infraestructura y desarrollo) y estoy teniendo una diferencia de opinión con el desarrollador de frontend líder. Su enfoque es crear clases individuales que cada uno aporta una funcionalidad, y combinar tantas clases como sea necesario con el estilo de un elemento:

HTML 
<div class="float_left padding_10 width_60_percent"></div> 
<div class="float_left width_30_percent"></div> 
<div class="float_left padding_10 width_10_percent"></div> 
CSS 
.float_left { float: left; } 
.padding_10 { padding: 10px; } 
.width_60_percent { width: 60%; } 
.width_30_percent { width: 30%; } 
.width_30_percent { width: 10%; } 

Pros:

- comprensión de CSS a través del HTML: usted puede entender lo que está haciendo el CSS simplemente mirando los nombres de las clases en el HTML.
- facilidad de creación: una vez que haya definido su conjunto de clases, solo se trata de combinarlas en el HTML, no tiene que escribir constantemente nuevas CSS.
- facilidad de mantenimiento: el mismo motivo que el anterior.
- portabilidad: puede utilizar el mismo enfoque para cualquier sitio web en el que trabaje (lo cual tiene sentido para él, ya que es un contratista que trabaja en diferentes proyectos).
- CSS más pequeño: siempre que su diseño alcance un cierto tamaño crítico mediante el cual las mismas clases se reutilizan una y otra vez (lo que sería el caso con un diseño adecuado, pero obviamente no se refleja anteriormente debido a la concisión del ejemplo).

Contras:

- grande HTML.
- HTML más difícil de leer si no está interesado en la parte de CSS (que mis desarrolladores de backend no crean).
- más difícil de integrar Javascript según los selectores de clase (estamos usando jQuery).

Mi enfoque no está dictado por la facilidad de escribir/mantener CSS, sino por la preocupación de que una parte sustancial de nuestro código HTML se utilizará únicamente con el propósito de integrar nuestro CSS, lo que afectará el rendimiento : Creo que es mejor tener un CSS más grande que se sirve y almacenar en caché una vez, y un HTML más pequeño que le ahorra ancho de banda en cada vista de página, en lugar de lo contrario. En consecuencia, yo optaría por el siguiente enfoque:

HTML 
<div id="column_left"></div> 
<div id="column_middle"></div> 
<div id="column_right"></div> 
CSS 
#column_left { float: left; padding: 10px; width: 60%; } 
#column_middle { float: left; width: 30%; } 
#column_right { float: left; padding: 10px; width: 10%; } 

Pros/Contras
opuesto como anteriormente.

tengo la sensación de que tener un código HTML ligero es fundamental para lograr el crecimiento de su sitio web:
carga -página será más rápido que ayudará con SEO y experiencia de usuario.
-más páginas se pueden servir con el mismo ancho de banda que le ahorrará costos de infraestructura.

En un intento por obtener una respuesta de facto, escaneamos sitios web "grandes" para ver qué parte de HTML se asignaba al uso de identificadores y clases.Aquí está el código:

<?php 
require_once 'simple_html_dom.php'; 
$pages = array('http://www.amazon.com', 'http://www.ebay.com', 'mywebsite.html', 'http://stackoverflow.com','facebook.html'); 
foreach ($pages as $page) { 
    echo "\n$page\n"; 
    $html = new simple_html_dom(); 
    $string = file_get_contents($page); 
    $total = mb_strlen($string); 
    echo "HTML = " . $total . " characters\n"; 
    $html->load($string); 
    foreach (array('id', 'class') as $attribute) { 
     $count = 0; 
     $elements = $html->find("*[$attribute]"); 
     foreach ($elements as $element) { 
      // length of id or classes, + id="..." or class="..." 
      $count = $count + mb_strlen($element->$attribute) + mb_strlen($attribute) + 3; 
      //echo $element->$attribute . "\n"; 
     } 
     echo " -from $attribute attributes = $count -> " . round($count/$total * 100) . "%\n"; 
    } 
} 

y aquí están los resultados:

http://www.amazon.com 
HTML = 101680 characters 
    -from id attributes = 943 -> 1% 
    -from class attributes = 6933 -> 7% 

http://www.ebay.com 
HTML = 71022 characters 
    -from id attributes = 1631 -> 2% 
    -from class attributes = 4689 -> 7% 

ourwebsite.html 
HTML = 35929 characters 
    -from id attributes = 754 -> 2% 
    -from class attributes = 2607 -> 7% 

http://www.imdb.com/ 
HTML = 74178 characters 
    -from id attributes = 1078 -> 1% 
    -from class attributes = 5653 -> 8% 

http://stackoverflow.com 
HTML = 204169 characters 
    -from id attributes = 3376 -> 2% 
    -from class attributes = 39015 -> 19% 

facebook.html 
HTML = 419001 characters 
    -from id attributes = 6871 -> 2% 
    -from class attributes = 85016 -> 20% 

Hasta ahora hemos estado usando "mi" enfoque y estoy feliz de ver que estamos manteniendo los porcentajes de código relacionado con los atributos de la clase id and` en las mismas proporciones que otros sitios web grandes (alrededor del 2% y 7%, respectivamente). No obstante, a fin de validar que elegir, me gustaría hacer las siguientes preguntas que espero desarrolladores experimentados/webmasters podrán responder:

P1: ¿Ves otras ventajas/desventajas a favor/en contra de cualquiera de las 2 enfoques?

Q2: Desde su experiencia, ¿es tan crítica que preocuparse de tener un código HTML ligero, o no esto se convierta despreciable con el uso de la compresión y otros criterios (por ejemplo, va a gastar más dinero luchando con sus desarrolladores frontend)?

Al observar los resultados, se verá que parece que hay un patrón en la cantidad de código relacionado con los id y class atributos (aunque sé escanear más páginas web proporcionaría una imagen más precisa):
-todos los sitios web tienen alrededor de 1% a 2% de su código HTML relacionado con los atributos id.
-4 de los sitios web tienen alrededor del 7% de su código HTML relacionado con classes.
-los otros tienen alrededor del 20% de su código HTML relacionado con classes.

Q3: ¿Hay alguna explicación técnica (por ejemplo, Facebook y Stackoverflow usando los mismos marcos para generar su CSS) para estos patrones?

Answer 1

soy un desarrollador de la aplicación acerca de un proyecto de software web corporativa, con cerca de 50 personas de escribir código, la mayoría de ellos backend. Inicialmente, acordé con tener el menor número de clases posible para hacer que el código sea más claro, usando mucha herencia en el CSS. Así que hemos estado usando el enfoque de "pocas clases como sea posible".

A1: Con el enfoque de algunas clases, un montón de definiciones CSS van a utilizar los nombres de elementos a añadir estilo, algo así como .left-column section li aesto hace la vida más fácil para los desarrolladores, pero en realidad hace que el css lento, como CSS se analiza desde De derecha a izquierda. En mi ejemplo, el navegador primero verifica todos los enlaces, luego todos los elementos de la lista, y así sucesivamente. Si tuviera a.lc-link, el css sería más rápido de usar y tendría menos elementos para buscar.

Otro problema con el que nos encontramos es la falta de modularidad. Puedo diseñar un buen elemento, llamémoslo .flight-dates y funciona genial. Luego aparece un nuevo caso de uso y alguien quiere utilizarlo en el medio de un formulario, no como un módulo de página principal. Pero el formulario fue creado para usar una sola clase en la etiqueta de formulario y todo lo demás usa herencia. Toda la herencia contamina las fechas de vuelo, así que necesito volver y agregar mayor especificidad al CSS, por lo que todos los estilos de fechas de vuelo tienen una definición adicional para cuando son hijos del formulario.

Ese tipo de cosas suceden 3 o 4 veces a la semana. Menos clases = menos flexibilidad + hojas de estilo feas con especificidad muy alta, es lo que me he quitado de ella.

A2: Con la cantidad de Javascript sucediendo en las páginas, la cantidad de clases que se utilizan actualmente es casi irrelevante. No hace ninguna diferencia en las velocidades de manipulación de DOM de las que soy consciente. Así que ya hemos perdido cualquier ventaja que podamos haber obtenido del enfoque de pocas clases.

Con referencia a sus pruebas, recuerde, descargando css y analizando css no son lo mismo.

Además, las enmiendas css mencionadas anteriormente han hecho que las cosas sean más lentas para los desarrolladores backend y frontend. Debido a que tratamos de utilizar el menor número posible de clases para hacer las cosas más fáciles para el back-end, los backend tienen componentes que lloran como un bebé si los pones en un nuevo contexto, y frontend tienen que cambiar CSS que escribieron hace 6 meses. Personalmente he perdido semanas.

Yo diría que ha hecho que el trabajo sea más lento, y no hay una ventaja en rendimiento que valga la pena mencionar.

A3: Cosas como Sass y Less tienden a conducir a patrones comunes en css. Además, muchas redes buenas y marcos de CSS relacionados usan nombres de clases comunes. Piensa jQuery ui o 960 grids.

Si quiere aprender de nuestro error, escuche a su interlocutor. La gente de tu backend estará más feliz porque los componentes siempre se comportarán de la manera que ellos esperan. La gente de tu frontend estará más contenta porque podrán escribir robustos y fáciles de olvidar que no tendrán que recurrir a nuevos casos de uso cada vez que aparezcan. Su html será un poco más grande, pero sinceramente la diferencia será insignificante, no creo que vaya a causar ningún cuello de botella significativo. Tu css se ejecutará más rápido. En última instancia, el trabajo llevará menos tiempo.

Answer 2

Lo que hace su desarrollador frontend se llama css orientado a objetos (OOCSS), que algunos creen que puede ser beneficioso para la velocidad de su sitio.

No me siento como un refrito de los argumentos a favor de OOCSS aquí, por lo que acaba de leer este FAQ:

https://github.com/stubbornella/oocss/wiki/faq

Editar: Yo prefiero errar por el lado de facebook/pila de Amazon/ebay cuando se trata de estándares de codificación. Observe que los sitios más progresivos (fb/stack) parecen tener porcentajes de clase más altos.

Answer 3

Vi un artículo recientemente de Google aparentemente alentando el enfoque de oocss, sin embargo, casi con certeza crea html y css más grandes, que realmente importan en sitios más grandes.

Nunca he conocido a un desarrollador que use oocss, lo que me haría sugerir que si el sitio está siendo trabajado por otros desarrolladores, o lo será en el futuro, puede ser mejor adoptar un enfoque que más los desarrolladores siguen