this post contains a list of things i want to do with this blog

In making a tiny blog, I wanted to force myself to write more; I like writing, and I enjoy the act of making stories, but I found that whenever I took a break from writing for even a little bit, I’d regress heavily. By making a blog, and thus, by forcing myself to write more, even when it’s not about stories, I would try to make sure my writing elsewhere stayed sharp.

You will notice that there’s nearly a month-long gap of posts in this blog already. You will also notice that, instead of a traditional writing post, all I did to stop that dry spell was posting this SCSS function, which is a kind of writing, but not, like, prose. This is because, in deciding I needed to make a tiny blog, I proceeded to re-remember all the CSS I had forgotten over the years… which, uh, made me realize just how much CSS is different from when I was a decade younger.

I went right to SASS, in making this blog, because I assumed that since I hadn’t heard much about CSS in recent years that there’d basically be no new developments, as opposed to looking up a random function I wanted, and then learning that, actually, nearly everything I’d want SASS for and more is in CSS now. Not just being able to nest selectors, which is the most pleasant surprise, ^{[1] Link to footnote 1} but shit like color mixing and modern selectors that basically lets you do what most mixins are for anyways and… layers!? Wait, they just let you do that yourself now? I saw a guide to @layer, in particular, and it reminded me of just why I used to tinker so much with using CSS when I was a kid. In a world where coding a thing meant that you had to compile, and recompile, and re-recompile, web development was something where I could mess with it and instantly get an output showing what I did.

This has, genuinely, lit up the fire I had as a teenager, when I really wanted to get into webdev as a career, ^{[2] Link to footnote 2} and now I have spent far too much time than is healthy retracing all my steps from back then.

Thus, the todo list. Here we go:

ditch scss entirely

On paper, the only thing I’ll truly miss from SCSS is comments not feeling like shit to put in. If you don’t know, CSS comments are like this:

/* Man this is, like, the most annoying combination of keystrokes */

And SCSS comments are like this:

// Oh thank god something that'll make me want to put in comments

I want you to type in two slashes, into whatever text field is closest to you, and then compare that with typing in /* this nonsense */. One of these is, very obviously, significantly less annoying to do. This isn’t a small problem, in my opinion; if there’s one thing I’m learning very quickly, it’s that your CSS being legible is a thousand times more important than anything else, and that starts with writing comments, which, therefore, starts with actually wanting to write in the comments. I get why it’s not something you can plug in willy-nilly; CSS isn’t actually a multi-line syntax, so just two slashes wouldn’t actually be parsable, whereas SCSS can just spit out double-slashes into more CSS-friendly formats–but like, man, could you at least let me replace the asterisks with a second slash, or something? Having to make my right hand do acrobatics every time I want to explain what a custom property does is annoying, dude.

…Ahem. Regardless, everything else I’d want in SCSS is either covered by new CSS goodies, or it’s covered by me throwing shit at LightningCSS and seeing what sticks. Sass, as a concept, feels like something that’s becoming downright wasteful over time, and if I want to actually get up to speed, I’ll start by seeing how little of it I actually require. I’m sure there’s a solution to having relatively sane comments that won’t require me to do anything too esoteric, especially since I’m using a postprocessor that could theoretically just handle it.

learn how layers work

As a starting point, it seems not insanely hard to wrap my head around? So like, you put some stuff at the top like

@layer lowprio, midprio, highprio;

and then you call it like

@layer highprio {
    p {
        color: purple;
    }
}

@layer midprio {
    p {
        /* this bit stays */
        font-size: 1.125em;
        /* this bit doesn't */
        color: green;
    }
}

@layer lowprio {
    p {
        /* neither of these stay */
        font-size: 1rem;
        color: red;
    }
}

and then the paragraph would be purple and not green or red, and it’d be sized at 1.125em and not 1em, because purple and 1.125rem would both be the higher priority thing. While fucking around, I noticed that you can also do the opposite, so you can nest the @layer lowprio in the p instead. I imagine, since unlayered stuff takes priority, you could have, like, a reverse-!important, ^{[3] Link to footnote 3} where you need to make 100% sure that something only comes up if nothing else is already there:

That all tracks, what I think is going to take a bit with it isn’t that, it’s moreso that CSS, up until this point, has always been about unlearning all the ways I’d want to organize everything. I might want some stuff that I mess with to appear closer to the top of the text editor, but that might break everything in two without me noticing! I’ve gotta throw around !important modifiers or else I might move a single selector and instantly shatter my entire web page!

It’s going to take a bit because this feels too comfortable, and that means I’m going to keep thinking it feels wrong for a while, until it doesn’t. Completely pulling this out of my ass, but if I were to hazard a guess, I’d probably want something on this blog that’s like

@layer reset, base, overlay, fakemixins;
@import url(reset.css) layer(reset);

@layer overlay {
    /* all my spending-three-hours-styling-one-frontpage-tag stuff */
}

@layer base {
    /* all my touched-this-once-three-weeks-ago-and-never-again stuff */
}

and that would probably do well enough for now. Speaking of that last layer…

try out some freak modularity shit for clamping

The little I still make use of a sass preprocessor for, on paper, is stuff you could just throw into custom properties. Probably the easiest example of me being kinda lazy is in the <hr> adjacents I use; I hate dealing with inlined SVGs in CSS, so instead I have an extremely unnecessary function that exists exclusively so I can throw in the raw HTML, and have it spit out base64-friendly code later.

…I’m not even sure why I don’t just inline it in the HTML in the first place, really. I guess I’m just so used to inlining that stuff that I never thought about it.

As I’ve shown on this blog, the way I do fluid type in SCSS will never work in pure CSS, despite MDN implying otherwise, but that also isn’t the only way to do fluid type. I already linked it before when pointing out that you basically already have what most mixins are for, but for posterity, that site selects, in one block, everything that needs fluid type attached to it, all around a --font-size custom property, and then you just customize each element like

h1 {
    --font-size: var(--font-size-1);
}
h2 {
    --font-size: var(--font-size-2);
}
h3 {
    --font-size: var(--font-size-3);
}

so that each one is building a calc off a different number. Seems a thousand times less complicated than what I’m doing to get similar output, if anything.

This is a list of ideas I have right now, anyways. I may try to set up some frontpage situation that shows what I have and haven’t done; it’ll feel nice to check it off, especially in the one place I have to go to every time I test stuff locally. I dunno! This is the fist time in a really long time that something’s been kind of exciting for me to mess with, so I can’t say. If nothing else, it’ll make for a fun learning experience to mess around in, even if the end result kind of sucks ass.