# Build Bridges Build Bridges Build Bridges Build Bridges Published on: November 29, 2025 Categories: Fediverse 3, Mastodon 6, IndieWeb 11 Current music: 36 — _Inside (2:56AM Mix)_ {fallback} Current drink: Lemongrass, Ginger & Black Pepper tea This is a very quick shout-out to the Bridgy Fed project by Ryan Barrett. Its goal is to connect people across otherwise unrelated federated network: Fediverse, Bluesky, and even IndieWeb sites. After the exodus from more corporate and capitalist networks, people ended up in different parts of the web. Each segment could be well-connected inside, but if you want to participate _everywhere_ where people are now, you often need to create and maintain multiple accounts. I often see people reposting the same thing in multiple places — which is fine, but not everyone has the spoons to do so. Not everyone is also ready to create an account in a network they do not understand or do not like. That’s where Bridgy can really help: it is the _easiest_ and most straightforward way to connect your account to other networks. * If you’re on Mastodon or elsewhere in the Fediverse and want to make it possible for people from Bluesky to follow you, you can either log in with your account here or just follow the `@bsky.brid.gy@bsky.brid.gy` account from your client (you can use search to find it there via its handle). * If you’re on Bluesky, and want to make it possible for people on Mastodon and the Fediverse at large to follow you, you can either log in with your account here, or just follow @ap.brid.gy from Bluesky. That’s it. Bridgy works as opt-in — nothing is bridged without your consent, and by default it will only bridge your public posts. Here is, for example, my bridged account on Bluesky, where the posts from my Mastodon profile go automatically. And here is my bridged Pixey (Pixelfed instance) account where the photos from my Pixey gallery go. Bridgy even handles replies, DMs, and more. It is zero maintenance, and there is zero reason not to use it. If you know people who are only present on one of the networks and are not bridging their accounts — nudge them to do so! The more interconnected our web is, the more powerful it is. I find it awesome that vastly different networks can talk to each other thanks to projects like that.

Blink: Intent to Ship: Focus's focusVisible option

# Scope for Examples Scope for Examples Scope for Examples Scope for Examples Published on: November 20, 2025 Categories: CSS Scope, CSS Scopes 4, CSS 83 Current music: Jenn Champion — Going Nowhere Current drink: Thyme, rosemary & lemon infusion With yesterday’s post, — “Anchoring to a Containing Block” — I started to use `@scope` for my code examples. This is one of the most exciting use cases I saw for the `@scope` — an ability to do something like this: Hello! p { outline: 2px solid var(--PINK); } <p>Hello!</p> See how I render this code inline in my post, and the `p` selector is not applying to this literal paragraph that I am writing right now? And, actually, let me show you how this looks like in my markdown: I am not mentioning it in this post, but I also have a `require` prop to signify the support of the feature and add a warning to browsers that do not support it yet. <LiveExample isScoped require="at-scope"> ```CSS p { outline: 2px solid var(--PINK); } ``` ```HTML <p>Hello!</p> ``` </LiveExample> This is how I write all the examples in my blog: I have my custom Astro `<LiveExample>` component, which takes the Markdown code blocks inside, and both shows the corresponding code, but also outputs these code blocks’ content on the page, so I can just write my examples once, have their code visible, and not have to duplicate the effort when I need to update something. In the above case you can see the `isScoped` prop: before I had it, all examples did output their code _literally_ , so whenever I had to have similar examples, I had always to come up with some prefix or unique class names for them. With `isScoped`, I wrap the content of the inner CSS block with just `@scope {}`, so that code will be equivalent to @scope { p { outline: 2px solid var(--PINK); } } Which can be called “local scoping”, see the “Identifying Scoping Roots and Limits” section of the Cascading and Inheritance Module 6. How it works is: if we add an HTML `<style>` tag in our HTML, and inside this tag there will be an `@scope` without the scope start selector, it will be scoped to that `<style>`’s parent element: > If no `<scope-start>` is specified, the scoping root is the parent element of the owner node of the stylesheet where the `@scope` rule is defined. And that is very useful for any blog posts with code examples — this makes every example to work independently of others. There are a few things I will need to improve with how I use these types of examples: * Sometimes, there is a need to share some styles across different examples. Possible solution: use named scopes, and overload the prop to allow also doing `isScoped="foo"`, where I could mention some ident, and then both the example will get this ident automatically added as a class name to the example’s wrapper, and it will go into the `@scope` like `@scope (.scope-foo)` or something. * It can still be useful for understanding of the examples to have their full code, so maybe there could also be something done on the LiveExample’s side to add some automatic diffing of consequtive examples, where we could highlight the changed lines in some way? In yesterday’s post, that would’ve been pretty handy. ## But… `@scope` is not Baseline? Yeah, but I also write about non-baseline things. When writing about CSS features like anchor positioning or scroll-driven animations, or anything newer, there is no reason _not_ to use `@scope`. If you have a blog, write about modern CSS, and create inline demos there (not by embedding CodePens or anything else as `<iframe>`s), I highly recommend you to try `@scope`. It is cool.