La creación de Atomic CSS: una entrevista con Thierry Koblenz trucos CSS

Entrevisté Thierry Coblenzacreador de CSS atómicopara comprender la historia y los antecedentes que llevaron a la creación del popular marco CSS. Thierry, ahora jubilado, tiene una amplia experiencia en la escritura de CSS a gran escala y anteriormente trabajó como ingeniero senior en Yahoo!.

Retrocediendo años hasta principios de la década de 2000, ¿cómo te involucraste en el desarrollo web, especialmente en la escritura de CSS, para ganarte la vida?

Thierry Coblenza: Aprendí por mi cuenta HTML, CSS y JavaScript como pasatiempo después de mudarme a los Estados Unidos en 1997.

En ese momento, usaba FrontPage y dependía en gran medida de los grupos de orientación. Rápidamente me convertí en un habitual de Macromedia NewsGroups y en CSS-DiscutirAl principio, apoyé la filosofía de proyecto estándar web y yo estaba muy interesado en la accesibilidad. Durante años, el front-end no era más que un pasatiempo para mí (mi verdadero trabajo era un comerciante de antigüedades). De vez en cuando creaba un sitio web, pero sobre todo escribía y publicaba (muchos) artículos, compartiendo técnicas que había aprendido o "descubierto".

Esto valió la pena en forma de una llamada telefónica de Yahoo! en 2007, cuando me preguntó si podía ayudarlo a corregir y crear hojas de estilo para Yahoo! Soluciones del sitio (YSS). Descripción del trabajo: ¡sin HTML, sin JavaScript, solo CSS! ¡Y mucho de ello!

¿Cómo fue tu trabajo diario en Yahoo!?

conocimientos tradicionales: Mi papel en Yahoo! ha cambiado mucho a lo largo de los años.

Mi primer trabajo fue crear hojas de estilo (a la CSS Jardín Zen) para la plantilla YSS. Luego reescribí las marcas y los estilos en el sitio web de YSS justo antes de que se "enviara" el YSS a Bangalore, India, donde me enviaron con mis colegas con fines de "transferencia de conocimientos".

Como nota al margen, el desafío de intercambiar hojas de estilo para crear diferentes diseños para YSS nos obligó a encontrar ligero (no js) solución para cambiar el tamaño de videos sobre la marcha; y asi lo invente "Creación de relaciones internas de video".

Después de YSS tuve la oportunidad de trabajar solo en proyectos iniciados. desde cero (reescrituras o no) y se comprometió cada vez más con Yahoo! FE. Edité y creé muchos documentos internos (es decir, estándares de codificación CSS), participé en el proceso de contratación (como todos los demás en mi equipo), lideré sesiones de revisión de código; dirige clases y seminarios de CSS; habla en la FED de Londres; ayuda a otros equipos con HTML/CSS/accesibilidad; Participa en las decisiones sobre la adopción de tecnología (es decir, Bootstrap o no Bootstrap); crea bibliotecas; revisa documentos internos; escribe sugerencias; etc

Otra nota, durante mis ocho años en Yahoo!, es posible que haya escrito menos de 100 líneas de JavaScript. Y si no renuncié o me despidieron, es gracias Lingyang Zhu y Renato Ivashima; me ayudaron incansablemente a la hora de configurar mi entorno o trabajar con la línea de comandos (porque todavía tengo miedo de eso).

¿Cuáles eran las prácticas populares de escritura de CSS que prevalecían en ese momento?

conocimientos tradicionales: En los primeros días, no había bibliotecas ni metodologías publicadas; era el salvaje oeste, todo iba: clases "no semánticas", identificadores, hacks CSS, comentarios condicionales, frames, expresiones CSS, "JS sniffing", diseño principalmente para Internet Explorer, etc. Incluso tenía este comentario en mi antiguo sitio web:

<!--MSIE5 Mac needs this comment -->

Todo fue juego limpio y todo fue mal utilizado, ya que teníamos un conjunto muy limitado de herramientas con el requisito de hacer mucho.

