Drop https://www.w3.org/TR/tracking-dnt/

[sideshowbarker]

https://www.w3.org/TR/tracking-dnt/ never made it to Recommendation; instead it was retired as a Working Group Note:

https://www.w3.org/TR/2019/NOTE-tracking-dnt-20190117/

Its formal status is Retired:

https://www.w3.org/TR/?tag=privacy&status=ret

And its Status section says:

Since its last publication as a Candidate Recommendation, there has not been sufficient deployment of these extensions (as defined) to justify further advancement, nor have there been indications of planned support among user agents, third parties, and the ecosystem at large.

Related BCD change: mdn/browser-compat-data#10469
Related MDN change: mdn/content#4960

[tidoust]

Just to link things together and make sure that we're all on the same page: DNT was added recently in #285, as requested in #281 following discussions on missing specs for BCD with @Elchi3 in #279.

[sideshowbarker]

Just to link things together and make sure that we're all on the same page: DNT was added recently in #285, as requested in #281 following discussions on missing specs for BCD with @Elchi3 in #279.

Ah, perhaps we need to keep it — I defer to @Elchi3 on that. But both mdn/content#4960 and mdn/browser-compat-data#10469 have been merged, so it’s now marked deprecated both in MDN and BCD.

Perhaps it makes sense for the MDN Yari tooling to just completely ignore spec URLs for anything marked deprecated (that’s what the mdn-spec-links tooling does), and so not have any need for the relevant specs to be in browser-specs.

[Elchi3]

But both mdn/content#4960 and mdn/browser-compat-data#10469 have been merged, so it’s now marked deprecated both in MDN and BCD.

Yeah, we probably should have done that earlier instead of adding the DNT spec here. Given the deprecation I'm fine with dropping it, also given https://github.com/w3c/browser-specs#spec-selection-criteria says

The spec is stable or in development. Superseded and abandoned specs will not appear in the list. For instance, the list contains the HTML LS spec, but not HTML 4.01 or HTML 5).

Fwiw, we have the same story with CSP2, SVG 1.1 and maybe with other specs where browsers still implement features from a now abandoned spec (and said features aren't in a later spec, but implemented in browsers). I think browser-specs should decide if it allows all of these or none at all. The criteria hints more at not having these but then browser-specs will ignore a few specs that specify APIs that (for now) still exist in the real world...

[tidoust]

Fwiw, we have the same story with CSP2, SVG 1.1 and maybe with other specs where browsers still implement features from a now abandoned spec (and said features aren't in a later spec, but implemented in browsers). I think browser-specs should decide if it allows all of these or none at all. The criteria hints more at not having these but then browser-specs will ignore a few specs that specify APIs that (for now) still exist in the real world...

The Spec selection criteria also acknowledges that "there are and there will be exceptions to the rule". I don't think that we want to adopt strict rules for the time. And the goal is more to specify APIs that exist in the real world, which suggest not closing the door to specs that don't fully fit criteria.

For DNT, following discussion with @dontcallmedom, we note that it is deprecated but still implemented across browsers, and it is not yet clear when and whether support for the IDL will be removed from browsers. It seems OK to keep it in browser-specs for now (Reffy does not extract the IDL yet, but that's a different story).

[sideshowbarker]

For DNT, following discussion with @dontcallmedom, we note that it is deprecated but still implemented across browsers, and it is not yet clear when and whether support for the IDL will be removed from browsers. It seems OK to keep it in browser-specs for now

Sounds good to me — so, going ahead and closing this

[sideshowbarker]

Fwiw, we have the same story with CSP2, SVG 1.1 and maybe with other specs where browsers still implement features from a now abandoned spec (and said features aren't in a later spec, but implemented in browsers). I think browser-specs should decide if it allows all of these or none at all.

As far as CSP2, the current status is that in the latest round of spec URL changes, we dropped the last remaining CSP2 spec URL — so we no longer have any references to CSP2 in BCD at least.

As far as SVG1.1, I count 26 features in BCD for which we have SVG1.1 URLs. They all have implementations but they’re also all marked deprecated in BCD and MDN both.

So as far as CSP2 and SVG1.1: I think that BCD/MDN perspective — or more broadly the fact that they don’t define any features which aren’t either superseded by definitions in the current CSP spec and SVG2 spec, or else are deprecated — gives weight to deciding to drop those two from browser-specs.

But other than SVG1.1 and DNT, I think the only other superseded/deprecated spec for which we now have any spec URL in BCD is MathML3 — and that case, it’s a single reference that we’ve discussed in a previous issue here, for menclose.

And the menclose case is different than the SVG1.1 cases, and even all other MathML cases.

But that said, it’s seems like we there’s at least one problem with the menclose case that we could solve: Rather than needing to keep the MathML3 spec around as a reference for it, at least we could instead just have the https://mathml-refresh.github.io/mathml/ MathML4 (aka MathML Full) spec be the reference for it.

I realize that introduces a different kind of messiness — in that for MathML-in-browsers purposes we want everybody to be using the MathML Core spec, and not using the MathML4/Full spec. But while the definitions in the MathML3 spec are now clearly superseded — by either by definitions in the MathML Core spec or the MathML4/Full spec or both — and the MathML3 spec is frozen and unambiguously not in active development, the MathML4/Full is clearly not frozen and is being actively maintained.

Given that, I’ve raised mdn/browser-compat-data#10516 to replace the MathML3 spec URL for menclose in BCD with instead the relevant URL from the MathML4/Full spec.

I don’t know ye whether that’ll get merged — but if it does, that at least will shift the related browser-specs discussion away from being about whether browser-specs should include the MathML3 spec and over to whether browser-specs should include the MathML4/Full spec (in addition to MathML Core).

[Elchi3]

Thanks Mike! All this makes sense to me 👍