style page care

contents/care_for_code.md

@@ -11,7 +11,7 @@ Enter the documentation sessions. Two hours where to sit with source code and wr
 
 Writing documentation is tricky! But let's face this together: prompts and suggestions will be offered for inspiration, and coffee and snacks for restoration. If you want there will be space to share your work and exchange feedback, if not no prob: just enjoy the cozy music and write some docs.
 
-## Why documenting when one can "just" code?
+###  Why documenting when one can "just" code?
 
 These sessions grow out of the contradiction of being frustrated in having to deal with undocumented pieces of software, and at the same time never documenting anything. While for sure there is some thrills in understanding how to stitch codes together, the lack of documentation poses a great hindrance for the participation of diverse knowledges in the making of software.
 
@@ -42,9 +42,10 @@ A useful resource to navigate programmers' needs with documentation is the Diata
 
 _Tutorials_ offer entry points for the newcomers, while _explanations_ unveal core mechanisms for more navigated readers. _How-to guides_ teach how to get the work done, while _references_ report lists of information ready to be consulted. Different documentations for different readers for the same code.
 
+Read more about it at [diataxis.fr](https://diataxis.fr).
+
 ![diataxis scheme](https://hub.xpub.nl/soupboat/~kamo/thesis/img/diataxis.jpg)
 
-Read more about it at [diataxis.fr](https://diataxis.fr).
 
 ### Start from the code!
 
@@ -76,7 +77,6 @@ Explanation of an API by Chaeyoung Kim
 ![frogs](https://git.xpub.nl/kamo/pad-bis/media/branch/master/lifecycle.jpg)
 Lifecycle of an etherpad document when stored in the Padliography.
 
-![nassi schneiderman]()
 
 ### Start with someone else!
 
@@ -102,7 +102,7 @@ Here the making of software resembles gardening: code changes continuously, and
 
 Such care requires time and energies, that are not always super available! Here is where the idea of pairing really shines: by providing an explicit reference to the version we talking about we are at least sure of two things: which code and which documentation to look for.
 
-## Mmmmm next what ? ?
+### Mmmmm next what ? ?
 
 I don't know. As a matter of fact documenting requires as much practice as programming, so the best we can hope for is learning by doing. Eventually sharing methods, and tricks, and examples, and resources.
 

static/css/care.css

@@ -0,0 +1,65 @@
+@font-face {
+  font-family: "Unilegant";
+  src: url("https://hub.xpub.nl/soupboat/docs/font/Unilegant.woff2")
+      format("woff2"),
+    url("https://hub.xpub.nl/soupboat/docs/font/Unilegant.woff") format("woff");
+  font-weight: normal;
+  font-style: normal;
+  font-display: swap;
+}
+
+html,
+body {
+  background-color: white;
+  font-family: sans-serif;
+  font-size: 18px;
+  line-height: 1.4;
+}
+
+img {
+  width: 100%;
+}
+
+main > p {
+  max-width: 65ch;
+}
+
+h1 {
+  font-size: 28px;
+  line-height: 1;
+  font-family: "Unilegant";
+}
+
+h2 {
+  font-size: 24px;
+}
+
+h3 {
+  font-size: 21px;
+}
+
+blockquote {
+  font-family: serif;
+}
+
+code {
+  display: inline-block;
+  padding: 0.1em 0.5em;
+  background-color: #eee;
+  border-radius: 1em;
+  margin-inline: 0.5ch;
+}
+
+strong {
+  text-decoration: underline;
+}
+
+@media print {
+  nav {
+    display: none;
+  }
+
+  h2 {
+    break-before: page;
+  }
+}