factotum/NOCLIP
1
Fork 0
Code Issues 10 Projects Releases Activity
NOCLIP/documentation/templates/style.css

318 lines
7.2 KiB
CSS
Raw Normal View History

docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
@charset "UTF-8";
:root {
/* Base16-Eighties, lightly modified*/
--gray-n2: #1E1E1E;
--gray-n1: #262626;
--gray-0: #2D2D2D;
--gray-1: #393939;
--gray-2: #515151;
--gray-3: #747369;
--gray-4: #A09F93;
--gray-5: #D3D0C8; /* foreground */
--gray-6: #E8E6DF;
--gray-7: #F2F0EC;
--red: #F2777A;
--orange: #F99157;
--yellow: #FFCC66;
--green: #99CC99;
--aqua: #66CCCC;
--blue: #6699CC;
--purple: #CC99CC;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
--pink: #FFCCFF;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
/* Semantic aliases*/
--background-color: var(--gray-0);
--foreground-color: var(--gray-5);
--nav-color: var(--gray-n2);
--sidebar-color: var(--gray-n1);
--border-color: var(--gray-1);
--example-min-width: 950px;
--description-max-width: 850px;
--description-min-width: 600px;
--section-header-height: 70px;
--nav-sidebar-width: 270px;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
--nav-horizontal-padding: 30px;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
/*@media (prefers-color-scheme: light) {
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
:root {
--background-color: var(--gray-7);
--foreground-color: var(--gray-1);
--sidebar-color: var(--gray-6);
--border-color: var(--gray-6);
}
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
}*/
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
body {
background: var(--background-color);
color: var(--foreground-color);
margin: 0;
font-size: 16pt;
font-family: sans-serif;
}
pre { margin: 0; }
p {
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
color: var(--foreground-color);
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
hyphens: auto;
-webkit-hyphens: auto;
margin: 0;
}
p + p {
text-indent: 1em;
}
body .layout {
height: 100vh;
display: grid;
grid-template-rows: 1fr;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
grid-template-columns: auto 1fr;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
grid-template-areas: "sidebar doc";
max-width: 100vw;
}
body .layout .sidebar {
grid-area: sidebar;
/* border-right: 2px solid var(--border-color);*/
background: var(--nav-color);
overflow: scroll;
}
body .layout .sidebar nav {
padding-bottom: 1em;
}
body .layout .sidebar .header {
position: sticky;
top: 0;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
box-sizing: border-box;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
background: var(--nav-color);
height: var(--section-header-height);
line-height: var(--section-header-height);
font-size: 20pt;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
padding: 0 var(--nav-horizontal-padding);
width: var(--nav-sidebar-width);
}
label.collapse-label {
display: block;
cursor: pointer;
}
input.collapse-toggle {
display: none;
}
input.collapse-toggle:checked + label.header {
color: var(--blue);
transform: rotate(90deg);
width: var(--section-header-height);
}
input.collapse-toggle:checked + label.collapse-label + .collapse-view {
max-height: 0;
max-width: 0;
padding: 0;
overflow: clip;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
body .layout .sidebar .nav a {
color: var(--gray-4);
text-decoration: none;
}
body .layout .sidebar .nav a:hover {
color: var(--blue);
}
body .layout .sidebar .nav .item {
box-sizing: border-box;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
padding: 0.2em var(--nav-horizontal-padding);
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
body .layout .doc {
grid-area: doc;
height: 100vh;
overflow-y: scroll;
}
documentation: semi-minimally-functional zed It can load things from files now, but the cmark dependency needs to be properly integrated into the build still.
2023-05-11 11:06:28 -07:00
a {
text-decoration: none;
font-weight: bold;
color: var(--blue);
}
a:hover {
text-decoration: underline;
}
p code {
background: var(--sidebar-color);
color: var(--gray-4);
/* border-radius: 10px;*/
}
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
body .layout .doc .doc-padding {
padding-bottom: 80vh;
max-width: 100%;
}
documentation: tweak the style a bit There are a few additional things worth fixing here I think but it's probably better to actually write the documentation first.
2023-04-08 15:17:36 -07:00
body .layout .doc .doc-padding::after {
bottom: -40vh;
color: var(--gray-1);
content: 'THIS OVERSCROLL INTENTIONALLY LEFT BLANK';
display: block;
font-size: 30px;
font-weight: bold;
position: relative;
text-align: center;
width: 100%;
}
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
body .layout .doc section {
display: grid;
grid-template-columns: minmax(var(--description-min-width), var(--description-max-width)) minmax(var(--example-min-width), 1fr);
grid-template-areas: "description example";
}
body .layout .doc section .header {
grid-column-start: description;
grid-column-end: example;
background: var(--sidebar-color);
font-size: 20pt;
line-height: var(--section-header-height);
padding: 0 1ex;
/* position: sticky;*/
/* top: 0;*/
/* border-bottom: 1px solid var(--border-color);*/
}
documentation: tweak the style a bit There are a few additional things worth fixing here I think but it's probably better to actually write the documentation first.
2023-04-08 15:17:36 -07:00
body .layout .doc section .header::before {
content: "#";
display: inline-block;
visibility: hidden;
margin-right: 0.3em;
color: var(--gray-3);
}
body .layout .doc section .header:hover::before {
visibility: visible;
}
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
body .layout .doc section .description {
grid-column-start: description;
grid-column-end: description;
box-sizing: border-box;
padding: 1em;
text-align: justify;
}
body .layout .doc section .example {
grid-column-start: example;
grid-column-end: example;
overflow: visible;
}
body .layout .doc section .example .codebox {
box-sizing: border-box;
position: sticky;
top: 0;
overflow-x: scroll;
background: var(--sidebar-color);
padding: 1em 1em;
border-bottom: 15px solid var(--background-color);
}
body .layout .doc section .example .code-markup {
counter-reset: example;
font-size: 12pt;
line-height: 1.3;
/* border-left: 2px inset black;*/
/* box-shadow: 10px 0 10px -10px var(--gray-n2) inset;*/
/* top: var(--section-header-height);*/
}
body .layout .doc section .example .code-markup .line {
padding-right: 1em;
}
.code-markup .keyword { color: var(--purple); }
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
.code-markup .type { color: var(--purple); }
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
.code-markup .builtin { color: var(--aqua); }
.code-markup .string { color: var(--green); }
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
.code-markup .comment { color: var(--gray-3); }
.code-markup .literal { color: var(--orange); }
documentation: semi-minimally-functional zed It can load things from files now, but the cmark dependency needs to be properly integrated into the build still.
2023-05-11 11:06:28 -07:00
.code-markup .label { color: var(--yellow); }
.code-markup .field-name { color: var(--red); }
.code-markup .variable { color: var(--red); }
.code-markup .function { color: var(--blue); }
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
/*It turns out these have to come after the directives they override.*/
@media (max-width: 1820px) {
body .layout .doc section {
display: grid;
grid-template-columns: 1fr;
grid-template-areas: "header" "description" "example";
}
body .layout .doc section .description {
max-width: var(--description-max-width);
}
body .layout .doc section .example .codebox {
max-width: calc(100vw - var(--nav-sidebar-width));
border-bottom: none;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
position: initial;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
body .layout:has(> .sidebar #destroyer-of-navs:checked) .doc section .example .codebox {
max-width: calc(100vw - var(--section-header-height));
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
body .layout .doc section .example:last-child {
margin-bottom: 15px;
}
}
@media (max-width: 1220px) {
body .layout {
display: grid;
grid-template-rows: auto auto;
grid-template-columns: 1fr;
grid-template-areas: "sidebar" "doc";
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
height: initial;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
max-width: 100vw;
}
body .layout .sidebar {
overflow: visible;
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
position: sticky;
top: 0;
z-index: 1;
}
input.collapse-toggle:checked + label.header {
width: 100%;
transform: initial;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
}
body .layout .doc {
docs: fiddle around with collapsible nav This probably needs polishing. Or just not to be done in the first place.
2023-04-05 18:20:04 -07:00
height: initial;
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
overflow-y: initial;
}
body .layout .doc section .description {
width: 100%;
margin: auto;
}
documentation: tweak the style a bit There are a few additional things worth fixing here I think but it's probably better to actually write the documentation first.
2023-04-08 15:17:36 -07:00
body .layout .doc section .example .codebox,
body .layout:has(> .sidebar #destroyer-of-navs:checked) .doc section .example .codebox {
docs: bad but in a good way I've decided (perhaps stupidly) to eschew existing static site generators and documentation templating systems. It seems fitting to reinvent the wheel, which is something this project is entirely about doing. The actual justification is a drama in a few very pathetic parts: a) existing documentation tools and static site generators are written primarily in other programming languages. It feels bad to have a dependency on a completely separate programming language ecosystem to build the documentation. b) existing documentation tools on average do a lot of things I don't like. Things like trying to haul in google analytics and fonts and in general having a truckload of javascript jammed in the frontend. The page should have minimal or (ideally) no javascript at all. c) modern documentation generators have really standardized on a three column layout that looks flashy but doesn't make very good use of space, and I think there's room to experiment with some ideas I've seen while looking around. So here we are. The approach being taken is to hand-roll html+css directly, and that will hopefully converge to something that isn't garbage. Once that has run its course, I will start considering what level of automation makes sense to add. Important takeaways: 1. Modern CSS is absurdly complex. It has had so many features jammed into it over the years, it's completely nuts. I don't think it's possible for any single person to store the details of all of it in their head. 2. Using non-tiny fonts takes up a lot of room quite quickly. Even if you want to have a column larger than 800px, it's very easy to run out of space quickly. 3. there's more than one way to make a list in ascii.
2023-04-04 04:37:22 -07:00
max-width: 100vw;
}
}
Reference in New Issue Copy Permalink