Wording of X-Frame-Options as legacy and "obseleted"

DRANK

What is the issue with the HTML Standard? Currently the spec has the following (emphasis my own): The X-Frame-Options HTTP response header is a legacy way of controlling whether and how a Document may be loaded inside of a child navigable. It is obsoleted by the frame-ancestors CSP directive, which provides more granular control over the same situations. It was originally defined in HTTP Header Field X-Frame-Options, but the definition and processing model here supersedes that document. [CSP] [RFC7034] That wording has been taken to mean that X-Frame-Options is deprecated and should be discouraged. That is not the case. X-Frame-Options is limited (and in particular the ALLOW-FROM variant is poorly supported and that is unlikely to change. CSP does offer a better solution to that use case. However, outside of that, the use of X-Frame-Options is well supported and is unlikely to be removed from browsers (without causing a massive degradation in security for no real benefit). This is especially true as CSP usage considerably trails X-Frame-Options (and only half of those use frame-ancestors!) I suggest a new wording of (again emphasis my own - and this emphasis wouldn't be included in the spec and is only shown here to show the changes): The X-Frame-Options HTTP response header is an older way of controlling whether and how a Document may be loaded inside of a child navigable. For sites using CSP, the frame-ancestors CSP directive provides more granular control over the same situations. X-Frame-Options was originally defined in HTTP Header Field X-Frame-Options, but the definition and processing model here supersedes that document. [CSP] [RFC7034] WDYT?