Welcome to the Safari and Web Technologies Group Lab. My name is Saranya Barak and I'm part of the WebKit team here at Apple. And I'm joined by Tim Nguyen, Alexei Marchenko, Kiara Rose, Brandal Zatranuk, and Jen Simmons. In addition to those on screen, there is a whole team behind the scenes, helping with the triage of all of your inbound questions. We're excited to hear your questions today about Safari, about WebKit, and about web technologies. If you have code-specific questions or we don't get to your question today, we'd really encourage you to bring your questions to the developer forums at developer.apple.com/forums, where we will continue the conversation. If you have a bug or a feature request, we'd encourage you to go to bugs.webkit.org as we want to focus our questions on what will help the broader audience. And with that, let's get started. We're going to begin with a short preview of what's new in WebKit for Safari 27 by Jen Simmons, one of our web evangelists. Jen, take it away. Thanks. So we shipped a lot of new web technology in WebKit already this year, and there's even more coming in Safari 27. Grid Lanes shipped in Safari 26.4, you can use it to create masonry-style layouts with really simple CSS. Check out this website we launched, the Field Guide to Grid Lanes, at gridlanes.webkit.org to experience what's possible with Grid Lanes. And watch Learn CSS Grid Lanes, where Brandon will walk you through exactly how to use it. Customizable Select is coming this fall in Safari 27. It lets you fully style the HTML select element to match your design, and it lets you add custom content with all the accessibility and robustness of HTML forms. Tim teaches you how in his session, Rediscover the HTML Select Elements. In Safari 27, the model element comes to iOS, iPadOS, and macOS. Use it to add a 3D model to your website. It works just like the other HTML media elements, and you can manipulate it using JavaScript. Alexei will show you how and get started with the HTML model element. Immersive website environments come to VisionOS 27. Use the web to provide an immersive environment to users. Maybe you make something beautiful or something practical, like a place for people to preview tickets when they're buying a seat. John will show you how and explore immersive website environments in VisionOS. And then web extensions. In Create Web Extensions for Safari, Kiara will walk you through the entire process of building a web extension and show you how to distribute your extension to Safari users without Xcode or even without a Mac. But really, the biggest news for WebKit this year, it's not any particularly exciting specific one feature. It's our deliberate effort to improve the quality of the browser engine. We tackled over 1,100 feature improvements and fixes since last fall. Learn all about the quality efforts watching What's New in WebKit for Safari 27. We'd love to have you test your projects in the latest versions. And if you are having problems, file an issue at bugs.webkit.org or in Feedback Assistant. Check out our website at webkit.org, where we have all sorts of useful content that we hope will help you make the projects you're making. There, you can learn everything about what's in WebKit for Safari 27. And we're thrilled to be here today to talk about it all. Wonderful. Thank you so much, Jen. Now let's dig into your questions. Okay, let's start with a good one. Okay. What web technologies or APIs do you think every new web developer should learn today to prepare for the future of the web? Very timely. I like this question. Yeah, I think in many ways, even though so much is changing right now, the answer to this question is kind of the same. It really helps to understand why there's HTML, CSS, and JavaScript, why there are three programming languages for the web. I think it really helps to learn what you can do with semantic HTML, which is expanding. There's so much happening. Things that you used to have to use JavaScript for that now you can do declaratively in HTML alone. So I think investing that time into learning HTML, CSS to really understand how do you do CSS layouts, how do you make your website work on every screen, Progressive enhancement. Like how do you make sure your website works in every browser that your user might be using? You know, both the different browsers also on the different operating systems also back in time ways because people, it takes time to update. So those core skills, like even as folks, more and more people might be turning to large language models or using AI tools, it feels like those fundamentals are the things that will like help you know whether or not the code that's getting generated by a tool is good code. Like you kind of really like and those investments into learning that stuff will last you your entire career. I agree. I also think that there are a lot of things that if you've been in web development for a long time, we've had to create some workarounds, things like CSS preprocessors and way back to things like jQuery, where the web standards themselves have kind of come along and actually simplified and cleaned those things up. It's worth understanding the latest and greatest. If you are beholden to working on a large existing code base, by all means, you need to know how it is solving those problems. But the reality is that all of those platforms, the HTML, the CSS, and the JavaScript, are all getting better at meeting those needs directly. And so looking at the state of the art today is an important part of being able to make sure that you're producing and shipping the simplest code possible. Yeah, and to add on top of that, I think like these days, understanding 3D and spatial web is also important. Like for the last couple decades, web used to be pretty much like 2D. But now we have things like model element and other things and technologies like WebXR that allow you to interact with 3D spaces and bring 3D content into the web. So start learning about this, like educating yourself about these things, also important and useful. I want to mention accessibility. And I think learning the basics, HTML, CSS, and JavaScript can really help also understanding accessibility. Because when you start using semantic HTML instead of custom JavaScript, that by itself helps accessibility already. And so I want to go back to what the two first panel said about how learning the basics is really important. - Yeah, and John, who's in the back, he was saying earlier, just make it easy. Always choose the easier path, make it easy for yourself. And I think doing things like using a semantic HTML element, you get accessibility for free. You get robustness and progressive enhancement for free. And sometimes there were reasons that people couldn't in the past, but there's been so much work done recently, especially like in the last five years to try to be like, you don't have to use a pile of JavaScript with spans and divs. Now you can use this other new, we like we paved that cow path. So it's easier. Like it's easier for you as a web developer. Like be lazy. Be lazy. Lesson of the group lab. Be lazy. I love that. Kara, I'm curious, where do web extensions fall into the things I should learn about and be good at for the web for the future? Where does that fall into place? Well, yeah. So as mentioned, web extensions use JavaScript, CSS, HTML. So if you're familiar with those technologies and you haven't considered using a web extension or creating one, you can. And it could be a really good tool to supercharge your browsing experience or provide useful tools for users who use Safari or other browsers. And so, yeah, you can use those tools for web extensions as well. And with it being made up of those main three languages, you can port over extensions that you might have in other browsers to Safari. We've created numerous developer tools to help developers who've created extensions for other browsers to have support for them in Safari. So yeah, and we've done a lot of work in the Web Extensions Community Group to help standardize Web Extension APIs to make the development process smoother for developers across browsers. So yeah, we're excited about the work that we're doing there. Awesome. That is exciting. And speaking of standards, my next question is about web standards. What upcoming web standards is the team most excited about? I'm really excited about new install element declarative partial updates in HTML and Canvas. And this is from DFA Bulik, I believe is how you say that. Yeah. Well, I'm really excited about the Web Extensions Working Group that was just founded. We've been involved in the community group for the past five years, meeting biweekly to discuss issues within the Web Extension space, helping specify APIs and clarify things. And now we can do so in a more concrete manner and actually have a spec for the Web Extensions and push towards interoperability across the browser. So I'm really excited about that. Nice. I want to encourage everyone to watch our session. But on a personal level, I'm very excited about the random item function that's in the new CSS value spec. So it's similar to the random function that shipped recently in Safari, but instead of being restricted to just numbers and lengths, you can actually pick between different values for keywords for different CSS properties. And I think that opens up a lot of possibilities. And the other one that I'm excited to see coming is Spatial CSS. That some of my colleagues have been working on. I actually wanted to mention that Spatial CSS is one of the most exciting things I've been working on as a developer. and see my team and my colleagues contributing as a standard and as a SPAC. And it's an amazing technology that will allow us to bring more compelling content to the web. Can you say more? What kind of cool stuff will you be able to do with it? I mean, we already can see from the SPAC draft that we can do transforms on multiple objects, like 3D objects. In 3D space, like real 3D space. Yes, in 3D space on platforms that are going to be able to support it, like Apple Vision Pro and other platforms that are like it. But it also has relevance for the objects that you display on a phone or on a Mac or a laptop. Almost everybody in an e-commerce context today shows their product in some kind of 3D configurator. And having more people be able to reach for a system that allows them not just to display that object, which model element achieves for folks in Vision OS, Mac OS, and iOS 27 today, but also through JavaScript polyfills for other platforms. But looking forward to Spatial CSS, you'll be able to combine those, annotate them, work with the sort of now excellent accessibility trees and solutions that have been sort of following along in the long run of the web. You know, we have added many new platforms to the web over the last three and a half decades. And, you know, it takes a process of kind of figuring out what those platforms need. Spatial CSS, I think, is the very beginning of thinking about what we need to do to move into this new dimension. And I think it's going to be awesome. What makes me really excited about spatial CSS is if you know the basics, like absolute positioning, anchor positioning, it just extends naturally from that. If you know top, left, right, bottom, those properties, there's now depth. It very naturally expands from what you already know. So that's-- - From 2D to 3D, and anchoring is actually one of the really exciting things. Like when you can combine multiple models into a single object that can be customized, I think that's gonna be a huge hit at e-commerce. At least it has everything for e-commerce to be. - It's interesting when you asked the question about web standards and what's most exciting, I was sort of guessing, it's like, oh, a third of this panel is from the spatial web. and and like i think that answer is probably you know there there are a whole bunch of people here right now and a lot more in in our team buildings and it's like gosh that the answer to that question would be so personal to all the different teams so personal because there's so many different groups of experts that i've honestly like really honestly feel very lucky to be working with and i can i just their faces were flashing through my head and i was like well these people would say this and this guy would say this and this person would say that and like it's kind of I don't know there's a lot of different web standards happening and they're all interesting and exciting and hard I mean I don't want to romanticize the web standards process it's a hard it's a hard process it can end up feeling like it's taking years longer than you want it to be taking but at the same time like it goes slow on purpose in a way because if it's hard to change, it's hard to change back. And these things, these decisions like, oh, maybe it took like three years longer to ship grid lanes than we wanted it to. But also, will anyone care 40 years from now? No, they will be very happy that it was the best designed API it could be. And so I feel like we feel a lot of responsibility at Apple. Like we're willing to go slow because we want the end result to be really, really good. We don't like going slow, but we're willing to go slow if that's what it takes to end up with a result that's excellent. Because on the web, we're not just going to throw away HTML5 and like replace it with HTML17. It's HTML. Like HTML is HTML is HTML. So, yeah, anyway, we could talk about standards forever because we do talk about it so often. But it's a core part of what I think we care about in the work that we're doing here. I see that throughout the whole team. Next question is from Josh D. I'm a native app developer on Mac OS iOS. I've been using agentic coding to play with some JavaScript-driven apps and have noticed that Safari can sometimes be more performant than native in terms of UI UX. Can you explain how this is possible? A long time ago, at the very beginning of iOS, there was a plan that we didn't follow through with not to ship apps on iOS at all. It was an idea that people could build everything they needed as web apps. That turned out while – and in fact, it's in a book that was published by one of the early developers inside Apple – that the Stocks app and a number of other apps were built that way. But ultimately, they realized that while you can build performant web apps, it is hard. But that means that when web apps are performant, they are every bit as good and potentially even better than native apps, depending on what people are doing and how they're working with it. WebKit is doing a lot of work under the hood to optimize a lot of the different things that end up happening on the web in terms of things like a lot of content and refreshes and things like that. So depending on what you're doing, there may be extra help that is being given to you from WebKit and other browser engines. You know, one thing I think that I did not understand as a web developer, and I imagine a lot of people don't, is just how deeply integrated WebKit is into the operating systems of all of our platforms. that JavaScript core, which is what runs JavaScript on a website, is a big chunk of the operating system. Like, it's built into the operating system. And if any other app anywhere doing anything is using JavaScript, it's also using JavaScript core. And WebKit is now a view in SwiftUI, where people could just open up SwiftUI, be coding an app using all the best modern practices for app development, and realize, oh, you know what? I think actually here I'd like to use web technology for this. And then they just bring me up. Then they're writing web technology. So it's interesting. Sometimes I feel like there's this sort of, I don't know, like sports game, this or this. Only there's two teams and they're very clear which is which and only one can win and they're up against each other. And it's like that's not actually what's happening. People are using whatever tool they want to make whatever work they want. And users, our customers, they don't know. They don't care. People just want to do what they want to do, and people who make those experiences are reaching for the tools that they find appropriate. And the truth is that WebKit and JavaScript Core are deeply integrated into every one of our operating systems, even like watchOS. There's no web browser on watchOS, but WebKit is running on watchOS. JavaScript Core is running on watchOS. So performance matters a lot, a little to the device. So I think we all have to take our hats off and say a big thank you to JavaScript Core Exactly. All right. Next question. This is from D Fabulic. Web devs have very strong opinions about what web features WebKit should and shouldn't support. How does Apple recommend that WebDevs advocate for these features? And what shouldn't we do? Are WebKit standards positions factoring in our radars? I'll take that. Wow, I'm reading it again. Web developers have very strong opinions. Yes, they do. I mean, we always love to hear from web developers. I honestly mean that. And bugs.webkit.org is one place. You can find our evangelists on social media. That's another place. And I do think that often what really helps us, because we have so many fantastic ideas, and there's just not enough human beings on Earth to get them all done. So we have to prioritize, like any software team we're prioritizing. So we're taking in a lot of information as we set those priorities, and knowing sort of what is the use case and what is the benefit to your users. Because that's what Apple really cares about is that end user. What is it that you want to create for them? And how is it that this API would really help you do that job? Or how is it that not having that API is making it hard for you or perhaps impossible for you to do what it is you're trying to do? So, I mean, I think that's part of it. I feel like there's another piece of that question, though, that I don't remember at the moment. Yeah, how does Apple recommend that? Oh, standards positions. Like, a lot of people might not know, you know, web standards is a conversation between lots of different people about what might become an official web standard in the future. And so there's a lot of things that get introduced and perhaps even implemented in one browser that are not actually web standards yet. There's no consensus. There's just an idea and perhaps other browser engines have been very vocal that they think the idea could be better. That maybe the use case is a good use case to solve, but that first idea is going too fast, and we need it to be more private, more secure, more performative, something that won't hurt people's battery life as much, something that will be easy for web developers to use. There's quite a few web standards positions we have out there where we're like, we don't know about that. And the reason is because we think it's going to be too hard to use. It's going to be too hard to use that API. It needs to be designed better so that when web developers do use it, it works out really well for them. And so if people are curious about standards positions, you can find them on GitHub, the official standards positions that we've published. It gets really in the weeds because it's, you know, it's web standards conversations. But I do think that what I'd love for people to understand is that there is true passion and there is true desire to get it right for users first, for developers second, and for ourselves third. much like the priority of constituencies written into the HTML5 design principles, which, by the way, was written by one of our standard engineers and the person who was in charge of all of WebKit back in the day. So, like, Ana and Maciej wrote that principle. Like, that's not – we believe it very deeply. And sometimes, you know, there's something that would be great for a project or a developer, but we can see some way that it would be dangerous for users if misused. And so we're often like, gosh, I wish we could ship that. That would be awesome. But these other people would do something really bad with it. And so we can't. We can't. We have to protect users. We have to make sure that if you ever click a link, anyone ever clicks a link, that what happens after that link is clicked is safe. That's one of our top priorities. And privacy, that people's data is not being sucked into something that's not good for those people. So that's what often our web standards positions are about. I would also say that there's a difference between user needs and standards positions. And even if Apple has or WebKit has a standards position, that should never prevent developers and users from enunciating and describing their actual needs. Because the web is such a vast platform at this point, there are often ways to disentangle these things or approach them in a slightly different way. So a specific feature or a specific APA may be something that Apple doesn't feel comfortable getting behind. But we are always responsive to trying to work out what is the best, webbiest way to be able to meet these user needs. And so no matter what we've said or we haven't said anything, filing those requests is absolutely vital in working out what it is that we actually can do with and for the web in order to meet those needs. Well, and it is an ongoing conversation. Yes. It's never a done deal. No. And things change. I mean, I don't think we had a standards position against a parent selector, but it certainly came up over and over and over and over for years and years and years. And I think it's right to say that Apple was like, yeah, that's never going to happen. A lot of browser engineers were like, that's never going to happen. And then I guess it was Agalia who was like, wait, we really think Has can happen. And for some reason, that triggered our engineers to be like, all right, well, look at Has again. We've said a billion times, it's not going to work. A parent selector is going to be too slow. It's going to slow the browser down. The chips aren't fast enough. We can't do it. The hardware's not fast enough. And then our engineers looked at it again. And I don't remember who it was exactly, but it had a genius stroke of like, but what if we did it this way? And also, hey, the hardware is a lot faster now that it was 20 years ago. And we figured it out. After saying no for so many years, it was the WebKit team at Apple who figured out how to do Has as a parent selector in CSS and make it super fast. And that unlocked everything. And now it's shipped in every browser. But, yeah, things change. Very nice. Just to double down on what Brendel said, be vocal about features you need and you want, build JavaScript libraries, demos, whatever, share it across the web, on social media, and bring it to people's attention so others can hear about that and see it. And eventually, if it's useful and people want it, it will get into a standard and into WebKit or Safari. Yeah, I think it really helps to know, is it just a couple people or is it a lot of people who want or need something. And is it just for one or two use cases or is it for a lot of use cases? I also think that being really kind helps and realizing that these are humans and we're having a conversation and we're really just trying to figure out what's best rather than other things. That's a good point. And make demos that represent your actual use cases. That's very important. Not just like flashy demos that makes the most of the API you're trying to use. Yeah, because we want to know, is it realistically something that people are going to be using and that's going to really help our users? Nice. This one is from Harsha. Is there any improvement to cookie synchronization in WK WebView similar to the behavior that UI WebView used to provide? We're still seeing challenges keeping cookies in sync between the app and WK WebView. So I'm curious if there are any recent enhancements or recommended approaches. So from the backroom, the backroom suggested to use WK HTTP cookie store to observe and manipulate cookies for WK WebView. I don't think we have experts on cookies here. All right. So this is a good question for the forums then, for developers, for the developer forums. Okay, next we have, excited to see we can create extensions from a prompt. This is from Jay Kingens. This motivated, this motivates more powerful extension-based API support. Are there plans to further close the gap on API support with what Chrome and Firefox offer? For example, tab group APIs. Yes, so a lot mentioned there. I'm also excited to see that users can create an extension from a prompt. We really wanted to give users the opportunity to see what extensions are in the App Store, if they're already there, or to get creative with their browsing experience and specify an extension that meets their unique use case. As referring to the different APIs, We encouraged for you guys to reach out to us on bugs.webkit.org, file a bug. As mentioned earlier, it's always helpful to get the use case for that specific API because there's so many APIs. And as Jen was saying, there's not enough time or people or resources to tackle all of them. And so what really comes into consideration is the use case and what benefit it adds to your extension or other extensions that you might see that might benefit from that API and why it'd be useful to have additional support for that. But in addition to that, we are working really hard in the community and working group to standardize those APIs and to get them the same behavior across platforms. And so if you see an API that might be available in another browser but not in Safari, Be loud about it and let us know why. And we'll work really hard to figure out if that's something that we can get done. Cool. This one is from Paul Sheldon. With spatial CSS, do I see things on my Apple Vision Pro in 3D coming from the web? So spatial CSS at this point is a proposal. It's not something that we have any specific news about shipping. But given that it is coming from us, it's something that we feel positively about. What we do have at this point with the sort of spatial representation on the web is the inline HTML model element, allowing you to have USD and other 3D file format based 3D models placed into the web page, as well as being able to drag them out or now with the immersive environments being able to see those at full scale. That also allows you to create things procedurally, so you would be able to create things that are like CSS. We're excited for people to play with that. Ultimately, we think that spatial CSS and having the full accessibility tree, all of the other features is the right way to do that, but nothing today is going to prevent you from playing and experimenting with those things in a way that's going to look a lot like that, and I would like to see it personally. Very nice. Cool. This is from Wagi, I think is the name. Do you think we reach the end game for optimizations and performance in the web, or do you think there is still more performance to squeeze out of the browser? Yeah, I don't write browser engine code, so I'm not one of the people working on performance, but there's a lot of people working on performance all the time. So I think, and you know what, I think one thing, when I've heard web developers talk a lot about performance, they're often thinking about how do they make their JavaScript run faster? How do they make their images load faster? How do they make sure their website is in front of users as fast as possible to the point where a user can use it? And yes, also, I know my colleagues here, my friends here at Apple are like thinking about how do we make sure that a particular website or a browsing experience doesn't tax people's batteries too much? Because that's what a customer is thinking about. They're thinking about like, oh, I haven't gotten home yet. I'm trying to take the train and my battery is down to 15%. Oh, no. Like that's the thing. There's lots of ways to define performance and there's lots and lots. There's always going to be, because we keep making the web more powerful, and then we need to make it more performant. We make it more powerful, we make it more performant. So, yes, I don't think that that's going to end anytime soon. In the context of things like 3D graphics, not just on Vision OS, but everywhere else as well, we started with WebGL back sort of starting in 2010. And after a few years of that, we realized that what was really taking the most time, what was really hard on these chipsets across the entire industry was a little bit different to what looked like was going to be the bottleneck at the outset. And that is why we moved from WebGL still exists and WebGPU is the successor to that in terms of making sure that it is most appropriate as a match to the silicon that Apple, but all of the other major vendors are producing as well. So as we discover what people want to do the most of, we also end up with different optimizations. And it can take a while for that circle to close in terms of how we do it and then how we do it as efficiently and as performantly as possible. So unless we end up stopping development on the web at all, I think that we're probably in line for about as much performance improvement there as well. like WebKit engineers, they have to deal with benchmarks every day. We can't regress benchmarks. And we're also constantly looking for improvements. And what I found is it's very surprising what can or what can't affect performance. It's often like a complete surprise. And so it's hard to say if there's a ceiling that we've reached. And even if there's a ceiling that we've reached, often we create a new version of the benchmark that takes into account the new needs of the web. Websites constantly keep evolving, so there's always new optimizations we need to think about for the evolving needs of the web. Something users care about a lot. As a person who worked on performance for the model element, I can say there is no end game for performance, never. As Brendel said, only if we stop development completely. At the same time, every change in the code can have positive or negative implications on performance. And big shout out to WebKit PNP team, Power and Performance, who are actually working on an infrastructure that is running performance tests, like on loading, on rendering, on power, for pretty much every commit, or at least we try to run it for every commit in order to have data, like what is going on with performance on Safari. And faster we get the data, better we understand what is going on, if something is going wrong, or if a performance improvement actually hitting the target. I mean, we're obsessed, which is why we have the fastest browser. Yeah. This is from Dirk Yo. I would like to create a Safari extension for SEOs that takes what's in Safari and displays reports, guidance, and a Swift UI window so users can use it across any platform. Fast apps switching on iOS, separate palette next to Safari on macOS and visionOS. What is the path you'd recommend for this? Good question. There are a couple of things that you can do. You can display some of this information in some extension UI, so you can use an extension pop-up for this. In terms of monitoring different changes within the page, there are different extension APIs that you can use to leverage that. So web navigation APIs. If you want to get some communication back and forth between your app and the web extension, you can use native messaging to get that information and display it in the app and such. So different variations that you can leverage there. Very nice. All right. Let's see. Okay, Tim, this is for you. If a developer wants to progressively enhance an existing select, adding appearance-based select without breaking the experience in browsers that don't support it yet, what is the safest approach? So it's very important to always have textual content in your select because with customizable select, it can be pretty tempting to remove text and put icon-only interfaces or color swatches-only interfaces. And if you have text content, then when you use a browser that doesn't support customizable select, that text content is just automatically used, and that's the beauty of progressive enhancement. But for that to happen, it's very important to have text content. As well as in a browser that doesn't support the technology, you'll just see a blank pop-up, which isn't great for users. And not only is it great for progressive enhancement, It's also great for accessibility because that's what screen readers will read out loud when you navigate to select. And often it's also good for UX. Sometimes icons are hard to recognize. And having a text label can help clarify the meaning of the icon that you put in your UI. So always put text. - Yeah, so it's pretty simple, right? If you use select in the traditional way and you put all the text options in and then you layer on top of it, oh, also we're gonna put these images in here, we're gonna put this extra content in here, we're gonna style it with all this CSS, and then when a user goes to a browser that doesn't have support, they just get the OG list of text and the browsers we support get all the fanciness and the web developer doesn't have to do anything. They can just be totally lazy. Yeah, I think that that's one of the things that people, maybe especially if people learned other programming languages first, maybe they have a computer science degree, or maybe they went to boot camps and they learned all about React or whatever, but they sort of learned a framework or another way of programming, and then they didn't. Now they're trying to figure out the web. I think sometimes it can be tough for people to understand progressive enhancement because I don't know that other programming environments work this way, but because the web technology never changes. Like, I mean, you know, there's never a version two. It's always building on the original web. Progressive enhancement is so, like, and Select was designed that way on purpose. Wasn't there a conversation about making a new element that had a different name? Yeah. And then they didn't go that way because of the progressive enhancement story? Yes, yes. It used to be a select menu element. That was the original proposal. And it was suggested by one of our standards engineers, I think, Anna, to reuse a select element so all the browsers could get a nice fallback. Yeah, the semantic underpinning of the web is really a secret superpower. It enables so many things from accessibility trees to AI-readable content. incredible localization capabilities that simply don't come in either windowing and layout management systems unless they are either secretly actually the web underneath or people are going to an incredible amount of effort for it. So I absolutely think that using Select the way it's supposed to be is probably the best bet. And not to mention you get like keyboard navigation for free, which I haven't mentioned, but it's really awesome. Yeah, and not just like your keyboard navigation, but all the keyboards and all the input devices and all the output devices, including Braille keyboards, are devices you have never even seen. Just use HTML. I mean, that's the exciting thing. That's the exciting thing about not only customizable select, which is pretty darn exciting, but then also there's a spec in progress that you wrote the first draft of, Tim, of appearance base to be able to style all the HTML form controls because that's one of the number one reasons why people reach for other tooling or use divs or spans instead is because they need to make them look a certain way for their brand so that spec is still in progress there's still discussion that needs to happen i think even you and i don't agree completely yet on how like there's discussion that's going to happen about how it works before anybody sees it running in a browser but to find a path to solve a 30 year old problem of like can we actually give developers full control over styling real HTML form controls so that everyone can use real HTML form controls that can be totally interactive and you can make them look however you need to for the project that you're working on. All right. Alexei, this is for you. How does the model element handle loading states and errors and what control do developers have over the experience while a model is still loading? That's a good question. So we have already promised in order to signal developers that the model is loaded or not. And I think with combination of this promise and like let's say a spinner that you can implement, we can provide a really good experience for users to see like whether a model is loading or not. And when it's done, like you can hide the spinner and present the model. And the second part of the question was? The second part was do we have control over, what control do developers have over the experience while a model is still loading? While it's still loading. I mean, that's pretty much it. Maybe Brandel has something more in mind, but before it loaded, you can't do anything with it. Fair. So we will signal you with promise, and then you can interact and use like entity transform and other things and other JavaScript APIs. - Do we have a CSS pseudo class for when the model is loading? - That's great feedback. So one thing that is, it's like images, but more so, is that there is a difference between downloading bytes For an asset and having the resource actually loaded and usable. And so, you know, that's the difference between sort of fetching the core bytes of a JPEG or a PNG and then when the image element that results from it is actually loaded. And the same is the case for a model element. You can get the bytes and you can then process them and put them into a model element. And there will still be some period of time before that is actually ready to use in that same way. So you can look at those two distinct states more or less in the same way that an image works as well and sort of reason about or present those things. And likewise, if you are generating a model procedurally using some kind of JavaScript library, then you're still going to have to wait from the bytes, even though you have them already in the browser locally, for those to be processed into the actual resulting model. So there are a couple of different phases, but there are ways of reaching in and reasoning about and presenting relevant information. for each one. How big do you expect most models are on the web? Or will be? Well, models can go crazy. But we would encourage people to keep them smaller and optimize them before putting on the web. The same thing that you do for images, right? Because loading time will increase and processing time. And, of course, as engineers, We love to take memory as an infinite entity, but of course it's limited, and it's our job to make sure that we can have enough memory in order to show our content to visitors of the website. I would encourage, in terms of the size, it depends on what you actually need to see out of a model. So, for the most part, if a model is content on a page, it's not going to be bigger than that page. That also means that the number of textures and the size of the textures doesn't need to exceed what is relevant for displaying that. Likewise for the geometry, the shape of the object. So we don't have any hard guidelines, but in general we've found that people can get what – hit the maximum sort of visual quality in somewhere around 10 megabytes, which is larger than an image of the same thing. But we think that given the flexibility and the range of motion and animation and things that can be achieved with it, that most people should be able to do that. If you have an environment like in Jean's session, those things can end up larger and need to be made out of more polygons and more textures. But that's in order to sort of stand in as a full screen experience, much more in the same way that a long running or large video might end up being a lot larger than the page it's actually hosted on. Yeah, and what a lot of maybe web developers, web designers who are newer to the industry might not remember, but those of us who've been around for a long time do, is it used to be that watching a video on a web page was an experience that included a bunch of waiting. And before that, it used to be that looking at an image on a web page was an experience that required a lot of waiting. So it feels like some of the – often the lessons learned in the past reemerge, And maybe this is a moment to think through where it sounds like designers and developers need to think through, like, what should the experience be? And how can they help their users through it? And how can they optimize it to make it better? But also that things will continue to evolve. And maybe there will be better ideas and new ideas about how to support loading and new technology to get invented over the next couple of years or so. I'm just making this up. I know. It's absolutely true. So USD Crush, which we've outlined in the number of talks, is a command line tool provided by the Alliance for OpenUSD. And in the past, that would reduce everything down to JPEGs. As we've sort of agreed upon it, now that is compressing to AVIF files, which are much smaller. And we are in discussions with the Alliance for Open Media about what might be an appropriate mesh compression format for being able to pursue these things. And when that happens, then that's the kind of thing that people will be able to kind of do. It's back to that point of like, what are people doing a lot of and how can we make that easier? And that sort of circle takes a while to close, but the progress happens. When you said like there used to be times when we waited images to load, I hear a modem connecting. Oh, it's there. Next question, how should developers think about permissions in Safari extensions compared to other browsers? Are there things Safari is more restrictive about, and how does that affect what an extension can actually do? That's a great question. When it comes to permissions for extensions in Safari, we design the permission models with privacy first and privacy in mind, and with the user's privacy in mind, because extensions can be really powerful. They can access a lot of data, a lot of sensitive browsing data, and we wanted to make sure that the users are in control of the data that can become available to an extension. So permissions that are requested in extensions manifest, for example, aren't automatically granted to that extension. We give the user that choice to decide which site they want the extension active on and so forth. then we try to be as clear as possible to the users of Safari of what that extension can do if it's granted access. And a lot of the time developers aren't even trying to really access all this information, but they may be unsure of what sites the user might be on for their extension. So they might request too much access. And one way that they can work around that is with the active tab permission so that the extension is only active on the tab that the user is on and then they lose host permissions once the user navigates. And so that's one workaround for that issue. But we really want to make sure that users' privacy and data is kept as protected as possible and that they're aware of the sites that the extension can access. Cool. How does the immersive API interact with existing web content? If a user is in an immersive environment and something on the page needs their attention, how does that handoff work? In an immersive environment, the web page is still up. And so whatever you need to do on that page, you will have full ability to do. If you need to get into another application, I believe that this is a single app experience. and so if you had messages open on the side, that may dim, but it's available just with a crown press restoring you back to your sort of general shared view. But if you need the web page, or if you want the web page to alter things about the immersive environment, say to move the position of where you are in it or play or pause an animation, then you can put whatever UI onto that web page for the user to be able to do that. Very nice. I know that for a lot of web developers, the idea of doing anything spatial is still very new, and it might not always feel relevant to their work and their kind of everyday experience of developing. Is the model element the thing that tips that over, or how is spatial web relevant to kind of more everyday developers these days? So I would say model element is just the first step and probably the easiest step for web developers to experience 3D stuff of the web, or even like spatial web. And it's definitely the easiest way to go right now. Even if you don't have a model, you can either find online or with modern generation tools. Like you can actually generate 3D models to your liking, whether it's a creative generation or use like a bunch of images in order to create an object that looks like a real object. And I would highly encourage people who are interested in spatial web to start with this. It's like less friction in order to get into that. And maybe after that, even learn a little bit more about 3D, about tools that allow you to build custom stuff, like Blender or something like that. And yeah, I mean, there is natural progression in that, but the first steps I outlined right now, it's the easiest and probably most compelling, like when you can see results pretty quickly. Absolutely. Okay. With appearance-based select, how much of the styling just works out of the box versus what do developers need to explicitly reset or redeclare to get a consistent result across browsers? This question is from me. It's not, it's not. But this is the topic that Tim and I don't agree with. Ew. Spicy. Yeah. Yeah, but go ahead, Tim. So with appearance-based select, what you get out of the box at least is the layout. The layout works correctly. And also, it's better than appearance-none where it uses its custom font. And with appearance-based, the font just gets in your control without any changes. but what I find amazing about appearance based selects are the pseudo elements that you get from it like now you can select the picker icon part and style that separately without changing anything else in the select or you can change just the drop down menu or just the check mark in the select element So that's personally what I'm the most excited about, the new access to the specialized parts of the select. Yeah, and the appearance-based select for the select element and also appearance-based, which will come later. It's not shipping now, but it will be for all of the form control elements, including select. Eventually, everybody will just choose appearance-based. It does, yes, deliver a functional form control unlike appearance-none. and it is 100% interoperable between browsers. So you're not going to get a different looking or different feeling form control in different browser engines, which is sort of the basic foundation that's needed in order to be able to style it, to put your own styling on top of it. Because if different browser engines had different versions of the form control and you would apply styling over here to make it look how you want it, but then that styling being applied over here would end up with a different result if they don't start in the same place. So I think that's one of the most profound things about this work is switching to an 100% interoperable base on which to start. And then, yeah, pseudo-element so you can target things that you weren't able to target before and more. Also, the DOM structure being consistent between browsers that the HTML under the hood, you can address it because it's the same between all of the browsers. That's why it's very hard. It's a hard project. And the thing that I'm kind of laughing about that we're not quite, the little bit of discussion is still happening about is what will it look like when you apply appearance-based or appearance-based select? What's the default? Is it sort of, does it remind you of the 1990s where now you need to make it look good? Or does it somehow look like a modern form control and you don't have to write as much CSS to make it look good? But what does modern even mean? And is that a fashion point that's going to change? Whose opinion is that? But no matter where it starts, the idea is for it to inherit as much as possible from the existing website, which forms don't do by default or they haven't done in the past. So, yeah, if you have a background color, that your background color is being seen. If you have a font, your font is being used. If you've set your font color to something, that font color is being applied. to just for the UA style sheet to have as little opinion as possible and just to inherit as much as possible. Because that's how everything else works in CSS. It's how a dialogue works. It's how a detailed element works. Everything works like that. To make it easier. And I want to add on top of that, that appearance-based doesn't use any layout magic that form controls have. So it's entirely... Under the hood, it functions, the way it's laid out is exactly like a normal HTML element. The normal CSS and HTML layout applies. There's no special hacks to size it a certain way or special hacks to clip it a certain way. It's all hopefully predictable web technology that gets into play. Yeah, it's wild to me that inside the select popover, what's it called, the picker, you can use grid or flexbox or grid lanes to lay out your options. Yeah, it's incredible. For a developer who has an existing Chrome or Firefox extension, what's the realistic amount of work to get it into Safari, and where do the manifest or API differences tend to bite people? So, in terms of a realistic amount of time, it depends on the extension, in short. You might have an extension that you can convert and it just works out of the box. And there aren't any browser-specific APIs that that extension that was being run in Firefox or Chrome was relying on that isn't supported in Safari or is just in that browser alone. But for the most part, we've been working really hard in the Web Extensions Community Group to find inconsistencies within APIs across browsers. And so if you experience that, you've converted it and you've tested it out in Safari. And for those who might not know, you can go into the developer menu and you can load a temporary extension. You can just use the extension resources for that extension that you've shipped to Firefox or Chrome or another browser. load it in Safari, test it out, see what works, see what doesn't. And if there is an API that behaves differently in Safari than it does in Firefox or than it does in Chrome, or if you've noticed, oh, Safari aligns with Firefox, but we don't align with Chrome, we've had those discussions and we're continuing to have those discussions. So bring that to the community group or the working group or file a bug on bugs.webkit.org or use Feedback Assistant to let us know that this is an inconsistency that you've experienced and we will take a look and see what we can do. But in terms of manifest differences, there aren't any grave differences between our manifest support across browsers. And we tend to not fail on unsupported keys. And so that was a really big thing that we wanted to do to help developers who were migrating their extensions to Safari to not fail on things that we don't support. and things like that. So, yeah. Now for our final question, I'd love to get an answer from each person, a quick one if possible. What is one thing that you would love people watching, web developers who work with Safari, who work with WebKit, what do you want them to know about either the upcoming release or WebKit in general? Am I starting? You can if you want to. I'll just let this one. Gosh, I wish I had time with this question, But I mean, the answer that I think the thing that might get easily missed, but that I do hope people realize, is just how long the release notes are this year. They are so long. They are really long. Just scrolling for days. I think the Safari 27 beta release notes are like twice the normal length. Yeah. And not just 27, but also 26.2, 26.4, all of the 26.23456 release notes. If you add them all up together, which I have done multiple times, it's an incredible amount of work. And it's because so much time and attention went in this year to hunting down those little paper cuts and doing whatever it took to fix them. And we're not done. Nobody thinks we're done. we're going to continue that work but i know i've heard from a lot of web developers you know in my mentions or wherever i see people frustrated or feeling dejected or feeling like i don't know they they come to some kind of conclusion that was you know a different ideas coming from a different browser engine about like whether or not we even care it's like we absolutely care and sure you're hitting a bug like let us know we're going to squash that book because what's the advantage of making users experience of the web worse in safari why in the world would that be our goal that's not our goal like so yeah um yeah i mean we mean it people worked incredibly hard this year this whole cycle to um to really align with web standards and really like improve the quality of the browser engine. We've gone as far as rewriting our JavaScript module loader to fix the top-level await bug that people have been mentioning. I think just that effort is amazing for a couple of bugs. Yeah, and something to look forward to or to look for on the web extension side is that not recently, but a few years ago, we moved all of our support for extensions into WebKit, and that might not be something that folks know. And so if you have filed a bug or you want to see a difference in an API, you can contribute and you can bring your contributions to WebKit. So feel free to check out the code base, file a bug, and see how you can help improve it. Nice. Yes, father of three, I can't pick a favorite child. But to highlight one, I would definitely say play with model element and see how it works on different platforms and just enjoy 3D on the web. All right. And I would say the web is such an incredible platform these days that if you've just started or if you've been on it for a while, try to look back and figure out how little work you have to do based on what the web standards are doing for you. I have been a web developer professionally for over 25 years now and I mostly managed to get away with not using any frameworks, not using any environments and I just couldn't be happier about that. So for web developers, think about how little you might be able to get away with building and using because I think you would be pleasantly surprised by the state of it these days. I would love to see people use more like Safari specific technologies in demos. I want to see more random function demos and filter function demos. You mean things that we've shipped first, that are web standards and will be coming to other browsers sooner. Yeah, hanging punctuation. I want to see more love. There are quite a few things I think people don't realize. We often are inventing new technology and shipping things first. Yeah. Very nice. Well, that is about all the time we have today for this group lab. We are so thankful that you all joined us today, and we hope that you found it really helpful. I also want to say thanks to our wonderful panelists, as well as all the folks working hard behind the scenes to make this happen today. As we mentioned earlier, if we didn't get to your question, please visit the developer forums at developer.apple.com slash forums, where we will continue the discussion. And visit bugs.webkit.org to file any bugs or feature requests. We really do appreciate your bug reports and feedback. For more articles and release notes on WebKit and Safari, check out webkit.org. And if you want to learn more about Grid Lanes, we made an amazing field guide for you at gridlanes.webkit.org. It is so good. Speaking of feedback, you should receive an email with a survey link to let us know about your experience at WWDC. We would love to incorporate your feedback in future events. Thanks again for joining us and hope you have a great WWDC.