online - ¿Generas HTML bien formateado?
identar html (19)
El formato HTML depende en gran medida de la necesidad de legibilidad (y, por lo tanto, compatibilidad) frente a la optimización de la página.
Por ejemplo, si tiene controles que están generando una serie de tablas anidadas (como suele ser el caso con los controles .Net), entonces deberá asegurarse de que estén bien diseñados y bien formados para que pueda depurar cualquier problema de representación en el marcado. Esto incluiría sangría y espacios en blanco.
Sin embargo, si el tamaño de su página significaba que se enviaban muchos gráficos y / o etiquetas por el éter, la velocidad de carga de la página podría ser una preocupación mayor. En ese caso, sacrificaría marcas bonitas y ordenadas para HTML más compacto y tamaños de página reducidos. Esto sería especialmente cierto en los países que todavía tenían muchos usuarios con conexiones más lentas o acceso telefónico (como hacemos en Nueva Zelanda con un 40% todavía en acceso telefónico).
Yo diría que todo buen desarrollador web debería al menos considerar el diseño del HTML que está escribiendo. Al igual que los comentarios y la estructura del código es importante en el código detrás de las páginas, se debe realizar un esfuerzo rudimentario para mantener el HTML razonablemente ordenado también.
Cuando se utiliza alguna tecnología del lado del servidor que está produciendo HTML, ¿intenta formatear bien la salida? Por ejemplo, agregar saltos de línea y sangría?
¿Cuáles son los pros y los contras de cualquier estilo?
Estilísticamente, no. El código en mi archivo de plantilla y cualquier fragmento de HTML en mi código del lado del servidor están formateados muy bien cuando los escribo, pero no le presto mucha atención a cómo se ve el producto final una vez que todo se analiza en conjunto. Mientras valide, eso es suficiente para mí. La adición de límites de línea o pestañas explícitamente complica su código, lo que hace que las cosas sean un poco más difíciles de mantener.
Hice un marco en PHP en el que cada elemento era un "elemento", el resultado de lo cual era una gran estructura de árbol de elementos (al igual que la fuente HTML). Cuando se imprimió, el HTML se detectó al 100% y separado por líneas. Lo llamé "Pretty Print".
La moraleja de esta historia: nadie se dio cuenta, excepto yo.
Una ventaja es que facilita la depuración. Pero las herramientas de depuración de HTML de hoy en día (como FireBug) hacen el formateo por usted. Aparte de eso, la única otra ventaja es el orgullo.
Me aseguro de que mi HTML esté formateado correctamente en los archivos de plantilla. Esto permite una fácil edición del código y la depuración.
Sin embargo, para cuando los archivos se han ensamblado y enviado al navegador, la sangría puede irse de inmediato, esto no importa, ya que Firebug (y la barra de herramientas de desarrollador de IE, hasta cierto punto) es perfectamente buena en formatearlo para yo. Y cuando necesito ir y cambiar algo, el archivo que vengo para cambiarlo coincide con esa sangría y formato, ya que fue escrito muy bien.
Básicamente, hago todo lo que puedo para mantener mis trabajos y los de los demás fáciles, sin preocuparme demasiado por cómo el servidor realmente escupe mi código.
No soporto el código mal formateado, ya sea escrito por un ser humano o por una máquina. No puedo cambiar la forma en que otros escriben / generan su código, así que trato de hacer lo mejor que puedo por mi cuenta.
Por alguna razón, al leer esta pregunta, Haml viene a la mente. El lenguaje de plantillas Haml siempre tiene un buen formato de salida, simplemente no puede escribir las plantillas de otra manera o no funcionará. Para los desarrolladores de .net, ahora también existe el equivalente NHaml .
No estoy seguro de si esto es completamente relevante para su pregunta, pero en lo que respecta a las plantillas del lado del servidor, hace las cosas bastante bonitas.
Sí, en realidad soy EXTREMADAMENTE anal sobre esto.
PROS: Ver la fuente y hacer cambios es extremadamente simple. Al mostrar muestras de código, resulta extremadamente evidente que escribe sus propias cosas y no las "llama por teléfono" a través de Dreamweaver, etc. Menos "hinchazón" que los programas como Dreamweaver agregan.
CONTRAS: Se agregó el tamaño de archivo debido a los saltos de línea y tabulación, aunque he visto muy pocos sitios que tienen todo en una sola línea. Potencialmente hace que sea fácil para las personas codificar un bot para escanear y robar contenido.
Si estoy construyendo un sistema basado en web que tiene un prototipo construido por un diseñador antes de que comience la codificación, siempre uso el prototipo como plantilla, pero incluso lo limpio ...
Las herramientas de diseño tienden a tener una buena cantidad de código que puede simplificarse, eliminarse o optimizarse.
El resultado final es un HTML bien formateado, tanto por lo que genera mi plataforma de aplicaciones como por la plantilla creada para mis aplicaciones.
Tiendo a no molestarme. Dadas herramientas como DOM Inspector y Firebug de Firefox, que convierte tu HTML en un buen árbol colapsible, no veo sentido para hacer que el HTML en bruto tenga un buen formato. También ahorra unos pocos bytes en cada solicitud.
Tipo de en el medio.
Cuando genero cosas, el código para generarlo está muy bien formateado. Por lo tanto, la salida suele ser correcta. Cuando tengo que depurar algo, obtiene el tratamiento completo. Por supuesto, cuando algo no se procesa correctamente debido a problemas DOM / CSS, obtiene el tratamiento completo de inmediato, ya que a menudo la presencia de ausencia de espacio en blanco puede tener efectos impredecibles.
Una de las dos razones por las que no me entusiasma el desarrollo web es el hecho de que HTML siempre parece un generador de código que acaba de vomitar antes de explotar.
Todo lo que hago está formateado muy bien.
E xcepto
esta !!!!
Yo personalmente trato de usar las pestañas o espacios. Incluso escribo mi función de una manera que permite la cantidad de sangrado a veces. Creo que realmente ayuda con la legibilidad para depurar el marcado.
Cuando estoy reuniendo plantillas para un sitio, empiezo con todas ellas formateadas y sangradas hasta que lo hago bien, conservo una copia de ellas y luego las hago crujir, no hasta una sola línea, sino no muy lejos.
En términos generales, la audiencia de los sitios que realizo es del público en general, a los que realmente no les importa el código, les gustan los sitios web rápidos y, en la mayoría de los casos, mis clientes quieren que compren algo.
Cada byte cuesta dinero, no importa mucho en sitios pequeños, pero si algo se golpea millones de veces al mes, cada byte que puede recortar de cada respuesta hace la diferencia. Constantemente malgastar el ancho de banda para facilitar la depuración es una pérdida de dinero para mis clientes. El código de depuración no es un código de versión.
Si alguien quiere mirar debajo del capó, bueno y bueno, pueden pegarlo en algo que lo reformatee para ellos, o simplemente usar firebug.
Do you generate nicely formatted HTML?
Sí, sí, sí y sí. No hay absolutamente ninguna razón para crear un programa que emite código mal formateado, no le cuesta nada extra. *
Si necesita reducir el código, publique su salida a través de un compactador / ocultador / etc., pero siempre genere código de buena calidad, legible y formateado.
* EXCEPCIÓN: en situaciones de rendimiento extraordinariamente alto, tiene sentido producir directamente un código precomprimido, ofuscado, etc. En esos casos use debug define para agregar / eliminar el código de formato para que lo codifique como si estuviera formateado, y puede depurarlo como tal, pero puede eliminarlo en producción. Tenga en cuenta, sin embargo, que con el tiempo tendrá que depurar el código no formateado / comprimido / ofuscado, y eso será ... divertido ... para algunos valores de diversión ...
-Adán
Los archivos Javascript están comprimidos y no tienen un formato muy agradable (jQuery anyone) ?
Las imágenes no se distribuyen en un formato legible o en capas (photoshopm, pngs en capas)
Los archivos SWF están compilados.
Los archivos binarios no son fáciles de leer en un editor hexadecimal.
El código fuente HTML no debe ser leído por el cliente por el cliente. Está destinado a ser leído por una máquina e interpretado.
HTML es un conjunto de instrucciones. Si puedes compilarlo para que elimines todos los comentarios y comprimas los elementos
Como se mencionó anteriormente, NO tiene sentido el buen formato de HTML, a excepción de la depuración.
editar: por supuesto, no estoy diciendo que no comentes tu código / html en el lado del servidor. Los comentarios deben eliminarse del código PRODUCTION. Sirven poco o nada si tienes acceso a la fuente.
Si y no. :-)
El HTML generado está muy bien formateado, pero hay muchas posibilidades de que no lo veas. Hemos creado un "filtro de salida", si lo desea, en la clase base de la página (.NET). Se eliminan todos los espacios en blanco para disminuir el tamaño de la carga útil para la experiencia de descarga del usuario y para una iniciativa de ahorro de ancho de banda.
Formateado, sí. Agradable ... raramente.
Cada vez que he intentado hacer legible el código HTML generado, ha convertido el código de generación en un completo desastre. Todavía trato de hacerlo, pero se necesita un gran esfuerzo para hacerlo bien y siempre hay compromisos.
Si puedo dar un consejo aquí, nunca intente utilizar una API XML para HTML. Para empezar, puede parecer agradable, y probablemente pienses que configurar un solo booleano para sangrar todo tu código es genial, pero es un pozo de alquitrán de Turing. He probado todas las API enumeradas en el manual de PHP y cada vez que el proyecto terminó atascado en las funciones de envoltura.
Estoy empezando a preguntarme si es mejor dejar el HTML sin defectos ...
Estoy usando funciones de elementos de inspección en Firebug, Chrome y otros kits de herramientas para desarrolladores que muestran el código html en una estructura de árbol plegable, no solo una versión embellecida, así que ¿para qué molestarse? Además de embellecer, ayuda a encontrar errores de coincidencia de etiquetas al instante, porque el árbol no se poblaría en absoluto, si es que hay alguno. Personalmente, rara vez uso ''ver fuente''.
No peleo con el código si la salida no es bella ''gratis''. Si le cuesta solo el retorno del carro, puedo hacerlo. Si me cuesta refactorizar las líneas de código, simplemente lo dejo tal como está.
Cuando el código se refactoriza a cierto nivel, y veo los lugares donde naturalmente puede encajar una lógica de aprendizaje, y no me cuesta casi nada y solo entonces podría implementar alguna lógica de ''embellecimiento''.
Para mantener mi código HTML bien formateado sin agregar desorden al código donde se genera, simplemente descargo todo el resultado en un búfer de salida, y como último paso utilizo un formateador bastante optimizado para agregar una sangría correcta justo antes de mostrar el HTML.