"Safe to release exceptions" are an interesting case because there are not included on a module basis but on a feature basis. They currently may be selectors, properties, or even values, but this may evolve. To specify they are exceptions, i only see think about two options: we have to (1) mark each of them independently, or (2) list all of them somewhere.
For (1), we would have to change the current structure of the test file, since some of the exceptions tested are not objects but only strings (for example, min-content) and thus cannot be annotated as is.
For (2), we would need to define some way to declaratively reference a given test somewhere in the testbase.
I tend to prefer option (1) because we already have similar logics in other places and it keeps things more modular. As noted by @PolariTOON, this means that the structure within some of the test files needs to be changed.
In any case, this requires to filter the specifications by individual features. That means, when filtering, the specs should be shown with only those features visible.
One open question here is how the UI for filtering those features should look like. One way would be to add a checkbox for them next to the CSS snapshot filters.
As discussed in #220 and #223, we'd like to add single features that are marked as safe to release in the CSS snapshots to the filtering system.
@PolariTOON's suggestions from #220:
I tend to prefer option (1) because we already have similar logics in other places and it keeps things more modular. As noted by @PolariTOON, this means that the structure within some of the test files needs to be changed.
In any case, this requires to filter the specifications by individual features. That means, when filtering, the specs should be shown with only those features visible.
One open question here is how the UI for filtering those features should look like. One way would be to add a checkbox for them next to the CSS snapshot filters.
Sebastian