MDN Web Docs is an open-source, collaborative project that documents web technologies including CSS, HTML, JavaScript, and Web APIs. Alongside detailed reference documentation, we provide extensive learning resources for students and beginners getting started with web development.
MDN's mission is to provide a blueprint for a better internet and empower a new generation of developers and content creators to build it.
The strength of MDN Web Docs lies in its vast community of active readers and contributors. Since 2005, approximately 45,000 contributors have created the documentation we know and love. Together, contributors have created over 45,000 documents that make up an up-to-date, comprehensive, and free resource for web developers worldwide.
In addition to English-language articles, over 35 volunteers lead translation and localization efforts for Chinese, French, Japanese, Korean, Portuguese, Russian, and Spanish.
To set up the site locally, you need to have Node.js and Yarn installed. You can check if these are installed by running the following commands:
node -v
yarn -v
After you have installed Node.js and Yarn, you can install the dependencies using yarn
and start the local preview:
yarn
yarn start
Once started, a live preview is available at http://localhost:5042/
.
You can contribute to MDN Web Docs and be a part of our community through content contributions, engineering, or translation work. The MDN Web Docs project welcomes contributions from everyone who shares our goals and wants to contribute constructively and respectfully within our community.
To find out how to get started, see the CONTRIBUTING.md document in this repository. By participating in and contributing to our projects and discussions, you acknowledge that you have read and agree to our Code of Conduct, which means adhering to Mozilla's Community Participation Guidelines.
You can communicate with the MDN Web Docs team and community using the communication channels.
content's People
Forkers
peterbe cool-rr lexishanson samgaw-archive sudarshan-kj kgibm rcopeland fiji-flo keith-cy glrodasz sachinmk27 balain kamilrogala elchi3 ryuno-ki iamstarkov saschanaz zorky arthropodseven mattjanssen fahadashiq12 gdsimoes nschonni sphinxknight saurav1-2 sanitz leesong-git lencioni vkweb rachelandrew segheysens senthilp hamishwillee mopig hnq90 whimboo mmxw yejiel iceprosurface talsafran ssirdi-dev dontcallmedom nbp nullvoxpopuli le0tan mikemaccana bassofbass virtuoushub nick22nd nathan-contino-mongo kevintcoughlin jdahlin kaylequbit ramiy lol768 foolip tomasdelaveau rm3l senocular sthagen axelnennker rikotacards jasontwuk xboxyan hellow554 0707jim spartasixzero caitmuenster andredalwigk niass divine1 jsoncode ariasuni weiplanet jieyimao ponomaryovroman c2cn mnirfan vterebenin sringly tusharv polaritoon jakubmakielkowski pranjalshinde mbrukman lloydk chaitanyasai508 kuator hamsterbacke23 timohaver kenrussell erick2280 toastal seblor firer denialadams global-localhost global19 scttpr zearincontent's Issues
Service Workers: Question about handling different paths for different environments
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!
Add API overview page for SVG
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.
The doc about iframe sandbox does not describe the effect of allow-same-origin on access to cookies
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.
Express Author_list_page has unnecessary populate() method
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
/en-US/docs/Web/API/Media_Session_API
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
.get() in Headers does not return all headers
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…
Strict mode article should reflect current ES6 instead of ES5
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
Uml figure
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,
Url:
https://developer.mozilla.org/en-US/docs/Learn/Server-side/Django/Models
Details
Rework/delete event guide pages
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
https://wiki.developer.mozilla.org/en-US/docs/Web/JavaScript/Closures$history
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
Create plan for retitling WebAPI/JavaScript ref pages
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
-
- Create a list of JavaScript objects and WebAPI interfaces that need dealing with.
-
- Write a plan of exactly what need to be done in each case
-
- Update the MDN page type templates as appropriate
-
- 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
Replace usage of depricated Object.observe
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?).
Add API overview page for File API
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.
Explain what stable sorting means
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.
Add documentation for TextDecoderStream and TextEncoderStream
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.
/en-US/docs/Web/CSS/@media/forced-colors and approximate implementation in EdgeHTML
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 valuesactive, black-on-white, white-on-black
(andnone
prior Edge/18) (MSDoc) and-ms-high-contrast-adjust
using valuesauto, 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
.
Notification example doesn't work
Summary
The Tag Example Notifiy Me
button logs an error to the console.
Steps To Reproduce (STR)
How can we reproduce the problem?
- Launch Firefox v76.
- Browse to https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API
- Scroll to end
- 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.
Attributes documentation for HTML input elements is confusing
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.
"/en-US/…/List of default Accept values" missing info for Firefox 72+
Request type
- Please close this issue, I accidentally submitted it without adding any details
- New documentation
- Correction or update
Details
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.
icecandidate_event update the meaning of null candidate
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.
Add API overview page for Geometry Interfaces
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.
Disambiguate Exceptions Types and Exception Names Across MDN
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.
Resolution switching: Same size, different resolutions - Article Error or Clarification
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!!
https://developer.mozilla.org/en-US/docs/Web/API/AnalyserNode/getByteTimeDomainData
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
Need example of when a <section> might NOT have a heading
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.
Archive mozmill pages
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.
Should we have a policy for if/when attributes can be documented in their own MDN sub-articles?
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 forname
) - 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).
/en-US/docs/Web/JavaScript/Reference/Template_literals
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.
<meta> ref page doesn't cover <meta name="format-detection">
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.
SubtleCrypto.deriveBits() with PBKDF2 and output length > 2048 bits
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 documentedLength
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).
Add a debounce example on the Window: resize event page
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.
/en-US/docs/Web/API/MediaSession/setActionHandler
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 MediaSessionAction
s: stop
and seekto
.
The examples should be updated as well.
Source: https://github.com/w3c/mediasession/blob/master/explainer.md
Update pointer event reference articles to clarify order of firing with mouse events
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.
Add API overview page for Device Orientation Events
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.
Improve cookie path documentation
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
Document async iterators and generators
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.
imagesrcset and imagesizes on link element
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.
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?
Add Screen Orientation API overview page to GroupData.json
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.
/en-US prototype inheritance doc contradiction
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
Document WebAssembly.Global.p.value and WebAssembly.Global.p.valueOf
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 :)
Update the "Localizations and character sets" guide
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.
How to stretch an background image to completely cover the viewport without cropping?
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?
/en-US/docs/Web/JavaScript/Reference/Statements/var
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).
Add description of relatedTarget to focusin/focusout event
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
Document form-associated custom elements
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.
Add API overview page for Web Midi API
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.
/en-US/docs/Web/API/HTMLMediaElement/srcObject
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?
Broken example for Number.MIN_VALUE
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.
German and English <img> element pages differ
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
JavaScript: Add article listing and explaining automatic features of iterables
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).
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.