Hello.

Link: AI Focus

I've launched a new blog. It's called AI Focus, and it's dedicated to exploring the intersection of artificial intelligence and web development. My goals of the blog is to cover a range of topics that I think are going to affect the web and web development in the coming years.

Why? I think that the nature of the web has changed and it will change even more in the coming years. I love the web and web development, but I don't think we can idly sit by and assume that "the web will always win". I don't "always bet on the web", I bet on the people who build for the medium that is the web, that is the users, the authors, the developers, the designers, the creators and web browser engineers. I think we are going to have to adapt to the changes that "AI", or at least the technology that is Large Language Models, bring to the web, and I want to be at the forefront of that change.

I'm experimenting with a more essay focus to the writing which pose more questions than answers at the moment. I've been silently writing articles on it for the past couple of weeks, covering topics like:

• The future of emedding?
• The future of linking?
• Will there be a super-app?

My buddy Andre Bandarra has also written some great pieces about Mashups and assistance in web development

Let me know what you think, and also what topics you'd like to see covered in the future. I'm always looking for new ideas and perspectives, and I want to expand my understanding and opinion.

Link: Diving into the Data on Feature Availability and Adoption [BlinkOn 20] - YouTube

This is a great talk from Annie Sullivan at BlinkOn 20 about the availability and adoption of web features. Annie discusses the importance of understanding how features are used in the wild, and how this can inform the development of new features.

I took a few notes on the talk, which I thought were interesting and linked to them below:

• Core Web Vitals: Discusses work on improving web page quality metrics (LCP, INP, CLS) using HTTP Archive data to identify and fix issues [00:00:21], [00:00:50] and how this was the groundwork for the talk.
• Baseline Data: A baseline dashboard by the WebDX community group provides metadata on web features, including their availability status and [00:03:32] and how Annie would use this aligned with usage data to understand the adoption of web features (rest of the talk)
• Key Findings:
  • Wider availability leads to higher adoption [00:05:56] <-- We all had a feeling this was the case, but it's nice to see it backed up with data.
  • Feature adoption isn't significantly skewed by website popularity [00:06:15].
  • 1. we can do splits on data easily, 2) HTML and JavaScript features show clearer adoption patterns than CSS [00:07:19].
  • HTTP Archive data aligns well with real Chrome usage data [00:09:27].
• Analysis Tools: Uses HTTP Archive and BigQuery to analyze feature usage [00:10:14].
• Adoption Factors:
  • Site-building platforms (e.g., WordPress) [00:12:54].
  • Third-party embeds (e.g., YouTube) [00:08:52].
  • Progressive enhancement with fallbacks [00:17:43].

Our team has long been pushing to understand API usage and how collaborating with site-building platforms can help us understand the impact of our work (selfishly for me), but I do think broadly that this type of insight helps us get more investment in to the web platform and helps us prioritize the right things.

Link: From PyTorch to Browser: Creating a Web-Friendly AI Model

I loved this post from Andre about running sentiment analysis in the browser using a model that he'd trained on embeddings generated from a YouTube comments data was great and shows that you don't have to run everything through the full language model and instead can use just the embedding APIs to get a decent result.

The client side part of the code can be seen below:

const input = 'Hello, your video is amazing!'; const embedResult = await genAi.models.embedContent({ model: 'text-embedding-004', contents: [input], }); const embeddings = embedResult.embeddings.map(embedding => embedding.values); const outputTensor = await model.predict(tf.tensor2d(embeddings)); const argmax = await tf.argMax(outputTensor, 1).array(); const labels = ['Positive', 'Neutral', 'Negative']; const results = argmax.map(i => labels[i]); console.log(results);

const probabilities = await tf.softmax(outputTensor, 1).array() console.log(probabilities);

Link: How to Write Blog Posts that Developers Read · Refactoring English

I think this post would be good for every developer to read. It's more about communication than just blogging.

