Refactor chrome_settings_overrides page to use <dl> syntax

[RobertCraigie]

Description

Adds anchors for all the fields in the chrome_settings_overrides web extensions docs so they can be directly linked to.

Motivation

I wanted to share a link to the search_provider section but it is currently awkward to share a direct link to the right position as you can only use the "Copy link to highlight" version0, and even then it doesn't scroll as nicely as it does with an explicit anchor on the row imo.

Additional details

[github-actions]

Preview URLs

• /en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/chrome_settings_overrides

Flaws (3)

URL: /en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/chrome_settings_overrides
Title: chrome_settings_overrides
Flaw count: 3

• unknown:
  • No generic content config found
  • no blog root
  • no blog root

External URLs (1)

URL: /en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/chrome_settings_overrides
Title: chrome_settings_overrides

• https://www.iana.org/assignments/character-sets/character-sets.xhtml (1 time) (Note! This may be a new URL 👀)

(comment last updated: 2026-01-05 22:45:27)

[wbamberg]

I'm not a reviewer for the webextensions docs, so this is just informational, but: an alternative which is adopted by the other MDN docs is to use a definition list for the properties, with MDN's <dl> syntax.

These get anchors auto-applied in the platform so you can link to things like RequestInit.mode or icons.sizes.

Advantages of doing this:

• it makes the webextension docs more consistent with the rest of MDN
• you can do it in just Markdown
• the description gets the whole width of the page, rather than being squeezed into a single column

The disadvantage is that you don't have a consistent/structured way to capture the property type, you just have to put it in the description.

If @rebloor wanted to do this, it should be done for all the manifest members of course, so as to be internally consistent.

[rebloor]

Thanks @wbamberg I'm already reviewing this with the team.

[Rob--W]

I'm not a reviewer for the webextensions docs, so this is just informational, but: an alternative which is adopted by the other MDN docs is to use a definition list for the properties, with MDN's <dl> syntax.

These get anchors auto-applied in the platform so you can link to things like RequestInit.mode or icons.sizes.

I am in favor of following MDN's convention here. Ideally consistently across all articles that have such a table. We have to start somewhere, I'd be okay with this PR covering chrome_settings_overrides only.

One potential challenge here is that properties can be nested. In this specific example even, the search_provider row encapsulates several other properties. I'm not sure if the result (of using definition lists) would be as readable, but I'm willing to consider it.

The disadvantage is that you don't have a consistent/structured way to capture the property type, you just have to put it in the description.

That's fine by me. We don't need a whole column for just a type; many other WebExtension documentation have the type inline at the front (e.g. MDN: webRequest.onBeforeRequest).

[rebloor]

One potential challenge here is that properties can be nested. In this specific example even, the search_provider row encapsulates several other properties. I'm not sure if the result (of using definition lists) would be as readable, but I'm willing to consider it.

We have numerouse example fo nexted properties lists in the API\s, e.g. browserAction.onClicked

Arguably that's a much cleaner, obvious presentation of nested properties.

[rebloor]

@RobertCraigie would you like to go ahead and make the changes. You can find more information on the syntax in. MDN's

syntax. If you have any issues, please let me know.

[RobertCraigie]

Updated! It now looks like this:

Definitely much easier to read.

[rebloor]

@RobertCraigie thanks for these changes. I've left a couple of comments to flag that the search_provider is an object in its opening sentence and adjust the text before the properties list, give the reader now knows that it's an object.

[rebloor]

Thanks @RobertCraigie