Add <portal> feature (discouraged)

[ddbeck]

No description provided.

[ddbeck]

It turns out that this doesn't even exist behind a flag anymore, so mdn/browser-compat-data#25805 is going to remove the data from BCD.

I have mixed feelings about this PR now. On the one hand, it's a little bit silly to create a feature that will never go anywhere. On the other hand, this feature can still do some useful things:

• Direct developers to the contemporary alternatives
• Safeguard against reusing the portal feature identifier
• Map to the caniuse entry

After writing that out I'm still slightly on the side of including this, but it's a narrow decision.

[captainbrosset]

Are you proposing that we keep this even if the BCD keys get removed? If yes, I like that thought. No reason web-features couldn't play this education role for developers (even in cases where there's nothing in BCD or caniuse to map to).

[Elchi3]

Much like in BCD or in documentation generally, I like to think about the whole lifecycle of data or docs. That said, in the web-features lifecycle, when would we consider removing this? Or does web-features never remove feature IDs at all? If it does, what are the lifecycle policies?

From BCD's lifecycle policies, we consider it "irrelevant" and the guiding factor for that is that no one shipped it (without flag) in the last two years and additionally, the spec is no longer being worked on.

[ddbeck]

For BCD, I think it makes sense to fully remove features:

• To retain historic keys indefinitely, BCD would pay unbounded maintenance costs. Every key for every surface of every failed feature would have to be maintained (albeit minimally).
• For fully withdrawn features after BCD's sunset period, BCD would tell no compatibility story not already represented by non-existence in BCD (that is, anything that doesn't exist is "compatible"). The only developer-facing information would be a specification URL.
• Disambiguation has no meaning for BCD keys. If a new feature moved into a vacated namespace (e.g., some window.example fails, then 10 years later someone ships an unrelated window.example feature), BCD doesn't need to act is if those represent two different things, since APIs can never share a name (or at least not in ways that can't be represented by partial implementation data, which could be backfilled in such a scenario).

For web-features, we have a few different considerations:

• The cost of preservation is much lower. We'd have to record just once that the entirety of feature's surface area is not shipping and link just once to an archival specification.
• web-features provides information about discouraged features that is not in-scope for BCD, namely references to alternative successor features.
• Relatedly, conceptual features seem to remain relevant longer than specific APIs. Alexis has said that historic features still get traffic, making him reluctant to remove them. I suspect there's also an opportunity here for web-features to help soften the harsh experience of MDN sometimes 404-ing removed reference pages.
• Preventing ID reuse avoids disambiguation problems that web-features has that BCD does not have. If we remove a feature and later add a new one with the same ID, the Baseline web component could display data for the new feature on old, unrelated blog posts. This could mislead readers.

[Elchi3]

Thanks Daniel. I think I'm convinced.
LGTM with compat_features removed.

[captainbrosset]

Same, LGTM with keys removed.