Add Baseline banner to Fullscreen API pages

[dfabulich]

These pages were referencing the browser-compat data for the deprecated api.Document.fullscreen feature, which doesn't have a corresponding feature ID in web-features. As a result, these pages weren't displaying a Baseline banner.

By removing that key from browser-compat, the features will show the correct Baseline status banner.

[github-actions]

Preview URLs (2 pages)

• /en-US/docs/Web/API/Fullscreen_API/Guide
• /en-US/docs/Web/API/Fullscreen_API

External URLs (1)

URL: /en-US/docs/Web/API/Fullscreen_API
Title: Fullscreen API

• https://mdn.github.io/dom-examples/fullscreen-api/index.html (1 time)

(comment last updated: 2026-03-20 04:20:18)

[hamishwillee]

Thanks. It works but I'm not sure this is the "right" fix.

@caugner Is there any reason we can't add "a corresponding feature ID in web-features" for api.Document.fullscreen?

[dfabulich]

I think my PR is the right fix (though I'm not 100% sure there isn't a better solution)… but I know that adding a web-features ID for api.Document.fullscreen is not the right fix.

1. The web-features build will not allow you to create a feature for api.Document.fullscreen; if you try, its CI will fail with this error.

   error: fullscreen: contains deprecated compat feature api.Document.fullscreen. This is forbidden for non-discouraged published features.

   (I did try that approach before filing this PR!)

2. Let's suppose we somehow made an exception for api.Document.fullscreen, giving it its own separate legacy_fullscreen feature. Well, even then, fred would refuse to show a Baseline banner on this page, because pages whose browser-compat section lists references multiple different web-features never show Baseline banners. "Web components" page missing Baseline status fred#1391

[hamishwillee]

@dfabulich Sorry, perhaps I should have just been more clear: it is not the right fix.
Baseline needs to be made to work with the docs: we don't mess with docs to get baseline to work.

The right thing to to do is raise an issue against that infrastructure. I've only left this open to keep it visible until @caugner can look. IF you want to create an issue against the https://github.com/mdn/fred (I think?) then we can close this.

[dfabulich]

I strongly disagree with your characterization of this PR as "messing with docs to get baseline to work." Removing api.Document.fullscreen from these pages is the right thing to do, regardless of Baseline.

• https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API/Guide doesn't mention or document api.Document.fullscreen at all. It is completely wrong for api.Document.fullscreen to appear in the browser-compat list on this guide page; removing it is the right thing to do, and it would be the right thing to do even if that had no effect on the Baseline banner.
• https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API only links to api.Document.fullscreen to say that it's legacy/deprecated. This page isn't about api.Document.fullscreen; it should be removed from this page also.

Cleaning up invisible metadata wouldn't really be worth filing. The fact that removing api.Document.fullscreen also makes Baseline work is what made this cleanup PR worth filing.

More deeply, Baseline is not allowed to show a banner when there are multiple web features, one of which is deprecated.

• I'm not allowed to add api.Document.fullscreen to web-features, so as long as api.Document.fullscreen appears in the browser-compat of this page, it won't have a Baseline banner. There is no reasonable issue anyone could file on fred that could possibly make that work.
• I've already filed "Web components" page missing Baseline status fred#1391 and fixed it in feat(baseline): show banner when all BCD keys have baseline High rari#582 but it's labeled "needs content decision" so it's not allowed to merge.
• But even that PR would only affect pages with multiple web-features where all of them are "Widely Available." There is no issue I can correctly file on fred that would show a banner on pages referring to multiple web-features IDs where one of them is "Limited Availability" and one of them is deprecated.

In #43480 (comment) you wrote:

• if a page has more than one browser compat entry then the compatibility is not shown. I'd argue that it would be useful to be able to note that parts of an API are very stable and parts are not.

Good thinking! But, I already tried that, in mdn/rari#527 and it was closed without merging, with this explanation:

As written, this would show a "Limited availability" banner on https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API, which is not really what I think we want.

I can't fix Baseline because it would show the wrong results on Fetch API, but I can't fix Fetch API because I should have fixed Baseline instead.

I'm not sure it's possible to fix bugs in this system. Every part of the system says that it must not be solved here it must be solved somewhere else, anywhere but here.

[caugner]

I don't have concerns about removing the deprecated feature from browser-compat here, but it would be good to have a second opinion from @LeoMcA.

[caugner]

Is it normal for guides to have compat tables? And if it is, shouldn't this guide have the same browser-compat values as the parent page?

[caugner]

I don't have concerns about removing the deprecated feature from browser-compat here, but it would be good to have a second opinion from @LeoMcA.