davidbgk
/
larlet-fr-david
Watch 1
Star 0
Fork 0
Code Releases 0 Activity
Browse Source

Article

master
David Larlet 2 months ago
parent
0f01e1947d
commit
a8e3a79c80
Signed by: David Larlet <david@larlet.fr> GPG Key ID: 3E2953A359E7E7BD
10 changed files with 960 additions and 43 deletions
Split View Show Diff Stats
  1. 8
    0
      david/2024/02/17/index.html
  2. 452
    0
      david/2024/02/18/index.html
  3. 51
    0
      david/2024/_sources/2024-02-18 - Indirections.md
  4. 126
    0
      david/2024/commun/index.html
  5. 126
    0
      david/2024/dependance/index.html
  6. 5
    4
      david/2024/index.html
  7. 126
    0
      david/2024/technique/index.html
  8. 4
    3
      david/index.html
  9. 50
    36
      david/log/index.xml
  10. 12
    0
      david/recherche/index.html

+ 8
- 0
david/2024/02/17/index.html View File

@@ -152,6 +152,10 @@
title="Aller à la page de recherche"
rel="search" data-no-instant>Recherche</a>
• <a rel="next"
href="/david/2024/02/18/"
title="Publication suivante : In·directions">Suivant →</a>
</p>
</nav>
@@ -195,6 +199,10 @@
<a href="/david/2024/" title="Liste des publications récentes">↑ En 2024</a>
• <a rel="next"
href="/david/2024/02/18/"
title="Publication suivante : In·directions">Suivant →</a>
</p>
</nav>


+ 452
- 0
david/2024/02/18/index.html View File

@@ -0,0 +1,452 @@
<!DOCTYPE html><!-- This is a valid HTML5 document. -->
<!-- Screen readers, SEO, extensions and so on. -->
<html lang="fr">
<!-- Has to be within the first 1024 bytes, hence before the `title` element
See: https://www.w3.org/TR/2012/CR-html5-20121217/document-metadata.html#charset -->
<meta charset="utf-8">
<!-- Why no `X-UA-Compatible` meta: https://stackoverflow.com/a/6771584 -->
<!-- The viewport meta is quite crowded and we are responsible for that.
See: https://codepen.io/tigt/post/meta-viewport-for-2015 -->
<meta name="viewport" content="width=device-width,initial-scale=1">
<!-- Required to make a valid HTML5 document. -->
<title>
In·directions
— David Larlet</title>
<meta name="description" content="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.">
<!-- That good ol' feed, subscribe :). -->
<link rel="alternate"
type="application/atom+xml"
title="Feed"
href="/david/log/">
<!-- Generated from https://realfavicongenerator.net/ such a mess. -->
<link rel="apple-touch-icon"
sizes="180x180"
href="/static/david/icons2/apple-touch-icon.png">
<link rel="icon"
type="image/png"
sizes="32x32"
href="/static/david/icons2/favicon-32x32.png">
<link rel="icon"
type="image/png"
sizes="16x16"
href="/static/david/icons2/favicon-16x16.png">
<link rel="manifest" href="/static/david/icons2/site.webmanifest">
<link rel="mask-icon"
href="/static/david/icons2/safari-pinned-tab.svg"
color="#07486c">
<link rel="shortcut icon" href="/static/david/icons2/favicon.ico">
<meta name="msapplication-TileColor" content="#f7f7f7">
<meta name="msapplication-config"
content="/static/david/icons2/browserconfig.xml">
<meta name="theme-color"
content="#f7f7f7"
media="(prefers-color-scheme: light)">
<meta name="theme-color"
content="#272727"
media="(prefers-color-scheme: dark)">
<!-- Is that even respected? Retrospectively? What a shAItshow…
https://neil-clarke.com/block-the-bots-that-feed-ai-models-by-scraping-your-website/ -->
<meta name="robots" content="noai, noimageai">
<!-- Documented, feel free to shoot an email. -->
<link rel="stylesheet" href="/static/david/css/style_2024-02-03.css">
<!-- See https://www.zachleat.com/web/comprehensive-webfonts/ for the trade-off. -->
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_a_regular.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)"
crossorigin>
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_a_bold.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)"
crossorigin>
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_a_italic.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: light), (prefers-color-scheme: no-preference)"
crossorigin>
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_b_regular.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: dark)"
crossorigin>
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_b_bold.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: dark)"
crossorigin>
<link rel="preload"
href="/static/david/css/fonts/century_supra_ot_b_italic.woff2"
as="font"
type="font/woff2"
media="(prefers-color-scheme: dark)"
crossorigin>
<script>
function toggleTheme(themeName) {
document.documentElement.classList.toggle(
'forced-dark',
themeName === 'dark'
)
document.documentElement.classList.toggle(
'forced-light',
themeName === 'light'
)
}
const selectedTheme = localStorage.getItem('theme')
if (selectedTheme !== 'undefined') {
toggleTheme(selectedTheme)
}
</script>
<style type="text/css">
.tippy-content {
min-width: 280px;
padding: .5rem;
font-size: calc(var(--fluid-0) * 0.8);
font-family: var(--labor-font);
letter-spacing: initial;
text-align: left;
}
.tippy-content h3 {
margin-top: 0;
}
.tippy-content h3 img {
max-width: 2rem;
max-height: 2rem;
display: inline-block;
}
.tippy-content .tippy-links {
display: flex;
justify-content: space-around;
}
.tippy-content a {
padding: .4rem;
color: #F06048;
}
</style>

<body data-instant-intensity="viewport-all">
<article>
<header>
<hgroup>
<h1>In·directions</h1>
<p>Le <time datetime="2024-02-18">18 février 2024</time></p>
</hgroup>
</header>
<nav>
<p>
<a rel="prev"
href="/david/2024/02/17/"
title="Publication précédente : Quotidien">← Précédent</a> •
<a href="/david/" title="Aller à l’accueil" rel="up">Accueil</a>
•
<a href="/david/recherche/"
title="Aller à la page de recherche"
rel="search" data-no-instant>Recherche</a>
</p>
</nav>

