Request type

• Correction or update

Details

Cookies: Scope of cookies
has:

For example, if Path=/docs is set, these paths will match:

• /docs
• /docs/Web/
• /docs/Web/HTTP

It needs a "these paths will not match" and "and thus the cookie will not be sent" section

See https://discourse.mozilla.org/t/attributes-for-input-elements/43899.

We should give each input element its own "Attributes" list including all the attributes it supports (apart from the real global ones) and scrap the "Supported common attributes" row in the blue box.

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

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

A user requested the addition of both interfaces into the BCD (see mdn/browser-compat-data#3447), although it appears that we're missing TextDecoderStream and TextEncoderStream from the documentation.

GroupData.json lists "File API" as a Web API with the following contents:

        "File API": {
            "guides":     [ "/docs/Using_files_from_web_applications",
                            "/docs/Extensions/Using_the_DOM_File_API_in_chrome_code" ],
            "interfaces": [ "File",
                            "FileList",
                            "FileReader",
                            "FileReaderSync",
                            "Blob" ],
            "methods":    [],
            "properties": [],
            "events":     []
        },

...but it doesn't have an API overview page. We should write a page and add the "overview" property to GroupData.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Hi,

I am following your guide of Django and i think i spotted a mistake in de uml figure in chapter "Designing the LocalLibrary models". The relation between book to author should be a 1* and not a 1.
As also described in the box within book itself.

Kind regards,

Ricky

Url:
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Models

Details

GroupData.json lists "Device Orientation Events" as a Web API with the following contents:

        "Device Orientation Events": {
            "guides":     [ "/docs/Web/API/Detecting_device_orientation" ],
            "interfaces": [ "DeviceAcceleration",
                            "DeviceMotionEvent",
                            "DeviceOrientationEvent",
                            "DeviceRotationRate" ],
            "methods":    [],
            "properties": [],
            "events":     [ "Window: deviceorientation",
                            "Window: compassneedscalibration",
                            "Window: devicemotion" ]
        },

...but it doesn't have an API overview page. We should write a page and add the "overview" property to GroupData.

Summary
The Tag Example Notifiy Me button logs an error to the console.

Steps To Reproduce (STR)
How can we reproduce the problem?

1. Launch Firefox v76.
2. Browse to https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API
3. Scroll to end
4. Click Notify Me

Actual behavior
See alert "Hi".
See "The Notification permission may only be requested in a top-level document or same-origin iframe." in the console.

Expected behavior
A notification.

Additional context
The example is in an CORS iframe. Needs to be fixed.

Request type

• [] Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

The sample function multiply() on this page is broken: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MIN_VALUE

First of all, Number.MIN_VALUE has nothing to do with -Infinity. The example is conceptually confused.

Moreover, any negative product of x and y will pass the test since Number.MIN_VALUE is a positive number.

URL(s)

No page currently exists(I believe)

Request type

• New documentation

Details

While reading the HTML spec, as one does :), I stumbled across two attributes I have not heard of before related to the link element. The attributes are imagesrcset and imagesizes.

At first, I thought it related to rel="icon" somehow but, after some experimentation, it seemed unlikely. I opened an issue on whatwg/html and received clarity on the situations.

whatwg/html#5604

It seems that there is no content related to these attributes on MDN. According to Domenic, Chrome has supported these for ~15 months now. There is currently a PR open to clarify its use whatwg/html#5606

Seems like we might want to add some docs on this to MDN?

It's currently hard to find specific information about what an iterable object actually has in it automatically upon creation. Does it automatially have a forEach() method without having to explicitly define one? That kind of thing.

There should be an article "Standard features of iterables in JavaScript" that lists these (with multiple sections to provide separate lists if there are different scenarios or types of iterable).

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Add cross reference to the current and applicable non standard implementation of forced-colors-* in EdgeHTML (Edge 18-) on MDN; -ms-high-contrast and -ms-high-contrast-adjust.

Details

EdgeHTML implements

• -ms-high-contrast using values active, black-on-white, white-on-black (and none prior Edge/18) (MSDoc) and
• -ms-high-contrast-adjust using values auto, none (MSDoc)

