Fun never gets old - Oredev 2026

Hi

The year is 1996. I'm sixteen, discovering the internet at the family computer. Using what looks like Netscape, dominant browser at the time. Before you ask, yes, those are coyote pajamas. This photo means a lot to me now, because I'm now spent more than then years working on browsers and about twenty years working on the web total. I was blown away by access to what felt like infinite information. But the really exciting part was that I could contribute, not just consume. I wanted my own place on the web. I had no idea this would become my career.

I didn't have any programming knowledge, so my path into it was very visual. I'd create designs in Photoshop, slice them into tiny pieces, and then painstakingly put those pieces back together in HTML using tables, spacer GIFs, and hard-coded positions and sizes. The goal was to reproduce the original image exactly. Not responsiveness. Not adapting to user preferences. Pixel-perfect everywhere.

Apps like Dreamweaver were a huge help. They let me turn those visual designs into pages with actual content and even a little interactivity. I loved rollover effects, for example. Dreamweaver could generate JavaScript that swapped images when you hovered over or clicked a button. If you wanted a fancy button that reacted to the user, swapping images was pretty much the way to do it. Images were the name of the game. We wanted to reproduce, on this new web medium, exactly what we'd created in our graphic design tools.

[Hover the box to expose the pieces] Here is another example. At the time, no gradient background, no rounded corners. So for a box like this, we'd actually have to create 9 images. Four corners, four sides, a center. All custom made just for this box. The custom images and repeated backgrounds created the illusion of one shape. Today, not only do we have borders, corners, gradients, but we have so many ways to draw shapes such as clip-path, and the shape function, and more coming, with the border-shape property. We didn't do all this because we loved to create images and spend hours combining them in interesting ways in HTML. We did this because we wanted decorations, and interactions. And images were the only way to do it. We abused the tools we had at the time because the web platform couldn't yet express what we wanted. By web platform, I mean the set of technologies used to create sites. And this abuse was evidence of an unmet need. Eventually, the web learned.

Space Jam's 1996 website is a wonderful time capsule. It has been exactly the same since its creation, to promote the movie, in 1996. Creating this layout back then required a complex HTML table with multiple rows and columns, with cells spanning several rows and columns, and hard coded sizes. Lot's of markup, fixed image sizes, carefully placed empty space. It works great for the screen its authors had in mind. But the layout and the document structure are tangled together. No separation of concers. No responsiveness, very little consideration for accessibility. Doing this today would be much simpler, with modern CSS layout primitives, fully accessible with semantic markup, responsive, and maintainable. [view source]

We didn't use tables because we loved tables. We used them because we wanted layout, and the web didn't have layout. The tortured HTML markup we saw before was not just technical debt, it was telling us something: developers wanted control over layout. It was evidence of an unmet need. Next is another example of a thing we did to work around the lack of native support for a pattern that emerged in the early 2000s.

Behold the loading GIF! Ajax became a very popular technique in the early 2000s. And I was definitely here for it. But until then, the browser had been responsible for navigating between pages and it also gave users a clear indication that something was happening when it navigated. Status bar updates, loading indicator somewhere in the title bar. Once we started loading content asynchronously, that indication disappeared. And we needed a way to tell the user: hang on, something is happening here. So we turned to animated GIFs. And we went a bit crazy with them. We'd load relatively heavy images, sometimes 100 KB or more, just to display a little spinning animation while something else loaded. Again, we weren't being stupid. We had created a new interaction pattern, and that had created a new UX problem: how do you tell the user that something is happening? So we improvised with the tools of the time.

Again, the web platform caught up. CSS has come a very long way. We have animations, gradients, transforms, masks, clipping paths, and all sorts of drawing primitives. With just a few lines of presentation code, we can build animations that are responsive, themeable, and highly interactive. We can even respect the user's reduced-motion preference. The user need stayed the same; but our tools got better. Developers pulled the web forward by making the need visible and addressable.

Let's go even further back in time than Ajax. The need for loading content on various regions of a page without reloading the full window has been around for a long time. Who remembers framesets? They let you define regions in a page and load different HTML documents into them without reloading everything. This was basically doing SPAs before SPAs were a thing. A testament to the enduring need for partial page updates. An early built-in solution for it, which goes back to Netscape 2 and IE3, and which was part of the HTML4 spec. But which didn't survive the passing of time, due to multiple issues like back/forward navigation was broken, bookmarking was broken too, search engines indexing was a disaster, etc.

