figures & figcaptions for docs

could probably work in trees but eh
This commit is contained in:
りき萌 2025-08-31 12:54:13 +02:00
parent 944a56800e
commit ce04cbdc92
2 changed files with 68 additions and 7 deletions

View file

@ -133,10 +133,23 @@ It was a fight to the death over who can win the most friends online in a room a
It was a matter of creating the best multiplayer painting app, and swaying our whole community over to it. It was a matter of creating the best multiplayer painting app, and swaying our whole community over to it.
{.wide} {.wide}
:::: figure
![MultiPixel running in the browser. There's a toolbar listing a bunch of tools on the left, including brushes, a flood fill, an airbrush, and smears. Next to that is a brush settings window, with a colour palette, and sliders for Size, Flow, and Smoothing. On the canvas there's a couple scribbles, including an at "@" and a tilde "~".][pic:01K3XBA43PZMKRC6VGJE0DYSB5] ![MultiPixel running in the browser. There's a toolbar listing a bunch of tools on the left, including brushes, a flood fill, an airbrush, and smears. Next to that is a brush settings window, with a colour palette, and sliders for Size, Flow, and Smoothing. On the canvas there's a couple scribbles, including an at "@" and a tilde "~".][pic:01K3XBA43PZMKRC6VGJE0DYSB5]
{.overlay-bottom-right}
::: figcaption
This is what MultiPixel looks like today.
It's got plenty of drawing tools.
:::
::::
Ultimately, I think MultiPixel won the battle. Ultimately, I think MultiPixel won the battle.
It had a browser version, a flood fill tool, and undo/redo, and that was enough to make the drawing experience _miles_ better than what NetCanv could ever hope to offer. It had a browser version, a flood fill tool, and an undo feature, and that was enough to make the drawing experience _miles_ better than what NetCanv could ever hope to offer.
The one thing NetCanv was better at was performance, being a native app written in OpenGL, with client-side, GPU-powered rendering of brushes. The one thing NetCanv was better at was performance, being a native app written in OpenGL, with client-side, GPU-powered rendering of brushes.
But raw performance is never nearly enough to win people over. But raw performance is never nearly enough to win people over.

View file

@ -108,13 +108,50 @@ main.doc {
} }
} }
& figure {
margin: 0.5lh 0;
position: relative;
& p:has(img.pic) { & p:has(img.pic) {
padding: 0;
}
& img {
display: block;
margin: 0;
}
& figcaption {
padding: 0.25lh 0.5lh;
text-align: center; text-align: center;
& p {
padding: 0;
}
&.overlay-bottom-right {
position: absolute;
right: 0;
bottom: 0;
background-color: var(--background-color);
border-top-left-radius: 0.8rem;
border-bottom-right-radius: 0.4rem;
text-align: left;
}
}
}
& p:has(img.pic),
& figure p:has(img.pic) {
text-align: center;
}
& .wide { & .wide {
grid-column: left-wide / right; grid-column: left-wide / right;
} }
}
& header { & header {
& h1 { & h1 {
@ -171,8 +208,8 @@ main.doc {
& .doc-text { & .doc-text {
--code-block-grid-space: 0; --code-block-grid-space: 0;
& > pre, & pre,
& > th-literate-program { & th-literate-program {
/* Stretch to whole page. /* Stretch to whole page.
This way of doing it feels a bit brittle, though. This way of doing it feels a bit brittle, though.
It might be good to refactor this to CSS grid at some point. */ It might be good to refactor this to CSS grid at some point. */
@ -190,6 +227,17 @@ main.doc {
tab-size: 2ch; tab-size: 2ch;
} }
} }
& figure figcaption {
&.overlay-bottom-right {
position: static;
background: none;
border-radius: 0;
text-align: center;
}
}
} }
} }
} }