📌 Bookmarklets!

Did you know you can run javascript with a URL?

In place of a http: or https:, you can prefix a URL with javascript: and it will evaluate the following text as JS. You'll still need to URL encode the Text, but it does provide a handy way to use JS.

Bookmarklets are a term for Bookmarks, which trigger some Javascript instead of loading a webpage.

Some bookmarklets I use.

Drag the Link into your bookmarks bar to use it yourself!

• New Window Props

  This bookmarklet checks where your current window properties differ with the Initial window object.

  Handy for checking what global objects are declared when adding a js script

  New Window Props

• Picture in Picture Mode

  Firefox has a PIP Button overlayed on videos. Chrome does not.

  Handy for triggering PIP mode on any webpage with a video.

  Picture-in-Picture

😱 Emoji OMG

Pulling an emoji from text isn't super straightforward. There's no special character for emoji in regex.

I'd like to start replacing the favicon for the page with a favicon found in the <h1> of the current section. So the first step is determining if there's an emoji in the <h1> at all. However, this task is tricker than it seems. EVERYTHING online indicates the best solution is a LONG LONG string of regex which tests the unicode data.

I'll do some research and see if I can find a better way to do determine if a character is regex.

My Findings!

The typical advice you'll find online when searching for how to determine if a character is an emoji is to use RegEx, but I've found a MUCH easier way!

Strings in js can be split into characters, and with the spread operator, it's easy!

Splitting a String into Chars

const string = "🤖: Hello World! 👋";
const charList = [...string]; // [ "🤖", ":", " ", "H" [[...]] , "d", "!", " ", "👋" ]

Which doesn't mean much on it's own. Frankly, it's more cumbersome to deal with. BUT! Javascript did something interesting! It didn't split up ALL the characters! As you can see from the any emoji regex example, Emojis are comprised of MANY characters! Those characters will render as a single, emoji.

So JS is put in a weird position. The EXPECTED behavior of splitting a string, is accomplished. Yet, the LENGTH of each character, is technically different! Since Emojis are just unicode data rendered in a particular way, splitting a string does something fascinating in JS.

"🤖".length; // outputs: 2
"👋".length; // outputs: 2
"📌".length; // outputs: 2

What it means!

Because JS splits a string by what is rendered, not by how it's represented in data, String.length does something super fascinating! It will give back a value greater than 1 for emojis!

With this interesting tidbit, you can determine if a character in a string is an emoji! Furthermore, you are able to use the many Array Methods to deal with the characters!

const string = "🤖: Hello World! 👋";
const charList = [...string];
charList.some(char => char.length > 1) // charList contains an emoji
charList.filter(char => char.length > 1) // return an array of all of the emojis in charList
charList.find(char => char.length > 1) // return the first emoji in charList

I hope you found this helpful! I know it's much easier for me to deal with Emojis now.

🥣 Ought Mealy

Some days the web seems woefully under-equipt. Today is one of those days. Here is where I bloviate so I can look up to see if I'm right later.

I think a large unaddressed issue with the web is mealy machines. AKA Transitioning States.

For Example, This navbar was a bit more complex than I wished it to be because there's no way to determine scroll direction. A scroll event will take a snapshot in time and say:

Gee, thanks DOM, that's mostly useless, but alright.

To know scroll direction, you need to preserve state, and compare the new state to the previous state.

This should be built into the browser right? I'd imagine this is useful information. However, there seems to be a philosophy with the web where previous states, aren't preserved. Thus, knowing much more than X event happened, seems far more difficult than you'd wish.

I'm not sure if I have any great insight here, This seems to be something that has been worked around, but never really through. xState has inspired much of my thought on this, but it seems to be a tool, without much opinion on how it's implemented. Perhaps having a good Library to handle State transitions, would be helpful beyond just handling events. I mean the core of adios is making changes based on data changes, if I can find a nice API to work with the entire platform and its events it could be a useful tool for building websites.

🤔 Rethinking Adios.js

For the past year or so I've been kicking around a js library idea called adios.

I still think adios is a nice idea, frankly I also think the DX is okay. I built it so I know how it works, which makes the issues less frustrating. But I also think underlying adios, is a more powerful idea.

The core of Adios

Adios isn't using witchcraft or dark magic. It's using 2 well supported web APIs and the event loop. That's really it.

Mutation Observer

This is an intimidating name with a complex API. However once you get a grip on what it does, it's pretty nice. It lets you know if the DOM has changed, before the browser paints the changes.

