Issue with "HTMLIFrameElement": …

[ryc76]

MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement

What information was incorrect, unhelpful, or incomplete?

Many of the links are broken

Specific section or headline?

Browser Compatibility Page

What did you expect to see?

Not a broken link

Did you test this? If so, how?

Clicked on the height link in the table

MDN Content page report details

• Folder: en-us/web/api/htmliframeelement
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement
• GitHub URL: https://github.com/mdn/content/blob/master/files/en-us/web/api/htmliframeelement/index.html
• Report started: 2020-12-16T23:23:39.179Z

[chrisdavidmills]

This is an interesting one. Most HTML attributes don't have their own separate page, so we shouldn't be turning them into links in the BCD tables.

@ddbeck , is this what we did historically for the old tables on the previous platform?

@peterbe also tapping you to see if we could get a quick fix here.

[ddbeck]

The underlying BCD featuers have mdn_url values for each of the attributes. But, as you can see, most (all?) of them are 404s.

This is also how the wiki worked. On the wiki, however, broken links had a different color to indicate their brokenness. The new site doesn't do that, which makes this sting a bit more.

We've considered removing non-existent mdn_urls from BCD, but it's been neglected because it was never broken enough to matter.

Narrowly, you can fix this by removing the MDN URLs from the underlying BCD features. Or we could put some effort into coming up with a better approach to MDN URLs in BCD overall.

[Ryuno-Ki]

This might be related by #1712 and mdn/yari#2065 by now.

[mirunacurtean]

@chrisdavidmills, @ddbeck I've stumbled upon this while working on 10423 for #4309 and the subfeatures have a MDN URL in BCD despite the pages not being created.
I first considered this the expected default, but still at least an indicator should exist to signal to the users that these links do not redirect to existing pages.
That is if we cannot make away with attributes/features that are not documented having an MDN URL in the first place...
I'd like to know how this should be prioritized and what to label it further so that it gets some attention again. It would be useful to have an understanding on how to proceed with these types of links in the meantime if a resolution is not reached - in the meantime, should I follow Daniel's suggestion from a previous comment and just remove these URLS while I happen to work in such an area?

[chrisdavidmills]

@mirunacurtean this is an issue with different types of broken links behaving differently. Once all links behave the same (see mdn/yari#3799), this should mitigate the problem somewhat. If this is the case (it is clearly indicated when a link is broken because the page just doesn't exist), then I don't think it is worth removing the links.

[himanshugarg]

The broken links now all show red and mdn/yari#3799 is closed. This may no longer be an issue.

[sideshowbarker]

Closing per #328 (comment), as the links to pages which don’t exist yet are now clearly distinguished and easily identifiable.

The problem of pages having some links to other non-existing-yet pages is a general problem that’s not exclusive to the https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement page — and I don’t think we want to raise an open issue for every single page that has such links on it. So I’m going ahead and closing this one.