# In·directions

> [en] Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for ==abstracting== that value into a name that better describes the intention of the value in the design.
>
> <cite>*[Naming Variables In CSS](https://jwdallas.com/posts/namingcssvariables/)*</cite>

Je me demande souvent quel est le bon niveau hiérarchique au sein des CSS modernes. L’approche constatée actuelle semble être de mettre des variables par couleur (par exemple) puis ensuite définir des variables intermédiaires pour leur donner un sens pour un contexte donné.

```
:root {
  --umap-color-darkBlue: #263B58;
}
button {
  --color-primary: var(--umap-color-darkBlue);
}
button.primary {
  background-color: var(--color-primary);
}
```

Il s’agit ici de partir d’un exemple simpliste mais concret. J’imagine qu’il y a autant de dévelopeur·euse que de façon d’écrire ces 3 seules déclarations :). Pourquoi `:root` et pas `html` ? Est-ce qu’il faut définir les couleurs primaires sur le `button` ou sur `form, nav` ? Ou faire sauter cet intermédiaire ? Est-ce qu’il faut `button.primary`, `.primary`, `.button-primary`, `.button.button-primary` ? Etc, etc.

Et je ne mentionne même pas les solutions à partir de `:host` / `:host-context()` ou `:scope` qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir populaires.

Venant d’un langage dont l’[un des mantras](https://en.wikipedia.org/wiki/Zen_of_Python) est <q lang="en">There should be one-- and preferably only one --obvious way to do it.</q>, il est plus difficile de se retrouver devant une telle… flexibilité ? Lorsqu’on envisage un commun sur ces 10 prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec enthousiasme ?

Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du tout.

> [en] To keep up with the ever-evolving CSS standard Tailwind introduced another set of language literals. Over the years Tailwind has grown from a simple set of atoms to a ==vendor-specific== language with expressions, operators, and method calls.
>
> <cite>*[Tailwind marketing and misinformation engine](https://nuejs.org/blog/tailwind-misinformation-engine/)*</cite>

---

> [en] *File over app* is a philosophy: if you want to create digital artifacts that last, they must be files you can control, in formats that are easy to retrieve and read. ==Use tools that give you this freedom.==
>
> *File over app* is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their data.
>
> <cite>*[File over app - Steph Ango](https://stephango.com/file-over-app)*</cite>

---

> [en] Learn about the systems that already exist, and build on them rather than around them. If an existing system doesn’t do what you want, maybe the problem is in the design of your system, not that one.
>
> If you do build a new component, make sure it’s of general utility. Don’t build infrastructure that solves only the problems of your own team.
>
> It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. ==But the costs accumulate and you lose in the long run.==
> 
> <cite>*[command center: Simplicity](https://commandcenter.blogspot.com/2023/12/simplicity.html)*</cite>

#commun #dépendance #technique