New repository

This commit is contained in:
southerntofu 2020-05-04 14:09:17 +02:00
parent 8601202154
commit 9742792d3f
47 changed files with 772 additions and 1 deletions

View File

@ -1,3 +1,9 @@
# staticadventures
Source for https://staticadventures.netlib.re/
Build with:
```
$ zola build
```

50
config.toml Normal file
View File

@ -0,0 +1,50 @@
base_url = "https://staticadventures.netlib.re"
theme = "water"
compile_sass = true
highlight_code = false
build_search_index = false
generate_rss = true
default_language = "en"
taxonomies = [
{name = "skills", rss = true},
]
languages = [
{code = "fr", rss = true },
]
[extra]
title = "staticadventures"
header = "_common/header.md"
menu = "_common/menu.md"
stylesheets = [ "style.css", "custom.css" ]
home_section = "blog"
home_fullarticles = false
home_title = false
[extra.forge]
source = "https://tildegit.org/southerntofu/staticadventures/raw/branch/master/"
browse = "https://tildegit.org/southerntofu/staticadventures/src/branch/master/"
home = "https://tildegit.org/"
name = "tildegit"
# Need to keep this here until zola has support for theme translations
[translations.fr]
source = "Source de cette page"
readmore = "Lire la suite"
previousPage = "Page précédente"
nextPage = "Page suivante"
dateFormat = "%d/%m/%Y"
nothing_yet = "Il n'y a pas encore d'article dans cette section."
# Custom
skills = "Cet article présume que tu connais : "
[translations.en]
source = "Source for this page"
readmore = "Read more"
previousPage = "Previous page"
nextPage = "Next page"
dateFormat = "%m/%d/%Y"
nothing_yet = "There is no article in this section yet."
# Custom
skills = "This article assumes you know of: "

View File

@ -0,0 +1,3 @@
+++
render = false
+++

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

View File

