Tufte-css: Formato CSS

Elegí el estándar de formato utilizado en este proyecto porque no veo la necesidad de dar espacio a llaves abiertas o cerradas, y porque encuentro que el escalonamiento horizontal es una muleta visual / mental útil para diferenciar los bloques selectores.

Dado que la sangría "estándar" de CSS _disminuye_ la legibilidad para mí, el único valor agregado que veo para usarlo sería aumentar la coherencia del código con proyectos externos. Parte de la razón por la que no lo encuentro tremendamente convincente es que no paso mucho tiempo con CSS en otros proyectos, por lo que no tengo una sobrecarga mental involucrada en el cambio de contexto. ¿La falta de familiaridad es perjudicial para otras personas? ¿Hay otros beneficios de la sangría "estándar" que no veo?

En mi caso, convertí mucho de esto a SCSS para mi propio proyecto, y fue doloroso tener que reformatear todo al estándar. No recuerdo si fue solo para eliminar las advertencias o porque también causó errores. Cosas como anidar definitivamente requieren reformateo.

También me disuade de regresar para actualizaciones que de otra manera se fusionarían más fácilmente.

En un editor con softwrapping a 80 caracteres (lo cual es bastante normal), las partes con las consultas de medios se vuelven realmente desordenadas.

¡No es que quiera gemir! :) Todo el mundo tiene sus formas preferidas de formatear, solo para hacerle saber mi experiencia.

Saludos,

@ yb66 La conversión SCSS es una razón sustancial que no me vino a la mente.

... pero en una inspección más profunda, ¿las herramientas como http://csstoss.com/ no hacen esto sin dolor? ¿O incluso simplemente seleccionando todas las llaves abiertas, agregue una nueva línea después, luego seleccione todas las llaves cerradas, agregue una nueva línea antes y luego vuelva a sangrar el archivo?

También reconozco el problema de la envoltura blanda.

Creo que sería muy útil especificar un formato y proporcionar la especificación para una herramienta de linter / formateador determinada. Creo que apoyar una herramienta de este tipo y luego hacer cumplir su uso con cada compromiso combinado en realidad facilitaría que las personas realicen contribuciones y solicitudes de extracción. No creo que nadie quiera pasar su tiempo jugando con sangrías y llaves, cuando podría ejecutar un comando en el archivo *.css antes de comprometerse y terminar con él. Me es indiferente qué formato se elige, solo que puede satisfacerse ejecutando una herramienta de línea de comandos simple antes de realizar cambios.

Una opción es stylelint.io, pero también hay otras.

editar: gramática

Quiero decir, hemos tenido la sección CSS Style Guide en el README desde los días en que los dinosaurios vagaban por la tierra y las confirmaciones se enviaban por barco a través del Atlántico. Mi política para hacer cumplir ese estándar ha sido

1. espero que la gente se conforme
2. aceptar RP independientemente
3. coaccionar manualmente el código no conforme a la conformidad

Este proyecto tiene menos de 300 líneas. Respetuosamente, no veo la necesidad de introducir una dependencia de la herramienta de línea de comandos para automatizar el proceso de tomar 90 segundos para corregir las seis a ocho llaves que tienen la mayoría de los RP.

Es cierto que he sido lento al abordar los errores y las relaciones públicas, pero eso no se debe a problemas de estilo, se debe a la presión del tiempo externo y la complejidad de los cambios de prueba en muchos dispositivos y escenarios.

Mi punto original pretendido, que lamento no dejar más claro, es que el ojo se ve obligado a zigzaguear para leer el código.

Comparemos el formato actual con otras dos opciones A y B.

Actual:

.table-caption { float:right;
                 clear:right;
                 margin-right: -60%;
                 width: 50%;
                 margin-top: 0;
                 margin-bottom: 0;
                 font-size: 1.0rem;
                 line-height: 1.6; }

.sidenote-number { counter-increment: sidenote-counter; }

.sidenote-number:after, .sidenote:before { content: counter(sidenote-counter) " ";
                                           font-family: et-book-roman-old-style;
                                           position: relative;
                                           vertical-align: baseline; }

.sidenote-number:after { content: counter(sidenote-counter);
                         font-size: 1rem;
                         top: -0.5rem;
                         left: 0.1rem; }

.sidenote:before { content: counter(sidenote-counter) " ";
                   top: -0.5rem; }

blockquote .sidenote, blockquote .marginnote { margin-right: -82%;
                                               min-width: 59%;
                                               text-align: left; }    

p, footer, table, div.table-wrapper-small, div.supertable-wrapper > p, div.booktabs-wrapper { width: 55%; }