Proxy

This has a confusing name with an API that leaves a bit to be desired. However, once you work around the shortcomings, it's pretty nice. It lets you know when an object is being interacted with and how.

What Adios Does

Adios binds data to DOM elements. By putting data-text="path.to.string" in your HTML. Adios will keep your Data and DOM in sync. Moreover, it'll PULL data from the DOM, removing the need to "Hydrate". If anything, the DOM hydrates the Data.

Whatever, All of that was preamble.

The real nice part of adios is being able to easily create and tap into DOM and DATA events. Powered by Mutation Observers and Proxies respectively. I'd like to find a way to break it into smaller pieces. I'm not exactly sure what those pieces look like.

Ideas

I'd like to

• create attributes that respond to custom events.
• set up a generalized way to dispatch custom events.
• omit and listen for data change events.
• omit and listen for dom change events.
• keep this centralized and extensible.
• write basic js inline
• make it feel nasty to write imperative JS vs Declarative HTML.

👁 Viewport Events

Inline events are nice for quick and easy events which operate upon the idea of LOB. It's hard to beat the ease of use. However, it seems they were largely abandoned. Not sure why. I guess configuration can be strage in HTML?

Regardless, I whipped up this quick example to illustrate how it makes life much easier as a Utility first oriented developer.

How It works

I leveraged quite a few nifty Web APIs.

1. IntersectionObserver

   This API basically lets you know whenever an elements position on the viewport has changed. As you scroll elements, if you're observing them, you can determine a ton of details regarding their position. This is what we use to determine if we should be firing off our custom inline events.

2. MutationObserver

   As you add new elements to the page, how do to make sure you're monioring those elements for these custom inline events? This solves that issue, it'll check every new element and attach an (Intersection)observer if relevant.

3. Function()

   Takes a string, and some arguments and turns it into real JS without some of the issues things like eval, or script injection would introduce. This is what makes our custom inline events work under the hood.

Take it for a whirl!

Below there's a list with one <li.>. It's got a couple attributes. tailwind classes. An animate attribute which is just an attribute selector for our animate.css stylesheet to target. An on-reveal class which fires once when the element is brought into the viewport. An on-view-center attribute which fires when the element is in the center of the screen

The inline on-reveal code does two things. First, it loads the next element. Then, it animates itself into view via the [animate] attribute.

The inline on-view-center code replaces the title tag content with the content of the element.

📏 Scale Experiements

When designing something there are a million choices. Many of those choices are a waste of time. A design system is valuable because it reduces those pointless choices. There are many areas where designer need to make choices, Typography, Color, Composition, Spacing, and more. Limiting spacing options saves time when finding the best size for an element.

An Example

Let's say you're dealing with an icon, and it looks good at 30, 31, and 32px. Which is the "right" size? Perhaps 30px feels right because it's a multiple of 10. Perhaps 32px feels right because it's a multiple of 8. Well, without a design system, any value is fine. Heck, 31.23px is totally fine. But in reality, You know what you prefer. A design system provides a rule for yourself and your team, that 31.23px, is a value that shouldn't be explicitly used.

But which values should be used?

Tachyons

Tachyons, (with inspiration from @stubbornella) uses an exponential scale. 2n. It's pretty nice! (1,2,4,8,16,32,64,128,256,512), It's great because you'll never question which unit works the best. There's a literal magnitude of difference between each unit. The downside is it lacks a lot of the smaller units which are handy for smaller elements. Think chips, these are much nicer when you have 2px-8px to fudge the areas between text, images, icons, and edges.

Tailwind

tailwindcss uses a bizzare linear system. Where each unit is 0.25rem or 4px. Yet, these units don't increment linearly. They increment in a nonsenical sort of way. Basically tailwindcss doesn't have a system for saying what's included and what isn't. 30 isn't a default, but 28 and 32 is. 40 is a default, but 38 and 42 are not. JIT, IDEs, and etc make this less of an issue, but it's still a strange, linear system which still expects fractions, especially at lower px values.

My Scale

The scale which I've been toying with is a hybrid of the two. At work, I evaluated all of the CSS being used, and I found that it doesn't really fit a linear scale well, nor does it fit an exponential scale super well. If you were to choose a range of values near the minimum and a range of values near the max. You'd see the gap between values is consistent, HOWEVER the size of that gap changes.

So I found a pattern which matches that pretty closely.

