:focus-visible in WebKit/Safari
:focus-visible pseudo-class matches only in heuristic cases where a native indicator would be
shown, thus making it possible to have good style and retain good accessibility.
Status: Implemented behind a flag in Chrome and Firefox.
inert in WebKit/Safari
inert is a boolean attribute in HTML/DOM which manages several lower level DOM aspects: whether a
subtree is available to the accessibility tree, or whether its contents are focusable or activatable. It is
useful for building higher level UI and components like modal dialogs without complex script.
Status: Implemented behind a flag in Chrome, in development in Firefox.
Will you help fund one? Which ones are most important to you?Contact us!
Ultimately, a large amount of the pains that developers face in waiting for things to get widely implemented are rooted in complex, but ultimately mundane difficulties involved in managing the prioritization of work across several vendors. Historically, setting these priorities is done almost exclusively by browser vendors, but it doesn’t have to be. Igalia has been expanding the number of ways that these priorities can take shape for several years, bringing rapid advancement of features to the platform by expanding investment in the commons.
We believe that this experiment can achieve some interesting goals:
- It can shed light on the particular sorts of challenges faced
- It can shed light on the fact that there are other opportunities available
- It can help give developers a more direct voice in prioritization
- It can expand the funding of the commons.
Do we have to pick just one thing?
Yes, for this experiment. That is what prioritization means, in a nutshell: Picking how to invest some finite resource. For our initial experiment there is intentionally a very finite list of options. If you can only advance one, which one?
Will Igalia do more of these?
If it works, definitely! We would love this to be successful and do a lot more of it. We believe that a commons works best with a diverse set of voices, interests and investments - but this has never really been tried before, so first we have to know that it can work.
Why isn’t one of the options Container Queries?
Container Queries are an example of a feature that needs a lot more standards work and R&D. While we have some good ideas, progress and are on the way, the problem space is currently still unbounded and impossible to estimate. Though, you’ll be happy to know that Igalia is investing in some of this R&D and gaining implementation proof of our ideas in this space.
This initial experiment is focused simply on shipping code for features that suffer purely from lack of priority.
…But, I am interested in <something else> :(
Great! If you’re willing to fund some standards work to help advance this, we’d still love to talk to you! We’re happy to help advocate too - that just isn’t this experiment. Definitely, reach out to us!
Still, please consider trying to help make this experiment a success so that we can do more.
Where does the budget go?
It goes directly to development costs (i.e. salaries).
What is the minimum pledge?
There is none, really.
So, a whole lot of developers could make something happen with lots of small dollar pledges?
Why would developers pay? Is this a good idea?
There are a variety of reasons. Maybe you just think this is a good thing to do. Maybe a lacking feature causes you a lot of pain and you think it’s worth a few bucks if you could get it done. Maybe you realize that you’re funding this work historically indirectly through ad revenues and product purchases today and you’re interested in changing that model somehow and having a more direct voice. The goal definitely isn’t to guilt anyone into anything, or to convince you that you should – it is simply to make it possible for us to directly shape this, and to to help illuminate the costs and complexities about prioritization that go unseen in our conversations.
Ok… I’m interested. Can I pledge to multiple options?
Absolutely. In fact, it’s a useful form of preferential voting: Money is only deducted when one actually funds. Once one funds, the rest will be closed (for now) and no money for those will come out of your pocket. Help one thing a lot, and another a little, it’s fine.
Can companies pledge?
Now, you might be thinking "Whoa… Wait… That seems unfair? Companies have a lot of money". But this is actually pretty complex: There are way more developers than there are companies. Meetup.com alone lists over 13 million people who identify as Web Developers. Developers are generally a lot more ‘connected’ to the wants and pains than companies, and can decide faster.
We believe it is very possible for developers to help fund the commons via large amounts of small dollar donations, and that might very well be what happens. Past experiments haven’t proved this out though, so it’s not a widely held belief… Let’s see! Prove us right. Or wrong. There’s nothing to lose - funding is based on reaching the goal - and we all win if the commons gets a little better.
Hmm… Couldn’t just a few organizations get together and decide to fund one of these relatively painlessly?
Yes! We wish they would. But… again - historically speaking: Collectively negotiating priority and funding in practice has never been done before. It would be super cool and very productive thing to see that work out. Please, try it.
It seems like that takes away from developers ability to shape it then?
It’s a mix of advantages and disadvantages for each group: Companies don’t currently do this and they are generally not designed for making monetary decisions with speed, while developers and small dollar donations, can add up fast if there is something they can agree they really want. Let’s see!
Either way - we’re all building the commons: Everyone wins. Expanding the ways the commons is built seems very positive!
Can a single company just pledge the whole amount?
Yes, and no.
That isn’t this experiment, but of course we are interested! If your company is willing to fully sponsor one of these, we’re happy to take it out of the mix, write up a contract and continue the larger experiment with whatever options remain.
Wait… Why would a single company pay the whole thing?
ResizeObserver in WebKit or lazy image loading.
Lots and lots of folks are interested in things actually getting done. They’re only truly useful if they get done. If your thing didn’t get chosen, and your company is willing to fund that work - just reach out, that’s what we do!
Some of the items cost significantly more than others… It seems easier to fund the smaller ones… Is it fair?
True. Welcome to prioritization! It is complicated!
How do you prioritize? You can definitely close the small gaps so that everyone can use it in the very near future? You can also invest in something you don’t necessarily need right now but will probably be necessary in a few years.
For example: If you want to do anything like container queries, even if it is in user-space, containment is necessary. It’s a necessary part - it’s just not entirely clear how directly it will actually help the ultimate container queries solution, yet. Do you fund it now so you can unblock other stuff later? Hard to say!
What happens if it becomes clear that the budget is off?
The particular size and space of the things we’re offering in this experiment are things we feel pretty comfortable with in order to help mitigate this risk. We’ve done our best to price a range where we’re likely not off by much. If we’ve over-estimated a little, Igalia makes a slightly higher rate. If we under-estimated a little - Igalia will cover the difference. We regularly invest back into the platform ourselves, so we’re happy to take up a little slack for the greater good of the commons we all share.
That said, it is possible that despite all of our best efforts, there may be something we didn’t see and the project may go dramatically better or worse than estimated.
We will do our best to mitigate this as early as possible and stop work/report immediately. In the event of a dramatic cancellation, the remaining funds will be handled just like a very fortunate dramatic over-funding.
What happens if things go dramatically easier than estimates.
In offering fixed prices, Igalia stands to make a somewhat variable rate. However, we’re also interested in being good citizens and don’t believe in price gouging anyone. In the event that we’ve dramatically over-estimated the difficultly (or we’ve had to cancel a project because of reasons listed above) and there are remaining substantial excess funds, Igalia will offer a list of open bugs to those who pledged and we will use that budget to work on them in the order provided by the community.
Thoughts on what to choose?
Oh yes! In fact, here are 4 different blog posts explaining different items and making different cases for why these are a good choice, and perhaps better to prioritize…
- Open Prioritization and Advocacy, by Brian Kardell, which argues for
- Open Prioritization and CSS Containment, by Manuel Rego Casasnovas, which argues for
- Open Prioritization for implementing selector list argument of
:not()in Chrome, by Oriol Brufau, which argues for
- Igalia’s contribution to the Mozilla project and Open Prioritization, by Frédéric Wang, which argues for
There are no right or wrong answers here, we look forward to hearing your own reasons and advocacy. Please share them with us on social media with the hashtag