The biggest mistake software bloggers make is meandering.

Often, the author has some valuable insight to share, but they squander their first seven paragraphs on the history of functional programming and a trip they took to Bell Labs in 1973. By the time they get to the part that’s actually interesting, everyone has long since closed the browser tab.

This is me to a tea. I remember when I first started blogging and I would just get traffic, times have changed and I certainly need to be a lot clearer with my writing.

This really resonated with me:

If you want people to read your blog, choose topics that have a clear path to your readers. Before you begin writing, think through how readers will find your post.

I tend to fart out a blog post, and the guidance here is very similar to the guidance I hear from a lot of content creators. Study your medium, understand your audience, how to reach them, and then plan plan plan.

If you're interested in the broader topic of writing for an audience (probably a more business focused one) then I really enjoyed Pyramid Principle by Barbara Minto, it's helped me a lot within my role as a way to communicate more effectively (although, I still have a long way to go).... I've heard it's favoured by McKinsey consultants, while that's not my cup of tea, the principles seem sound to me.

Link: Rainbow Shadow Button · 19 March 2025

background: linear-gradient(to right in oklch longer hue, oklch(95% var(--vibrance) 0) 0 100%);

I know CSS pretty well, but I'm mind blown by what Adam produces. It's like when I draw, I know what I want, but translating it from the image in my brain into something that looks good on paper is a whole other story.

Link: Real-world uses of TypeScript’s utility types - Piccalilli

I have a bit of love-hate relationship with TypeScript, but there are parts of the typescript Type system that I really like. This article from Piccalilli is a great introduction to TypeScript's utility types (which is one of the areas I like, even though it is a bit complex)

Utility types are types that modify other types. You can think of them as functions, but they operate on types instead of values. It’s mind bending at first — especially if you’re coming from languages that don’t have anything similar — but we’re going to walk through a load of examples to see how they work.

Mind-bending indeed.

One of my favorite types that I've made is here in Breadboard. It could take a function and return a proxy for that function that had the same calling parameters.... I think... I'm not sure, I wrote it a while ago... heh, that's the "hate" part of the relationship. :D

Link: Adactio: Journal—Command and control

I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).

I'm fully aligned with Jeremey on this one, there's a heap of commands and actions that a user invokes in the browser that should be more accessible from the client and be able to be invoked without JavaScript.

Turns out there is work being done around this area for dialog and popover elements, with scoping for more elements in the future.

Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.

Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.

More details about what Jeremy is talking about can be found in this developer.chrome.com article.

I agree with where Jeremy wants to see this head, as the article says "We welcome community input—if you have suggestions don't hesitate to file an issue on the Open UI Issue Tracker."

Maybe we can get button command="bookmark"... I joke... kinda... we used to have an API for this back in the day and while I don't think we would want an API to your bookmarks, I could see a world where a lot of the Fediverse's issues could be solved with a few more declarative commands.

Link: Browser adaptation

Something that I've been thinking about a lot recently is that the medium that is the web. It enables a lot of things that only the web can so this post by Brad Woods really resonated with me and it talks about how the web can be used to adapt stories to different mediums.

Different mediums convey information in unique ways and creators interpret the same story through unique perspectives. Tolkien gives relatively little detail of what Middle-earth looks like, leaving much of the work to the reader's imagination. Jackson on the other hand paints vivid pictures. Tolkien emphasizes the length of the journey by detailing every step, making readers feel the weight of the adventure. Jackson focuses on the major events, creating a fast-paced narrative. Neither approach is superior. Each explores Middle-earth from a different angle. Adaptations allow audiences to make a deeper connection with the story, enriching their understanding and appreciation of the original work.

What the browser offers

The browser offers the following communication tools:

▪text ▪image ▪video ▪sound ▪interactivity ▪video game environments (2D and 3D) With these, we can recreate most story mediums. For example, using image and text to make a comic book or sound to make a podcast. This gives the creator freedom to choose the communication tool(s) that best fit the story they want to tell.