Pero las cosas cambiaron radicalmente cuando me uní a Yahoo!. Los desarrolladores del Reino Unido han apoyado firmemente los estándares web y admito que han tenido un gran impacto en la forma en que se escriben HTML y CSS en Yahoo! El etiquetado semántico era una realidad, y CSS se escribió siguiendo el principio de dividir la preocupación (SoC) en "T" (que, sin embargo, a veces era demasiado entusiasta para mí).

YUI había componentes CSS, pero todavía no había un marco CSS. Había una biblioteca CSS interna (llamada Lego), pero nunca tuve que usarla. Metodologías y bibliotecas como OOCSS, SMACSS, ECSS (llame al ben), BEM, Bootstrap, Pure y otros vendrán poco después.

¿Qué llevó a la idea de Atomic CSS?

conocimientos tradicionales: Antes de que el YSS se trasladara a la India, mi gerente, miguel montesanopreguntó si había alguna forma de que el nuevo equipo de Bangalore evitara la necesidad de editar la hoja de estilo y, por lo tanto, reduciendo el riesgo de roturaSupongo que la experiencia con las plantillas de YSS (clientes que pagan quejándose de las páginas rotas) lo volvió bastante paranoico a la hora de cambiar la hoja de estilo.

Así que creé una "hoja útil" en el espíritu de la mía. ez-css biblioteca - una hoja diseñada para permitir a los desarrolladores lograr su estilo sin tener que editar o agregar reglas a una hoja de estilo.

Unos años más tarde, Michael, entonces director de ingeniería, me preguntó si podía volver a trabajar en Yahoo! Página principal uso de clases útiles solosabiendo que nuevamente no seremos responsables del mantenimiento del sitio web. Hablamos de priorizar las clases útiles encima clases semánticas, algo que no creo que existiera a ese nivel en ese momento. Fue un movimiento muy audaz.

Este ejercicio a gran escala se convirtió rápidamente en evidencia de un concepto que mostraba los muchos beneficios del estilo. marcandoMarcó tantas casillas que se decidió usar esta hoja de estilo "estática" (llamada Stencil) para rediseñar Yahoo! Mi página de inicio.

¿Cuáles fueron las pautas para diseñar Atomic CSS (ACSS) y quiénes fueron las personas involucradas?

conocimientos tradicionales: Nuestra biblioteca estática Stencil fue una gran herramienta para imponer/reforzar el estilo de diseño, lo cual pensamos que Yahoo! percibirá en todas sus propiedades. Rápidamente nos dimos cuenta de que esto no sucedería. Cada Yahoo! tenía la suya vemos cuál es el tamaño de fuente ideal, el margen ideal, etc. y constantemente recibíamos solicitudes para agregar estilos muy específicos a la biblioteca.

Esta situación no era compatible, por lo que decidimos crear una herramienta que permitiera a los desarrolladores crear sus propios estilos sobre la marcharespetando la naturaleza atómica del método del autor. Y así es como Pulverizador Dejamos de preocuparnos por agregar estilos (declaraciones CSS) y, en cambio, nos enfocamos en crear un vocabulario rico para brindar a los desarrolladores una amplia gama de estilos, como consultas de medios, selectores descendientes y pseudoclases, entre otras cosas.

S ACSSlos desarrolladores eran libres de usar lo que quisieran; por lo tanto, los equipos podrían adoptar diferentes estilos de diseño y guías de estilo mientras usan la misma biblioteca. Y hubo algunos beneficios inmediatos que eran nuevos en la forma en que los desarrolladores estaban acostumbrados a escribir estilos. Ya no tenían que preocuparse por romper la página con su estilo o preocuparse por escribir selectores para estilizar sus componentes.

ACSS se creó principalmente para tratar con Yahoo! y trabajar en medio de Yahoo!.

Las personas asociadas con Atomic CSS fueron Renato Ivashima, Steve Carlson y yoRenato y Steve crearon Pulverizador.

¿Qué conceptos erróneos tiene la gente sobre CSS cuando no escriben CSS para las grandes empresas?