@ -0,0 +1,49 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape (http://www.inkscape.org/) -->
<svg xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://www.w3.org/2000/svg" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:ns1="http://sozi.baierouge.fr" xmlns:xlink="http://www.w3.org/1999/xlink" id="svg4394" viewBox="0 0 647.74 616.38" version="1.1" inkscape:version="0.91 r13725">
<title id="title5000">Anarchist-Comunism</title>
<g id="layer1" transform="translate(-65.531 -92.849)">
<g id="g4975" transform="translate(1981 751.55)">
<path id="path4968" style="stroke-linejoin:round;stroke:#000000;stroke-width:5;fill:#ff0000" d="m506.35 490.92-179.13-169.09-215.08 120.26 105.49-222.61-180.88-167.4 244.32 31.517 103.33-223.71 45.52 242.1 244.7 29.12-216.19 118.1 47.92 241.71z" transform="matrix(.99235 -.12347 .12347 .99235 -1955.8 -469.71)"/>
<path id="path4960" style="stroke-linejoin:round;stroke:#000000;stroke-width:5;fill:#000000" d="m-1591.7-656.2-74.906 234.75-246.34-1.0938 200.16 143.78-77.188 233.94 198.56-145.91 1.5 1.0938v-461l-1.7812-5.5625z"/>
</g>
</g>
<metadata>
<rdf:RDF>
<cc:Work>
<dc:format>image/svg+xml</dc:format>
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
<cc:license rdf:resource="http://creativecommons.org/licenses/publicdomain/"/>
<dc:publisher>
<cc:Agent rdf:about="http://openclipart.org/">
<dc:title>Openclipart</dc:title>
</cc:Agent>
</dc:publisher>
<dc:title>Anarcho-communism</dc:title>
<dc:date>2010-03-22T17:00:05</dc:date>
<dc:description>Anarcho-communism symbol drawn on Inkscape.</dc:description>
<dc:source>https://openclipart.org/detail/33199/anarcho-communism-by-andy_gardner</dc:source>
<dc:creator>
<cc:Agent>
<dc:title>Andy_Gardner</dc:title>
</cc:Agent>
</dc:creator>
<dc:subject>
<rdf:Bag>
<rdf:li>Anarchism</rdf:li>
<rdf:li>anarchy</rdf:li>
<rdf:li>communism</rdf:li>
<rdf:li>political</rdf:li>
<rdf:li>politics</rdf:li>
<rdf:li>symbol</rdf:li>
</rdf:Bag>
</dc:subject>
</cc:Work>
<cc:License rdf:about="http://creativecommons.org/licenses/publicdomain/">
<cc:permits rdf:resource="http://creativecommons.org/ns#Reproduction"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#Distribution"/>
<cc:permits rdf:resource="http://creativecommons.org/ns#DerivativeWorks"/>
</cc:License>
</rdf:RDF>
</metadata>
</svg>

After

Width:  |  Height:  |  Size: 2.8 KiB

View File

@ -0,0 +1,23 @@
+++
title = "Footer"
date = 2018-01-03
+++
![Kopimi](kopimi.jpg)
# KOPIMI
Licence © [CC BY-SA](https://creativecommons.org/licenses/by-sa/4.0/). Certaines illustrations ne sont pas de moi mais sont reproduites ici car [Sharing is caring](https://kopimi.com) et **NIQUE LA PROPRIÉTÉ PRIVÉE !** [Problème ?](/contact)
---
![Anarcho-communisme](Anarchist-Comunism.jpg)
# Sujets
⚠️ Site et opinions personnelles. Technophilie anarchiste / communiste libertaire. Pas intéresséE ? Va naviguer plus loin !
---
<i>~</i>
# Tildeverse
Ce blog est aimablement hébergé par [thunix.net](https://thunix.net), member de la fédération [Tildeverse](https://tildeverse.org) de coopératives d'hébergement autonomes et de cyber-hackerspaces.

View File

@ -0,0 +1,23 @@
+++
title = "Footer"
date = 2018-01-03
+++
![Kopimi](kopimi.jpg)
# KOPIMI
© [CC BY-SA](https://creativecommons.org/licenses/by-sa/4.0/) license. Some graphics not mine. Just reproducing them here because [sharing is caring](https://kopimi.com/) and **FUCK PRIVATE PROPERTY!** [Problem?](/contact)
---
![Anarcho-communism](Anarchist-Comunism.jpg)
# Topics
⚠️ Personal website & opinions. Tech-savvy anarchism / libertarian communism. Not interested? Feel free to browse away!
---
<i>~</i>
# Tildeverse
This blog is kindly hosted by [thunix.net](https://thunix.net), a proud member of the [Tildeverse](https://tildeverse.org) federation of autonomous hosting coops and cyber-hackerspaces.

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

View File

@ -0,0 +1 @@
<svg xmlns="http://www.w3.org/2000/svg" width="256" height="256"><circle cx="128" cy="128" r="119.428" fill="#fff" stroke="#000" stroke-width="16.502"/><path d="M161.405 210.657L138.2 227.233 34.412 153.79V91.316l23.204-16.32 37.233 26.01V48.73l23.206-16.576 23.46 16.576v52.276l16.832-11.731 19.892 14.027 20.144-14.281 23.46 16.576v62.477l-23.46 16.32-20.144-14.282-16.832 11.987zM40.79 91.314L57.62 103.3l17.086-11.986L57.62 79.328zm20.144 14.28l16.83 11.986 17.086-11.985-16.83-11.987zm19.89 14.281l17.087 11.985 17.086-11.985L97.91 107.89zm37.231-83.132L100.969 48.73l17.086 11.982 17.084-11.982zm0 28.56l-17.086 11.985 17.086 11.985 16.83-12.24zm0 28.305l-17.086 11.987 17.086 11.985 16.83-11.985zm-17.084 40.547l17.086 11.73 16.83-11.985-16.83-11.73zm20.144 14.025l17.084 11.985 16.831-11.985-16.831-11.984zm37.23-54.572l-17.086 11.987 16.832 11.985 17.085-11.985zm40.038 0l-16.834 11.987 16.834 11.985 17.083-11.985z"/></svg>

After

Width:  |  Height:  |  Size: 933 B

View File

@ -0,0 +1,6 @@
+++
+++
# static<wbr>adventures
## Ramener le web<wbr> en avant

View File

@ -0,0 +1,6 @@
+++
+++
# static<wbr>adventures
## Bringing back<wbr> the web forward

View File

@ -0,0 +1,16 @@
+++
+++
[À propos](@/blog/starting-static-adventures/index.md)
---
[Blog](@/blog/_index.fr.md)
---
[Contact](@/contact.fr.md)
---
[RSS](/rss.fr.xml)

16
content/_common/menu.md Normal file
View File

@ -0,0 +1,16 @@
+++
+++
[About](@/blog/starting-static-adventures/index.md)
---
[Blog](@/blog/_index.md)
---
[Contact](@/contact.md)
---
[RSS](/rss.xml)

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
Flexbox are a CSS3 standard to build one-dimensional layouts. Here's [a tutorial](https://css-tricks.com/snippets/css/a-guide-to-flexbox/) with everything to know about flexbox. When you're done reading the tutorial, head over to the educational game [Flexbox Froggy](https://flexboxfroggy.com/) and you should be able to complete the game with your flexbox-fu.

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
git is a [distributed version control system](https://en.wikipedia.org/wiki/Distributed_version_control) (DVCS), which allows several people to cooperate on the same project on their own machine, while synchronizing through a forge (such as Gitea/Github) where only "maintainers" decide what changes to incorporate.

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
HTML5 introduced a number of new semantic tags that are really useful, including `<article>`, `<main>`, and `<header>` among others. Here's [a tutorial](https://dev.to/kenbellows/stop-using-so-many-divs-an-intro-to-semantic-html-3i9i) to introduce HTML5.

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
Macros are function-like structures that take input data and output other data. Macros are used to deal with repetitive patterns, making them easier to type out. In the context of a static-site generators, macros are special pieces of template that you use as functions to invoke more complex markup. Tera, Zola's templating engine, has [docs on its macro system](https://tera.netlify.com/docs/templates/#macros).

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
Markdown is a language to describe content, just like HTML. Actually, Markdown usually compiles to HTML and can contain HTML markup. Markdown is commonly used to replace wiki-style syntax or other BBCode systems of the past. Here's [an introduction](https://daringfireball.net/projects/markdown/) to Markdown.

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
Media queries (@media) are CSS blocks applied only to clients matching some criteria. For example, we may want to add rules for devices of a certain screen size with `@media min-width: 48em`. Or, remove a lot of cruft when the document is being sent to a printer with `@media print`. Here's a [general introduction](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries) to media queries, and here's [a tutorial](https://css-tricks.com/css-media-queries/) demoing what you can do with thosein practice.

View File

@ -0,0 +1,5 @@
+++
draft = false
+++
The [shell](https://en.wikipedia.org/wiki/Shell_(computing)#Command-line_shells) is the program that handles your command-line interface, what happens inside the terminal. There's plenty of tutorials around to learn the command-line.

4
content/_index.fr.md Normal file
View File

@ -0,0 +1,4 @@
+++
title = "Accueil"
+++

4
content/_index.md Normal file
View File

@ -0,0 +1,4 @@
+++
title = "staticadventures"
+++

View File

@ -0,0 +1,7 @@
+++
title = "Derniers articles"
sort_by = "date"
paginate_by = 5
weight = 10
+++

7
content/blog/_index.md Normal file
View File

@ -0,0 +1,7 @@
+++
title = "Latest articles"
sort_by = "date"
paginate_by = 5
weight = 10
+++

BIN
content/blog/capitalism.jpg Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 26 KiB

View File

@ -0,0 +1,102 @@
+++
title = "Entering the static web"
date = 2019-03-28
+++
You've probably heard that the static web is rising again, and that many websites are dropping CMS (content-managing systems, such as [Wordpress](https://wordpress.org)) in favor of static-site generation (SSG) tools such as [Jekyll](https://jekyll.org), [Nikola](https://getnikola.org), [hugo](https://gohugo.io) or [zola](https://getzola.org). **But what exactly does that mean?** Let's take some time to think about it.
# Some (incomplete) web history
## Hyperlinks are our friends
The web started in the early 90's as a protocol (HTTP) and a language (HTML) to make documents accessible on the network, and let them link to one another. At the time, no language would define how the content would be rendered: it was entirely up to the web browser (the client). Cascading Style Sheets (CSS) were standardized only a few years later.
At the time, it was unconceivable for the browser to run code from the page (Javascript did not exist), and serving content from a database didn't really make sense when you just wanted to serve a bunch of HTML pages. **Your website was just a folder containing files** (some of which were HTML), and doing it any other way would have complicated things for no benefit (overengineering) given the usage of the web we had back then.
## The rise of the CMS
But in the early 2000's, some people started building tools to make website management easier. They called them CMS for Content Managing Systems, and they were basically programs writing your HTML pages for you, through which you can post a new article from a nice web interface.
These CMS, usually, are connected to a database storing the raw content (page title, publication date, author), and assemble the page that you want to read upon request. So when your browser queries a web page managed by a CMS, there are good chances that the server will have to run a query against the database, then run some code to generate the HTML page you're trying to access.
This process is terribly unefficient, because most of the content doesn't change when two different persons access the page. So running the same queries and **building the same pages over and over again is basically wasting computing power and therefore natural resources and energy**.
As a response to this problem, many CMS or CMS plugins started implementing caching strategies to reduce the number of identical queries and instructions being run throughout the website. This does reduce the load on the server, but is the computing equivalent of putting a bandage on a deep wound: from the outside it looks better, but it's far from ideal if we're trying to fix the actual problem.
## The great security disaster
Content Managing Systems are great at… managing content. No surprise here. However, just about anything else they do is disastrous. As mentioned earlier, they are really bad for saving energy. But they are even worse when it comes to security! Security experts could build CMS (like some did with [Airship CMS](https://paragonie.com/project/airship)), and they would still probably end up with a few bugs in their implementations. However, most **CMS are not built by security experts and are just full of mines ready to explode**.
Every year, most CMS have to release urgent security patches to avoid websites getting hacked. However, most website owners do not have time or the knowledge to update their websites… or just hear about it too late! There is something deeply wrong with the idea that **your website which was doing fine last week could anytime become a danger to you and the people visiting it**.
A CMS has the whole website as an attack surface, as every page is generated dynamically depending on the client request. **Serving your website as simple HTML pages reduces the attack surface** to the actual folder where your website resides. Which is really easier to secure than thousands of lines of spaghetti-code calling pseudo-PHP templating (Wordpress, I'm looking at you).
# Introducing static-site generators (SSG)
In the wake of the many security issues (CVE) affecting CMS, people turned to the past to look for answers. Why did we start overengineering this all in the first place?
## What's an SSG?
A static-site generator is a program that takes a bunch of content files following a hierarchy corresponding to the website's tree-structure, and applies HTML templates on these content files to produce a complete output, a process we call "building the site". So if you have a `about` folder in your content folder, there will be a `/about/` page available on your website.
The templates, as defined in your theme or in your site root, are just HTML pages following some syntax to incorporate variable elements, such as child article, or website title. They allow to easily and safely part your website into smaller pieces that are easier to maintain. This way, **if you'd like to change the way articles are displayed, you don't have to edit each and every article**. You just need to edit a single `page.html` that will be applied to all articles when rebuilding the site.
So when is it appropriate to rebuild the site? **Most of the time, we want to rebuild the website only when content files have changed.** We'll see later about tools to automate this. However, sometimes we may need to rebuild the site more often. For example, we can rebuild a site every night to integrate today's agenda from an external tool (such as NextCloud) into the header or sidebar. However often we rebuild the website to update it, in most cases it will be less resource-wasting than having a whole CMS build every page on every request.
## The bike analogy
**Building a Wordpress-like CMS to make a website is the digital equivalent of building a nuclear-powered car to travel 2km everyday**. Sure, it took you lots of time and energy to build it and you're really proud. Sure, at the moment it works just fine. But when things go wrong (and they always do), you really wish you had walked the 2km everyday instead of building that shit-atomic car of yours.
Back to the web. In between manually editing HTML pages (walking) and using a CMS (building a nuclear-powered car), there's options to explore. A static-site generator (SSG) is a tool that fits somewhere on this spectrum to make your life easier without overengineering, and limiting security risks. If you'd like to follow me on this analogy, a static-site generator is some kind of bike. Sure, it's not going to ride through a swamp/desert, and it's probably inappropriate to ride more than 100km/day, but **it's simple and solid tech that brings you autonomy and isn't going to ruin your entire life the day it breaks down**.
## The future emerging from the past
**Back in the 90's, many tech people already built static-site generators**, although they weren't called that exactly. They were simple personal scripts taking files from a folder and applying additional markup here and there to get the pages ready for publishing… which is amazing! However, those tools often lacked proper documentation and an inclusive community to take them forward, and they were slowly replaced by the ways of the CMS.
Nowadays, some few free-software community-run projects are taking the web in this direction. Although they are not 100% compatible with one another, they share enough concepts and approaches to ensure it's really easy to switch from a generator to another. They let you work close enough to the HTML/CSS layer that **you don't need expertise on any of these tools in particular**: skills you learn as you go will be useful to you with any templating system (even Timber and Ganttry for Wordpress).
## Some new tools
In the past few years, modern static-site generators emerged with each their specificities. Some favor speed, others favor customizability. Some try to integrate external tools, others reinvent the wheel. But surely you'll find a static-site generator to match your needs. If you're not sure which direction to go, don't hesitate to start with a tool you have plenty of documentation and support available for. If some comrades or friends of yours are working with Jekyll, you can always start down this path, learn on the go, and change your tools as your needs and desires evolve.
## A new ecosystem
Along with more modern static-site generators a whole ecosystem of tools has emerged to help us deal with our static sites. The biggest advance we made is probably to tie our static websites to version control systems (such as git), and building the site directly from the repository through Continuous Integration procedures (i.e. a script run on every commit). **Now, you can have different branches of your website deploying automatically on different webroots**, so you may have for instance the `testing` branch on your repo deploying to `testing.example.com` (protected by some basic auth) while the `master` branch deploys to `www.example.com`.
There's also some attention dedicated to static content managing systems, which are basically simplified user-interfaces to write and post files to your content folder. The most advanced examples of this are [PubliiCMS](https://getpublii.com/) and [netlifyCMS](https://netlifycms.org) (not to be confused with [netlify.com](https://netlify.com) the webhost), implemented as a client-side Javascript application. It'll ask you to authenticate on your forge (Github, Gitlab, or Bitbucket so far) and then let you upload files there from a sleek web interface. So that's nice, although running a whole web browser just to edit text is definitely not the best we can do.
# Consequences
## Latency gets better
As your website is served directly by the web server, your visitors get a better latency. This means the information takes less time to travel from the web browser to the server and back again.
This is true both because we reduced the global amount of computing applied on your data, and because web servers such as [nginx](https://nginx.org) apply incredible optimization tricks upon serving static files, that they can't when calling CGI scripts or acting as a reverse-proxy.
Have you ever wondered why some webapps/CMS ask you to configure your webserver to redirect *all* requests to the backend Python/Go app? Well I have, and I still haven't found an answer.
## Backup & Migration
Have you ever had to deal with a missing database backup? Or a painful forced migration of services when you just don't find a honest hosting solution for your tech stack? With a static site, such worries are problems of the past! The fundamental principle of static sites is: **your website is its own folder**.
Whether we're talking about the source folder (usually your git repo) or the built website (the `public` folder), your website is a single folder to backup and move around, making it extremely convenient to work with. **You would have a hard time finding a webhost that does not support static files!**
## Interoperability with different networks
Being just a folder means it's also shareable through other networks than the standard web. Your website could be distributed as a torrent, for instance. That would be easier on your bandwidth costs, however people wouldn't be able to browse your website with a proper client as they currently do. But take for instance [IPFS](https://ipfs.io), a p2p file-sharing system which supports a web of *ipfs://* URIs. Then people can browse it using compatible browsers or browser plugins for Firefox/Chrome.
IPFS is not the limit. **There's many different networks the web can reach through static sites** that could never have been integrated in a CMS. [Freenet](https://freenetproject.org/), for example, only supports static sites contrary to [Tor](https://torproject.org) and [I2P](https://geti2p.net/en/) which have onion and garlic services (respectively). Well your favorite static website can be hosted on Freenet, too!
In regards to the social web (the web as an open-standards social networking platform), the static web doesn't have all the tools ready just yet. We just need to write them! For example, we can write an ActivityPub or a webmention endpoint that connects to the repository to store incoming interactions following templates that would be standardized to match each SSG's data model. We're not there yet, but soon we'll exchange comments between my static site and yours, and they'all all be self-hosted on our own forge ;)
# Conclusion
[The web isn't just about us webdevs](https://sonniesedge.co.uk/talks/dear-developer). But building a more static web can make our lives a little better, by using tools that don't get in our way. Also, not having to constantly worry about security updates is a plus. The static web really offers hope for a better and more humane web, and opens the door to many positive innovations.
# PS: Are dynamic web services irrelevant?
Server-side programming hasn't become irrelevant in any way. It's just not needed and not desirable in most cases. **We just need to learn when building dynamic content from a database is appropriate**. Doing this for a showcase website or a simple blog is fore sure overengineering it. But the web as a platform to exchange and link dynamic data is still a thing! I've mentioned ActivityPub and Indieweb before. They're really great examples of web-based federation protocols, and just one of the many uses of server-side computing.
**The whole web doesn't have to be static. But most times, it just should be.**
_Note: This article was originally written in august 2018 but never got published. I updated it to reflect changes in the world around us (such as the Gutenberg SSG being renamed into Zola) but if you find outdated information, please [contact me](/contact) so i can correct it._

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 698 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 129 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 77 KiB

View File

@ -0,0 +1,110 @@
+++
title = "What happened to our dreams of real-time collaborative writing?"
date = 2019-07-31
[taxonomies]
skills = ["html5", "markdown"]
+++
Lately, i've been experimenting with real-time collaborative writing (pads) for editing a static website. Here's my story down the rabbithole of the Etherpad ecosystem and why writing Markdown with Etherpad in 2019 is still so complicated. Don't worry, we won't go too deep because i want to keep whatever's left of my sanity after spending a few days crawlin through a somewhat-antique codebase riddled with [dynamic typing](https://en.wikipedia.org/wiki/Dynamic_typing#Static_and_dynamic_type_checking_in_practice).
# Pad all the things!
Etherpad is a tool for real-time edition of documents. You create a pad on a pad server, and by giving other people its address, they can join in on the fun and start writing with you. Each person gets their own color, and all edits are saved so we can always roll back to a previous version if we need to. Also, pad URLs are predictable and easy to memorize: `https://SERVER/p/NAME` will take me to pad `NAME` (and create it if it doesn't exist yet) on Etherpad instance `SERVER`.
![Etherpad demo at École Henri Matisse Damgan](framapad_small.gif)
Back in the late 2000s, when Etherpad was released as an open source project, everyone was really thrilled about it. Many server operators started hosting public instances of Etherpad so anybody could collaborate on text. This was used by many collectives to write posts, do translations, or document things as people would do on a wiki. Many of us thought it would become very common over the years to have content-managing systems integrate pads in some form or another to promote real-time cooperation. This mostly did not happen, even though some CMS plugins do just that.
# The missing features
Over the years, Etherpad has grown an ecosystem of plugins that augmented its capacities. Some plugins are very well designed and supported, like [ep_mypads](https://framagit.org/framasoft/Etherpad/ep_mypads) (maintained by [Framasoft](https://framasoft.org)) which adds support for user-based and group-based permissions on pads because not everyone should be able to see/edit your content. But many others are at best unmaintained, if not utterly broken. That's the case with most plugins intended to add features to the editor, as we are going to see.
Support for adding images and links (or basically anything that is not plaintext) to a pad was nowhere to be seen, so some people wrote plugins for this purpose.
## Links
Links are the foundation of the web. But because of "security reasons", the Etherpad team never implemented proper support for links. They claimed a such feature could be used to trick users into clicking a malicious link, which is of course true of all links on the web. So the only way to link to another page by default is to write out its complete URL. You can link to a page, but you cannot give this link a nice title to fit into your content.
[ep_linkify](https://github.com/fourplusone/etherpad-plugins/tree/master/ep_linkify) adds the possibility to use internal links with the `[[page]]` syntax which generates a `<a href="page">page</a>` link. Still, no custom titles for links. While this is not too bad, ep_linkify is unmaintained. It was updated 2015 to follow some syntax changes, but nothing more. Also, the version found on the NPM repository (the recommended way to install Etherpad plugin) does not include this fix. So if you want to use this plugin, you need to install it from git directly, like so:
```
$ # From your etherpad-lite folder
$ git clone https://github.com/fourplusone/etherpad-plugins /tmp/etherpad-plugins
$ # Copy the plugin to the node_modules folder where Etherpad looks for plugins
$ cp -r /tmp/etherpad-plugins/ep_linkify node_modules/
```
[ep_embedded_hyperlinks2](https://github.com/seballot/ep_embedded_hyperlinks2) (successor to the defunct [ep_embedded_hyperlinks](https://github.com/inicio/ep_embedded_hyperlinks)) is a more complex plugin that adds a link button in the toolbox, so you can select any block of text and add a link on it just like you would in any WYSIWYG editor. However, the links are not generated in the HTML export.
## Images
There are two ways to embed images in an HTML document. The first is to link to the image, and let the browser load it separately. The second uses [data: URIs](https://en.wikipedia.org/wiki/Data_URI_scheme) to encode the image directly into the document (making it **huge**). Of these two approaches, the first is prefered in most situations because it allows to load the HTML document without necessarily having to download images (which can take a long time on slow connections).
[ep_previewimages](https://github.com/JohnMcLear/ep_previewimages) embeds external images in the editor, but they are not added to the HTML export. [ep_copy_paste_images](https://github.com/JohnMcLear/ep_copy_paste_images) only accepts images from the clipboard and encodes them to data URIs. [ep_image_upload](https://github.com/citizenos/ep_image_upload) only accepts images through file upload, not supporting external URLs.
In any case, none of these plugin support a description alongside the image, like `<img src="foo.png" alt="description">` in HTML or `![description](foo.png)` in Markdown. So yet again, the situation is far from ideal.
## Markdown
Markdown, the simple markup language used almost everywhere on the modern web, also has very poor support on Etherpad.
[ep_markdown](https://github.com/ether/ep_markdown) keeps Etherpad's markup language as the pad content and simply decorates the view with illusions of Markdown markup. It's visually ugly, but it's also far from functional. Links still can't have titles, and the Markdown export generates some weird stuff, like replacing raw URLs with `\url{https://...}`. Also, this plugin is unmaintained (issues on the bugtracker get no reply).
![ep_markdown is ugly](ep_markdown.jpg)
[ep_markdownify](https://github.com/f0i/ep_markdownify) works with actual Markdown within the pad. So you write Markdown as the pad content, and then the plugin renders it in the view. Behind the scenes, ep_markdownify doesn't use a proper Markdown parser; it uses the regex/prefix/suffix hacks provided by Etherpad's plugin API, which works surprisingly well! The support for images is far from ideal: they're stacked in the bottom-right corner of the screen. But the links work great! Except when they don't, because Etherpad's linking of raw URLs will take the closing parenthesis (and any text following until whitespace) into the href. So if you write `[link](https://thunix.net)`, clicking `link` will take you to [thunix.net](https://thunix.net), but clicking `thunix.net` will take you to [thunix.net)](<https://thunix.net)>).
So what's great with ep_markdownify is we can use the plaintext export as a Markdown source for the pad. What's less great is that this plugin is also unmaintained ([see here](https://github.com/f0i/ep_markdownify/issues/2#issuecomment-412354606) how to patch it for more recent versions of Etherpad).
As we just saw, the situation with Markdown is also not ideal. Still, many people requested Markdown support ([1](https://github.com/ether/etherpad-lite/issues/695), [2](https://github.com/ether/etherpad-lite/issues/1669), [3](https://github.com/ether/etherpad-lite/issues/3503), [4](https://github.com/ether/etherpad-lite/issues/3385)) because it would bring many features that have been missing for years in the Etherpad ecosystem.
When Etherpad came out, many markup languages were emerging. Markdown lacked many features and didn't have a proper specification. Nowadays, there is the [Commonmark](https://commonmark.org/) spec and Markdown is the de-facto standard for writing content on many blogs, forums, commenting systems, bugtrackers and other projects. Etherpad has been experimenting with their own markup language, but Markdown now addresses many of the issues they faced over the years.
# The future?
A week ago, i took for granted it would be easy to link pads together and get a Markdown export so i could generate a static site from it. But it all turned out to be wrong, mostly because i've had a consumer relationship with Etherpad. As an end-user, i did not see all of Etherpad's technical debt. However, things are still moving with Etherpad and the latest [v1.7.5 release](https://github.com/ether/etherpad-lite/releases/tag/1.7.5) brought support for [skins](https://etherpad.org/doc/v1.7.5/#index_skins). So maybe there is hope the situation improves.
![Colibris skin demo](47423842-c2e64980-d78e-11e8-8bd8-2aa0e01961ba.png)
It would not be hard to replace Etherpad with another solution such as [HackMD](https://hackmd.io) or [Gobby](https://gobby.github.io/), or even to write one from scratch. But taking a such approach would not address the issues for all the communities who rely Etherpad on a daily basis. So what can we do to change the status quo?
An obvious way of improvement would be to properly decouple and document different parts of Etherpad's codebase, so the synchronization logic can be used as a library for any custom client to use. That would allow easy integration of Markdown (and many other markup formats) as well as custom pad types, like HackMD proposes "templates" for making a slideshow or a docbook.
![How to make a slideshow with HackMD](hackmd_slideshow.jpg)
To some extent, that's already possible using [Etherpad's API](https://etherpad.org/doc/v1.7.5/#index_http_api), but this requires using an API key so you couldn't just plug your 3rd party client to any server. Properly exporting and documenting this internal API would help make initiatives such as [etherpad-vim](https://github.com/guyzmo/vim-etherpad) (who don't use an apiKey and therefore works with every server) easier to develop and maintain.
If supporting 3rd-party clients is not going to be a priority for the Etherpad project, we could probably try and improve the existing plugins. Forking ep_markdownify to implement HTML export and better support for images is a reasonable idea. But Etherpad's current plugin API prevents us from working with the whole content of the pad (it works on a node-per-node basis with hardcoded regex and prefix/suffix rules), making the situation for multi-line markup (such as tables) a lot tougher.
This situation with Etherpad is so disconnected from the dreams we had back then. And not because those dreams were technically unachievable, but because we've let them fall into the hands of cyberfascist [silos](https://indieweb.org/silo) such as Google Docs and Microsoft Office. It's time to reclaim our dreams.
Who knows, maybe in a couple years, federating pad permissions over different Etherpad instances will be a thing?
# [Annexes](https://en.wiktionary.org/wiki/annex)
## Accessibility concerns
Despite some [efforts](https://github.com/ether/etherpad-lite/issues/1803) to make Etherpad more accessible with screen readers (for visually-impaired users), requiring a GUI browser limits usability for people with [braille terminals](https://en.wikipedia.org/wiki/Refreshable_braille_display), as well as for people with old hardware incapable of running a modern browser. Supporting 3rd-party clients as proposed above would help a lot in regards to accessility.
## Towards a federation?
Etherpad is used by many collectives to provide private pads to their users, with the [ep_mypads](https://framagit.org/framasoft/Etherpad/ep_mypads) plugin. Now that we have user management, we could federate those users with other instances. Implementing a federation protocol such as [ActivityPub](https://www.w3.org/TR/activitypub/), [XMPP](https://xmpp.org/), or [SSB](https://www.scuttlebutt.nz/) would allow a user on an instance to give access to a private pad of theirs, to a user on another instance.
Currently, ep_mypads can either use a server-defined external identity provider (through [LDAP](https://en.wikipedia.org/wiki/LDAP)) or act as one with a hardcoded list of users. In the context of a federation protocol, the instance will in any case act as an identity provider. But the whole protocol doesn't have to be implemented. The point is to not reinvent the wheel. Smart people already have been through the process of writing federation protocols, and we can benefit from their experiences and past mistakes. Concretely, we can use one of the many readily-available software libraries for those federation protocols.
Additionally, and independently from the federation protocol adopted, we could leverage user-supplied identity providers through standard federated authentication protocols: [IndieAuth](https://indieauth.com) (from the [indieweb](https://indieweb.org) ecosystem), [Id4Me](https://tools.ietf.org/html/draft-bertola-dns-openid-pidi-architecture-01) (from the DNS ecosystem), [SAML](https://en.wikipedia.org/wiki/SAML), [RFC8414](https://tools.ietf.org/html/rfc8414) (from the OAuth 2.0 ecosystem) or even [XEP-0070](https://xmpp.org/extensions/xep-0070.html) (from the XMPP ecosystem).
## Security concerns
It is worth noting that using external resources raises some security questions. For example, loading external images can allow the hosts of these images to track pad users.To tackle this issue, we can either make image opt-in on the client side (through a clickable « Download image » block), or implement a server side cache of linked images and have the client query the cache instead of the actual source of the image. The second option would play well with Etherpad instances hosted [onion services](https://en.wikipedia.org/wiki/Onion_services#Onion_services) such as Riseup's [pads](http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/) (also available at [pad.riseup.net](https://pad.riseup.net)).
Links are less of a threat because users have the possibility to inspect them. Still, someone can maliciously replace a link with the intent to [phish](https://en.wikipedia.org/wiki/Phishing) people or infect their computer through [zero-day](https://en.wikipedia.org/wiki/0day) or unpatched vulnerabilities, knowing that many people won't bother to inspect them. These issues could be mitigated in various ways.
For example, we could have an instance-wide whitelist of domains anyone could link to. But this approach brings more questions than answers, in that pads are currently mostly a neutral and common tool where - except for some private instances - anyone can write anything. Restricting what users can do in the name of security rarely brings any security, but always empowers some people to exert more control over our tools and our lives.
But there's a less invasive way to deal with this: make sure editing a URL visually changes the color of the displayed link to match the person who did the edit. Just like with any other piece of text, with the subtlety that authorship of the link title would have to change when authorship of the link URL changes. So if [Alice](https://en.wikipedia.org/wiki/Alice_and_Bob) adds a link to her public key in the pad (`[Alice](https://example.com/alice.asc)`, when Mallory changes the link to `https://example.net/alice.legit.asc`, authorship for of the link should be attributed to Mallory. This way, when Bob goes to the pad where they usually hang out with Alice, he will notice instantly that the link doesn't match Alice's color.
Then again, that's what we can do if we think links are a threat. But maybe they're not! Encouraging users to inspect links isn't a waste of energy. If we feel like we need more security on our pads they contain crucial/private data, maybe we should consider setting up some forms of permissions management (or [ACL](https://en.wikipedia.org/wiki/Access_control_list)) so only logged-in users can read oredit certain pages.
Links are rather neutral as a tool: they are not themselves vectors of power dynamics, allowing centralization or decentralization of power depending on how links are used in practice. Links are the foundation of the web: restricting the use of links in web software contributes to damaging the [World Wide Web](https://en.wikipedia.org/wiki/WWW) in irreversible ways.

View File

@ -0,0 +1,16 @@
+++
title = "git-build.sh: un outil low-tech pour garder tes builds à jour"
date = 2020-04-25
+++
Est-ce que tu trouves ça dur de garder à jour tous tes projets git, et de rebuild tout quand il y a des mises à jour ? Bien, c'est peut-être facile pour quelques projets, mais que fais-tu quand il y en a plus ?
Maintenant, que fais-tu quand il y en a plus d'une dizaine répartis sur plusieurs serveurs ? La réponse est [git-build.sh](https://tildegit.org/southerntofu/git-build.sh) ! Ce script te permet de garder tes projets à jour, et d'automatiquement démarrer des taches ("task") quand des mises à jour sont disponibles. En plus, tu peux faire une configuration par machine (basée sur le `$HOSTNAME`) pour pouvoir partager le même `~/.git-build/` sur tes différentes machines.
Ce qui est spécial avec cet outil, c'est qu'il est **simple**. Son interface est conçue pour être à la fois sensée pour les humainEs, et scriptable par ordinateur. Cela permet de pouvoir la scripter avec tes outils favoris, tout en gardant la possibilité d'éditer quelque chose à la main si le besoin se fait sentir. Tout ce que tu dois savoir sur `git-build.sh` tient dans le fichier `README.md`.
Il y a probablement plein d'autres solutions dévelopées par d'autres personnes pour faire cela, pourtant je n'en ai pas trouvé. Si tu sais quelque chose, envoie moi un mail et j'ajouterai une mention dans le `README.md` du projet.
Ce blog est maintenant entièrement déployé grâce à `git-build.sh`. Pour publier un article, je commit et je push sur le dépôt, puis lance `git-build.sh` sur thunix.net. Si quelque chose va mal, j'ai `~/.git-build/static-publish.{log,err}` pour répondre à mes questions.
Voilà c'est tout. N'hésite pas à critiquer/commenter !

View File

@ -0,0 +1,18 @@
+++
title = "git-build.sh: a low-tech tool to keep your builds updated"
date = 2020-04-25
[taxonomies]
skills = [ "git", "shell" ]
+++
Do you find it hard to keep updated all your git projects and rebuild everything when updates are available? Well it may be easy for a handful project, but what do you do when there's a dozen of them?
Now, what do you do when there's dozens of them spanned across several servers? The answer is [git-build.sh](https://tildegit.org/southerntofu/git-build.sh)! It allows you to keep your projects updated, and automatically start some tasks when updates are available. In addition, per-host config is supported (based on `$HOSTNAME`) so you can share the same `~/.git-build/` configuration folder across machines.
What's really special about it, is that it is **simple**. Its interface is designed to be both meaningful to humans and machine-scriptable so you can integrate it with your favorite tools, yet still edit something manually when the need arises. Everything you need to know about `git-build.sh` fits in the `README.md` file.
There's probably plenty of other solutions developed by other people that fit this description, however i could not find any. If you know something, just mail me and i will place a mention in the project's `README.md`.
This blog is now fully deployed by `git-build.sh`. To publish an article, i just commit and push it to the repository, then run `git-build.sh` on thunix.net. In case something goes wrong, i have `~/.git-build/static-publish.{log,err}` to answer my questions.
That's all there is to it. Don't hesitate to criticize/comment!

View File

@ -0,0 +1,136 @@
+++
title = "Multi-column layouts for static sites using macros"
date = 2019-07-10
[taxonomies]
skills = ["html5", "flexbox", "@media", "markdown", "macros"]
+++
Today, we're gonna see how to build a simple multi-column widget with the [Zola static site generator](https://getzola.org/) (SSG). That's a common pattern in webdesign to have several columns of same width to present content. While many people load up a full CSS framework (such as [Bootstrap](https://getbootstrap.com/)) to achieve this, we'll simply use common and well-supported [CSS Flexbox](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Flexible_Box_Layout/Basic_Concepts_of_Flexbox) properties.
![Example from the getzola.org website](multi-column-zola.jpg)
Our widget should take a parameter for a page (inside the `content/` folder), parse the page's content and split it in different parts, then output those parts in separate columns (visually). For this demo, we will output 3 columns of same width and spaced evenly, but each column will fall back to full-width when the screen is too small (using media queries).
![Small-screen responsive view from the previous example](responsive-columns-zola.jpg)
Please be aware that i'm not a graphics designer so everything you'll find below is more or less ugly but functional. I'd be glad to receive feedback on making it all prettier!
# Organizing the content
So first, we want to find a convenient way to organize the content of our columns, so it can be easily edited and translated. As with most SSGs, we can use Markdown pages with Zola to describe our content. To separate the different columns within the Markdown document, we can use [thematic breaks](https://spec.commonmark.org/0.29/#thematic-breaks) that compile to `<hr />` HTML markup. These thematic breaks are used to separate (in meaning, and sometimes visually) different parts of the content: chapters of a book, slides of a presentation, or in our case columns for our webdesign.
These thematic breaks are triggered by having three or more consecutive dashes (`-`), stars (`*`), or underscores (`_`). For example, as of writing this article, the footer for this blog is generated from the following Markdown page `content/_common/footer.md`:
```
+++
title = "Footer"
date = 2018-01-03
+++
![Kopimi](/images/kopimi.svg)
# KOPIMI
© [CC BY-SA](https://creativecommons.org/licenses/by-sa/4.0/) license. Some graphics not mine. Just reproducing them here because [sharing is caring](https://kopimi.com/) and **FUCK PRIVATE PROPERTY!** [Problem?](/contact)
-----
![Anarcho-communism](/images/Anarchist-Comunism.svg)
# Topics
⚠️ Personal website & opinions. Tech-savvy anarchism / libertarian communism. Not interested? Feel free to browse away!
-----
<i class="fa-4x">~</i>
# Tildeverse
This blog is kindly hosted by [thunix.net](https://thunix.net), a proud member of the [Tildeverse](https://tildeverse.org) federation of autonomous hosting coops and cyber-hackerspaces.
```
# Multi-column layout with flexbox
So we want to reduce the boilerplate for our layout to a minimum, like so:
```
<div class="pillar">
<div class="pillar-column">First column</div>
<div class="pillar-column">Second column</div>
<div class="pillar-column">Third column</div>
</div>
```
To go alongside this HTML, we need some basic CSS styling:
```
.pillar {
display: flex; // We start a flex container (horizontal direction by default)
flex-wrap: wrap; // Columns should not grow outside their box
align-items: flex-start; // Columns should start at the top of their row
justify-content: space-evenly; // Columns should be spread horizontally
}
@media (min-width: 48em) { // Following rules only apply on screens larger than 48em
.pillar-column {
max-width: 33%; // On wide screens, a column should not exceed 33% of container width
}
}
```
# Building columns from the content with a macro
Zola has an amazing macro system, which basically allows us to define custom functions directly from within our templates. These macros accept parameters and can generate different output depending on them. [Tera](https://tera.netlify.com), the template engine powering Zola, has [docs about the macros](https://tera.netlify.com/docs/templates/#macros).
So we want to build a macro that:
- fetches content from a Markdown page
- splits it in different parts following thematic breaks
- outputs markup to place the parts in separate columns
Here's what this can look like in a `templates/macros/widgets.html` file:
```
{% macro pillar(contentPage) %}
<div class="pillar">
{% set page = get_page(path=contentPage) %}
{% set columns = page.content | safe | split(pat="<hr />") %}
{% for column in columns %}
<div class="pillar-column">
{{ column | safe | trim }}
</div>
{% endfor %}
</div>
{% endmacro pillar %}
```
Now that our macro is assembled, we can call it from any template. On this website, i've included such a layout in the footer in `templates/index.html`:
```
{% import "macros/widgets.html" as widgets %}
(…)
<footer>
{% block footer %}
<hr>
{{ widgets::pillar(contentPage="_common/footer.md") }}
{% endblock %}
</footer>
```
Of course, we can also create a [shortcode](https://www.getzola.org/documentation/content/shortcodes/) that wraps around it, if we want to summon a multi-column layout directly from within our content pages.
# Translations
The [get_page](https://www.getzola.org/documentation/templates/overview/#get-page) function used in the macro does not seem to return the localized version of the page at the moment. And this usage is not mentioned in the [multilingual docs](https://www.getzola.org/documentation/content/multilingual/). This will probably be addressed upstream at some point. There's [a discussion](https://zola.discourse.group/t/rfc-i18n/13) around a proposal for translation submitted by Keats, maintainer of the Zola project.
# Styling the layout
For the blog, i used an additional rule for styling. I want the first element in the column, when it's an image, to be of bigger size. This is the rule used:
```
.pillar-column > p:first-child > img:only-child { // Any single image, child of the first paragraph of a pillar-column
height: 4rem; // Is 4 times bigger
}
```
Of course there's a lot more you can do to make the style more responsive, more modern and more pleasant. I would love to see people coming up with their own stylesheets, because i'm not a designer :)
# Conclusion
Separation of concerns is important when building a website. We want to make it possible for website contributors to edit the content of the website without speaking HTML/CSS because we want to leave that to webdesigners. By leveraging macros and thematic breaks within content pages, we can allow many parts of the website to be editable directly from Markdown files, lowering the barrier to contribution and ensuring modifying the content of our website will not break the layout in terrible ways.
This pattern for building static websites AFAIK is not widely spread, and doesn't have a name yet. But there's room for improvement and innovation in this space that will push us towards websites that are easier to build and to maintain in the long run. This also enables us to share short macros and styles around so we don't have to reinvent the wheel every single time. Let's make it happen!

Binary file not shown.

After

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

View File

@ -0,0 +1,10 @@
+++
title = "Le début de Static Adventures"
date = 2018-08-17
+++
Bienvenue sur Static Adventures, un nouveau blog à propos des nouvelles technologies qui nous permettent de faire ressortir le meilleur du web. Ça fait un moment que je bidouille avec le web, et j'en ai ras-le-cul du [bloat](http://idlewords.com/talks/website_obesity.htm) et de la surcomplexité de tout. Le web pourrait être un réseau libre d'information qui rapproche les gens, mais nous avons utilisé ces pouvoirs à notre disposition pour rendre la vie des gens plus merdique et plus complexe. [Hé, les développeureses, le web n'est pas (que) pour nous](https://sonniesedge.co.uk/talks/dear-developer).
Sur ce blog, je compte publier mes expériences et découvertes. Ça va beaucoup parler de générateurs de site statique (SSG), d'utilisation du web comme réseau social décentralisé, et d'incorporer des mesures anti-censure et anti-surveillance dans nos sites web. En général, ça va parler de politique et de technologie et de politiques de la technologie. Ce blog est dédié à tous les peuples sur Terre se battant pour le changement social, des communautés auto-organisées du Kurdistan ou du Chiapas, aux révolutionnaires urbains qui [attaquent la Bête de l'intérieur](https://www.theguardian.com/technology/2018/jan/17/apple-bus-attack-pellet-guns-silicon-valley).
L'industrie technologique doit mourir. Toute industrie doit mourir. Brûlons tout, et cultivons sur ces cendres une société plus humaine et plus juste !

View File

@ -0,0 +1,10 @@
+++
title = "Starting Static Adventures"
date = 2018-08-17
+++
Welcome to Static Adventures, a new blog about how to use modern technologies to bring the web to its best! I've been messing around with the web for a while now, and I'm fed up with [web bloat](http://idlewords.com/talks/website_obesity.htm) and overengineering. The web could be a free network of information bringing people closer, but we've used the extra power at our disposal to make people's lives more shitty and complicated. [Dear developers, the web isn't about us](https://sonniesedge.co.uk/talks/dear-developer).
On this blog, I intend to post my experiments and findings. Mostly, it will be about static-site generators, using the web as a decentralized social platform, and incorporating anti-censorship and anti-surveillance measures into our websites. In general, it'll be about politics and tech and tech politics. This blog is dedicated to all people on Earth fighting for social change, from the self-organized communities in Kurdistan or Chiapas to the urban revolutionaries [attacking the beast from within](https://www.theguardian.com/technology/2018/jan/17/apple-bus-attack-pellet-guns-silicon-valley).
The tech industry needs to die. All industry needs to die. Let's burn everything down, and grow a more humane and fair society from the ashes!

1
content/contact.fr.md Symbolic link
View File

@ -0,0 +1 @@
contact.md

5
content/contact.md Normal file
View File

@ -0,0 +1,5 @@
+++
title = "Contact"
+++
<center>✉ southerntofu (@) thunix (.) net</center>

40
sass/custom.scss Normal file
View File

@ -0,0 +1,40 @@
:root {
--links: #A30006;
}
header {
> nav {
background-color: var(--text-bright);
> a {
color: var(--background);
font-weight: bolder;
}
}
> h1 {
margin: 0.5rem 0 0 0;
line-height: 1.1;
}
> h2 {
line-height: 1.1;
font-style: italic;
font-weight: normal;
margin: 0;
}
}
.skills {
background-color: var(--background-alt);
border-radius: 5px;
border: 1px black;
padding: 0.5em;
margin-top: 1em;
text-align: center;
}
.e-content {
> h1::before { content: "# "; opacity: 0.5; }
> h2::before { content: "## "; opacity: 0.5; }
> h3::before { content: "### "; opacity: 0.5; }
> h4::before { content: "#### "; opacity: 0.5; }
> h5::before { content: "##### "; opacity: 0.5; }
}

17
templates/index.html Normal file
View File

@ -0,0 +1,17 @@
{% extends 'water/templates/index.html' %}
{% block header %}
{{ widgets::menu(path=config.extra.menu) }}
{# TAXONOMY PROBLEM (not needed with Zola > 10.1) need to check if lang exists, do not display anything otherwise #}
{% if lang %}
{% set header = get_page(path=widgets::i18n_path(path=config.extra.header, lang=lang)) %}
{{ header.content | markdown | safe }}
{% if translations %}{{ widgets::translations(translations=translations) }}{% endif %}
{% endif %}
{% endblock header %}
{% block footer %}
{{ widgets::columns(path="_common/footer/index.md") }}
<hr>
{{ super() }}
{% endblock %}

17
templates/page.html Normal file
View File

@ -0,0 +1,17 @@
{% extends "water/templates/page.html" %}
{% block main %}
<article class="h-entry">
<div>
<h1 class="p-name">{{ page.title }}</h1>
<a class="u-url" hidden aria-hidden="true" href="{{ page.permalink }}">Permalink</a>
{%- if page.date -%}<time class="dt-published" datetime="{{ page.date }}">📅&nbsp;{{ page.date | date(format=trans(key="dateFormat", lang=lang)) }}</time>{%- endif -%}
</div>
{% if page.taxonomies.skills %}
<aside class="skills">
👍 {{ trans(key="skills", lang=lang) }}{% for skill in page.taxonomies.skills %}<a href="{{ get_taxonomy_url(kind="skills", name=skill) }}">{{ skill }}</a>{% if not loop.last %}, {% endif %}{% endfor %}
</aside>
{% endif %}
<div class="e-content">{{ page.content | safe }}</div>
</article>
{% endblock %}

6
templates/section.html Normal file
View File

@ -0,0 +1,6 @@
{% extends "water/templates/section.html" %}
{% block main %}
{# HACK: paginator is not set on transparent sections (i.e. blog/2020/_index.md) #}
{{ widgets::section(cur_section=section, full_articles=false, cur_paginator=paginator|default(value=false)) }}
{% endblock main %}

View File

@ -0,0 +1,12 @@
{% extends "index.html" %}
{% block main %}
<section>
<h1>{{ taxonomy.name }}</h1>
<ul>
{% for term in terms %}
<li><a href="{{ term.permalink }}">{{ term.name }}</a></li>
{% endfor %}
</ul>
</section>
{% endblock main %}

View File

@ -0,0 +1,15 @@
{% extends "index.html" %}
{% block main %}
<section>
<h1>{{ term.name }}</h1>
{% set page = get_page(path="_common/skills/" ~ term.slug ~ ".md") %}
{{ page.content | safe }}
<h2>Latest articles:</h2>
<ul>
{% for page in term.pages %}
<li><a href="{{ page.permalink }}">{{ page.title }}</a></li>
{% endfor %}
</ul>
</section>
{% endblock main %}