<blockquote lang="en">
<p>Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for <mark>abstracting</mark> that value into a name that better describes the intention of the value in the&nbsp;design.</p>
<p><cite><em><a data-link-domain="jwdallas.com" href="https://jwdallas.com/posts/namingcssvariables/" hreflang="en"
title="Consultation de l’article (anglais)">Naming Variables In CSS</a>
<a href="/david/cache/2024/d0ffe1891c332b6fc6e7d7826d8489da/" hreflang="en"
data-tippy data-description="Some collected thoughts around how to name variables in CSS. Ideas, conventions, and some do's and don't for consideration."
data-source="https://jwdallas.com/posts/namingcssvariables/"
data-date="2024-02-18"
data-favicon="https://jwdallas.com/icons/favicon.ico"
data-domain="jwdallas.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<p>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&nbsp;donné.</p>
<pre><code>:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
</code></pre>
<p>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&nbsp;seules déclarations&nbsp;:). Pourquoi <code>:root</code> et pas <code>html</code>&#8239;? Est-ce qu’il faut définir les couleurs primaires sur le <code>button</code> ou sur <code>form, nav</code>&#8239;? Ou faire sauter cet intermédiaire&#8239;? Est-ce qu’il faut <code>button.primary</code>, <code>.primary</code>, <code>.button-primary</code>, <code>.button.button-primary</code>&#8239;? Etc, etc.</p>
<p>Et je ne mentionne même pas les solutions à partir de <code>:host</code> / <code>:host-context()</code> ou <code>:scope</code> qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir&nbsp;populaires.</p>
<p>Venant d’un langage dont l’<a data-link-domain="en.wikipedia.org" href="https://en.wikipedia.org/wiki/Zen_of_Python">un des mantras</a> 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é&#8239;? Lorsqu’on envisage un commun sur ces 10&nbsp;prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec&nbsp;enthousiasme&#8239;?</p>
<p>Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du&nbsp;tout.</p>

<blockquote lang="en">
<p>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 <mark>vendor-specific</mark> language with expressions, operators, and method&nbsp;calls.</p>
<p><cite><em><a data-link-domain="nuejs.org" href="https://nuejs.org/blog/tailwind-misinformation-engine/" hreflang=""
title="Consultation de l’article">Tailwind marketing and misinformation engine</a>
<a href="/david/cache/2024/44c12c8fbb59c7239f0f3b04bae189b7/" hreflang=""
data-tippy data-description="The origins of Tailwind and how it is framed against semantic CSS"
data-source="https://nuejs.org/blog/tailwind-misinformation-engine/"
data-date="2024-02-18"
data-favicon="https://nuejs.org/img/favicon.svg"
data-domain="nuejs.org"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-77" title="Lien vers cette section de la page"><hr id="hr-77" /></a>

<blockquote lang="en">
<p><em>File over app</em> 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. <mark>Use tools that give you this&nbsp;freedom.</mark></p>
<p><em>File over app</em> is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their&nbsp;data.</p>
<p><cite><em><a data-link-domain="stephango.com" href="https://stephango.com/file-over-app" hreflang="en"
title="Consultation de l’article (anglais)">File over app - Steph Ango</a>
<a href="/david/cache/2024/20d288eb47779c4f1b3f36fb86aa7108/" hreflang="en"
data-tippy data-description="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..."
data-source="https://stephango.com/file-over-app"
data-date="2024-02-18"
data-favicon="https://stephango.com/icon.svg"
data-domain="stephango.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-78" title="Lien vers cette section de la page"><hr id="hr-78" /></a>

<blockquote lang="en">
<p>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&nbsp;one.</p>
<p>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&nbsp;team.</p>
<p>It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. <mark>But the costs accumulate and you lose in the long&nbsp;run.</mark></p>
<p><cite><em><a data-link-domain="commandcenter.blogspot.com" href="https://commandcenter.blogspot.com/2023/12/simplicity.html" hreflang="en"
title="Consultation de l’article (anglais)">command center: Simplicity</a>
<a href="/david/cache/2024/6b26bff7f4772cf8fb78878ff4f9594f/" hreflang="en"
data-tippy data-description="In May 2009, Google hosted an internal Design Wizardry panel, with talks by Jeff Dean,  Mike Burrows, Paul Haahr, Alfred Spector, Bill Cou..."
data-source="https://commandcenter.blogspot.com/2023/12/simplicity.html"
data-date="2024-02-18"
data-favicon="https://commandcenter.blogspot.com/favicon.ico"
data-domain="commandcenter.blogspot.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>

<nav>
<p>
<a href="/david/2024/commun/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#commun</a>
<a href="/david/2024/dependance/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#dépendance</a>
<a href="/david/2024/technique/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#technique</a>
<a href="/david/2024/#tags" title="Liste de toutes les étiquettes 2024">tous ?</a>
</p>
</nav>
<nav>
<p>
<a rel="prev"
href="/david/2024/02/17/"
title="Publication précédente : Quotidien">← Précédent</a> •
<a href="/david/2024/" title="Liste des publications récentes">↑ En 2024</a>
</p>
</nav>

<form action="/david/recherche/" method="get">
<fieldset>
<legend>Recherche</legend>
<label for="input-search">Termes de votre recherche :</label>
<input id="input-search" type="search" name="s" aria-describedby="indexation-infos" required>
<input type="submit" value="Chercher">
<p id="indexation-infos">
<small>
Seuls les contenus de ces 8 dernières années sont indexés.
</small>
</p>
</fieldset>
</form>
<aside>
<theme-toggle></theme-toggle>
</aside>
</article>
<hr>
<footer>
<p>
<a href="/david/" title="Aller à l’accueil">Accueil</a>
•
<a href="/david/log/" title="Accès au flux RSS">Suivre</a>
•
<a href="http://larlet.com"
title="Go to my English profile"
data-instant>Pro</a>
•
<a href="mailto:david%40larlet.fr" title="Envoyer un courriel">Email</a>
•
<abbr title="Hébergeur : Alwaysdata, 62 rue Tiquetonne 75002 Paris, +33184162340">Légal</abbr>
</p>
<template id="theme-selector">
<form>
<style type="text/css">
fieldset div {
text-align: center;
}
</style>
<fieldset>
<legend>Thème</legend>
<div>
<label>
<input type="radio" value="auto" name="chosen-color-scheme" checked>
Auto
</label>
<label>
<input type="radio" value="dark" name="chosen-color-scheme">
Foncé
</label>
<label>
<input type="radio" value="light" name="chosen-color-scheme">
Clair
</label>
</div>
</fieldset>
</form>
</template>
</footer>
<script src="/static/david/js/instantpage-5.1.0.min.js" type="module"></script>
<script>
class ThemeToggle extends HTMLElement {
constructor() {
super()
const themeSelectorTemplate = document.querySelector('#theme-selector')
const form = themeSelectorTemplate.content.firstElementChild
this.attachShadow({ mode: 'open' })
this.shadowRoot.appendChild(form.cloneNode(true))
}

connectedCallback() {
const form = this.shadowRoot.querySelector('form')
form.addEventListener('change', (e) => {
const chosenColorScheme = e.target.value
localStorage.setItem('theme', chosenColorScheme)
toggleTheme(chosenColorScheme)
})

const selectedTheme = localStorage.getItem('theme')
if (selectedTheme && selectedTheme !== 'undefined') {
form.querySelector(`[value="${selectedTheme}"]`).checked = true
}
}
}