conocimientos tradicionales: Cuando me uní a Yahoo! en 2007, aprendí rápidamente cuán vasta puede ser la base de código. Había equipos trabajando en muchos lugares/zonas horarias; innumerables productos; cientos de componentes compartidos; código de terceros; estrategias de pruebas A/B; escalado como requisito; diferentes direcciones de guión; localización e internacionalización; diferentes ciclos de lanzamiento; complejos mecanismos de implementación; toneladas de métricas; patrimonio de todo tipo; estrictos estándares de codificación; procesos de construcción; política; y más política; etc

La mayor parte de esto era completamente nuevo para mí y tenía que aprender si algo de esto podría afectar la forma en que escribo CSS y cómo. Empecé a reconsiderar y desafiar todas mis creencias, ya que muchas técnicas o métodos que eran una práctica común para mí parecían inadecuados o al menos contraproducentes para aplicaciones complejas.

Un "control de la realidad" se refiere a la abstracción del estilo. Todos hemos leído artículos que dicen que mapear M-10 clase a margin: 10px no fue una buena idea porque significaba editar tanto HTML como CSS para cambiar el estilo. Desafortunadamente, esto sucede en proyectos grandes/complejos:

• Diseñador: desear 15px brecha
• Desarrollador: Vale eso es todo M-3x (5px aumentar)
• Diseñador: Por supuesto, ¡cualquier cosa!
• Desarrollador: ¡Hecho!
• Diseñador: De hecho, 15px es un poco demasiado grande, ¿puedes hacerlo? 12px?
• Desarrollador: No, tampoco tenemos eso. 10px o 15px.
• Diseñador: Lo siento, eso no funciona para mí. ¿Podemos cambiar? M-3x ser - estar 12px?
• Desarrollador: No, no podemos hacer eso porque los otros equipos están esperando. M-3x ser - estar 15px.
• Diseñador: De acuerdo, trata de encontrar una manera, porque queremos que el margen sea 12px. 15px es demasiado y 10px es muy poco
• Desarrollador: (¡Mierda!)

Para anticipar tal problema, uno debe entender la intención del diseñador detrás de su solicitud: si el estilo fue elegido por su abstracción, p. color primario, o por su valor específico, p. 15px en nuestro M-3x Si existe una guía de estilo para hacer cumplir los principios de diseño, entonces clases como M-3x puede estar bien, pero si los equipos de diseño pueden preguntar cualquier estilo quieren, entonces es mucho más seguro mantenerse alejado de las convenciones de nombres que conducirán a un estilo ambiguo. En mi experiencia, todo lo ambiguo conduce, tarde o temprano, a las fracturas.

Confiar en la estructura de un documento o componente para su estilo, a través de combinadores como > o + - suena como un enfoque puro para crear una hoja de estilo, pero ignora el hecho de que en un entorno complejo no se puede asumir que una marca o construcción en particular es inmutable.

Crees z-index es complicado Piénselo de nuevo cuando ni siquiera tenga el rango de la pila en la que vive su componente. Este es uno de los problemas más difíciles de resolver en un proyecto grande, donde los equipos son responsables de diferentes partes de la página. escribí una vez propuesta para eso.

Criadores calificados - Me gusta input.required contra. .input.required - puede parecer bueno y semántico, pero crea un nivel innecesario de especificidad - como 0.1.1 frente a 0.2.0 - e impide el cambio de marcado; dos cosas que puede evitar fácilmente asegurándose de no cumplir con los requisitos de su selector.

Confiando en el selector universal, *para estilizar el alcance global? En un proyecto muy grande, esto puede significar que está estilizando el componente de otra persona. No tome decisiones de estilo para las personas a menos que conozca sus requisitos.

