Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

To understand this PR, is the following the desired nesting?
Also, I guess, I'm a little unclear what we call parameter vs. option.

MediaCapabilities:

• decodingInfo method
  • configuration_parameter
    • keySystemConfiguration_parameter (option?)
    • type_parameter (option?)
      • webrtc_option
• encodingInfo method
  • configuration_parameter
  • type_parameter (option?)
    • transmission_option
    • webrtc_option

From https://github.com/mdn/browser-compat-data/blob/main/docs/data-guidelines/README.md#parameters-and-parameter-object-features

For properties of parameter objects, use a subfeature named paramname_prop_parameter with description text paramname.prop parameter, where paramname is the name of the parameter object and prop is the name of the property.

Is this the rule? I think you have more recent experience with nested data structures. Would like to hear your thoughts.

Thanks @Elchi3.

1. Yes, I was trying to achieve exactly the nesting you show above in FF152 MediaCapabilities.decodingInfo/encodingInfo() - config.type.webrtc option #29739 (comment)
2. A parameter is a top level object, a property is a property of that object, and an option is an enumerated value of a property or parameter.
3. I updated the original pr you looked at with this commit 7d24f9e - this is based on fetch() - I got a few things wrong in the first instance. This is nested and uses the convention I understand. Note, Claude helped.
4. I updated again with another commit. This (current) version is flat, and is based on the schema link you provided. In that everything is flat, and the naming convention maps the structure. This doesn't use the term option, because the schema doesn't cover how you should document such a case.

I used to do the schema defined way, but have been told recently (and asked to modify my PRs) to support a nested form. I recalled "option" being used for enumerated values but I can't find evidence of that.
So I'd say that people are working on a new approach but that the schema has not been updated. I have partially learned that and relied on reviewers to correct me.

We this needs to be discussed in the BCD meeting to confirm the schema and naming convention to use and then I can match it. My preference is nested "FWIW" - it just feels cleaner and more logical - provided the rendering in MDN works adequately. If that happens ideally I can just drop the last commit.

We this needs to be discussed in the BCD meeting to confirm the schema and naming convention to use and then I can match it. My preference is nested "FWIW" - it just feels cleaner and more logical - provided the rendering in MDN works adequately. If that happens ideally I can just drop the last commit.

Thanks Hamish, this is exactly spot on. We also agreed that nesting is better and that we even have better validation/linting in place if features are properly nested.

The guidelines are old and need to be rewritten. They were in fact written because MDN couldn't render deeply nested structures but we believe this is no longer the case.

If you could drop the last commit and go back to nested, that would be great!

Daniel also noted that there is prior art in this Fetch PR for a good structure: #29451

We should be using names from the specification but roughly, it should be like this.

• someMethod
  • options_parameter
    • propA
    • propB
    • propC_options_parameter (we don't need the longer names)

Expect an issue (and a PR) on the BCD guidelines soon. Sorry for the back and forth.

Thanks @Elchi3

I've reverted the last commit so this should be good to review.

From the guideline PR #29856 it is not clear if the property needs a prefix in its key name (assume not) or if options values need a prefix. See #29856 (comment)