const prefersColorSchemeDark = '(prefers-color-scheme: dark)'
window.addEventListener('load', () => {
let colorsLayer = undefined
let hasDarkRules = false
for (const styleSheet of Array.from(document.styleSheets)) {
let mediaRules = []
for (const layerRule of styleSheet.cssRules) {
if (!(layerRule instanceof CSSLayerBlockRule)) {
continue
}
if (layerRule.name === 'colors') {
colorsLayer = layerRule
}
for (const cssRule of layerRule.cssRules) {
if (cssRule.type !== CSSRule.MEDIA_RULE) {
continue
}
// WARNING: Safari does not have/supports `conditionText`.
if (cssRule.conditionText) {
if (cssRule.conditionText !== prefersColorSchemeDark) {
continue
}
} else {
if (cssRule.cssText.startsWith(prefersColorSchemeDark)) {
continue
}
}
mediaRules = mediaRules.concat(Array.from(cssRule.cssRules))
}
}

// WARNING: do not try to insert a Rule to a styleSheet you are
// currently iterating on, otherwise the browser will be stuck
// in a infinite loop…
for (const mediaRule of mediaRules) {
// Safari requires the `0` second parameter (even if default).
colorsLayer.insertRule(mediaRule.cssText, 0)
hasDarkRules = true
}
}

if (hasDarkRules) {
if ('customElements' in window && !customElements.get('theme-toggle')) {
customElements.define('theme-toggle', ThemeToggle)
}
}
})
</script>
<script src="/static/david/js/popper-2.11.8.min.js"></script>
<script src="/static/david/js/tippy-bundle-6.3.7.umd.min.js"></script>
<script>
tippy('[data-tippy]', {
content(reference) {
reference.addEventListener('click', (e) => e.preventDefault())
return `
<h3 lang="fr">
<img src="${reference.dataset.favicon}" loading="lazy">
<a href="${reference.dataset.source}"
>Article sur ${reference.dataset.domain}</a></h3>
<p lang="${reference.hreflang}"><em>${reference.dataset.description}</em></p>
<div class="tippy-links" lang="fr">
<a href="${reference.href}">Archive au ${reference.dataset.date}</a>
</div>
`
},
allowHTML: true,
interactive: true,
delay: [150, 700],
hideOnClick: false
})
</script>

</body>
</html>

+ 51
- 0
david/2024/_sources/2024-02-18 - Indirections.md View File

@@ -0,0 +1,51 @@
# 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

+ 126
- 0
david/2024/commun/index.html View File

@@ -134,6 +134,132 @@
</p>
</nav>
<h2>
<a href="/david/2024/02/18/" title="Lien permanent vers cet article">In·directions</a> <time datetime="2024-02-18">18 février 2024</time>
</h2>

<blockquote lang="en">
<p>Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for <mark>abstracting</mark> that value into a name that better describes the intention of the value in the&nbsp;design.</p>
<p><cite><em><a data-link-domain="jwdallas.com" href="https://jwdallas.com/posts/namingcssvariables/" hreflang="en"
title="Consultation de l’article (anglais)">Naming Variables In CSS</a>
<a href="/david/cache/2024/d0ffe1891c332b6fc6e7d7826d8489da/" hreflang="en"
data-tippy data-description="Some collected thoughts around how to name variables in CSS. Ideas, conventions, and some do's and don't for consideration."
data-source="https://jwdallas.com/posts/namingcssvariables/"
data-date="2024-02-18"
data-favicon="https://jwdallas.com/icons/favicon.ico"
data-domain="jwdallas.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<p>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&nbsp;donné.</p>
<pre><code>:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
</code></pre>
<p>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&nbsp;seules déclarations&nbsp;:). Pourquoi <code>:root</code> et pas <code>html</code>&#8239;? Est-ce qu’il faut définir les couleurs primaires sur le <code>button</code> ou sur <code>form, nav</code>&#8239;? Ou faire sauter cet intermédiaire&#8239;? Est-ce qu’il faut <code>button.primary</code>, <code>.primary</code>, <code>.button-primary</code>, <code>.button.button-primary</code>&#8239;? Etc, etc.</p>
<p>Et je ne mentionne même pas les solutions à partir de <code>:host</code> / <code>:host-context()</code> ou <code>:scope</code> qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir&nbsp;populaires.</p>
<p>Venant d’un langage dont l’<a data-link-domain="en.wikipedia.org" href="https://en.wikipedia.org/wiki/Zen_of_Python">un des mantras</a> 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é&#8239;? Lorsqu’on envisage un commun sur ces 10&nbsp;prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec&nbsp;enthousiasme&#8239;?</p>
<p>Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du&nbsp;tout.</p>

<blockquote lang="en">
<p>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 <mark>vendor-specific</mark> language with expressions, operators, and method&nbsp;calls.</p>
<p><cite><em><a data-link-domain="nuejs.org" href="https://nuejs.org/blog/tailwind-misinformation-engine/" hreflang=""
title="Consultation de l’article">Tailwind marketing and misinformation engine</a>
<a href="/david/cache/2024/44c12c8fbb59c7239f0f3b04bae189b7/" hreflang=""
data-tippy data-description="The origins of Tailwind and how it is framed against semantic CSS"
data-source="https://nuejs.org/blog/tailwind-misinformation-engine/"
data-date="2024-02-18"
data-favicon="https://nuejs.org/img/favicon.svg"
data-domain="nuejs.org"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-77" title="Lien vers cette section de la page"><hr id="hr-77" /></a>

<blockquote lang="en">
<p><em>File over app</em> 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. <mark>Use tools that give you this&nbsp;freedom.</mark></p>
<p><em>File over app</em> is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their&nbsp;data.</p>
<p><cite><em><a data-link-domain="stephango.com" href="https://stephango.com/file-over-app" hreflang="en"
title="Consultation de l’article (anglais)">File over app - Steph Ango</a>
<a href="/david/cache/2024/20d288eb47779c4f1b3f36fb86aa7108/" hreflang="en"
data-tippy data-description="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..."
data-source="https://stephango.com/file-over-app"
data-date="2024-02-18"
data-favicon="https://stephango.com/icon.svg"
data-domain="stephango.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-78" title="Lien vers cette section de la page"><hr id="hr-78" /></a>

<blockquote lang="en">
<p>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&nbsp;one.</p>
<p>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&nbsp;team.</p>
<p>It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. <mark>But the costs accumulate and you lose in the long&nbsp;run.</mark></p>
<p><cite><em><a data-link-domain="commandcenter.blogspot.com" href="https://commandcenter.blogspot.com/2023/12/simplicity.html" hreflang="en"
title="Consultation de l’article (anglais)">command center: Simplicity</a>
<a href="/david/cache/2024/6b26bff7f4772cf8fb78878ff4f9594f/" hreflang="en"
data-tippy data-description="In May 2009, Google hosted an internal Design Wizardry panel, with talks by Jeff Dean,  Mike Burrows, Paul Haahr, Alfred Spector, Bill Cou..."
data-source="https://commandcenter.blogspot.com/2023/12/simplicity.html"
data-date="2024-02-18"
data-favicon="https://commandcenter.blogspot.com/favicon.ico"
data-domain="commandcenter.blogspot.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>