Estoy seguro de que ha leído que los identificadores son malos y que la especificidad es mala, pero de hecho, una alta especificidad no es un problema tan grande como la cantidad de niveles de especificidad que crean sus reglas. Es mucho más fácil diseñar en un entorno donde solo hay dos o tres niveles, como 1.1.0, 0.1.0, 0.2.0, en lugar de un entorno donde la especificidad es bastante baja, pero sigue un "gratis para todos". " enfoque. - como 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, etc. - que a menudo se presenta como un mecanismo de defensa en grandes proyectos como una herramienta para los estilos de piedra arenisca.

Seguir ciegamente los consejos de la comunidad CSS puede llevarte a sorpresas desagradables. Nunca recurra a nuevas técnicas que aún no han sido probadas. will-change? Y siempre sepa qué hace o puede desencadenar cualquier estilo que use. Por ejemplo, position puede crear un contexto de apilamiento y un bloque contenedor mientras overflow puede crear un contexto de formato de bloque.

En mi experiencia, conocer CSS de adentro hacia afuera no es suficiente para escribir CSS de manera efectiva para una gran organización. Durante mi mandato en Yahoo!, a menudo me encontré en desacuerdo con las personas que conocí hace años. El ambiente es brutal y hay que ser muy pragmático para evitar muchos escollos. La próxima vez que mire el código fuente de un gran proyecto y vea algo que no tiene sentido para usted, recuerde esto Pío por Nicolás Zacas:

En lugar de aceptar que las personas son estúpidas, ignorantes y cometen errores, acepta que son inteligentes, dan lo mejor de sí y carecen de contexto.

- Nicolás C. Zacas (@slicknet) 10 de febrero de 2013

¿Cómo fue Yahoo! al CSS atómico?

conocimientos tradicionales: ACSS fue bien recibido por nuestro equipo de My Home Page, pero no funcionó bien. Nuestra primera interacción fue con un equipo deportivo con sede en Santa Mónica. Steve y yo estábamos en una conferencia telefónica tratando de convencer a los desarrolladores de que no seguir el principio de compartir preocupaciones es el camino a seguir y que no creará caos.

Los dirigimos a una pieza que Nicolás Gallagher Hace poco escribí, pensando que un artículo de un "forastero" ayudaría, ¡pero no! Las cosas no iban bien y había mucha fricción. El principal problema era el hecho de que la biblioteca estaba compuesta de clases útiles, pero sintaxis no ayudó a facilitar la conversación.

También recuerdo haberme reunido con el equipo de Mail, quienes no rechazaron la idea de Atomic CSS, pero querían idear su propio enfoque de JavaScript para usar declaraciones CSS "simples", porque no pudo resistir sintaxis ACSS. En todo caso, datos a favor de la biblioteca (~ 36% menos CSS y HTML) habló por sí mismo, por lo que finalmente se adoptó el ACSS. Y hoy, más de siete años después, la página de inicio de Yahoo!, Yahoo! Deportes, Yahoo! Noticias, Yahoo! Finanzas y otros Yahoo! todavía usa ACSS.

Para comprender mejor cómo un enfoque como ACSS puede beneficiar proyectos donde la reutilización de componentes es primordial, copie marcar un componente de yahoo! Finanzas y ponlo dentro yahoo! NoticiasEste componente debería verse como si perteneciera a la página. Esto se debe a que ACSS hace que estos componentes sean independientes de la página.

¿Cómo surgió la idea de usar corchetes para los nombres de las clases? ¿La sintaxis está inspirada en la forma en que se escriben las funciones?

conocimientos tradicionales: Habíamos identificado, a través de muchas iteraciones, dos conjuntos de "candidatos" para usar como delimitadores de valores de propiedad: paréntesis, ()y corchetes, [].

Renato recuerda que elegimos paréntesis en lugar de paréntesis debido a la familiaridad con las funciones de JavaScript, incluso si era el costo adicional Shift ACSS sintaxis Esta diseñado para:

• facilita la generación automática de reglas a través de Pulverizador
• permitir a los desarrolladores crear los estilos aleatorios o complejos que deseen
• reduciendo la curva de aprendizaje al mínimo

Se parece a eso:

[<context>[:<pseudo-class>]<combinator>]<Style>[(<value>,<value>?,...)][<!>][:<pseudo-class>][::<pseudo-element>][--<breakpoint_identifier>]