The scale will increment linearly in sets of 8. After a set of 8, the incrementing value is doubled. It sounds strange, but it works quite nicely. I'm not sure if I'm in love with 8. but designers do love 8. Perhaps 12 may work better? idk, overall the fusion of tachyons and tailwind scaling systems is pretty nice. I haven't been reaching for a value outside of the set, nor are there many values I'd never write by hand. Somehow, this scale scales very nicely.

🔤 Variable Fonts

Google fonts is great! Free, reliable, and now supports* Variable Fonts!

I've astrixed support because there's a few big issues, from a UX perspective. SO I'll just list of a couple reasons why variable fonts via google are a bit rough right now.

Issues

Discoverability

First and foremost, you can't see what they all look like. There's no filter on the main fonts page for variable, and the page that shows which fonts are variable fonts, DOESN'T show the fonts, it only lists them!

No UI

YOU have to handwrite the URL. Between the super strange syntax, some unexpected quirks, andexpecting you to alphabetize their parameters. It's a headache.

Docs are rough

I'm not super certain how to use the parameters. Weight is straighforward enough, but any other variable has me a bit stumped. If you know how to do it, shoot me a DM on twitter.

Better Discoverability

I'm really only addressing discoverability here, but regardless. Below I've listed every variable font available via google fonts, with a slider to change the weight of the font.

It's not much, it's imperfect, yada, yada, yada.

👋 My Site

🤨 The Problem

I'm sure you've seen hundreds of developer sites, and thought: Damn, I need to redesign my whole site. I've gotten sick of remaking my site countless times just to have my ambition fizzle out before I ship it. I didn't want to crush my desire to rebuild my site all the time. It's hard finding a cool idea you want to explore, but finding ways to make it work with your current site, or throw it out and start over.

🥅 The Goals

There are a couple things I'd like to be able to do: Allow my site to be flexible, Allow my ambition to be small, Persist old pages but most importantly, allow my site to evolve.

💡 The Idea!

It's a pretty dumb idea, but I hope it works as the site grows. Essentially, I'm going to build my site as a LONG scroll. Just one big ol' page in chronological order. I think normally this would be a disaster, but the web has changed, and so has my perception of it. Plus there are a bunch of great tools to assist me in this endeavor.

📐 The How

This whole concept hinges on a few web concepts.

The new CSS :where() psuedo selector

This new CSS psuedo selector can totally kill any specificity, and can scope without creating specificity issues with utility css and other more opinionated tools. If CSS is prefixed with a :where(.namespace), there shouldn't be any CSS leaking between pages.

CSS Scroll Snap

This CSS rule is nice. Think how tik-tok is just 1 LONG page full of videos. Normally that would be CHAOS and a total nightmare. However, only one video can be in frame at once, so it doesn't feel like 1 page, full of hundreds of videos, but rather 1 video per page. I hope to create that UX with this website.

HTMX

Perhaps I will use HTMX, perhaps I wont. Regardless, the perception shift HTMX created has influenced this idea. There are 3 parts where HTMX has inspired this: First, the idea of just using HTML over the wire. Second, the little on-event-attribute that fires when something rolls into view. SPA like behavior by pulling a full html document and combining it with the current html document.

TikTok

Lol, Dumb. But the UI/UX for that app is pretty neat. ALL VIDEOS EXIST ON THE SAME PAGE WHICH IS INSANE. but the scroll snap makes that point far less obvious.

The Vue3 Composition API

I don't know what to call it, It's not a Vue only idea, but was largely popularized by it. Essentailly, you just write code where it'll live. Styles/HTML/Scripts. I call it a triple, but I'm not sure what it's called. Basically this pattern is ideal IMO. It's perfect for first page loads, and I find it really to reasona about. Everything lives on one file, no running from file to file, trying to understand what file, added to what build process, created the bundle output that's giving you trouble.

💫 Mix it up.

I think the scroll snapping will make multiple-pages on one scroll more approachable. :where() will give my triples, the ability to namespace without creating specificity headaches for my utilityCSS. HTMX will handle combining the individual HTML pages together client side. 11ty will take these raw triples I make, and combine them with a valid HTML template, and set up loading previous and next pages when a page is scrolled to.

👋 Conclusion

It'll likely get messy. There will be mistakes I make. but I think I can keep nav elements sticky, and allow posts to exist within those nav eras. I think this is a pretty neat idea, I'm interested in exploring it, I'll keep this page updated with the progress I'm making or why I've decided to abandon it.