<nav>
<p>
<a href="/david/2024/commun/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#commun</a>
<a href="/david/2024/dependance/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#dépendance</a>
<a href="/david/2024/technique/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#technique</a>
<a href="/david/2024/#tags" title="Liste de toutes les étiquettes 2024">tous ?</a>
</p>
</nav>
<h2>
<a href="/david/2024/02/16/" title="Lien permanent vers cet article">uMap&nbsp;2</a> <time datetime="2024-02-16">16 février 2024</time>
</h2>

+ 126
- 0
david/2024/dependance/index.html View File

@@ -134,6 +134,132 @@
</p>
</nav>
<h2>
<a href="/david/2024/02/18/" title="Lien permanent vers cet article">In·directions</a> <time datetime="2024-02-18">18 février 2024</time>
</h2>

<blockquote lang="en">
<p>Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for <mark>abstracting</mark> that value into a name that better describes the intention of the value in the&nbsp;design.</p>
<p><cite><em><a data-link-domain="jwdallas.com" href="https://jwdallas.com/posts/namingcssvariables/" hreflang="en"
title="Consultation de l’article (anglais)">Naming Variables In CSS</a>
<a href="/david/cache/2024/d0ffe1891c332b6fc6e7d7826d8489da/" hreflang="en"
data-tippy data-description="Some collected thoughts around how to name variables in CSS. Ideas, conventions, and some do's and don't for consideration."
data-source="https://jwdallas.com/posts/namingcssvariables/"
data-date="2024-02-18"
data-favicon="https://jwdallas.com/icons/favicon.ico"
data-domain="jwdallas.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<p>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&nbsp;donné.</p>
<pre><code>:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
</code></pre>
<p>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&nbsp;seules déclarations&nbsp;:). Pourquoi <code>:root</code> et pas <code>html</code>&#8239;? Est-ce qu’il faut définir les couleurs primaires sur le <code>button</code> ou sur <code>form, nav</code>&#8239;? Ou faire sauter cet intermédiaire&#8239;? Est-ce qu’il faut <code>button.primary</code>, <code>.primary</code>, <code>.button-primary</code>, <code>.button.button-primary</code>&#8239;? Etc, etc.</p>
<p>Et je ne mentionne même pas les solutions à partir de <code>:host</code> / <code>:host-context()</code> ou <code>:scope</code> qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir&nbsp;populaires.</p>
<p>Venant d’un langage dont l’<a data-link-domain="en.wikipedia.org" href="https://en.wikipedia.org/wiki/Zen_of_Python">un des mantras</a> 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é&#8239;? Lorsqu’on envisage un commun sur ces 10&nbsp;prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec&nbsp;enthousiasme&#8239;?</p>
<p>Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du&nbsp;tout.</p>

<blockquote lang="en">
<p>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 <mark>vendor-specific</mark> language with expressions, operators, and method&nbsp;calls.</p>
<p><cite><em><a data-link-domain="nuejs.org" href="https://nuejs.org/blog/tailwind-misinformation-engine/" hreflang=""
title="Consultation de l’article">Tailwind marketing and misinformation engine</a>
<a href="/david/cache/2024/44c12c8fbb59c7239f0f3b04bae189b7/" hreflang=""
data-tippy data-description="The origins of Tailwind and how it is framed against semantic CSS"
data-source="https://nuejs.org/blog/tailwind-misinformation-engine/"
data-date="2024-02-18"
data-favicon="https://nuejs.org/img/favicon.svg"
data-domain="nuejs.org"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-77" title="Lien vers cette section de la page"><hr id="hr-77" /></a>

<blockquote lang="en">
<p><em>File over app</em> 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. <mark>Use tools that give you this&nbsp;freedom.</mark></p>
<p><em>File over app</em> is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their&nbsp;data.</p>
<p><cite><em><a data-link-domain="stephango.com" href="https://stephango.com/file-over-app" hreflang="en"
title="Consultation de l’article (anglais)">File over app - Steph Ango</a>
<a href="/david/cache/2024/20d288eb47779c4f1b3f36fb86aa7108/" hreflang="en"
data-tippy data-description="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..."
data-source="https://stephango.com/file-over-app"
data-date="2024-02-18"
data-favicon="https://stephango.com/icon.svg"
data-domain="stephango.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-78" title="Lien vers cette section de la page"><hr id="hr-78" /></a>

<blockquote lang="en">
<p>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&nbsp;one.</p>
<p>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&nbsp;team.</p>
<p>It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. <mark>But the costs accumulate and you lose in the long&nbsp;run.</mark></p>
<p><cite><em><a data-link-domain="commandcenter.blogspot.com" href="https://commandcenter.blogspot.com/2023/12/simplicity.html" hreflang="en"
title="Consultation de l’article (anglais)">command center: Simplicity</a>
<a href="/david/cache/2024/6b26bff7f4772cf8fb78878ff4f9594f/" hreflang="en"
data-tippy data-description="In May 2009, Google hosted an internal Design Wizardry panel, with talks by Jeff Dean,  Mike Burrows, Paul Haahr, Alfred Spector, Bill Cou..."
data-source="https://commandcenter.blogspot.com/2023/12/simplicity.html"
data-date="2024-02-18"
data-favicon="https://commandcenter.blogspot.com/favicon.ico"
data-domain="commandcenter.blogspot.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>

<nav>
<p>
<a href="/david/2024/commun/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#commun</a>
<a href="/david/2024/dependance/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#dépendance</a>
<a href="/david/2024/technique/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#technique</a>
<a href="/david/2024/#tags" title="Liste de toutes les étiquettes 2024">tous ?</a>
</p>
</nav>
<h2>
<a href="/david/2024/02/03/" title="Lien permanent vers cet article">Archives</a> <time datetime="2024-02-03">3 février 2024</time>
</h2>

+ 5
- 4
david/2024/index.html View File

@@ -181,7 +181,8 @@
<a href="/david/2024/02/14/">GéoCodage</a>,
<a href="/david/2024/02/15/">Licence</a>,
<a href="/david/2024/02/16/">uMap&nbsp;2</a>,
<a href="/david/2024/02/17/">Quotidien</a>.
<a href="/david/2024/02/17/">Quotidien</a>,
<a href="/david/2024/02/18/">In·directions</a>.
</p>
@@ -192,10 +193,10 @@
<a href="/david/2024/accompagnement/" rel="tag">#accompagnement (2)</a>,
<a href="/david/2024/addiction/" rel="tag">#addiction (4)</a>,
<a href="/david/2024/apprentissage/" rel="tag">#apprentissage (11)</a>,
<a href="/david/2024/commun/" rel="tag">#commun (6)</a>,
<a href="/david/2024/commun/" rel="tag">#commun (7)</a>,
<a href="/david/2024/communaute/" rel="tag">#communauté (5)</a>,
<a href="/david/2024/decision/" rel="tag">#décision (6)</a>,
<a href="/david/2024/dependance/" rel="tag">#dépendance (2)</a>,
<a href="/david/2024/dependance/" rel="tag">#dépendance (3)</a>,
<a href="/david/2024/documentation/" rel="tag">#documentation (1)</a>,
<a href="/david/2024/dystopie/" rel="tag">#dystopie (1)</a>,
<a href="/david/2024/echanges/" rel="tag">#échanges (4)</a>,
@@ -219,7 +220,7 @@
<a href="/david/2024/psychologie/" rel="tag">#psychologie (5)</a>,
<a href="/david/2024/solastalgia/" rel="tag">#solastalgia (1)</a>,
<a href="/david/2024/sport/" rel="tag">#sport (3)</a>,
<a href="/david/2024/technique/" rel="tag">#technique (11)</a>,
<a href="/david/2024/technique/" rel="tag">#technique (12)</a>,
<a href="/david/2024/velo/" rel="tag">#vélo (1)</a>,
<a href="/david/2024/web/" rel="tag">#web (6)</a>.