Both are virtually equivalent to what forced-colors and forced-colors-adjust aim to achieve --once implemented anywhere-- and are also documented on MDN. -ms-high-contrast actually links to forced-colors, however -ms-high-contrast-adjust has no such Remarks section to recommend using forced-colors-adjust.
I'd be willing to at least add a similar "Remarks" section to -ms-high-contrast-adjust for parity if that's ok.
Also MSDN has thorough reference documentatiion of these properties (check "MSDoc" link above) that I'd link to as well.

I don't know the policy on linking from Standards to proprietary extension, especially if said Standard is not implemented in any browser -- or proably won't be in the near future.
There are several pages that do so (mostly for -webkit-) such as @media.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

The examples should be updated to include the recently added actions: stop and seekto.
Source: https://github.com/w3c/mediasession/blob/master/explainer.md

Request type

• New documentation

Details

The String.raw() example lists incorrect output, indicating that the result of this expression: String.rawHi\n${2+3}! is "Hi\n5!". But that is a 5-element string which contradicts the next line of the example:
str.length;
// 6

The output should instead be "Hi\n5!"

Hmm...markdown renders that incorrectly...

"Hi\\n5!"

The examples on this page are likewise incorrect: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/raw

This page on String.raw() also uses the term "template string", which appears to be outdated based on the template literal documentation above.

https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Global/value and https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/Global/valueOf have yet to be written.

I’ve been meaning to write them up myself, but I wouldn’t be too disappointed if somebody else beat me to it :)

GroupData.json lists "SVG" as a Web API, but it doesn't have an API overview page. We should write a page and add the "overview" property to GroupData.

Replace usage of depricated Object.observe

• Correction or update

Details

In all examples on the Intersection Observer API page the depricated Object.observe() is used and should be replaced with an alternative (proxy?).

Request type

Correction or update

Page to change

https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode/getByteTimeDomainData
--AND--
https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode/getFloatTimeDomainData

Details

For both the aforementioned articles there exists the same discrepancy.

Second paragraph on page states:
"If the array has fewer elements than the AnalyserNode.fftSize, excess elements are dropped. If it has more elements than needed, excess elements are ignored."

Second sentence under the 'Parameters' section reads:
"If the array has fewer elements than the AnalyserNode.frequencyBinCount, excess elements are dropped. If it has more elements than needed, excess elements are ignored."

Seeing as the frequencyBinCount is half the fftSize, one of the sentences is incorrect - I believe the frequencyBinCount to be the correct parameter.

Both sentences are in need of grammatical adjustment - when the array has fewer elements than required, the missing elements are not "excess" and "dropped".

Kind regards, Nick

Each of the pointer event reference pages (pointerdown, pointerup, etc) needs to be updated to clarify the order in which it fires relative to the related mouse event. They also need to clarify the situations in which one of the events can cause the other not to occur; looking at the pointer events spec, there are cases in which canceling the pointer event causes the mouse event not to fire.

Now that we have done research into the API ref naming problem, the clear winner seems to be to lower-camel-case the interface name for instance members, to imply it is an object instance rather than an interface, e.g.

XMLHttpRequest.open() -> xmlHttpRequest.open()

This satisfies the worries of the spec folks, as well as not causing any detriment to our primary target audience or SEO.

This task is about creating a plan to implement these changes.

Acceptance criteria

1. • Create a list of JavaScript objects and WebAPI interfaces that need dealing with.
2. • Write a plan of exactly what need to be done in each case
3. • Update the MDN page type templates as appropriate
4. • Do the required work on a small sample of interface pages (say, 2 JS objects and 2 WebAPI interfaces) and get a further round of feedback to make sure we are going in the right direction before we go any further.

Tasks

See above

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

I think it would be useful to clarify what is meant by:

Typically, but not always, sections have a heading.

Specifically, I would like for the article to clarify when a section might not have a heading.

