diff --git a/files/en-us/mdn/contribute/changelog/index.html b/files/en-us/mdn/contribute/changelog/index.html index 4d8d9b4d985b721..ecce8ffc8240504 100644 --- a/files/en-us/mdn/contribute/changelog/index.html +++ b/files/en-us/mdn/contribute/changelog/index.html @@ -10,6 +10,21 @@
This document provides a record of MDN content processes, constructs, and best practices that have changed, and when they changed. It is useful to allow regular contributors to check in and see what has changed about the process of creating content for MDN.
+Interface mixins in Web IDL are used in specifications to define Web APIs. +For web developers, they aren't observable directly; they act as helpers to avoid repeating API definitions.
+ +Previously we commonly defined a landing page for a mixin class itself, and put the defined members on subpages underneath it, +before linking to those from the landing pages of the interfaces that implement those mixins. +This was confusing for readers because mixins are spec constructs — you never access the defined members using the mixin classes. +To avoid this confusion we've instead put the pages for members defined on mixins directly under the implementing class pages. +For more details, see the guide page on +how to write an API reference +and the discussion leading to this change at mdn/content#1940.
+toString()
) and the jsonizer (toJSON()
) are also listed if they do exist.Image()
for {{domxref("HTMLImageElement")}} ) are also listed, if relevant.List of properties, List of methods: These sections should be titled "Properties" and "Methods", and provide links (using the \{{domxref}} macro) to a reference page for each property/method of that interface, along with a description of what each one does. These should be marked up using description/definition lists, which can be created using the "Definition List", "Definition Term", and "Definition Description" buttons on the MDN editor toolbar. Each description should be short and concise — one sentence if possible. See the "Referencing other API features with the \{{domxref}} macro" section for a quicker way to create links to other pages.
diff --git a/files/en-us/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html b/files/en-us/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html
index 9198c241dd00f36..73f00b6e75b372c 100644
--- a/files/en-us/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html
+++ b/files/en-us/mdn/contribute/howto/write_an_api_reference/information_contained_in_a_webidl_file/index.html
@@ -91,18 +91,25 @@
For documentation purposes, we create a mixin page, with the same structure as an interface page. As they are not true interfaces, the word interface is not used — mixin is used instead.
+For documentation purposes, MDN hides mixins. They are abstract and specification-only constructs. +You can't see them in the browser console and it is more useful to know on which real interfaces methods and properties are implemented on.
-Mixin methods and properties are listed in the same way as regular methods and properties:
+If you encounter a mixin in IDL, like HTMLHyperlinkElementUtils, +search for the interfaces that implement the mixin, for example +HTMLAnchorElement, and document the mixin members directly on those interfaces. +
+In practice this means instead of documenting HTMLHyperlinkElementUtils
,
+docs are added to the concrete interfaces, like HTMLAnchorElement
+and HTMLAreaElement
.
See the following two pages that document HTMLHyperlinkElementUtils.hash
accordingly:
Body
properties and methods listed on both {{domxref('Request')}} and {{domxref('Response')}} interfaces, as they both implement the Body
mixin.HTMLAnchorElement.hash
HTMLAreaElement.hash
Note: Mixin names do not appear in a Web developer console. We shouldn't show them, but we currently do this as it saves us from duplicating content, which would lead to a maintenance issue. We do this if the mixin is only used in one interface. (Such cases are bugs in the relevant specs. They shouldn't be defined as mixins, but as partial interfaces.)
-For compat data, consult the data guideline for mixins in BCD.
The name of interface extends the following APIs, adding the listed features.