+ 126
- 0
david/2024/technique/index.html View File

@@ -134,6 +134,132 @@
</p>
</nav>
<h2>
<a href="/david/2024/02/18/" title="Lien permanent vers cet article">In·directions</a> <time datetime="2024-02-18">18 février 2024</time>
</h2>

<blockquote lang="en">
<p>Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for <mark>abstracting</mark> that value into a name that better describes the intention of the value in the&nbsp;design.</p>
<p><cite><em><a data-link-domain="jwdallas.com" href="https://jwdallas.com/posts/namingcssvariables/" hreflang="en"
title="Consultation de l’article (anglais)">Naming Variables In CSS</a>
<a href="/david/cache/2024/d0ffe1891c332b6fc6e7d7826d8489da/" hreflang="en"
data-tippy data-description="Some collected thoughts around how to name variables in CSS. Ideas, conventions, and some do's and don't for consideration."
data-source="https://jwdallas.com/posts/namingcssvariables/"
data-date="2024-02-18"
data-favicon="https://jwdallas.com/icons/favicon.ico"
data-domain="jwdallas.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<p>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&nbsp;donné.</p>
<pre><code>:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
</code></pre>
<p>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&nbsp;seules déclarations&nbsp;:). Pourquoi <code>:root</code> et pas <code>html</code>&#8239;? Est-ce qu’il faut définir les couleurs primaires sur le <code>button</code> ou sur <code>form, nav</code>&#8239;? Ou faire sauter cet intermédiaire&#8239;? Est-ce qu’il faut <code>button.primary</code>, <code>.primary</code>, <code>.button-primary</code>, <code>.button.button-primary</code>&#8239;? Etc, etc.</p>
<p>Et je ne mentionne même pas les solutions à partir de <code>:host</code> / <code>:host-context()</code> ou <code>:scope</code> qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir&nbsp;populaires.</p>
<p>Venant d’un langage dont l’<a data-link-domain="en.wikipedia.org" href="https://en.wikipedia.org/wiki/Zen_of_Python">un des mantras</a> 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é&#8239;? Lorsqu’on envisage un commun sur ces 10&nbsp;prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec&nbsp;enthousiasme&#8239;?</p>
<p>Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du&nbsp;tout.</p>

<blockquote lang="en">
<p>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 <mark>vendor-specific</mark> language with expressions, operators, and method&nbsp;calls.</p>
<p><cite><em><a data-link-domain="nuejs.org" href="https://nuejs.org/blog/tailwind-misinformation-engine/" hreflang=""
title="Consultation de l’article">Tailwind marketing and misinformation engine</a>
<a href="/david/cache/2024/44c12c8fbb59c7239f0f3b04bae189b7/" hreflang=""
data-tippy data-description="The origins of Tailwind and how it is framed against semantic CSS"
data-source="https://nuejs.org/blog/tailwind-misinformation-engine/"
data-date="2024-02-18"
data-favicon="https://nuejs.org/img/favicon.svg"
data-domain="nuejs.org"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-77" title="Lien vers cette section de la page"><hr id="hr-77" /></a>

<blockquote lang="en">
<p><em>File over app</em> 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. <mark>Use tools that give you this&nbsp;freedom.</mark></p>
<p><em>File over app</em> is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their&nbsp;data.</p>
<p><cite><em><a data-link-domain="stephango.com" href="https://stephango.com/file-over-app" hreflang="en"
title="Consultation de l’article (anglais)">File over app - Steph Ango</a>
<a href="/david/cache/2024/20d288eb47779c4f1b3f36fb86aa7108/" hreflang="en"
data-tippy data-description="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..."
data-source="https://stephango.com/file-over-app"
data-date="2024-02-18"
data-favicon="https://stephango.com/icon.svg"
data-domain="stephango.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>
<a href="#hr-78" title="Lien vers cette section de la page"><hr id="hr-78" /></a>

<blockquote lang="en">
<p>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&nbsp;one.</p>
<p>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&nbsp;team.</p>
<p>It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. <mark>But the costs accumulate and you lose in the long&nbsp;run.</mark></p>
<p><cite><em><a data-link-domain="commandcenter.blogspot.com" href="https://commandcenter.blogspot.com/2023/12/simplicity.html" hreflang="en"
title="Consultation de l’article (anglais)">command center: Simplicity</a>
<a href="/david/cache/2024/6b26bff7f4772cf8fb78878ff4f9594f/" hreflang="en"
data-tippy data-description="In May 2009, Google hosted an internal Design Wizardry panel, with talks by Jeff Dean,  Mike Burrows, Paul Haahr, Alfred Spector, Bill Cou..."
data-source="https://commandcenter.blogspot.com/2023/12/simplicity.html"
data-date="2024-02-18"
data-favicon="https://commandcenter.blogspot.com/favicon.ico"
data-domain="commandcenter.blogspot.com"
><svg xmlns="http://www.w3.org/2000/svg"
width="24" height="24" viewBox="0 0 24 24" fill="none"
stroke="currentColor" stroke-width="2" stroke-linecap="square"
stroke-linejoin="round"><circle cx="12" cy="12" r="10"></circle>
<path d="M9.09 9a3 3 0 0 1 5.83 1c0 2-3 3-3 3"></path>
<line x1="12" y1="17" x2="12.01" y2="17"></line>
</svg>
<span class="sr-only">[archive]</span></a></em></cite></p>
</blockquote>

<nav>
<p>
<a href="/david/2024/commun/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#commun</a>
<a href="/david/2024/dependance/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#dépendance</a>
<a href="/david/2024/technique/"
title="Liste de tous les articles 2024 associés à cette étiquette"
rel="tag">#technique</a>
<a href="/david/2024/#tags" title="Liste de toutes les étiquettes 2024">tous ?</a>
</p>
</nav>
<h2>
<a href="/david/2024/02/14/" title="Lien permanent vers cet article">GéoCodage</a> <time datetime="2024-02-14">14 février 2024</time>
</h2>

+ 4
- 3
david/index.html View File