Yes. YES. YES! I love it.

He also discusses the idea of Personalization and Interactivity. Quadruple yes! The web as a medium is so incredibly versatile and I love seeing people explore that.

In 2014 Jeremy Keith published a post "Continuum" and it touches on a different aspect of the value of the web: it's resilence and ability to adapt to the devices it runs on and the browsers it runs in.

I'm still working on how I want to be able to express the value of the web more, especially in a world where it looks like the youth of today who grew up with mediums such as YouTube, TikTok, Facebook and Instagram don't naturally see the web as a medium that they can use to express themselves (or even enjoy).

As a side note, this blog is a gold mine of neat experiments and explainers

• https://garden.bradwoods.io/notes/svg/draw-on-scroll
• https://garden.bradwoods.io/notes/css/blend-modes
• https://garden.bradwoods.io/notes/javascript/web-api/intersection-observer
• https://garden.bradwoods.io/notes/javascript/web-api/intersection-observer/dynamic-header
• https://garden.bradwoods.io/notes/misc/news
• https://garden.bradwoods.io/notes/game-dev-journal/03-persistence

Link: Planet Igalia

When I was preparing the Interop post yesterday, I found one of the agalia links didn't work and while I was hunting for the new link, I found Planet Igalia. :mind-blown:

I've always wondered what's happening at Igalia and while I love the podcast, I do love a good Blog.... I'm really not sure how I missed this entire part of the site, but it's go so much good information and often frequent deep dives in to browsers. For example Maxsim Sisov's post on "Unmasking Hidden Floating-Point Errors in Chromium’s Ozone/Wayland" - such an awesome read into an area I had zero knowledge about.

Triff and marv.

Link: ESLint now officially supports linting of CSS - ESLint - Pluggable JavaScript Linter

We feel that validation and enforcing baseline features are the minimum that a linter needs to support in 2025, and so we spent a lot of time making the no-invalid-at-rules, no-invalid-properties, and require-baseline rules as comprehensive as possible.

Love it!! Absolutely love it.

One of the areas that we would love to see more of (and we hope to work) is more integration of Baseline in to developer workflows. That could be Linters (like ESLint), boot-strappers, IDEs, compilers, frameworks, DevTools. You name it, I think it would help the entire ecosystem if we could get see increase awareness and usage of Baseline and therefore adoption of the features that all the browsers implement natively in to the hands of developers.

Exciting times.

Link: How Google Chrome’s autofill feature helps both shoppers and merchants

One of Shopify’s key metrics is Checkout Conversion Rate (CCR), which measures the rate of successful checkouts completed over a period of time. Through testing, Shopify found that removing unnecessary steps led to more customers completing their checkouts. Guest checkouts using autofill had a 45% higher CCR than guest checkouts without autofill. Basically, the customers who didn’t have to spend time filling out forms were more likely to actually buy something at the end of their online shopping trip.

Emphasis mine, but this is incredible and is something that I think has gone under the radar.

For the longest time it was thought that there was no way to measure the impact of autofill on the web. In 2016 I developed a small snippet to detect when autofill happens and while no one paid attention, it's good to see that with the introduction of CSS :autofill pseudo-class in Baseline, we can create some simple JS that will more effectively detect when autofill happens.

There's also now better autofill tooling in Chrome DevTools, so my hope is that more people will start to understand the impact of autofill on their sites and start to optimize for it....

... maybe.. There is still a lot of concern in the ecosystem about autocomplete=off and a lot of people that don't want the user's agent to control the autocomplete experience.

Link: Interop 2025: another year of web platform improvements

It's exciting to see the web platform continue to evolve and improve. Interop along with Baseline are aimed to solve some of the top challenges that developers have when building for the web.