Los desarrolladores construyen sus clases siguiendo la construcción anterior. La sintaxis básica se basa en Emmettherramientas populares. Adoptamos el enfoque de Emmet para reducir las idiosincrasias, ya que las clases principales son pares explícitos de propiedad/valor, no arbitrario instrumentos de cuerda.

También creamos una docena asistente clases Aplican múltiples declaraciones de estilo y son atajos, como ocultar contenido de los usuarios videntes, o trucos, como usar .Cf para clearfix. Y les hemos dado a los desarrolladores aún más margen de maniobra mediante el uso de un archivo de configuración en el que pueden crear variables, como .PrimaryColor - puntos de interrupción y muchos otros.

Las personas que nunca han trabajado con ACSS le dirán que la sintaxis es demasiado extraña (en el mejor de los casos), pero las personas familiarizadas con ella le dirán que es inteligente en muchos sentidos.

Hable acerca de cómo surgió su artículo "Mejores prácticas de CSS desafiantes" para la revista Smashing.

conocimientos tradicionales: Había escrito muchos artículos en varias publicaciones en línea antes, por lo que era natural escribir un artículo sobre este enfoque "desafiante".

yahoo! patrocinó una conferencia de interfaz en octubre de 2013, donde Renato tenía una conversación programada para presentar nuestra solución, y yo había intentado publicar el artículo antes. Elegí no publicarlo en la red de desarrolladores de Yahoo!, ya que el sitio web no ofrece una sección de comentarios. A List Apart no pudo publicarlo a tiempo, pero Smashing Magazine aceleró el proceso de revisión para que pudiera publicar la canción antes de finales de octubre.

Mi elección de ir a un editor que tenía una sección de comentarios valió la pena, ya que el artículo recibió más de 200 comentarios, lo que resultó ser una pérdida de tiempo y una decepción para mí, que tenía que responder.

¿Le parece extraño que el artículo aún se exima de responsabilidad por las técnicas discutidas, aunque ahora es muy popular en la industria?

conocimientos tradicionales: Cuando se publicó el artículo, le dije a Vitaly [Friedman, Smashing Magazine co-founder] que este comentario me sonó como una especie de descargo de responsabilidad; que sacudirá a la gente mientras lee el artículo. Pero realmente no retrocedí, porque sabía de dónde venía Vitaly. Me parece divertida esta nota. aún existe, esta metodología se ha generalizado.

Dado que la fecha anterior es 20/20, ¿hay algo que desee cambiar sobre Atomic CSS?

conocimientos tradicionales: Siempre hay espacio para mejorar, especialmente cuando eres un pionero en la solución. No puedes mirar lo que otros han hecho para aprender de sus errores o deficiencias. No tienes material para mejorar. Entonces, sería pretencioso pensar que lo hicimos en nuestro primer intento.

Atomic CSS ha tenido mucha experiencia en el desarrollo y uso de una hoja de estilo "estática" en un gran proyecto durante más de un año. Pero el lado dinámico, el lado de las herramientas, no es como encontrar mucha inspiración. seis años seguir el ejemplo de otras bibliotecas.

En francés decimos: essuyer les pâtres.

Un error que cometimos fue usar Atomic CSS como título acss.ioporque, como señaló John Polachek, esto creó cierta confusión. Hemos cambiado ese título desde entonces.

Lo único que lamento es cómo la comunidad ha tratado a Atomic CSS/ACSS a lo largo de los años, lo que recientemente condujo a un extraño intercambio en el que alguien explícamelo ¿Qué significa "CSS atómico"?

Biblioteca CSS atómica [ACSS] usa el nombre, pero creo que es engañoso, porque la función de la que estás hablando es la generación de estilo dinámico. "CSS atómico" como término general se refiere a pequeños selectores como átomos, pero son estáticos.

Hablar de borrar. 😉

---

Muchas gracias a Thierry por participar en esta entrevista y permitirnos publicarla para la comunidad.