@@ -143,6 +143,7 @@
<h2>Publications 2024</h2>
<p>Liste des publications récentes en ordre anté-chronologique :</p>
<p>
<a href="/david/2024/02/18/">In·directions</a>,
<a href="/david/2024/02/17/">Quotidien</a>,
<a href="/david/2024/02/16/">uMap&nbsp;2</a>,
<a href="/david/2024/02/15/">Licence</a>,
@@ -200,10 +201,10 @@
<a href="/david/2024/accompagnement/" rel="tag">#accompagnement (2)</a>,
<a href="/david/2024/addiction/" rel="tag">#addiction (4)</a>,
<a href="/david/2024/apprentissage/" rel="tag">#apprentissage (11)</a>,
<a href="/david/2024/commun/" rel="tag">#commun (6)</a>,
<a href="/david/2024/commun/" rel="tag">#commun (7)</a>,
<a href="/david/2024/communaute/" rel="tag">#communauté (5)</a>,
<a href="/david/2024/decision/" rel="tag">#décision (6)</a>,
<a href="/david/2024/dependance/" rel="tag">#dépendance (2)</a>,
<a href="/david/2024/dependance/" rel="tag">#dépendance (3)</a>,
<a href="/david/2024/documentation/" rel="tag">#documentation (1)</a>,
<a href="/david/2024/dystopie/" rel="tag">#dystopie (1)</a>,
<a href="/david/2024/echanges/" rel="tag">#échanges (4)</a>,
@@ -227,7 +228,7 @@
<a href="/david/2024/psychologie/" rel="tag">#psychologie (5)</a>,
<a href="/david/2024/solastalgia/" rel="tag">#solastalgia (1)</a>,
<a href="/david/2024/sport/" rel="tag">#sport (3)</a>,
<a href="/david/2024/technique/" rel="tag">#technique (11)</a>,
<a href="/david/2024/technique/" rel="tag">#technique (12)</a>,
<a href="/david/2024/velo/" rel="tag">#vélo (1)</a>,
<a href="/david/2024/web/" rel="tag">#web (6)</a>.

+ 50
- 36
david/log/index.xml View File

@@ -6,13 +6,62 @@
<link href="https://larlet.fr/david/" rel="alternate" type="text/html" />
<link href="https://larlet.fr/david/log/" rel="self" />
<id>https://larlet.fr/david/</id>
<updated>2024-02-18T12:00:00+01:00</updated>
<updated>2024-02-19T12:00:00+01:00</updated>
<author>
<name>David Larlet</name>
<uri>https://larlet.fr/david/</uri>
</author>
<rights>Copyright (c) 2004-2024, David Larlet</rights>
<entry xml:lang="fr">
<title type="html">In·directions</title>
<link href="https://larlet.fr/david/2024/02/18/" rel="alternate" type="text/html" />
<updated>2024-02-18T12:00:00+01:00</updated>
<id>https://larlet.fr/david/2024/02/18/</id>
<summary type="html">

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;Any time you have a design that references the same value across multiple pieces of UI, I’d suggest that is an opportunity for &lt;mark&gt;abstracting&lt;/mark&gt; that value into a name that better describes the intention of the value in the&amp;nbsp;design.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://jwdallas.com/posts/namingcssvariables/&quot;&gt;Naming Variables In&amp;nbsp;CSS&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;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&amp;nbsp;donné.&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;:root {
--umap-color-darkBlue: #263B58;
}
button {
--color-primary: var(--umap-color-darkBlue);
}
button.primary {
background-color: var(--color-primary);
}
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;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&amp;nbsp;seules déclarations&amp;nbsp;:). Pourquoi &lt;code&gt;:root&lt;/code&gt; et pas &lt;code&gt;html&lt;/code&gt;&amp;#8239;? Est-ce qu’il faut définir les couleurs primaires sur le &lt;code&gt;button&lt;/code&gt; ou sur &lt;code&gt;form, nav&lt;/code&gt;&amp;#8239;? Ou faire sauter cet intermédiaire&amp;#8239;? Est-ce qu’il faut &lt;code&gt;button.primary&lt;/code&gt;, &lt;code&gt;.primary&lt;/code&gt;, &lt;code&gt;.button-primary&lt;/code&gt;, &lt;code&gt;.button.button-primary&lt;/code&gt;&amp;#8239;? Etc, etc.&lt;/p&gt;
&lt;p&gt;Et je ne mentionne même pas les solutions à partir de &lt;code&gt;:host&lt;/code&gt; / &lt;code&gt;:host-context()&lt;/code&gt; ou &lt;code&gt;:scope&lt;/code&gt; qui sont encore d’autres façons de faire qui sont peut-être amenées à devenir&amp;nbsp;populaires.&lt;/p&gt;
&lt;p&gt;Venant d’un langage dont l’&lt;a href=&quot;https://en.wikipedia.org/wiki/Zen_of_Python&quot;&gt;un des mantras&lt;/a&gt; est &lt;q lang=&quot;en&quot;&gt;There should be one-- and preferably only one --obvious way to do it.&lt;/q&gt;, il est plus difficile de se retrouver devant une telle… flexibilité&amp;#8239;? Lorsqu’on envisage un commun sur ces 10&amp;nbsp;prochaines années, comment trouver une stratégie maintenable qui s’inscrira dans la durée avec&amp;nbsp;enthousiasme&amp;#8239;?&lt;/p&gt;
&lt;p&gt;Ce qui est certain, c’est que l’approche de Tailwind ne me convient pas du&amp;nbsp;tout.&lt;/p&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;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 &lt;mark&gt;vendor-specific&lt;/mark&gt; language with expressions, operators, and method&amp;nbsp;calls.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://nuejs.org/blog/tailwind-misinformation-engine/&quot;&gt;Tailwind marketing and misinformation&amp;nbsp;engine&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr /&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;&lt;em&gt;File over app&lt;/em&gt; 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. &lt;mark&gt;Use tools that give you this&amp;nbsp;freedom.&lt;/mark&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;File over app&lt;/em&gt; is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their&amp;nbsp;data.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://stephango.com/file-over-app&quot;&gt;File over app - Steph&amp;nbsp;Ango&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;hr /&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;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&amp;nbsp;one.&lt;/p&gt;
&lt;p&gt;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&amp;nbsp;team.&lt;/p&gt;
&lt;p&gt;It’s easy to build complexity. In the rush to launch, it’s quicker and easier to code than to redesign. &lt;mark&gt;But the costs accumulate and you lose in the long&amp;nbsp;run.&lt;/mark&gt;&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://commandcenter.blogspot.com/2023/12/simplicity.html&quot;&gt;command center: Simplicity&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;nav&gt;&lt;p&gt;&lt;a href=&quot;https://larlet.fr/david/2024/commun/&quot;&gt;#commun&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/dependance/&quot;&gt;#dépendance&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/technique/&quot;&gt;#technique&lt;/a&gt;&lt;/p&gt;&lt;/nav&gt;&lt;hr/&gt;&lt;p&gt;&lt;a href=&quot;mailto:david@larlet.fr&quot;&gt;Réagir ?&lt;/a&gt;&lt;/p&gt;</summary>
</entry>
<entry xml:lang="fr">
<title type="html">Quotidien</title>
<link href="https://larlet.fr/david/2024/02/17/" rel="alternate" type="text/html" />
@@ -1292,39 +1341,4 @@ par nos&amp;nbsp;obscurités&lt;/p&gt;
&lt;nav&gt;&lt;p&gt;&lt;a href=&quot;https://larlet.fr/david/2024/dependance/&quot;&gt;#dépendance&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/evolution/&quot;&gt;#évolution&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/parentalite/&quot;&gt;#parentalité&lt;/a&gt;&lt;/p&gt;&lt;/nav&gt;&lt;hr/&gt;&lt;p&gt;&lt;a href=&quot;mailto:david@larlet.fr&quot;&gt;Réagir ?&lt;/a&gt;&lt;/p&gt;</summary>
</entry>
<entry xml:lang="fr">
<title type="html">Marcher</title>
<link href="https://larlet.fr/david/2024/01/19/" rel="alternate" type="text/html" />
<updated>2024-01-19T12:00:00+01:00</updated>
<id>https://larlet.fr/david/2024/01/19/</id>
<summary type="html">

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;A walk-and-talk is a moveable salon. A small group of people walk together for a week, having casual conversations side-by-side during most of the day. In the evening the group sits down to an intense hours-long discussion centered on a daily chosen topic by those present. A moderator keeps the conversation on that day’s single topic to sharpen it and make it&amp;nbsp;memorable.&lt;/p&gt;
&lt;p&gt;&lt;mark&gt;To focus on conversations while walking,&lt;/mark&gt; participants carry only day-packs, and eat locally prepared meals. The walks are not strenuous and to keep it even more inspiring, they take place in storied environments that are walker-friendly, such as footpaths in England, Japan, and Spain. By the end of the week, every person present has walked about 100&amp;#8239;km and has had deep conversations with all the&amp;nbsp;others.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://craigmod.com/ridgeline/176/&quot;&gt;The Walk and Talk: Everything We&amp;nbsp;Know&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;C’est peu de dire que ce format m’intéresse et je l’ai envisagé à plusieurs reprises en France, notamment autour du Mont-Blanc. J’ai l’impression que la Traversée de Charlevoix serait un chemin assez idéal compte tenu des &lt;a href=&quot;https://www.traverseedecharlevoix.qc.ca/services-offerts/&quot;&gt;services proposés&lt;/a&gt; s’il s’agit de s’en tenir au format décrit (transport des&amp;nbsp;bagages).&lt;/p&gt;
&lt;p&gt;Le faire une première fois de manière rapide en solo cette année m’aiderait certainement —&amp;nbsp;en plus d’en faire la reconnaissance&amp;nbsp;— à l’envisager sur un rythme beaucoup plus doux en étant accompagné par la&amp;nbsp;suite.&lt;/p&gt;
&lt;hr /&gt;