Ultimately we only make progress as a platform when the major user-agents make shared and consistent progress on the platform and this has been a huge effort from the teams at Google, Microsoft, Mozilla, and Apple, not to mention Igalia and Bocoup as well as all the developers that have helped to prioritize what is important to them.

Here are the announcements from other browsers:

• WebKit
• Firefox
• Edge
• Igalia
• Bocoup

While I've been following the progress on Interop I hadn't noticed that they are looking at new areas of investment:

In addition, and as in previous years, there's a set of areas for investigation. These are areas where we don't have enough information or tests to include as a focus area, but the group feels some work should be done to get them to a stage where we can include them.

• Accessibility testing
• Gamepad API testing
• Mobile testing
• Privacy testing
• WebVTT

This feels like a good set of areas to focus on. I'm particularly interested in the Accessibility testing and Privacy testing. I think these are areas that are often overlooked and are critical to the success of the web platform.

Finally, I encourage everyone to look towards the tooling that is available because of the work that the Interop group is doing to understand all of the web-features and their availability across the platform.

You can follow along on the Interop 2025 dashboard at https://wpt.fyi/interop-2025 and as things become Baseline Newly available they'll show up in the Baseline 2025 list on webstatus.dev too.

Link: WikiTok

This is such an amazing site and has become a bit of a daily habit for me. It's a brilliantly simple idea that means I'm browsing more of Wikipedia than I ever have before.

I built a similar demo a while ago using the now-defunct Portals API because I want to explore what a Web Browser could be if it had a UI like TikTok. My hypothesis was that while links are amazing, what is behind them is hidden, and worse (imo) it's behind a banner image that is often not representative of the content.

So the idea was that as long as you had a list of sites that you might visit it might be neat to have a way to flick between them quickly and get an idea if you actually want to dive into the content. The portals API seemed like a good way to do it because it could run JS, but was non-interactive and in theory privacy-preserving.

I adapted it in mid-2024 to use generated screenshots of the pages. I also thought I should give it a snappy name. Flick the Web's code is here and the you can play with the demo that runs over the latest articles on HackerNews.

I'm really glad that WikiTok did this and also it has been open sourced as I can totally imagine that this type of UI takes off on the web.

A little bit about how I edit my blog: It's Hugo, on Vercel with a custom editor I built. Read More

Link: Why I use Cline for AI Engineering - by Addy Osmani

In this post Addy describes his use of Cline (Jan 30). It was the first time I'd heard of it. I was kinda surprised because I've been on top of tooling for a while now.

For the longest time I'd been using Replit, it had a nice flow to it. I could ask it to help me solve a problem and it would just apply the code to the project. For me, it was a nice way to get things done.

I liked Replit, I built a lot of apps with it, however their hosting is expensive and their new checkpoint based pricing model frustrated me, especially when it made very clear mistakes.

At the time (like two weeks ago) Copilot didn't apply any changes to the code, it just suggested things which I had to then copy and paste... and even then the suggestions just weren't that good.

Cline has replaced both Copilot and Replit.

I don't mind paying for the use of an LLM and as noted by Addy:

I’ve also deeply appreciated Cline’s proactive accounting of cost during a session. This is most notable when switching between model providers:

I love that I can see where the costs are coming from. I can see how much I am spending on the model and how much I am spending on the compute. It's a nice touch.

When you add this with something else Addy points out:

The DeepSeek-R1 + Sonnet hybrid approach Recent benchmarks and user experiences have shown that combining DeepSeek-R1 for planning with Claude 3.5 Sonnet for implementation can reduce costs by up to 97% while improving overall output quality.

It's a pretty compelling solution.

My own workflow at the moment has be to plan with R1 (via OpenRouter) and then implement with Sonnet. I personally don't look at the costs, but I do inspect the output a lot and this has felt like a pretty good balance for my personal projects.

It might be possible to build sites entirely from a simple description. Read More

This great post by Dion "English will become the most popular development language in 6 years" is worth a mull imho.

