¿Son las propiedades personalizadas un “menú de lo que cambiará”?

PPK expuso una situación interesante en “Dos opciones para usar propiedades personalizadas”, donde él y Stefan Judis tenían dos enfoques diferentes para hacer lo mismo con propiedades personalizadas . En un enfoque, los estilos de desplazamiento y enfoque de un vínculo se manejan con dos propiedades personalizadas diferentes, una para cada estado. En el otro enfoque, se utiliza una única propiedad personalizada.

Dos propiedades personalizadas:

.component1 {  --linkcolor: red;  --hovercolor: blue;}.component2 {  --linkcolor: purple;  --hovercolor: cyan;}a {  color: var(--linkcolor);}a:hover,a:focus {  color: var(--hovercolor)}

Una propiedad personalizada:

.component1 a {  --componentcolor: red;}.component1 :is(a:hover,a:focus) {  --componentcolor: blue;}.component2 a {  --componentcolor: purple;}.component2 :is(a:hover,a:focus) {  --componentcolor: cyan;}a {  color: var(--componentcolor)}

Hay algo más natural en el uso de dos propiedades, como si fuera muy explícito lo que debe hacer una propiedad personalizada en particular. Pero hay mucha elegancia en el uso de una propiedad personalizada. No solo por el hecho de ser una propiedad personalizada menos, sino porque la propiedad personalizada coincide 1 a 1 con una sola propiedad.

Llevando esto un poco más allá, podrías configurar un único conjunto de reglas con una propiedad personalizada por propiedad, dándole una especie de menú sobre qué cosas cambiarán. A eso PPK dice:

Ahora esencialmente encontró un archivo de definición. No sólo ve los estilos predeterminados del componente, sino que también ve lo que podría cambiar y lo que no.

Es decir, usaría una propiedad personalizada para cualquier cosa que desee cambiar, y cualquier cosa que no lo haga, no lo haría. Sin duda, es un enfoque interesante que no culparía a nadie por intentarlo.

.lil-grid {  /* will change */  --padding: 1rem;  padding: var(--padding);  --grid-template-columns: 1fr 1fr 1fr;  grid-columns: var(--grid-template-columns);  /* won't change */  border: 1px solid #ccc;  gap: 1rem;}

Mi duda con esto es que es, en el mejor de los casos, una pista de lo que cambiará y lo que no. Por ejemplo, todavía puedo cambiar cosas aunque no estén configuradas en una propiedad personalizada. Más tarde podría hacer:

.lil-grid.two-up {  grid-columns: 1fr 1fr;}

Eso elimina el uso de la propiedad personalizada. De manera similar, nunca podría cambiar el valor de --grid-template-columns, lo que significa que parece que cambia en diferentes circunstancias, pero nunca lo hace.

De igual forma podría hacer:

.lil-grid.thick {  border-width: 3px;}

…y aunque el conjunto de reglas de mi componente original implica que el ancho del borde no cambia, sí lo hace con una clase modificadora.

Entonces, para que un enfoque como ese funcione, lo tratas como una convención a la que te atienes, como un estándar de codificación genérico. Aunque me preocuparía que se convierta en un dolor de cabeza. Para cualquier declaración que decida cambiar, debe regresar y refactorizarla para que sea o no una propiedad personalizada.

Esto me hace pensar en la “API de estilo implícita” que es HTML y CSS. Ya tenemos una API de estilo en los navegadores. HTML se convierte en DOM en el navegador y le damos estilo al DOM con CSS. Selecciona cosas, dale estilo.

Tal vez no necesitemos un menú para lo que puedes y no puedes diseñar porque eso es lo que ya son DOM y CSS. Eso no quiere decir que un conjunto bien elaborado de propiedades personalizadas no pueda ser parte de eso, pero no necesitan representar reglas estrictas sobre qué cambia y qué no.

Hablando de API de estilo implícitas, Jim Nielsen escribe en “Shadow DOM y su efecto en la API de estilo no oficial” :

[…] el DOM en la sombra rompe la API de estilo autodocumentante que hemos tenido en la web durante años.

¿Qué estilo de API? Si desea aplicar estilo a un elemento en la pantalla, abre las herramientas de desarrollo, mira el DOM, encuentra el elemento que desea, descubre el selector correcto para apuntar a ese elemento, escribe su selector y estilos, y listo.

Eso es bastante notable cuando te detienes y piensas en ello.

Supongo que ese es mi mayor problema con los componentes web. No me desagrada el Shadow DOM; de hecho, es probablemente mi aspecto favorito de los componentes web. Simplemente no me gusta tener que inventar una API de estilo para ellos (al estilo de las propiedades personalizadas que se mueven dentro, o ::part) en lugar de usar la API de estilo que nos ha servido desde siempre: DOM + CSS.