Opcion A

.table-caption               { float:right;
                               clear:right;
                               margin-right: -60%;
                               width: 50%;
                               margin-top: 0;
                               margin-bottom: 0;
                               font-size: 1.0rem;
                               line-height: 1.6; }

.sidenote-number             { counter-increment: sidenote-counter; }

.sidenote-number::after,
.sidenote::before            { content: counter(sidenote-counter) " ";
                               font-family: et-book-roman-old-style;
                               position: relative;
                               vertical-align: baseline; }

.sidenote-number::after      { content: counter(sidenote-counter);
                               font-size: 1rem;
                               top: -0.5rem;
                               left: 0.1rem; }

.sidenote::before            { content: counter(sidenote-counter) " ";
                               top: -0.5rem; }

blockquote .sidenote,
blockquote .marginnote       { margin-right: -82%;
                               min-width: 59%;
                               text-align: left; }    

p,
footer,
table,
div.table-wrapper-small,
div.supertable-wrapper > p,
div.booktabs-wrapper         { width: 55%; }

Opcion B:

.table-caption {
  float: right;
  clear: right;
  margin-right: -60%;
  width: 50%;
  margin-top: 0;
  margin-bottom: 0;
  font-size: 1.0rem;
  line-height: 1.6;
}

.sidenote-number {
  counter-increment: sidenote-counter;
}

.sidenote-number::after,
.sidenote::before {
  content: counter(sidenote-counter) " ";
  font-family: et-book-roman-old-style;
  position: relative;
  vertical-align: baseline;
}

.sidenote-number::after {
  content: counter(sidenote-counter);
  font-size: 1rem;
  top: -0.5rem;
  left: 0.1rem;
}

.sidenote::before {
  content: counter(sidenote-counter) " ";
  top: -0.5rem;
}

blockquote .sidenote,
blockquote .marginnote {
  margin-right: -82%;
  min-width: 59%;
  text-align: left;
}

p,
footer,
table,
div.table-wrapper-small,
div.supertable-wrapper > p,
div.booktabs-wrapper {
  width: 55%;
}

Habiendo escrito cientos de miles de líneas de CSS en mi vida, estoy más acostumbrado a leer la Opción B, pero puedo ver absolutamente que se está haciendo un caso para algo como la Opción A. Dicho esto, me cuesta ver cómo la Opción A no No sobrepasa el formato actual en legibilidad. Por supuesto, como señala, son <300 líneas, por lo que no es gran cosa de ninguna manera.

En este punto, me estoy inclinando hacia algo más convencional, para que sea más legible y esté en línea con las normas CSS en la comunidad en general. La opción B parece que será más reconocible para la gente.

Yo también optaría por la opción B. ¿No hay una manera de especificar un formato que sea legible por humanos y legible por máquina para varios formateadores / linters?

Finalmente llegué a esto. Gracias por plantear este problema Adam, y gracias a todos los demás por sumar sus dos centavos.

Por favor , si tiene un minuto, eche un vistazo a la confirmación (https://github.com/edwardtufte/tufte-css/commit/bfbe3b5c50ee450ba09122f1506233edf6a97ffe) y avíseme si A) cualquier sangría o declaraciones podrían estandarizarse más, o B) observa cambios en la implementación. (No he implementado ninguna forma de probar los cambios, excepto desplazarme manualmente por el documento de muestra).

Me parece bien, @daveliepmann. ¡Sé lo difícil que puede ser encontrar la energía para enfrentar viejos problemas como este, así que agradecemos mucho el esfuerzo! Estoy en el proceso de volver a publicar mi blog en un nuevo sitio, así que usaré estos cambios y les haré saber si encuentro algún problema.

@daveliepmann se ve genial. Muchas gracias por hacer esto.

@ yb66 ¿... tienes tu SCSS en alguna parte? ¿En github? Estoy usando una herramienta de correo electrónico que permite anular el estilo al mostrar partes de mime HTML y usa SCSS. Me encantaría usar Tufte para esto, y si alguien ya ha hecho una conversión SCSS, lo haría mucho más fácil.

@serussell ¿No es CSS SCSS válido?

@adamschwartz : encogiéndose de hombros: No se me ocurrió; No soy un desarrollador web. Pero parece que tienes razón: SCSS es un superconjunto de CSS. ¡Buenas noticias para todos!

¿Puedo sugerir también sugerir el uso de un linter! Stylelint se ilumina como si fuera Navidad cuando uso el CSS aquí. Si bien algunos de ellos son una cuestión de estilo, también hay muchas inconsistencias de las que podemos deshacernos fácilmente.