Beyond Browser Vendors
I'd like to explain what I think is potentially the most exciting set of changes that have taken place in the latter stages of the Web's history: Why we are now collectively considerably more in control of our own destinies and have moved "beyond browser vendors".
For most of the history of the Web, browser vendors have played an exceptionally critical role in standardization. This isn't a secret, in fact, it's widely discussed. What is less widely discussed is why that is. Frequently, most of our discussions give this very political origins, or assume it is about power struggles. But in fact, much of it has been for pretty considerably less intriguing reasons: It was a sort of predictable, natural outflow of the reality that we had created.
The first popular web browser (Mosiac) was proprietary. For a good chunk of our history, either all or most of the deployed browsers were built upon proprietary stuff, managed entirely by a single company.
This matters a lot because it meant that, practically speaking, everyone who is not a browser, including the myriad of organizations that participate in standards efforts are, effectively asking a small number of companies to invest money and manage priorities and budgets very particularly.
Mundane Realities
What's very, very difficult to appreciate from the outside is just how much is impacted, historically, by the fairly boring and entirely mundane fact above and that browser vendors aren't actually that special.
That is, they ultimately operate very much like most other organizations: They have a budget, carved out of some larger company. That company has some larger goals.
Their organization has an org chart with managers, teams, and projects, and QAs. They hire staff with specialized skills (these can be quite specialized). They have tasks and processes and annual reviews, and goals, and so on.
Code and approaches are adapted, they look for ways to improve performance, extend ideas, make things more modular, and so on.
Each quarter, then, managers have to decide how to maximize the budget in a way that includes an intersection of things in the pipeline (or that they might be interested in introducing), which best align with larger organizational goals,for which they have free resources with the right skills to do that work this quarter.
The Under Discussed, Big Impacts
If you can imagine a conveyor belt of ideas that ultimately land as tasks to be implemented, you can understand some of the problem. Even given the exact same inputs, different people can make pretty different, but entirely reasonable and defensible choices. And the inputs aren't remotely the same. Perhaps it takes one vendor twice as long to implement because this feature is much harder in their architecture, or they simply have less resources, or perhaps they're in the middle of reworking their layout, or... There are myriad reasons why these things get prioritized and worked differently.
If you were to consider nothing else at all, you can see why things get gummed up. There is an absolute gauntlet that something has to run in order to become a standard, even when there isn't particular controversy.
Practically speaking, this leads to misses. It leads to things backing up. The more backed up things get, the less likely a browser vendor is to entertain new ideas and spend a lot of time discussing things that doesn't directly align with their existing investments and priorities.
Things that come from another vendor, on the other hand, are more likely to place more direct pressure on them to respond.
Worse still, this creates kind of a feedback loop that ultimately winds up with a reality that yields near total practical domination of Web standards by browser vendors for reasons that aren't really especially political ones. These outcomes are not because of controvery, nor even particularly intentional.
A different story...
"But we do manage to get things done, even big things, rather quickly, when we really want to, right?" Is a refrain I've heard a lot. What about CSS Grid, for example? Grid seemed to drop everywhere at pretty much the same time, in 2017. It seemed like it happened very quickly to many of us, and I've heard this comment a number of times. If this isn't and illustration of vendors aligning on big ideas, prioritizing things, and getting things done fast when they want to, I don't know what is... Right? Here's the interesting part: It isn't that at all.
And what it is is far more interesting and exciting.
The backstory of CSS Grid
In 1996, Bert Bos, Dave Raggett, and Håkon Lie were the authors of a proposal called "Frame-Based Layout" which attempted to tackle the idea of a grid-oriented layout controlled by CSS. That completely failed to get uptake and implementations.
At the end of 2005, Bert Bos put some of these ideas forward again in CSS Advanced Layout. This kind of then became CSS Template Layout in 2009. Not one browser shipped any of this. It was important to the print industry though, so they invested and made their own renderers for print.
Fast foward to 2011, Microsoft reframes this work as Grid Layout and pretty much just documented what they shipped in IE10. But then, that's it. It sat there, in no small part because it had some real problems, having been mostly developed by Microsoft for specific use cases.
But then something changed, what? Well, a lot of things, but very importantly, the model of it all.
Open
Something happened along the way in our history: Both the standards process, and the the Web Platform itself got increasingly open.
In fact, today all of the implementations are open, and that's a big part of how we moved grid.
Most of the work on CSS Grid in both WebKit and Chromium (Blink) was done, not by Google or Apple, but by teams at Igalia.
Think about that for a minute: The prioritization of its work was determined in 2 browsers not by a vendor, but by an investment from Bloomberg who had the foresight to fund this largely uncontroversial work.
This isn't a unique story, it's just a really important and highly visible one that's fun to hold up. In fact, just in the last 6 months engineers as Igalia have worked on CSS Containment, ResizeObserver, BigInt, private fields and methods, responsive image preloading, CSS Text Level 3, bringing MathML to Chromium, normalizing SVG and MathML DOMs and a lot more.
Igalia loves open, and open standards - it's what we do. We participate in TC39, W3C, WHATWG and Khronos. We work on V8, JavaScriptCore, SpiderMonkey. Our teams work on Chromium, Gecko/Servo, WebKit. We work very closely with browser vendors. Openness can really change the economics involved and remove some previously difficult hurdles. This allows us all (including browsers vendors) to address more of those things than we could before.
The possibilities
This is the really exciting reason that I came to work at Igalia: Igalia potentially entirely shifts the standards paradigm. All this stuff still has a lot of costs to manage along the way. Browsers still play a hugely important role in reviews, managing questions of maintenance and so on - but, finally, we can begin to imagine a world in where we can more collectively prioritize and cooperate.
Imagine the possibilities of all of the things we could get done together. Lots and lots of stuff is just stuck- and many of the causes for this are ultimately because of things that are more organizational than because something is particularly controversial. We can help break the cycle and give those uncontroversial things implementation priority.
All we have to do is decide a thing is important enough, and there are lots of ways to do that. We're already doing a lot and I think we've just begun to scratch the surface of what is possible.
Imagine, for example, a world in which organizations or groups very interested in moving a set of topics simply came together and helped collectively prioritize and fund the efforts of those things, for example. We could get things done. Things that have lingered. Honestly, the possibilities seem endless: From discrete proposals that are critically important to a small group to broad ideas like color systems that touch everything from design to accessibility... Or, good print support from the same rendering engines? New core capabilities to help make things more extensible that are just moving too slow?
Our possible future is very exciting, and more than ever in our collective hands to determine! If you're interested in learning more, or have questions, you can contact Igalia, or come and find me at TPAC if you happen to be here.