about summary refs log tree commit diff
path: root/readme.md
blob: e870276330d219d56dc44efb8e8a3fbba34beac8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# For Later
**Single-tile weather radar**  
Using the RainViewer API for the radar and an OpenStreetMap tileserver for the
map tile. Make a gif with a few frames of radar so we can embed it on the site.

Zoomed out far enough that I'm not worried about opsec and with no marker for
where I am in the tile.

## Dirfiles
These are files that match the name of the directory.

The problem with a normal `index.html` is that you need the full path to get a
semblance of what the file is for. This can be solved by matching the served
file of a directory to it's name. For example, a `multimedia/` would have it's
`index.html` renamed to `multimedia.html`. This does, however, make it harder
to change the name/path of directories as you'll have to rename the dirfile if
the directory name changes.

What do you name the root file, then? You shouldn't have to match the webroot's
directory name. Perhaps it should be configurable. I think for now we'll
hard-code in `home.html`, though.

**TODO:**  
we need to redirect directories to themselves with slashes. The browser thinks
that anything not ending in a slash is a file. It couldvery well be right, but
this causes chaos when we try to relative link to a directories resources.

## Page-content uses templates
Because writing the same outer-html for everything poses a few problems. I'll
enumerate them for fun!
1) it makes keeping a consistent page style difficult.
2) making a style change or renaming a core-stylesheet would require going
   through and editing a large number of files.
3) helps separate the layout and content of the page.

We're using the bempline templating engine. Not because it's the best or even
really *that good*, but because I wrote it and I like it :)

Page-content files will have frontmatter in the form:
```
---
key=value
---
```

blank lines and comments are acceptable. comments are lines starting with a `#`

with these keys being common and defined.

**title** (default: filename)  
the `<title>` of the page

== TODO: THE BELOW IS DREAMING ==

**og_title** (default: page title)  
the opengraph title of the webpage

**og_type** (default: website)  
TODO: not currently implemented. everything is a website.

**og_description** (default: none)  
a one or two sentence description of the page.

```html
<!-- required tags. us an image requried? i do not have one.-->
<meta property="og:title" content="nyble.dev | gone" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://nyble.dev/" />

<!-- not required but helps make better cards, etc. -->
<meta property="og:description" content="gone for now. stepped out for a bit." />
```

## Page content uses a weird kind of markup language
It's mostly just HTML, but I'm tired of writing `<p>` so damn much.

A block of text, a textblock, are consecutive lines that contain text. A double
linebreak separates blocks. If a block starts with a `<` it's assumed to be raw
HTML and will not be wrapped in a paragraph. 

You can escape any commands or annotations, both of which are described below,
with a `\`. Like this: `\[`. You can also escape the slash itself, `\\`, or an
opening greater-than, `\<`.

### commands

**[@paragraphs off]** - stop wrapping text-blocks in paragrapha and just pass
them through as is. this is useful for HTML.

**[@paragraphs on]** - start wrapping text-blocks in paragraphs starting at
the next line.

### annotations

**[#element-id]** - give the paragraph for this text block an ID of `element-id`