We have quite a few working drafts on the support list. No editor's drafts though.

IIRC @Anomie looked at the combination of W3C level and actual browser support and made the decision on a case-by-case basis.

In T354228#9431518, @Tgr wrote:

IIRC Anomie looked at the combination of W3C level and actual browser support and made the decision on a case-by-case basis.

And that would be another potential direction. It does come with the increased risk that implementations are bad (e.g. DoSing in calc) or that the designed property gets changed, especially now that test implementations match the originally specified name (behind browser config variables) rather than having browser specific names. A rule similar to implementation in the three major render engines + 95% uptake by viewership could be a reasonable base rule.

Another rule might be exceptional additions for mission critical changes like what I would think prefers-color-scheme would have been if it was just support at a certain standards track point.

Aside: probably someone needs to send an annoyed email to W3C about getting 10 year implemented properties into W3C Recommendation... :')

There's apparently a newish W3C project called Baseline that intends to define which web features are well-supported by browsers. (They don't really explain how to access the data, but it's displayed very prominently on caniuse.com.)

I also noticed it, it's displayed on MDN prominently, though I think it may have showed up on a Discord server I frequent first. From what I can see, the source data is web-platform-dx/web-features/tree/main/features. I don't understand how they get from the YAML files there to the .dist files. For example, <search> is currently "newly available" at MDN, which I suppose matches the search.yml.dist baseline: "low", but search.yml does not have an assertion that I can see indicating its baseline, and search.yml.dist indicates you're supposed to edit the source file, which I can only assume means search.yml. (I feel like the Baseline endeavor is somewhat hacking around the aforementioned failure of W3C to progress their documents on the standards track, but that's just a complaint with things outside this forum's interest.)

Their high support status is also defined kind of weirdly, solely in terms of Firefox for some reason.

But this could be another approach. It might be a reasonably practical one given the W3C standardization failure, and "Baseline" is more or less intended for authors (i.e. wiki editors). It would probably move most of our "Working Draft" items to "Baseline" items, which would probably be a good thing and not a bad one.

In T354228#9431518, @Tgr wrote:

We have quite a few working drafts on the support list. No editor's drafts though.

IIRC @Anomie looked at the combination of W3C level and actual browser support and made the decision on a case-by-case basis.

1074721 added an editor draft feature. In that case, the last WD was published in March 2021, but that version of the spec had a bug in it (#6391) which made it pretty much impossible to implement. The bug was reported in June 2021 and the fix was merged later that month. In the years since then, all the browsers implemented the fixed version, but the editors haven't made a new WD.

If the editors of the specs don't care about the W3C standardization process anymore, then I'm not going to insist on following it in a css-sanitizer code review. Note that the editors are from the implementing teams. Tab Atkins is on Google's Chrome team and fantasai is on Apple's Webkit team. They are responsible for merging the spec commits and then going ahead with implementation without any further spec work.

I'd propose that we abandon following specific specs, and instead use baseline of -3 years ago (So right now that would be baseline 2022). This would roughly correspond with what mediawiki's browser compatibility is for grade A browsers - https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

From a product perspective, i think that also makes the most sense, as generally we want users to create stylesheets that work well cross browser.

In T354228#11338860, @Bawolff wrote:

I'd propose that we abandon following specific specs, and instead use baseline of -3 years ago (So right now that would be baseline 2022). This would roughly correspond with what mediawiki's browser compatibility is for grade A browsers - https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix

This is almost Baseline Widely Available, which 2.5 years + whatever that caveat is about Firefox LTS that I mentioned above. In considering the baseline approach (which I am personally very warm to at this point) I'd prefer that slightly to a -3 year policy since Baseline Widely Available already has an external name.

(Difference: -3 years is baseline 2022 presently, and baselines are taken of the browser release in at the end of the calendar year [December 2022], which at the beginning of 2025 would be approximately -2 years. It would increase to -3 years by the end of the calendar year before flipping back to -2 in January. Baseline Widely Available instead is a rolling 2.5 years back, which right now is somewhere in April/May 2023 depending on browser cadence.)