> A feature like WebBiDi has nothing to do with the CSS engine team.
This example is almost true, but not entirely. For example the getBoxQuads API was something that testing tools wanted, which led to it being standardised [1]
More generally there can be surprising dependencies between features when it comes to implementation (e.g. both DOM and layout features might depend on accessibility work).
So from an implementer point of view, trying to encode the team that would do the work into the ranking tool is harder than it might sound.
One can imagine providing categories of features to help people find things that they're interested in. The counter argument is that people might just filter down to the kind of proposals they think they want, and end up missing things that were more important but got put in a different category.
In the end this simple approach proved helpful to us (Mozilla) last year, so we decided to do more or less the same again.
[1] https://github.com/w3c/csswg-drafts/issues/10537
This example is almost true, but not entirely. For example the getBoxQuads API was something that testing tools wanted, which led to it being standardised [1]
More generally there can be surprising dependencies between features when it comes to implementation (e.g. both DOM and layout features might depend on accessibility work).
So from an implementer point of view, trying to encode the team that would do the work into the ranking tool is harder than it might sound.
One can imagine providing categories of features to help people find things that they're interested in. The counter argument is that people might just filter down to the kind of proposals they think they want, and end up missing things that were more important but got put in a different category.
In the end this simple approach proved helpful to us (Mozilla) last year, so we decided to do more or less the same again.
[1] https://github.com/w3c/csswg-drafts/issues/10537