&lt;blockquote lang=&quot;en&quot;&gt;
&lt;p&gt;Going forward I plan to version the projects I work on in a way that communicates &lt;em&gt;how much effort I expect a user will need to spend to adopt the new version.&lt;/em&gt; I’m going to refer to that scheme as &lt;strong&gt;Intended Effort Versioning (EffVer for short)&lt;/strong&gt;.&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://jacobtomlinson.dev/effver/&quot;&gt;EffVer: Version your code by the effort required to&amp;nbsp;upgrade&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Il faudrait que je rende explicite ma façon de décompter les crédits (facturés) dans &lt;a href=&quot;https://larlet.fr/david/2022/12/15/&quot;&gt;mes journaux&lt;/a&gt; car la notion d’effort / pénibilité y est présente, ce n’est pas qu’une question de temps. Ça m’aide notamment à vérifier qu’une journée n’est pas trop intense et n’a pas consommé toutes mes &lt;a href=&quot;https://fr.wikipedia.org/wiki/Th%C3%A9orie_des_cuill%C3%A8res&quot;&gt;cuillères&lt;/a&gt;, sociales surtout, ce qui peut avoir des conséquences sur les jours&amp;nbsp;suivants…&lt;/p&gt;
&lt;hr /&gt;

&lt;blockquote&gt;
&lt;p&gt;il&lt;/p&gt;
&lt;p&gt;suffit&lt;br /&gt;
parfois d’&lt;br /&gt;
être&amp;nbsp;là&lt;/p&gt;
&lt;p&gt;pour que&lt;br /&gt;
quelqu’un nous&amp;nbsp;voit&lt;/p&gt;
&lt;p&gt;&lt;cite&gt;&lt;em&gt;&lt;a href=&quot;https://clairesohem.com/blog/2024/01/10-12-2023-2/&quot;&gt;10&amp;#8239;12&amp;#8239;2023&lt;/a&gt;&lt;/em&gt;&lt;/cite&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;nav&gt;&lt;p&gt;&lt;a href=&quot;https://larlet.fr/david/2024/accompagnement/&quot;&gt;#accompagnement&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/communaute/&quot;&gt;#communauté&lt;/a&gt; &lt;a href=&quot;https://larlet.fr/david/2024/echanges/&quot;&gt;#échanges&lt;/a&gt;&lt;/p&gt;&lt;/nav&gt;&lt;hr/&gt;&lt;p&gt;&lt;a href=&quot;mailto:david@larlet.fr&quot;&gt;Réagir ?&lt;/a&gt;&lt;/p&gt;</summary>
</entry>
</feed>

+ 12
- 0
david/recherche/index.html View File