But this has been such a recurring theme, that we've spent the last almost 15 years using workarounds, in the form of client-side frameworks like React, building single page apps. I'm very thankful that some developers are starting to see how much this has been costing to our entire industry in terms of performance, when HTML was here all along and actually really good. But the point is, these "workarounds" have been showing the lack of built-in support for something that developers have wanted to do for a long time. And now, we're starting to see native support appear, in the form of a new feature called "Declarative Partial Updates". Aka "Interleaved HTML streaming".

We didn't get modern web applications because somebody sat down one day and designed the perfect platform. Developers pulled the web there. The web has always evolved through creative attempts to push its boundaries and explore new possibilities. That's the legacy of developers refusing to accept limitations and, in the process, helping create the capabilities we have today.

Constraints made us creative. They forced us to invent ways around them. Standards often follow, codifying the solutions developers have discovered. But the interesting thing is that this isn't just how the web used to work. It's still happening today.

We now have a much richer set of capabilities at our disposal. CSS Grid. Container queries. View transitions. Web components, even declarative ones. New HTML elements and attributes. APIs for things we wouldn't have dreamed of doing in a browser in 1996. So we must be done, right? Plus, with AI writing all our code now, who needs new APIs anyway?

User needs never stop evolving. The ever-growing web reaches more and more of the world, which means that everyday there's a new market to reach, a new geography and its culture to adapt to, new user habits and expectations to understand. So there's never a point at which the web is simply "done." Sure, keeping up with this rapid evolution is uncomfortable. There are new things to learn all the time, new APIs that appear, old patterns that change, new best practices to learn, and so on. But this happens for a reason. Any application platform, and the web is the most successful one ever, must continuously evolve to meet the changing needs of its end users.

So, the playground in which we experiment has gotten bigger, not smaller. But it's still a playground. So, if anything, we should play more, not less. An application platform which stops evolving to go where the users are is a platform that's heading toward obsolescence. It slows down. It becomes complacent. It stops addressing unmet needs. We've kind of seen what happens when that virtuous cycle stops. After IE6, Microsoft dramatically slowed investment in the browser. The assumption was essentially that the browser problem had been solved. It hadn't. The web was only getting started.

In fact, I think of web developers a little bit as test pilots. I like this analogy. Test pilots, when they test planes, don't spend all their time using the perfect finished vehicle. They take experimental machines to their limits. They discover where things behave strangely and they encounter situations the designers hadn't anticipated. And that's part of how the plane gets better. We do that with the web too. Web features don't improve purely through theoretical discussions or rules that are written in advance, in a vacuum. They improve because developers try them. And they can only try them if we ship them in browsers.

There's a feedback loop that goes a little like this: You build something. You hit a bug or discover an edge case nobody thought about. You complain and ask for a missing capability. This constitute evidence which forces people building the web to confront the real world. And then we ship more things that you can in turn test. Standardization happens throughout this loop. But usually it's a by-product of this iterative process. It can't exist on its own. It would be like writing the rules for safe flights first and then building planes based on those rules. That can never work. Now I don't want to seem out of touch. I'm not saying you all need to actively be testing each and every little prototype we ship in browsers. that's not your job. What I'm saying is that just by using the capabilities of the web, you take part in the loop that drives its evolution. This is a special power you have over browsers. You can concretely influence our roadmaps. And I'll talk more about how later. Any feedback, whatever the form it takes, wherever it exists, can become a key part of how a feature evolves, or what next feature to build.

A big part of my job today is basically doing what 16-year-old me was doing in 1996: Taking web technology and trying to make it do things it probably wasn't designed to do. Things are very different of course. At the time, the web was mostly made to do text documents only. By wanting to do layout, fancy decorations, animations, and more, I was experimenting without really knowing it. Today, we have many more things at our disposal, but it's essentiall the same spirit. This is often how things go for me: I start working with an engineer or a product manager on the Edge team, who's thinking about shipping a new feature for the web. I get to be the tester 0, often testing things before they're even available anywhere. And I start testing this thing, but at some point I wonder: What if we made it do this instead? Or: How far can we take this? And then I build something silly. But occasionally the silly thing exposes something very real.

