Welcome, everyone. I'm Francial, the Community Manager for MDN at Mozilla and I'm here
to run a panel which is called Browser Priorities from a developers standpoint and here
we've got four lovely people who would you like to introduce yourself?
Hi. It's on.
Yeah, it's on.
Hello, everyone. I'm Kadir. I'm a web platform product manager at Google. But I was at Mozilla
before for over decade. I was actually here in 2004. I think it might be the first
time that we had this dev room. So it's nice to be in this room again.
I'm Silverest. I'm a director at Mozilla. I've been at Mozilla for only 12 years.
And I run a lot of different things like organization.
Only.
I'm a newbie.
I'm Tina. I work in Netapurah for last eight years.
I'm working mainly with some QA staff, like role-end features, like VPN and blocker releases, etc.
And also working with user reports. So I'm a person who read the box, actually.
And answer it sometimes. So yeah, nice to see all of you today.
And my name is Patrick. I work at Microsoft on the edge web browser.
Used to be at Mozilla before for a few years.
And then at Microsoft, I work on the web platform and the inter-approject and a little bit of dev
work. So I'm a bit over the place. But yeah, excited to be here.
Awesome. All right. So before we start, I wanted to lay the groundwork on what this panel actually is.
It's not a feature discussion. It's not a standards negotiation.
We're not here for the head. We don't want to start any fights.
But we really want to help you understand how do browsers ship.
And how can you play a more influential thing part in that?
And yeah, to start with, I think let's start with the big picture and inter-op.
For Kiddier, from browser engineering perspective, what has changed about inter-operability
say in the last five years?
Yes, really good question. About five years ago, we had our first big developer survey.
And one thing that came out of that was the MDN web developer needs assessment.
The MDN web DNA was 30,000 developers answering questions.
The biggest issue facing developers was interoperability.
So that's where we really saw for the first time at scale that's really something that we have to solve.
And since then, we've started a bunch of things. One big thing is the inter-op program,
which is where, for the first time, since we've started shipping the web,
browser vendors are actually coordinating on what to ship in the next year.
So many people haven't heard of that probably, but the major browser vendors and the ecosystem
coming together, looking at proposals and then deciding what's going to be interoperable by the end of the next year.
So that's new. And what we are also now doing is that we're looking at making the web platform easier to understand with baseline.
So that's something that didn't exist five years ago, but the states, if you want to know,
doesn't feature actually work in Toronto for aably?
The answer to that question is usually, is it baseline or is it not baseline?
And those are things that, yeah, we've only had for a few years, but they've changed fundamentally how interoperability works on the web platform.
I would actually like Dina's opinion on this, because something working in theory, something interoperable in theory,
versus actual real testing, how has that changed in the last few years?
Regarding how it works inside our teams now, it for the last five years probably over the pandemic, like the years,
we rely mostly on analytics team now. So before it, it was a kind of bug fixing just when bug appears.
So we start to fix it. And now we try to analyze the gaps.
Using different and analytical tools, usually it's look outside. I don't know, to deep diver like into details, but it helps us a lot,
and it also changed our culture inside the company. So yeah, in this way.
I would say that browsers broadly agree today, right? And I mean, yeah, we do.
But are there any interoperability problems that remain difficult to fix? Maybe, so let's check it on to this.
Yeah, I mean, sure, there are always interoperability problems. One is the platform above all the time.
And if the web is to win, it needs to absolutely continue evolving, and because it does, and it does in a messy way, that's not linear.
There are always differences between browsers. So although we do agree on the massive amount, like the majority of the things,
at the fringes is where it breaks. And I guess another example of this is different oasis, different devices, hardware,
means that even if we all agree on the same things, it's not going to work the same everywhere all the time.
WebGPU recently launched any supported by augmented browsers, but it doesn't actually work on exactly all of the different combinations of oasis and browsers.
And so there are some areas where it's just like that, and we have to take it into account, and it's messy, but eventually we get there along the way.
Well, we're at it. How do you balance that developer expectation, whether it's enterprise, whether it's an individual user?
So enterprise, excuse me, enterprise is a big thing for Microsoft, which I work for, obviously, because we have a lot of partners and there are our customers, and we need to make sure that they have a great experience.
And I think it's actually, they are usually the first ones to upgrade to the latest version of the browser, because they want the latest security fixes, security is super important to them.
So not everything is a problem, but we also do realize and we understand and we work with them on apps that they have that are business critical, right, and they can't really always change.
And also not all markets in the world are on this evergreen kind of web thing that most of us are on, I guess in this room, where we always have the latest browser versions.
So we have to be conscious of that, and we have to give IT admins that enterprises, the way to set flags, to turn off some stuff, or to remain in a sort of a legacy mode for a while.
Like we do this at Microsoft Edge on like a browser basis, or a per-site basis, we give them the tools essentially to stay, to keep on having their business critical application running.
So it's nuanced, there's no like one answer, but it is something that we have to care for pretty much eternally, because the web is here to stay.
Because the end I were talking about the scale of the web and how many users does the web platform actually cover at the end, it's more than 5 billion maybe.
And yeah, but these are the good things when we align, let's talk about a bit about when we don't align.
To sell faster, right, when browsers drift apart, does that make?
When browsers drift apart, is it usually because of lack of resources, issues or general technical disagreement?
I think the comments are when we talk about browser, it depends, it's sometimes we are going to align.
Sometimes we disagree, so some of the typical things are, which has been a lot of big subject of discussion, it seems like web USB web serial.
Google has been pushing both things for a long time, and we started also to change our mind, for example, for web serial, we realize that we have better way to make it and to make it more secure.
So sometimes we disagree at the beginning, and sometimes we are going to change our mind.
Another big subject that we have seen for a long time is web RTC, some of our competitors, we are not implementing web RTCs exactly the way they should do.
So we have been discussing with them in various forum, like the USB 3C and so on to say, can we align on those things?
We are so complex and so intertwined, so sometimes it takes forever.
We also, on the positive side, we collaborate a lot on the technical level, so for example, Google is now using Rust inside Chrome, which is initially a material project.
We share a lot of libraries and code, we often contribute, it's very common that, well, not that common, but sometimes we find security issues on Windows and we are going to report them to our friends.
We have private mailing list where we can share the kind of information, so we collaborate a lot.
We are competitors, but we are also partners in many subjects, and we like to improve the security of the web.
Well, say, anybody else wants to answer that?
Where about this email?
So, while we broadly agree on standards, where do standards sometimes give the impression that a problem is solved, right?
Even though developers still don't see a different behavior in their browser, right?
So I think I'll pass it on to Kadeen, Kadeen, that.
I think the issue is, oh, yeah, so, you know, yeah, sometimes it looks like a browser's implemented feature and they have, but the feature still doesn't work in general probably everywhere, and that is a big issue for developers.
So we have two ways to address that. One is, and we've heard about that today already, web platform tests.
So we have, I think at this point, I wanted to like, over two million tests running in web platform tests, the web platform is huge.
And so what we're trying to do is get features to ship with high quality test suites.
And that allows us, hopefully, to catch those things before they actually hit users and developers.
But sometimes, that's not possible. So they do get out.
And at that point, it is always a prioritization issue of like fixing issues.
Sometimes that's difficult because there's already an expected behavior that you can't easily change.
But one thing that we're now trying to do and have been doing over the last few years is within the intro project.
Those also are things that we try to align on as browser vendors and try to ship things truly interoperably.
So we don't just use interoperable new features that we align on.
But we also look at what are features that we've already shipped, but developers can't use them because they are too busy.
So the first few years of the intro program were actually focused on that.
So lots of CSS Grid and CSS Flexbox issues that we fixed in the first few years of that program.
There is still more. But the way to actually do that is we're trying to get better at web platform tests coverage.
And I think interoperable is common for everyone to come together and collaborate.
What does that look like on Google's and how does Google talk with other browser vendors and collaborate when it comes to interrupt?
Yeah, so that is the main, we do it all the time with browser vendors because that's the only way to really ship things to the web platform.
So we try to get things to consensus because developers often times rely on that interoperability before they can start using a feature.
So even if we don't initially have maybe buy in for things, we will still experiment with those things.
But we'll go back and try and show whether if there is developer interest, we show that there is developer interest and try to build consensus around that.
And again, the way we have been doing that in the last few years has been through the intro program which anybody can send proposals to.
So I think this year we had more than 150 proposals.
Some of those things, chrome and already implemented, some of those things other browsers already implemented.
And so that was the way to maybe get convinced again or look at the data again.
JPEC Excel is maybe a good example of this.
So originally we were convinced that there was a need.
And we thought that maybe there is already a good solution to that problem.
And over time, by hearing from developers about that issue, that convinced us that there is something here that we have to address.
And so the intro program is really the way where we coordinate these things.
And JPEC Excel is actually one of the highest rated months from the community right?
Yeah, it's one of the new things that we've launched called developer signals.
You can find us on can ius.com or if you go to webstates.dev.
There is an upload that gets you to get up repo where we collect information about what are developers using these things for.
Where are the issues, what are the work around so people are using and what are the use cases.
So that gives us lots more context for those things.
And yeah, in the case of JPEC Excel, if you use that information to change our mind of that one.
That's awesome.
Let's get into the decisions that developers really see.
So, Sebastian, what kind of trade-offs do blousetings make that developers really see?
So, I think even Google is actually dealing with that content.
There are so many things that we want to do on the web, but limited time and resources.
So we already have to make trade-offs.
So for example, in my team in my org, we do a lot of different things.
So we do engineering work flow.
So we provide the tool for the Firefox community to work on Firefox.
But we do a sort of translation. So we always have to make trade-offs.
Of course, at the end, the user Firefox or our Chrome, they don't care about the number of resources in the engineering teams.
They want to get new features.
So we always discuss among ourselves.
We define what is a priority.
We get feedback from everyone inside the organization.
And we also look at interrupt and what our competitors are doing and what the web devs they want.
So we pay a lot of attention.
But you can see that I have gray hair.
It's probably because of that.
It's all the trade-offs that we have to make all the time.
Because the web platform is where more complex and the operating system and everything is moving super fast.
So it's very hard.
That job.
And it's impossible.
But then when push comes to shove, how do you prioritize?
How do you decide what to prioritize was?
It's developed experience, consistency across browsers or scalability.
So we're seeing at once.
So you have to prioritize.
It's not like you cannot say web compact is not going to be a focus easier.
You always have to do the things on Firefox.
We have thousands of developers here.
So we need to make sure that the process is the CI works and so on.
So you cannot say we're not going to do the things this year.
You can de-priorize some things.
But you always have to invest in all those fields.
You cannot slow down.
That's awesome.
When once we've shipped something.
What trade-offs to browsers?
Brow it.
Brow the things make.
Between test coverage, shipping speed, catching real world compatibility issues.
That's what you know.
Okay.
Depends on the area probably in which we will dive deeper.
Because if we're talking about, let's say, prominent decks.
Yes.
Here we need to rely heavily on some automated tests.
And because we need to speed up, we need to deliver this.
Let's say security updates very fast.
So here it's testing quality, of course.
And we also need to keep a high level of internal testing.
Like we need to get sure that Opera Core tested well.
Because those things that we had and not connected to Chromium Core.
It also should be delivered and tested well together.
Like together with a Chromium Core.
So we need to know how it will impact real browser behavior.
And also, like, for example, such kind of things that may be developed.
It didn't think about.
But for example, we have some web.com tests.
But then we can't rely on them in 100 percent.
Because we have such feature as sidebar setup.
And in sidebar, let's say we have some messenger.
I don't know, Facebook for messenger.
And we also have to test how it will work together after an update.
After an after release and you have this from Chromium.
How will work?
Different context menu inside this panel.
Because let's say less, like, we're excited.
And that's it.
So it's how it works.
How it works.
That's awesome.
And how does scale come into picture here?
Do you worry about scale on how many devices the regions oftentimes when you're testing those features?
Like internally, we have we rely on a special lab.
Like we call it.
So we tested the huge amount of devices.
But if we're talking about desktop, we shouldn't rely on such amount of devices.
Of course.
So for the desktop, it's just operational systems.
It's Windows, Mac, and Linux, they should be tested.
And it's all.
Cool.
Next one is for Patrick.
I would love to know which engineering trade-offs most strongly shaped browser priorities in ways that developers tend to underestimate.
I think it's easy to underestimate the fact that the browser is just the window to everything else.
The browser is the most used app on any desktop for sure.
And it's the portal to everything else.
And so you can literally access any untrusted code on your computer at any time.
And I think it's easy to underestimate the trade-off that that causes to us as a browser team.
That means privacy and security are paramount.
Like they're super important.
And like recently I was looking at the local font API, which is an API that's proposed to access the list of fonts on your system.
And we can't really do it actually because if you do it's a way for potentially bad actors to fingerprint your device,
just by knowing the list of fonts that you have.
So there's all of these things are trade-off that we have to constantly make.
Because we run untrusted third-party code, we just can't open up everything.
And that's also why sometimes we don't agree between browser vendors because some things are seen as more difficult or complex security-wise or privacy-wise by certain vendors and less by others.
So yeah, that's a big trade-off that we have to make all the time.
Government regulation as well comes into play.
We are different per geographies.
Obviously we have to keep all of that into account.
We can't just do anything we want on the web.
We have to take all of these into account all the time.
And can you talk about a bit about backward compatibility and how much that matters?
I mean it matters a lot.
And if you take the first website ever created, it still runs spacejam.com still runs exactly the same as before.
So it's very, very important.
But I think one thing that developers and even me didn't really realize until recently is that backwards compatibility is not guaranteed.
We do take stuff out of the web on a regular basis more often than we probably realize.
Where SQL I think was the biggest most recent one that was just removed.
We obviously need to do this gradually because otherwise we break the web and no one likes to break the web.
But there is something that can happen every now and again.
That's awesome.
While we've talked about backward compatibility, I think we need to look ahead in the last five minutes.
This is an open question for everybody.
So I would love for each of you to answer this.
What is one realistic improvement, browser vendors could work on together in the next year or so?
In practical terms, what is good enough interoperability mean?
I mean, I didn't start.
I would flip it around.
I would ask the audience, what do you want us to work on?
What is the most important and that's why we have all of the surveys and repository to capture feedback.
Because we want to stay honest and do the things that matter the most for everybody.
I think something you said before Sylverse which is it's a game of consensus.
We have to agree on stuff together in the same rooms and we discuss all the time.
But we all come with our own perspective.
We come edge, we come with like a bit of enterprise perspective and other vendors may come with other perspective and it's great.
It's how we push forward.
We get all of these different voices.
We bring them all to the table.
We have these use cases from them and together we can shape the web into what it is.
Awesome.
You know?
Yeah, like what come to my mind it may be some kind of protocols or regarding some concerns.
For example, after some operational system updates,
if you choose browser, then it should be the same browser as the user should choose and something like that.
So maybe more working together regarding those kind of protocols.
So initially I was going to continue what we have been doing.
There are the places where we can improve and we haven't talked about AI at all.
And I have to talk about AI but not seriously.
We see that we are all trying to do different things in our own way and we need to be smarter.
It's not going to go away.
All our company are investing in those spaces and we don't want to fragment the web with AI.
So we'll have to coordinate more in the future.
What does it mean?
How it is relevant to the user?
How is it safe?
And a lot of unknown.
It's going to be exciting to see what we can do on the do.
That sounds good.
Absolutely.
Let's do something.
Yeah, yeah.
You know, one thing that we've been doing with the intro program that's been really great is we've identified solutions.
And that we're already in flight and needed introoperability.
And that's been working really great.
But that's of course very late in the process.
So one thing that I would like to see more of is as identifying spaces of opportunity like web UI.
Where we see styleable form elements, for example, is like an issue.
That's not just one feature.
That's the whole area of improvement.
So aligning on those things is way harder.
Getting data around the needs in that space is harder.
And I'm hoping that we can do more of that.
But also, if I'm allowed a second one.
I would love for more.
More people, developers, companies on the web to get involved in shaping the platform.
Because it's like it's the one platform that really truly doesn't belong to anyway.
It's the decentralized development really.
And for the most part, it's the big vendors that invest.
But there are lots of others who live on the web platform.
And I'd love for them to actually get more involved in expressing their needs,
but also in contributing to engines like all of the engines are open source.
So a huge opportunity that doesn't really exist anywhere else.
So I'd love to see more of that from the community.
Absolutely. That's actually a great segue into our channels.
Let me get to the next slide.
Yes.
Right.
Get heard.
So we've got four ways that you can get heard.
Get involved.
I think the 2026 proposals will be out soon.
But please, what's opinion?
Oh, yeah. I mean, if you go through this one, interrupt 2026 is now going to be announced.
But every year, once a year in the third quarter, there is a proposal that we are opening it up for proposals.
So get ready for that.
That's we really look at that state of service. That's the state of HTML state of jazz state of CSS.
We look at the results of those.
We go through them together.
So absolutely worst taking those surveys.
Can I use feedback?
So this is not just on can I use, but what Patrick mentioned.
Developers signals repo.
But it is exposed on can I use.
If you're in the hurry, just leave a up vote that you need that one.
If you have more time, let us know about your use case.
And you can do that throughout the year, any time.
And then the last one there is that that's where the feedback actually goes.
Yeah. That's the repo where you can get involved with what did everybody else say?
Yeah. That's perfect.
We are already up.
In terms of time, I'm sure you have questions.
Please find, I actually request you to stay around for the next 30 minutes.
Please find them around the bedroom.
Be a huge applause for our panel today.
Thank you so much.