@@ -276,6 +276,12 @@
</template>
<script id="search-index" type="application/json">[
{
"title": "In\u00b7directions",
"url": "/david/2024/02/18/",
"date": "2024-02-18",
"content": "Any time you have a design that references the same value across multiple pieces of UI, I\u2019d suggest that is an opportunity for abstracting that value into a name that better describes the intention of the value in the\u00a0design. Naming Variables In\u00a0CSS Je me demande souvent quel est le bon niveau hi\u00e9rarchique au sein des CSS modernes. L\u2019approche constat\u00e9e actuelle semble \u00eatre de mettre des variables par couleur (par exemple) puis ensuite d\u00e9finir des variables interm\u00e9diaires pour leur donner un sens pour un contexte\u00a0donn\u00e9. :root { --umap-color-darkBlue: #263B58; } button { --color-primary: var(--umap-color-darkBlue); } button.primary { background-color: var(--color-primary); } Il s\u2019agit ici de partir d\u2019un exemple simpliste mais concret. J\u2019imagine qu\u2019il y a autant de d\u00e9velopeur\u00b7euse que de fa\u00e7on d\u2019\u00e9crire ces 3\u00a0seules d\u00e9clarations\u00a0:). Pourquoi :root et pas html\u202f? Est-ce qu\u2019il faut d\u00e9finir les couleurs primaires sur le button ou sur form, nav\u202f? Ou faire sauter cet interm\u00e9diaire\u202f? Est-ce qu\u2019il faut button.primary, .primary, .button-primary, .button.button-primary\u202f? Etc, etc. Et je ne mentionne m\u00eame pas les solutions \u00e0 partir de :host / :host-context() ou :scope qui sont encore d\u2019autres fa\u00e7ons de faire qui sont peut-\u00eatre amen\u00e9es \u00e0 devenir\u00a0populaires. Venant d\u2019un langage dont l\u2019un des mantras est There should be one-- and preferably only one --obvious way to do it., il est plus difficile de se retrouver devant une telle\u2026 flexibilit\u00e9\u202f? Lorsqu\u2019on envisage un commun sur ces 10\u00a0prochaines ann\u00e9es, comment trouver une strat\u00e9gie maintenable qui s\u2019inscrira dans la dur\u00e9e avec\u00a0enthousiasme\u202f? Ce qui est certain, c\u2019est que l\u2019approche de Tailwind ne me convient pas du\u00a0tout. 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\u00a0calls. Tailwind marketing and misinformation\u00a0engine 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\u00a0freedom. File over app is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their\u00a0data. File over app - Steph\u00a0Ango Learn about the systems that already exist, and build on them rather than around them. If an existing system doesn\u2019t do what you want, maybe the problem is in the design of your system, not that\u00a0one. If you do build a new component, make sure it\u2019s of general utility. Don\u2019t build infrastructure that solves only the problems of your own\u00a0team. It\u2019s easy to build complexity. In the rush to launch, it\u2019s quicker and easier to code than to redesign. But the costs accumulate and you lose in the long\u00a0run. command center: Simplicity"
},
{
"title": "Quotidien",
"url": "/david/2024/02/17/",
@@ -564,6 +570,12 @@
"date": "2024-01-01",
"content": "33\u202f% de 44\u00a0millions de consommateurs vont faire le Dry January 22\u202f% des consommateurs ont une conso excessive, c\u2019est-\u00e0-dire 10\u00a0verres/semaine max et plus de deux\u00a0verres/jour. Les seniors sont aussi tr\u00e8s touch\u00e9\u00b7es. L\u2019alcool est une drogue.. On peut faire la f\u00eate sans alcool et\u00a0s\u2019\u00e9clater. Quand on arr\u00eate\u00a0: bienfaits sur le foie, la peau, le coeur, etc\u2026 Pb\u00a0: m\u00e9moire, troubles cognitifs, responsable de cancer, pb sommeil, d\u00e9compensation de maladie psy,\u2026 41000\u00a0d\u00e9c\u00e8s par an en\u00a0France. Les cinq sympt\u00f4mes d\u00e9finissent un probl\u00e8me de\u00a0d\u00e9pendance\u00a0: Perte de\u00a0contr\u00f4le Usage\u00a0compulsif Envie\u00a0r\u00e9pressive Usage\u00a0chronique Cons\u00e9quences psychiques, physiques, sociales,\u2026 Bon Dry J. pour celleux qui le font\u202f! Moi j\u2019en\u00a0suis\u202f! @Air@framapiaf.org Dans mon entourage, de plus en plus de personnes que j\u2019estime ne boivent pas d\u2019alcool, de plus en plus de personnes qui vieillissent en deviennent d\u00e9pendantes. Je suis davantage attir\u00e9 par la premi\u00e8re option\u2026 et pas pour un seul\u00a0mois. Je me sens pr\u00eat, on verra bien o\u00f9 cela me\u00a0m\u00e8ne. Grosse envie de reprendre la CSS par ici en ce d\u00e9but d\u2019ann\u00e9e. Avec le dilemme de faire chuter cette motivation si je publie d\u00e8s maintenant avec l\u2019ancienne (qui restera effective sur les anciens articles). Je vais essayer de me\u00a0retenir."
},
{
"title": "In\u00b7directions",
"url": "/david/2024/02/18/",
"date": "2024-02-18",
"content": "Any time you have a design that references the same value across multiple pieces of UI, I\u2019d suggest that is an opportunity for abstracting that value into a name that better describes the intention of the value in the\u00a0design. Naming Variables In\u00a0CSS Je me demande souvent quel est le bon niveau hi\u00e9rarchique au sein des CSS modernes. L\u2019approche constat\u00e9e actuelle semble \u00eatre de mettre des variables par couleur (par exemple) puis ensuite d\u00e9finir des variables interm\u00e9diaires pour leur donner un sens pour un contexte\u00a0donn\u00e9. :root { --umap-color-darkBlue: #263B58; } button { --color-primary: var(--umap-color-darkBlue); } button.primary { background-color: var(--color-primary); } Il s\u2019agit ici de partir d\u2019un exemple simpliste mais concret. J\u2019imagine qu\u2019il y a autant de d\u00e9velopeur\u00b7euse que de fa\u00e7on d\u2019\u00e9crire ces 3\u00a0seules d\u00e9clarations\u00a0:). Pourquoi :root et pas html\u202f? Est-ce qu\u2019il faut d\u00e9finir les couleurs primaires sur le button ou sur form, nav\u202f? Ou faire sauter cet interm\u00e9diaire\u202f? Est-ce qu\u2019il faut button.primary, .primary, .button-primary, .button.button-primary\u202f? Etc, etc. Et je ne mentionne m\u00eame pas les solutions \u00e0 partir de :host / :host-context() ou :scope qui sont encore d\u2019autres fa\u00e7ons de faire qui sont peut-\u00eatre amen\u00e9es \u00e0 devenir\u00a0populaires. Venant d\u2019un langage dont l\u2019un des mantras est There should be one-- and preferably only one --obvious way to do it., il est plus difficile de se retrouver devant une telle\u2026 flexibilit\u00e9\u202f? Lorsqu\u2019on envisage un commun sur ces 10\u00a0prochaines ann\u00e9es, comment trouver une strat\u00e9gie maintenable qui s\u2019inscrira dans la dur\u00e9e avec\u00a0enthousiasme\u202f? Ce qui est certain, c\u2019est que l\u2019approche de Tailwind ne me convient pas du\u00a0tout. 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\u00a0calls. Tailwind marketing and misinformation\u00a0engine 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\u00a0freedom. File over app is an appeal to tool makers: accept that all software is ephemeral, and give people ownership over their\u00a0data. File over app - Steph\u00a0Ango Learn about the systems that already exist, and build on them rather than around them. If an existing system doesn\u2019t do what you want, maybe the problem is in the design of your system, not that\u00a0one. If you do build a new component, make sure it\u2019s of general utility. Don\u2019t build infrastructure that solves only the problems of your own\u00a0team. It\u2019s easy to build complexity. In the rush to launch, it\u2019s quicker and easier to code than to redesign. But the costs accumulate and you lose in the long\u00a0run. command center: Simplicity"
},
{
"title": "Quotidien",
"url": "/david/2024/02/17/",

Write Preview
Loading…
Cancel
Save