For example, here's a hell of popup windows flying around the screen, following my cursor. This is built with CSS anchor positioning, only the red popup follows my mouse and all of the other ones are indirectly linked to it via a chain of anchors. This was a great way to learn how the feature works, and allowed me to demo it quite nicely for others. But, in doing this, I hit a bug. This demo used to crash Firefox quite badly. So I filed the bug and it later got fixed.

Another example. Here I'm abusing the `` element the recent ability to customize it fully with CSS. These are just `` elements. This is an exploration of what happens when you completely remove the background of the dropdown. The options float freely over the page, and are no longer constrained by the dropdown. This is something I expect will open up new possibilities which developers will start using, maybe even eventually leading to new ways to do it easily.

Another similar example, also using customizable selects.

[Go through slides quickly] And a lot more experiments. A solar system illustration that uses offset-path animations and anchor positioning.

A simple HTML-only pacman recreation which uses focusgroup to handle the keybboard, with 0 JavaScript code.

Flying maths built with MathML and 3D CSS animations.

A whack-a-mole game that uses the `

` element and invoker commands to control the closing of dialogs without JavaScript.

A Pong recreation that uses CSS Grid for the rendering engine. And many more. Most of these start for the same reason: testing these new things to the limit. And wondering if a particular use cases is supported. And most times that's all that comes out of it. But sometimes the silly demo isn't silly anymore and it exposes something real. It exposes a bug, or it exposes a new need. And it helps my team make the feature better.

I'm only scratching the surface. Some people in our community take this to a whole other level. Lyra Rebane used modern CSS features to recreate a fully functioning x86 CPU 100% in CSS. Jane Ori, amazing CSS experimenter, pushes CSS specs to their limits, often exposing things that should never have been possible in the first place, like revealing your IP address in CSS only. Temani Afif, another very prolific CSS hacker, explores new UI features and combines them together to unlock new possibilities, like CSS-only diagrams which you can move around. They push against the boundaries of new features. They take something that's only just becoming possible and abuse it until it does things nobody originally expected. They don't take "no" for an answer. They ask, "What if?"

There's a risk of losing our curiosity about the layer underneath. Abstractions are useful. Frameworks are useful. AI is useful. I use these things too. But there's a risk when all of our interaction with the web platform happens through somebody else's abstraction. We stop noticing where the edges are, which is bad because that's where our next users are. That's where the next generation of the platform comes from. User constantly bump into these edges unknowingly. We need to be there when they do. We need to follow where users are. We need to witness those moments.

When I was 16, I wasn't trying to advance the web platform. I didn't know what a standards organization was. I didn't even know browser engines existed. I certainly wasn't filing specification issues. I just wanted to make a website that looked cool. And that's enough. Making a website good is enough to help. You don't need to become a standards expert to participate in this process. You don't need to take hours away from your work to join W3C working groups. You don't even need to spend your evenings creating ridiculous CSS demos. There are much simpler and faster ways to participate. Think of these steps: Use → Try → Complain → Contribute

Use HTML, CSS, JS directly occasionally. What's one built-in browser feature which you learned about today, at this conference, or recently? Can you find a way to use it in your next project? Sometimes simply reaching for a native feature instead of a custom solution you've always used is enough to discover something interesting.

That's the next step: try something that's not ubiquitous yet. Look at what's becoming available in browsers today. Take a look at release notes and "Baseline Newly Available" features. Pick something that looks useful and experiment with it. If you're not familiar with Baseline, let me explain briefly. Baseline is a computed status that's based on web compatibility data, and it quickly tells you whether something is supported in all major browsers or not, and for how long. It gives you a sense of stability. One great way is, of course, MDN, which displays Baseline banners at the top of most pages. But, here's another site that's based on the same data: the Explorer. You can use it to list the "Newly Available" features, meaning those that recenytly became available in major browsers. If you're feeling even more adventurous, look at the features with limited availability too. Try them. Push them. See where they break.

Complaining is the next bit. Complain constructively when something doesn't work. File browser bugs. Report unexpected behavior. You can also, more simply, just talk to us. Many of the people working on browsers and standards are active online.