There's obviously a lot of push back on LLM's be it what they were trained on and how much energy they use. However the technology is here, and Dion poses a great question: Will natural language become the way people control their computers?

Two things resonated with me:

The reason that we see so many applications pop up with a chat side bar is a signal that we are building bridges between the computers and the humans in natural language ways.

and

Future: your English is the source, and as your computer systems improve, they can be regenerating new and improved implementations. It behooves you to invest in testing and validation in this world, but this is something that is actually really needed any way… we just sometimes get away without doing it.

I maintain a list of apps that I'm happy for people to use. I've also got a huge list of disposable apps that I've built for myself. I'm pretty certain that "natural language" as the main development language will happen at some point and as it developes millions more people will have the ability to control their compute in ways that echo how Spreadsheets enabled people to manipulate their data in their businesses.

Dion centers some of his discussion on Chat-first vs Spec-first. I agree that the Spec is important, I just don't know how this part will develop. Do we develop the spec completely up-front, or is there a chat-like assistant that accretes the spec as we develop. I'm thinking the later, I can imagine a world where we have a set of critics that attempt to objectively look at your spec and tell you what's missing or what could be developed further.

I hope this email finds you well. Read More

Link: https://webkit.org/blog/16413/the-success-of-interop-2024

I saw The success of Interop 2024! in Stefan Judis's Web Weekly Newsletter.

Jen Simmons at Apple on WebKit pulled together this great post about the progress that has been made in 2024.

In 2024, there were 17 such focus areas: Accessibility, CSS Nesting, Custom Properties, Declarative Shadow DOM, font-size-adjust, HTTPS URLs for WebSocket, IndexedDB, Layout, Pointer and Mouse Events, popover, Relative Color Syntax, requestVideoFrameCallback, Scrollbar Styling, @starting-style & transition-behavior, Text Directionality, text-wrap: balance and URL.

The value of Interop is so important. It's the reason that the web has been so successful. It's the reason that we can build things that work across all devices and all browsers. It's the reason that we can build things that work for everyone and I'm grateful for the collaboration between all the browser vendors on this.

We just have to be careful to say "the web is XX% interoperable" when the data in the interop project is a percentage of the shared focus areas, not of the entire platform. The dashboard is pretty clear, the actual situation of wider interoperability has a long way to go.

Either way, we should celebrate this progress. The web is getting better.

Link: My approach to running a link blog

I really like Simon's approach to running a link blog and his principles really resonate with me

I always include the names of the people who created the content I am linking to, if I can figure that out. Credit is really important, and it’s also useful for myself because I can later search for someone’s name and find other interesting things they have created that I linked to in the past. If I’ve linked to someone’s work three or more times I also try to notice and upgrade them to a dedicated tag.

Lifting people up is something that I've always valued (and valued when folks did it on my content). I probably lost my way at the start of my DevRel career - parts of the DevRel job ladder include being Industry influential. I took that to mean being an expert in web development and while I think I'm reasonable and I've built a great team, I love seeing other people succeed and I love sharing their work.

I try to add something extra. My goal with any link blog post is that if you read both my post and the source material you’ll have an enhanced experience over if you read just the source material itself.

This was actually something I struggled with in my first iteration of my link blog. I'm still not sure I can always provide more value than the original author but also I have a hunch that linking out of sites is a dying art.

Simon also had a bit about the technology behind his link blog:

The technology behind my link blog is probably the least interesting thing about it. It’s part of my simonwillisonblog Django application—the main model is called Blogmark and it inherits from a BaseModel defining things like tags and draft modes that are shared across my other types of content (entries and quotations).

This blog is entirely static (Hugo) and I've been butting my head up against the wall. Static is neat, but it's not enough. If you want to add Activity Pub, well you have to bend Hugo a long way. Add a link blog? Well, that's not too hard given it's structure but it also means having to make a full git-commit to the repo, and this was something that slowed me down last time.