(I'm wondering about this myself.)

A usage note specifies:

Each <section> should be identified, typically by including a heading (<h1>-<h6> element) as a child of the <section> element.

HTML Living Standard specifies:

A section, in this context, is a thematic grouping of content, typically with a heading.

The section examples at the section MDN page and https://html.spec.whatwg.org/multipage/sections.html#the-section-element all use <h1>-<h6> elements.

Cross-filed from https://bugzilla.mozilla.org/show_bug.cgi?id=1483152

Documentation for https://tc39.github.io/proposal-async-iteration/
(this shipped in Firefox 57, see bug 1352312)

Iteration protocol reference page:

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols needs to talk about the async iteration protocol.

Symbol.asyncIterator

• Docs could probably be derived from Symbol.iterator https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/iterator
• It's already listed on the Symbol page: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol#Well-known_symbols
• New page to be created here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol/asyncIterator
• Compat data update here: https://github.com/mdn/browser-compat-data/blob/master/javascript/builtins/Symbol.json#L58
• New interactive example here: https://github.com/mdn/interactive-examples/tree/master/live-examples/js-examples/symbol

for-await-of

[X] Needs to be listed here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements#Iterations
[X] New reference page here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await-of https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of
[X] New compat data entry here: https://github.com/mdn/browser-compat-data/blob/master/javascript/statements.json
[] New interactive example here: https://github.com/mdn/interactive-examples/tree/master/live-examples/js-examples/statement

Async generators

We have https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*, maybe it would be worth doing an extra reference page about async function* ? Then you would create e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function* maybe. Also add compat data and interactive example again, like for the other two above.

APIs that use async iterators / generators

I don't know all the APIs that use async iteration, but it seems like Streams are async iterables, so it might be interesting to look into our streams docs and update them if necessary https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

Guide page updates

• We have https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_generators
• Unfortunately we have no dedicated guide page yet on async JS programming. We want to create that at some point, though. See https://bugzilla.mozilla.org/show_bug.cgi?id=1305261
• More brainstorming on that here: https://docs.google.com/document/d/1ko8Xt5JaFVuXjEOHSyhw8MaxKPTbKiX6Qc7EXtczKUA/edit?ts=5b55b98b#heading=h.5tv0p4d6vqmu

Misc

• Joe Medley contributed this: mdn/interactive-examples#1036, check if it is integrated nicely.

Request type

• New documentation
• Correction or update

Details

See icecandidate event.

The code sample in "Sharing a new candidate" checks if event.candidate is truthy before delivering it to the remote peer. "Indicating the end of a generation of candidates" says that events where event.candidate == "" should be delivered, but the empty string is falsy in JavaScript and this signal would not be delivered. "Indicating that ICE gathering is complete" says that events where event.complete == null should not be delivered but then refers to the event.candidate == true test.

There is clearly a nuance here that I'm missing, but in any case this may need to be clarified. An uninformed reader would form the conclusion that actually a event.complete != null test is needed.

There's also mixed references to RTCPeerConnectionIceEvent (bluelinked) and RTCPeerIceCandidateEvent (redlinked), not sure if that's intentional.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

The Strict Mode article seems to not clearly reflect how strict mode works with the current version ES6. Many statements still refer to how strict mode worked with ES5 primarily. Now that ES6 is standard, refering to ES5 behavior primarily becomes just wrong.

For example, refer to this sentence about function definitions in block scope.

Second, strict mode prohibits function statements, not at the top level of a script or function

Prohibited in ES5, but allowed in ES6. Also the example that follows clearly only shows ES5 behavior. So in ES6 this statement is not true anymore, but the only thing there is is a small aside in the form of sentence

Note that function statements outside top level are permitted in ES2015.

The article should reflect primarily ES6 behavior, and only mention old ES5 behavior as an aside, instead of vice versa.

Just to preempt the question, why I create this issue instead of changing the wiki myself: Since I'm currently learning about strict mode, I feel not confident enough to change the wiki about a topic that I feel like I haven't understood yet. I hope somebody that feels more confident can look through the article and update it.

MDN URL: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode

Request type

• Please close this issue, I accidentally submitted it without adding any details
• Correction or update
• New documentation

The German and the English version of the HTML img tag differ.

On the German page, it explicitly mentions % to be valid in width or height.
On the English page, there is nothing about that.
Please be very clear about which types / units are valid across all languages of the documentation.

https://developer.mozilla.org/de/docs/Web/HTML/Element/img

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img

Edit; examples with my assumption:

<img width="50"... valid, represents pixels
<img width="50px"... strictly speaking, it's invalid, the only valid suffix is `%`
<img width="50%"... valid but not mentioned to be valid on the english page
<img width="50em"... invalid, not explicitly mentioned

Cross-filed from https://bugzilla.mozilla.org/show_bug.cgi?id=1480455

https://developer.mozilla.org/en-US/docs/Web/Guide/Localizations_and_character_encodings

This article should be really useful but actually contains vast amounts of Firefox-only trivia that belong in an internals document at best. It needs to be updated to be a general guide to dealing with different character sets, etc.

GroupData.json lists "Geometry Interfaces" as a Web API with the following contents:

        "Geometry Interfaces": {
            "interfaces": [ "CSSMatrix",
                            "DOMMatrix",
                            "DOMMatrixReadOnly",
                            "Point" ],
            "methods":    [],
            "properties": [],
            "events":     []
        },

...but it doesn't have an API overview page. We should write a page and add the "overview" property to GroupData.

GroupData.json lists "Web Midi API" as a Web API with the following contents:

        "Web MIDI API": {
            "interfaces": [ "MIDIInputMap",
                            "MIDIOutputMap",
                            "MIDIAccess",
                            "MIDIPort",
                            "MIDIInput",
                            "MIDIOutput",
                            "MIDIMessageEvent",
                            "MIDIConnectionEvent" ],
            "methods":    [ "Navigator.requestMIDIAccess()"],
            "properties": [],
            "events":     []
        },

...but it doesn't have an API overview page. We should write a page and add the "overview" property to GroupData.

In earlier versions of Firefox it was possible to completely cover the background of the viewport with an image by scaling width and height independently to 100% of the viewports dimensions regardless of the images own propotions.

	background-image:url("../img/Bkgnd/Bkgnd.svg");
	background-repeat: no-repeat;
	background-size: 100vw 100vh;

This does not work any more, actually the scaling maintains the proportions of the image, leaving uncovered bars either on top and bottom or on the sides of the image, depending on the aspect ratio of the viewport.

So, what is the correct CSS directive to regain the full coverage of the viewport with an image again? Without cropping parts of the image like 'cover' does?

We have an overview page for the Screen Orientation API: https://developer.mozilla.org/en-US/docs/Web/API/Screen_Orientation_API but it's not listed in the "overview" property of the GroupData.json entry:

        "Screen Orientation API": {
            "guides":     [ "/docs/Web/API/CSS_Object_Model/Managing_screen_orientation" ],
            "interfaces": [ "ScreenOrientation" ],
            "methods":    [],
            "properties": [ "Screen.orientation"],
            "events":     []
        },

We need to add an "overview" property to this entry like:

        "Screen Orientation API": {
            "overview":   [ "Screen Orientation API" ], 
            "guides":     [ "/docs/Web/API/CSS_Object_Model/Managing_screen_orientation" ],
            "interfaces": [ "ScreenOrientation" ],
            "methods":    [],
            "properties": [ "Screen.orientation"],
            "events":     []
        },

Then we will get a link to the overview page in the list at https://developer.mozilla.org/en-US/docs/Web/API#Specifications and in API sidebars generated using APIRef.ejs.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-sandbox describes that without allow-same-origin, the iframe is considered as being from a special origin failing same-origin policy. But it does not describe the effect of that change.
This sandbox restriction prevents access to storages (I found it for cookies in my case, I haven't checked localstorage and others), even when the iframe was already from a different origin.

It would be great if the doc could be more explicit on the impact.

As mentioned here: http://www.html-5.com/metatags/meta-format-detection.html

We should probably add information about this to the page, and a BCD entry, etc.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

There is an unnecessary populate() method called on Author model in authorController code in Express_Nodejs/Displaying_data/Author_list_page

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

Hi all, Thanks for the wonderful guides. I thought of an improvement with the following code example on the Closures page

as written on the page:

If you don't want to use more closures, you can use the let keyword introduced in ES2015 :

function showHelp(help) {
  document.getElementById('help').innerHTML = help;
}

function setupHelp() {
  var helpText = [
      {'id': 'email', 'help': 'Your e-mail address'},
      {'id': 'name', 'help': 'Your full name'},
      {'id': 'age', 'help': 'Your age (you must be over 16)'}
    ];

  for (**var i = 0**; i < helpText.length; i++) {
    **let item** = helpText[i];
    document.getElementById(item.id).onfocus = function() {
      showHelp(item.help);
    }
  }
}

setupHelp();

I would suggest using let in the first expression given to the for loop (let i = 0). I think adding let to the 'item' variable misses a teaching opportunity for a common pattern, used elsewhere on other MDN pages, such as https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for

Thanks,
Brant

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

According to W3C documentation on UI events, the main feature of focusin and focusout events is that the relatedTarget property is set to the corresponding counter-element in the FocusEvent argument of these two events, whereas with focus and blur events, the relatedTarget property is always null.

Shouldn't this important feature be mentioned in the docs of the corresponding MDN help pages?

Many people wonder why the relatedTarget property is always null when they listen to focus/blur, not knowing there are focusin/focusout events available.

I'd like to suggest to add this information (and "see also" references between these four events) to the corresponding MDN pages.

Related Pages on MDN

https://developer.mozilla.org/en-US/docs/Web/API/Element/focusin_event
https://developer.mozilla.org/en-US/docs/Web/API/Element/focusout_event
https://developer.mozilla.org/en-US/docs/Web/API/Element/focus_event
https://developer.mozilla.org/en-US/docs/Web/API/Element/blur_event

Request type

• New documentation
• Correction or update

Page to change

If this request relates to an existing article, please give its URL:
https://developer.mozilla.org/en-US/docs/Web/API/Headers

Details

Please describe the change you are requesting. If you know of technical experts who can review the change, please mention them.

Try it out in a JS console:

const test = new Headers();
test.append("bla", 1);
test.get();

Results in:

TypeError: Not enough arguments to Headers.get.

in Firefox 64

or

TypeError: Headers.get requires at least 1 argument, but only 0 were passed

in Firefox 66

Whereas test.get("bla") results in 1, as expected.

Related issues

If this request relates to other issues in Bugzilla or GitHub, please provide links:

I hope only the doc is wrong. I do not expect Firefox implements it in such a bluntly wrong way…

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

In mdn/browser-compat-data#4559, an entry for stable sorting was added. We should add a section explaining what that means, as well as code examples.

Hello, there!
So I have a question about how to most gracefully handle different paths for different environments.
For example, in this very repository, path to service worker is constant: /sw-test/sw.js. On localhost this is no longer the case as the path is now /sw.js and further development can't be done until one modifies the scope to match the local environment. On localhost, service worker just don't work. One needs to change the scope and then remember to change it back when pushing, which can be forgotten quite easily.
So, how should I manage the paths for different origins? I used to use the following method for my API to work on localhost (as I host my API on localhost as well during development):

let apiHostname = window.location.hostname.includes('localhost') ? 'http://localhost:8000' : 'https://[productionApiUrl]';

Is this good, should be applied to my service worker as well, or are there better methods?

Thanks!

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

Form-associated custom elements ("FACEs") were merged into the HTML standard on May 2019 and implemented in Chrome 77. Despite that, MDN doesn't yet cover the APIs this feature introduces (ElementInternals doesn't have a page, and HTMLElement.prototype.attachInternals() only shows up as an experimental API), let alone include them or their callbacks in the "Using custom elements" page.

Summary
What is the problem?
SubtleCrypto.deriveBits() with PBKDF2:

• Length argument must be a multiple of 8. This is congruent with the RFC but should be documented
• Length argument does not accept an input > 256 bytes. This constraint is not defined in the original PBKDF2 and should be considered to be removed.

Steps To Reproduce (STR)
How can we reproduce the problem?
Just run the following html in firefox:

<html>
<head><title>pbkdf2 - Firefox</title></head>
<body>
  <script>
    (async () => {
      const password = new ArrayBuffer() // empty password
      const passwordKey = await crypto.subtle.importKey('raw', password, 'PBKDF2', false, ['deriveBits'])
      const params = { // pbkdf2 params
        name: 'PBKDF2',
        hash: 'SHA-256',
        salt: new ArrayBuffer(),  // empty salt
        iterations: 1
      }
      crypto.subtle.deriveBits(params, passwordKey, 8 * 64).then(
        derivedKey => console.log(derivedKey), // no error since Lenght is a multiple of 8 and Length <= 256 bytes
        err => console.log("ERROR: can't derive more than 256 bytes (2048 bits)",err)
      )
      crypto.subtle.deriveBits(params, passwordKey, 8 * 384).then(
        derivedKey => console.log(derivedKey),
        err => console.log("ERROR: can't derive more than 256 bytes (2048 bits)",err) // error since Lenght > 256 bytes
      )
    })()
  </script>
</body>
</html>

Actual behavior
crypto.subtle.deriveBits(params, passwordKey, 8 * 384) produces error since 384 > 256

Expected behavior
To just derive 384 bytes (3072 bits)

Additional context
Sometimes you need an arbitrary output length for the PBKDF2 function, such as when using it to compute scrypt that you need to output p * 128 * r (with r usually 8 and p between 1 and 16).

Should all documentation for an attribute specific to a particular element be included within the MDN article for the element it belongs to? Or is it sometimes OK to create sub-articles related to such attributes? And if it is sometimes OK to have sub-articles for attributes, what criteria should we follow when trying to decide whether a particular attribute merits its own sub-article?

I think there are some specific cases in which splitting out some attribute documentation into sub-articles can clearly improve the content. But in general it also has some visible advantages: Specifically, it allows the MDN documentation for an attribute to:

• have its own Specifications table and spec URL
• have its own Browser Compatibility table

Case in point: name attribute for meta element

Here’s one concrete example: A couple days ago, I split out some MDN documentation related to the name attribute of the meta element into its own sub-article:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name

In fact, I went even deeper than that and also created another sub-article one more level down:

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta/name/theme-color

And in reviewing a related BCD change I also made, @Elchi3 pointed out:

I wonder if we have agreement on page structures on MDN. So far, the HTML reference documentation has pages for HTML elements and maybe sometimes pages for attributes. You've decided to go deeper and create pages for more attributes and specific values. This might make sense, but I would like it to be discussed.

So, I’m raising this issue here for discussion.

mdn/browser-compat-data#6014 (comment) has some rationale for creating those sub-articles.

But to also elaborate here on the rationale: one detail I want to mention is that the title I gave to https://developer.mozilla.org/docs/Web/HTML/Element/meta/name is the same as the corresponding https://html.spec.whatwg.org/multipage/#standard-metadata-names spec section.

That title is Standard metadata names and it follows a precedent in that we already a similar https://developer.mozilla.org/docs/Web/HTML/Link_types article related to the rel attribute and the HTML spec https://html.spec.whatwg.org/multipage/#linkTypes section titled Link types.

I think name (for meta) and rel are special cases meriting special treatment, because both are:

• attributes with their own spec section, with its own heading (Link types for rel, Standard metadata names for name)
• attributes with the additional level of complexity of having standard sets of keyword values defined in the HTML spec
• attributes with associated registries (https://wiki.whatwg.org/wiki/MetaExtensions and http://microformats.org/wiki/existing-rel-values)

As far as rel, having its own https://developer.mozilla.org/docs/Web/HTML/Link_types article seems clearly necessary, given it’s shared by multiple elements: a/area/link/form. Similarly, https://developer.mozilla.org/docs/Web/HTML/Attributes/autocomplete input/select/textarea with its own spec section; heading: Autofilling form controls: the autocomplete attribute.

As far as name for meta, it’s clearly not strictly necessary for it to have its own sub-article — but I think the main criterion for using a sub-article structure for it is: it’s so obviously similar to other cases (rel, autocomplete) that MDN already uses a sub-article structure for (as outlined above).

The following page: https://developer.mozilla.org/en-US/docs/Web/API/Window/resize_event

It is highly recommended to optimize the window.onresize event.

A good example is this page: http://bencentra.com/code/2015/02/27/optimizing-window-resize.html

I would like to see MDN add a debounce example to their Window: resize event page.

Also Browser compatibility is missing from the page as well.

Request type

• Correction or update

Details

Reference MDN Web Docs tutorial,
Responsive Images: Resolution switching: Same size, different resolutions.

Could this be looked at please?
Are the "x-descriptors" in the given sample image element crossed, or incorrectly assigned? And shouldn't the style width be 640px in the example as shown, for, as to, why would a 640px image be loaded only to be display at 320px?

In creating my own learning example using the article, I was getting opposite results than what I would have expected. On a desktop monitor (2560 x 1080) the browser would load the smallest resolution image, and on a cell phone a larger resolution image.

Example given
<img srcset="elva-fairy-320w.jpg, elva-fairy-480w.jpg 1.5x, elva-fairy-640w.jpg 2x" src="elva-fairy-640w.jpg" alt="Elva dressed as a fairy">
and it's related CSS
img { width: 320px; }

However to get the expected results, as I'd think, of a 640px resolution image, at a full size on a desktop, and a lower resolution image downloaded on a cell phone, I used the below on my example media learning & testing webpage, (and the source code link link).
for example, the bottom firetruck image.
<img id="firetruckimg" srcset="../images/fire-truck-320w.png 2x, ../images/fire-truck-480w.png 1.5, ../images/fire-truck-640w.png" src="../images/fire-truck-640w.png" alt="URAL 4320 fire truck AA-8.0">
and it's related CSS,
#firetruckimg { display:block; width:640px }

As you can see, I changed the CSS width to 640px and set the fire-truck-320w.png to 2x, and the fire-truck-640w.png to 1x by leaving it blank, basically opposite of what the given example html is showing.

Am I missing something here, or is the given example in error? This has caused myself much confusion and time, although by studying and staying at it, I now have a good understanding of what is intended to be demonstrated, at least, I think so anyway!
Please let me know!
Thanks!!

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

Conflicting info on prototype inheritance. First the docs say not to assign the prototype property directly, then later the example does just that.
url: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

don't set .prototype

later example sets .prototype

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

In Syntax > Parameters > type, the docs should include the recently added MediaSessionActions: stop and seekto.
The examples should be updated as well.
Source: https://github.com/w3c/mediasession/blob/master/explainer.md

Harald mentioned that Mozmill is really out of date, and should be archived:

• https://developer.mozilla.org/en-US/docs/Mozilla/QA/Mozmill_tests
• https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mozmill

That includes these pages, and their children.

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

The var hoisting paragraph might not be clear enough, may even be confusing.
According to the paragraph:
"Because variable declarations (and declarations in general) are processed before any code is executed, declaring a variable anywhere in the code is equivalent to declaring it at the top. This also means that a variable can appear to be used before it's declared. This behavior is called "hoisting", as it appears that the variable declaration is moved to the top of the function or global code."

A reader may think that, since both var and let varaibles' declarations are processed before any code is executed, both of them will be hoisted. We know this is not true.

One more misleading statement from this paragraph:
"It's important to point out that the hoisting will affect the variable declaration, but not its value's initialization. The value will be indeed assigned when the assignment statement is reached:"

Again, in reality, it does affect variable (implicit) initialization. Variables defined with var will be initialized with "undefined" value and we will be able to use them before explicit initialization (definition).

Let variables will also be declared at the start of their scope (block in their case) but will NOT be initialized (will be in temporal dead zone until their definition). Therefore, since only declaration, but not implicit declaration happens, we consider let variables not to be hoisted.

Please, see this article for more information (credits to Dmitri Pavlutin).

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

The page says this:
Note: As of March 2020, only Safari supports setting objects other than MediaStream.

But, would "Example: Fetch & Play" on https://developers.google.com/web/updates/2017/06/play-request-was-interrupted mean that Chrome supports Blob?

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

Some Exception sections on MDN don't make a distinction between error types and error names. For example, CustomElementRegistry.define() lists the following items under Exceptions

• NotSupportedError
• SyntaxError
• TypeError

If you do console.log(typeof ExceptionName) on instances of these, you'll find that the type for NotSupportedError is DOMException. The name NotSupported is what's returned by DOMException.name. The remaining two are actually error types.

I would just correct the page I linked to except this appears to be a wide-spread problem on MDN that requires a standard approach.

This is a work item for mdn/sprints#685.

We need to decide what to do with the pages in this tree https://developer.mozilla.org/en-US/docs/Web/Guide/Events and redirect, delete, or rework the pages.

@chrisdavidmills says "Looks like a lot of it can probably be deleted...I cover events for beginners in the learning area pretty well."

The pages are:

• https://developer.mozilla.org/en-US/docs/Web/Guide/Events
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Creating_and_triggering_events
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Media_events
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mouse_gesture_events
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Mutation_events
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Orientation_and_motion_data_explained
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Overview_of_Events_and_Handlers
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Touch_events_(Mozilla_experimental)
• https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Using_device_orientation_with_3D_transforms

Request type

• Please close this issue, I accidentally submitted it without adding any details
• New documentation
• Correction or update

Details

URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values#Default_values

Firefox 72 changed the Accept header again:
Bug 1544231 - Missing 'image/webp' in default navigation value of the 'Accept' header

A summary from fxsitecompat: https://web.archive.org/web/20200605081441/https://www.fxsitecompat.dev/en-CA/docs/2019/image-webp-has-been-added-to-default-http-accept-header/

This new info has not been included in MDN yet.