Finally, contribute signals. Two ways I want to highlight: 1. Developer-signals. It's a repo that collects thumbsups and use cases from developers, about features that aren't yet available on all browsers. It helps us understand what matters to developers. You can engage with this through places like MDN and Can I Use, so very simple. 2. Interop. There's also the Interop project. Every year, developers have an opportunity to tell browser vendors about the interoperability problems that hurt them most. This happens in September/October, so too late for this year, but there's always next year. Browser vendors and other organizations then collaborate on improving those areas.

Again, no need to be an expert in standards or browser internals. No need to join the W3C and write a spec. I know these circles can be intimidating. Most times, all it takes is, you know, just telling us where it hurts, and what workarounds you're having to still use.

Talking about workarounds, let's make this concrete. Let me tell you about two old needs that are still around today. These are about old primitives that either fell short or disappeared, but the underlying user need remains. These constitute evidence of unmet needs, and therefore possible next steps for the platform. They're great places to start asking what the platform should do next.

The web has had a primitive that a11y specialists, standards people, and devs themselves have pushed back against for decades: the title attribute. You can use it as a tooltip mechanism, but it has significant limitations. The resulting experience can be problematic for keyboard and touch users, and developers have no control over what the browser-generated tooltip looks like, when it appears, how big it is, etc. And yet the need hasn't gone away. Developers still need ways to provide supplementary information, particularly for things like icon buttons.

Because the platform's built-in solution is lacking, they often turn to libraries or implement tooltip systems themselves using JavaScript. So what are those workarounds telling us? Two things: 1. There's a real user need for contextual, supplementary information. 2. The web's native solution doesn't adequately address that need. And this is something that we'd love to address in browsers directly, which is why we have a proposal on the Edge team for a renewed, better, customizable, and accessible `title` attribute. And because the web platform has evolved so much over recent years, there are already primitives such as popover API, anchor positioning, and interest invokers, which make this possible a lot easier now than it was before. [hover over the qr code to show a native tooltip] And this is all accessible and completely stylable already. Just waiting for us to reuse and power the old title attribute with these modern features. I've blogged about it, and because the web evolves by experimentation and developer feedback, we'd love yours!

Here is another example. You've seen this before on the web. A blurry low-resolution preview appears first, instead of an empty area where and image is supposed to be. And later, when the final, full resolution image has finished loading, it appears in its place.

The lowsrc HTML attribute was an attempt to provide a low-resolution placeholder image while the main image was loading. And this made a lot of sense back when images could take 20 or 30 seconds to load on typical connections. But, even today, when network speed is relatively fast, this is still something that developers are doing, to provide their users with a better experience. A nice placeholder while the final images is loading. Certain sites load tons of images. Or operate in regions where fast network access isn't the norm. Or just because it's nicer this way. Now, the `lowsrc` attribute belonged to that end of the 90s period, and unfortunately didn't gain widespread adoption and was not included in the HMTL5 specification. But `lowsrc` didn't fail because image placeholders were a bad idea. It failed because the specific 1990s API never became a sufficiently well-defined, interoperable part of the web platform. The need didn't disappear just because this old solution did.

Today, achieving this effect requires a workaround. It requires developers to generate a low-res image, or solid color, or gradient for each image, send this as some kind of data together with the HTML, display it immediately, and then replace it when the final image is here, maybe with a fade-in effect. So, that's kind of a lot of work, and developers have invented their own ways to fill the gap left by the platform. There are even libraries that help developers do this. Here again, this is something my team is very interested in solving directly within the web platform, again, paving the cowpath, giving the web platform more power, covering more ground. We have a proposal for this. We'd love to bring back this attribute, or another attribute like this. Currently we're set on a new attribute called preview, and we're working with the community on a few remainaing open questions, such as how to let developers customize the transition between the low-res preview and the final image, and which preview formats to support out of the box. If this is something you're interested in, take a look at my blog post about it, and send your feedback!

I keep coming back to that picture of myself in 1996, sitting in front of the computer. I love this photo because now, I know something I didn't know at time. I thought I was just making silly web pages. I had no idea that I'd be spending my career working on browsers. But more importantly, I had no idea that millions of other people playing with this weird new medium would, often indirectly, be pulling the web forward.

The web is never a finished product. It's a playground under constant construction. The web's most important legacy isn't only the old code that still runs today. Although that's definitely part of it. It's the spirit of refusing to accept the limits of what the web can do. Keep trying things the web wasn't originally designed to handle. Keep finding the edges. Keep playing.

Thank you