So, an update. It looks like the most popular title suggestion is
InterfaceName: methodOrPropertyName (static) property/method
Examples:
- SharedWorkerOrGlobalScope: close() method
- URL: createObjectURL() static method
- Window: location property
- Notification: permission static property
I really like this too.
We also seem to like the “Other considerations” list:
- On interface landing pages, make sure static properties and methods are listed separately in “Static properties”/“Static methods” sections. The prototype properties/methods can just be listed in “Properties”/“Methods” sections.
- Update static property/method pages to include the word “static” clearly in the summary, e.g. “The Permission read-only static property of the Notification interface…” and “The createObjectURL() static method of the URL interface…”.
- If a situation arises where instance and static members collide (i.e. are called the same thing), add a disambiguation suffix to each slug, e.g. /x_prototype and /x_static, and a disambiguation page at /x.
- This should all be done for the JS built-in reference pages too. Let’s make everything consistent.
Future work:
- Investigate changing all instances of “interface” on MDN to “class” — “interface” is a historic WebIDL thing, but it conceptually wrong, and we seem to be moving towards “class”. The naming of ES2015 classes would support this too. This would need to be done carefully, and would take a bit of effort to make sure it is done across the whole site.
Before we do any of this, I am intending to do some further research and user testing.