Add css functions and mixins post amd delete old test posts. prs site is basically done now !!

src/content/blog/css-functions-and-mixins.md

···
+---
+title: CSS functions and mixins
+bio: tl;dr and my 2 cents
+banner: mixins.png
+pub: 2000-01-01
+---
+
+The CSS `@function` rule is now available in chrome 139, with a definition for `@mixin` in the editors draft. (Referenced [First Public Working Draft](https://www.w3.org/TR/2025/WD-css-mixins-1-20250515/), Referenced [Editors Draft](https://drafts.csswg.org/css-mixins/))  
+I wanted an excuse to read into a spec, and this seems quite an interesting one so I thought why not write a post about it! (this is definitely not also because I need something to post when i deploy my site so it doesn't look empty lmao)
+
+> _All ye who travel beyond this point, head this warning_:  
+> This spec got hands and idk how to shut up so this is a long ish post. Sorry! Also sorry about any syntax highlighting bugs. This is an experimental spec and I'm using nesting too, which might cause visual bugs with my syntax highlighter. This should resolve with time though. I hope.
+
+---
+
+## 1. What's in a function anyway?
+
+CSS has a bunch of functions (`rgb`, `anchor`, `blur`, and `var` to name a few), which are all free of side effects and consistent\*, but are fully defined in the spec, without any way for developers to specify their own functions.
+
+\*CSS random, as discussed in [this webkit post](https://webkit.org/blog/17285/rolling-the-dice-with-css-random/), isn't always consistent (it's a random function after all) however it is 1) not in anything except safari TP so I'm not gonna count it and 2) I Cant Find Any Actual Spec. So. also not gonna count it.
+
+Imagine this css:
+
+```css
+h1 {
+  font-size: 3em;
+
+  @media (max-width: 1200px) {
+    font-size: 2em;
+  }
+  @media (max-width: 600px) {
+    font-size: 1em;
+  }
+}
+
+img {
+  width: 1000px;
+
+  @media (max-width: 1200px) {
+    width: 800px;
+  }
+  @media (max-width: 600px) {
+    width: 450px;
+  }
+}
+
+.screen-mode::after {
+  content: "desktop";
+
+  @media (max-width: 1200px) {
+    content: "tablet";
+  }
+  @media (max-width: 600px) {
+    content: "mobile";
+  }
+}
+```
+
+While this isn't the most realistic css (the font size probably doesn't need to change, the image could be more fluid with %/vw/vh/etc, and you would basically never need to do that with `::after`), it's useful for demonstration of a potentially useful function.
+
+Below we're going to start defining a function which will take in 1 to 3 parameters, and return values matching the media queries above (ie: if it matches 600px it'll return `--mobile`, falling back to `--tablet` if not defined, and falling back to `--desktop` if thats not defined, etc) It'll make more sense when we define it
+
+```css
+@function --media(--desktop, --tablet, --mobile) {
+  /* function body here */
+}
+```
+
+This CSS defines a new function, which we could later use like `width: --media(1000px, 800px, 450px)`, however currently the arguments don't matter, and the result is the "guaranteed-invalid value" (same as if you use something like `var(--not-set)` without a fallback) and so won't work.
+
+For this to be useful, we need a `result`. `result` is a property which can be used within `@function` to define the output of the function. A simple negation function could look something like this:
+
+```css
+@function --negate(
+  --value type(<length> | <number> | <length-percentage>): initial
+) {
+  result: calc(-1 * var(--value));
+}
+```
+
+But wait, I hear you ask, what does all that stuff after `--value` mean???  
+CSS functions let you define a type and default value for a function. I've used the type definition of `type(<length> | <number> | <length-percentage>)` to tell the browser that if you pass in a value that isn't either a length, number, or length percentage, then it should treat the value as invalid. (note: browser dev tools for this aren't the _best_ right now, but this will come with time)  
+The `: initial`
+
+Going back to our `--negate` function, usage like `--negate(10px)` returns `-10px`, and `--negate(-5%)` returns `5%`, however something like `--negate(twenty)` wouldn't work, as `twenty` is not of type number, and even if we didn't have the type, `calc(-1 * twenty)` makes no sense, and would be invalid.
+
+So we can see that `result` simply defines the output for the function. This is great for making complex, repeated calculations more legible, and for repeating reused syntax (`result: 10px 10px 5px var(--colour, black)` could be used for a `--shadow` function), but doesn't solve our function, which does media query things. Thankfully, `@function` supports `@media` inside it (and some other @rules)
+
+```css
+@function --media(
+  --desktop,
+  --tablet: var(--desktop),
+  --mobile: var(--tablet)
+) {
+  result: var(--desktop);
+
+  @media (max-width: 1200px) {
+    result: var(--tablet);
+  }
+  @media (max-width: 600px) {
+    result: var(--mobile);
+  }
+}
+```
+
+This above code returns desktop, unless the screen is <1200px, in which case it returns tablet, and if the screen is <600px, it returns mobile. If mobile isn't defined, it's the same as tablet, and if tablet isn't defined, its the same as desktop.
+
+We can now replace our original example with an updated `--media()` function!
+
+```css
+h1 {
+  font-size: --media(3em, 2em, 1em);
+}
+
+img {
+  width: --media(1000px, 800px, 450px);
+}
+
+.screen-mode::after {
+  content: --media("desktop", "tablet", "mobile");
+}
+```
+
+Another thing worth noting about `@function` is that it can access custom properties from the "calling scope":
+
+```css
+@function --double--x() {
+  result: calc(2 * var(--x));
+}
+
+h1 {
+  --x: 2em;
+  font-size: --double--x();
+}
+```
+
+Keep in mind that arguments "shadow" the custom properties.
+
+```css
+@function --double--x(--x) {
+  result: calc(2 * var(--x));
+}
+
+h1 {
+  --x: 2em;
+  /* wont work because --x is not passed in */
+  font-size: --double--x();
+}
+```
+
+If you want to be able to use custom properties when no argument is provided, you can set the default value to "inherit"
+
+```css
+@function --double--x(--x: inherit) {
+  result: calc(2 * var(--x));
+}
+
+h1 {
+  --x: 2em;
+  /* works because --x is inherited from context */
+  font-size: --double--x();
+}
+```
+
+As you can see; there's quite a lot to functions. If you want more specific and detailed information, or anything not explained here (like how to pass in comma seperated lists or more specific type syntax), your best bet is to reference the spec (and eventually MDN) and just experiment!
+
+## Mixin? Mixin what? Mixin. Now.
+
+(I don't know what the title means and at this point I'm too afraid to ask [my brain])
+
+As mixins are experimental and subject to change (and have no browser support yet) I'm not going to go into masses of detail like I did with `@function`, and instead just hit the highlights.  
+Also these examples might be stupid I'm not justifying the feature its Fine
+
+### Mixin Arguments
+
+The most basic mixin definition is like this:
+
+```css
+@mixin --copy-paste() {
+  /* properties go here */
+}
+```
+
+`@mixin` is defined in basically the same way as `@function`:
+
+```css
+@mixin --horrible(
+  --background <color>: red,
+  --accent <color>: blue,
+  --scale <number>: 1
+) {
+  /* properties go here */
+}
+```
+
+Unlike `@function`, mixin properties are exposed under `env()`, not `var()`, so theres no risk of conflict and the properties arent injected outside the body. If you want values to be able to be accessed from outsize the mixin, you can still use custom properties.
+
+Mixins can also accept blocks of properties as an argument:
+
+```css
+@mixin --mobile(@contents) {
+  /* properties go here */
+}
+```
+
+And can accept both at the same time:
+
+```css
+@mixin --weird(--bg: <color>, @contents) {
+  /* properties go here */
+}
+```
+
+### Mixin Application
+
+When no args are passed/needed, you can do this to `@apply` a mixin:
+
+```css
+body {
+  @apply --copy-paste;
+}
+```
+
+Passing arguments is basically the same as custom functions:
+
+```css
+body {
+  @apply --horrible(orange, purple, 2);
+}
+```
+
+`@content` can be used like this:
+
+```css
+body {
+  @apply --mobile {
+    background-color: red;
+  }
+}
+```
+
+And you can use arguments and `@contents` together like this:
+
+```css
+body {
+  @apply --weird(red) {
+    color: blue;
+  }
+}
+```
+
+### Mixin Bodies
+
+Mixin bodies are **_basically_** inserted wherever `@apply` is used. Just list the properties you want to include inside the mixin and they'll be inserted, including custom properties.
+
+You can access the arguments to the function via a dashed indent in `env()`:
+
+```css
+@mixin --horrible(
+  --background <color>: red,
+  --accent <color>: blue,
+  --scale <number>: 1
+) {
+  background-color: env(--background);
+  color: env(--accent);
+  border: calc(5px * env(--scale)) groove env(--accent);
+  border-radius: 50%;
+  float: right;
+  &:hover {
+    background-color: env(--accent);
+    color: env(--background);
+    border-color: env(--background);
+  }
+}
+```
+
+You can insert whatever properties were passed into a mixin using the `@contents` at rule:
+
+```css
+@mixin --mobile(@contents) {
+  @media (max-width: 600px) {
+    @contents;
+  }
+}
+```
+
+You can also provide a default value for `@contents`:
+
+```css
+@mixin --mobile(@contents) {
+  @media (max-width: 600px) {
+    @contents {
+      &::before,
+      &::after {
+        display: block;
+        background-color: red;
+        color: black;
+        contents: "Warning: Unused `@apply --mobile`. Include a declaration list";
+      }
+    }
+  }
+}
+```
+
+If no declaration list is passed to the mixin, the fallback will be used instead.
+
+In a mixin, if you use custom properties, they are inserted along with other properties. This is useful if you want values to be accessible to the user (ie: exposing a colour derived from input for use elsewhere), but also pollutes the namespace. As such, you should avoid using custom properties when you don't explicitly want the user to read/override things. As such, use `@env` to define environment variables scoped to the mixin body.
+
+```css
+@mixin --mix-colour(--col1, --col2) {
+  @env --mix: color-mix(in oklab, env(--col1), env(--col2));
+  color: env(--mix);
+}
+```
+
+In this example `env(--mix)` is only avaliable inside the `--mix-colour` body, and doesnt pollute the calling context.
+
+Thats about the gist on mixins, its very new and experimental and has 0 implementation so go read the spec yourself lol
+
+## Listen to me speak now please thank you
+
+First note: I think these are really good so far, maybe some slight tweaks needed for mixins. I will say that with mixins I'm not the BIGGEST fan of using `env()`, but if I remember correctly it originally started with an `@result` at rule or something like that, so I'm pretty sure theres a reason we got an `@env` etc instead. That said I dont really mind `env()` to much so its Fine lmao.
+
+I also think its worth considering named `@contents` blocks instead, maybe something like this:
+
+```css
+@mixin --media(--desktop @contents, --mobile @contents) {
+  @media not (max-width: 600px) {
+    @contents --desktop {
+      desktop-fallback: here;
+    }
+  }
+  @media (max-width: 600px) {
+    @contents --mobile {
+      mobile-fallback: here;
+    }
+  }
+}
+
+body {
+  @apply --media() {
+      desktop-properties: here;
+    } {
+      mobile-properties: here;
+    }
+  }
+}
+```
+
+The current syntax of having a single trailing `@contents` and single trailing `{/*properties*/}` for cases where only one `@contents` is needed. This might need some tweaking for legibility etc, but some way to add multiple `@contents` blocks would be nice. I agree with the enforcing of them being at the end of the argument list though.
+
+Another suggestion, which may be defered to level 2: expose functions to CSS houdini.
+
+For example, something like this:
+
+```js
+// index.js
+CSS.functions.addModule("css-arrays.js");
+```
+
+```js
+// css-arrays.js
+registerFunction(
+  "--get",
+  class {
+    static get arguments() {
+      return [
+        {
+          type: "<string>#",
+        },
+        {
+          type: "<number>",
+          default: 0,
+        },
+      ];
+    }
+
+    eval(array, index) {
+      return array[index];
+    }
+  },
+);
+```
+
+`css-arrays.js` would run in a custom Worklet environment, most likely a plain ECMAScript environment with no APIs, which may be created and destroyed on each call. It wouldn't open the door to advanced functionality like `--anchor`, but could make "simpler" functions ponyfillable, like arrays/objects, or even things like `color-mix`.
+
+This is NOT a formal proposal, just a suggestion. Might make an issue in the repo later if I can be bothered.
+
+---
+
+Anyway, to conclude: I'm extremely happy with the reccomended API right now, and I would be happy to see this or something very similar land in browsers. Also let us do functions with JS it would be v good for ponyfilling.

src/content/blog/nested/test.md

···
----
-title: Testing nesting
-bio: nested !!
-banner: nested.png
-pub: 2025-08-13
----

src/content/blog/test.md

···
----
-title: Test
-bio: A Test Post
-banner: test.png
-pub: 2025-08-13
----
-
-## Header 2
-
-Paragraph  
-
-Second paragraph with *italics*, **bold**, and ***both***
-
-## Header 2
-### Header 3
-
-theres some `inline code`  
-and heres an html
-```html
-<span class="gay">Code Block</span>
-<!-- with a really super duper long comment aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -->
-```  
-
-```js
-smallLine()
-```
-
-## Header 2
-### Header 3
-#### Header 4
-
-> albert einstein said that or smthn  
-> idk what that guy said  
-> he was inertia or smthn  
-> smart meters  
-
---- 
-
-ol lorem ipsum dolor amet dolor sit  
-
-1. lists
-2. ordered
-    1. nested
-    2. properly
-        1. testing
-        1. testing
-            1. testing
-            1. testing
-            1. testing
-                1. testing
-                1. testing
-                1. testing
-                    1. testing
-                    1. testing
-                    1. testing
-                        1. testing
-                        1. testing
-                        1. testing
-                            1. testing
-                            1. testing
-                            1. testing
-                                1. testing
-                                1. testing
-                                1. testing
-                                    1. testing
-                                    1. testing
-                                    1. testing
-    3. see
-3. can go back out too
-1. numbers dont matter
-1. just gotta be there
-
-ul lorem ipsum dolor sit amet dolor sit  
-
-- unordered
-- lists
-    - nested
-        - deeper
-    - unnesting
-- see
-
-cl lorem ipsum dolor sit amet amet dolor sit  
-
-- [ ] incomplete
-- [ ] task
-    - [ ] relies on
-        - [x] complete task
-        - [x] eventually
-- [x] done
-
-ml lorem ipsum amet dolor sit  
-
-- unordered
-    1. then ordered
-        - then unordered
-            - [ ] then a list
-            - [x] which isnt done yet
-
-[heres a link](/) <https://example.com> <[e-mail]> 
-![an image](./assets/nested.png)
-
-## h2
-
-| Column  | Col2    |
-| ------: | :------ |
-| testing | testing |
-| empty cells |