-
Notifications
You must be signed in to change notification settings - Fork 22.9k
More updates to mark pages as deprecated #4226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| <dd>Called to handle the {{event("dataavailable")}} event, which is periodically triggered each time <code>timeslice</code> milliseconds of media have been recorded (or when the entire media has been recorded, if <code>timeslice</code> wasn't specified). The event, of type {{domxref("BlobEvent")}}, contains the recorded media in its {{domxref("BlobEvent.data", "data")}} property. You can then collect and act upon that recorded media data using this event handler.</dd> | ||
| <dt>{{domxref("MediaRecorder.onerror")}}</dt> | ||
| <dd>An {{domxref("EventHandler")}} called to handle the {{event("error")}} event, including reporting errors that arise with media recording. These are fatal errors that stop recording. The received event is based on the {{domxref("MediaRecorderErrorEvent")}} interface, whose {{domxref("MediaRecorderErrorEvent.error", "error")}} property contains a {{domxref("DOMException")}} that describes the actual error that occurred.</dd> | ||
| <dd>An {{domxref("EventHandler")}} called to handle the {{event("error")}} event, including reporting errors that arise with media recording. These are fatal errors that stop recording. The received event is based on the {{domxref("MediaRecorderErrorEvent")}} interface, whose {{domxref("MediaRecorderErrorEvent.error", "error")}} property contains a {{domxref("DOMException")}} that describes the actual error that occurred.</dd> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterbe Docs have heaps of "wrong macro" flaws for this case {{domxref("EventHandler")}. This points to https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Event_handlers, a document that I plan to move under https://developer.mozilla.org/en-US/docs/Web/Events
Is there a better macro to use, or should I just do a direct link?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escattone If you get the MacroWrongXRefError error when you use domxref what should the correct macro be? And can we just turn that into a fixable flaw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping @escattone ^^^^
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hamishwillee @peterbe Sorry for the delay! For the case of {{domxref("EventHandler")}}, all calls to {{domxref("EventHandler")}} should be replaced with {{event("Event_handlers")}}. I think we can add some more intelligence to the "wrong macro" flaws, and suggest the proper macro to call such that they'd become automatically fixable flaws. I think the way we'd do that is via some kind of mapping between macro and basepath. I'll discuss that with @peterbe some more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@escattone Thanks very much - certainly if it is possible to report a flaw auto-fixing it would be helpful. In particular for any "wrong" Xref macro.
I am a concerned about the {{event}} macro and when it can be used - because generally it isn't clear how it can know the right target - ie there are at least three copy_event docs on MDN.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hamishwillee FYI, I created mdn/yari#3779 so we (the dev team) don't forget to address this. Good point about the event macro. It is really limited to docs under /docs/Web/Events, so wouldn't apply to the copy_event docs I think, so maybe we should rename the macro to make its usage more clear? Something like webevent maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @escattone. FWIW I am really not sure about the name. But I do think we should add it to list of commonly used macros.
It might be useful to generally add more docs - so we currently say "links to a path in the XXXX" but perhaps something like "cssxref links to a page in the CSS Reference (any page with a stub nested below Web/CSS/Reference).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hamishwillee Great feedback, thank you! I didn't even realize that https://developer.mozilla.org/en-US/docs/MDN/Structures/Macros/Commonly-used_macros existed 😄! I created another issue to cover that suggestion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much @escattone .
I wonder if for unfixable macro flaws we should perhaps link to https://developer.mozilla.org/en-US/docs/MDN/Structures/Macros/Commonly-used_macros so that we have a convenient place for more detailed hints. I hesitate to suggest this though, because I'd rather we provided as detailed hints as possible in the flaw checker itself (let's avoid making people have to read more than the bare minimum :-)
Preview URLs
FlawsURL: No flaws! 🎉 URL:
URL: No flaws! 🎉 URL:
URL: No flaws! 🎉 URL: No flaws! 🎉 URL: No flaws! 🎉 URL: No flaws! 🎉 URL: No flaws! 🎉 URL: No flaws! 🎉 URL: No flaws! 🎉 URL:
URL:
URL:
URL:
URL:
URL:
External URLsURL: URL:
URL:
URL:
URL:
URL:
URL: URL: URL: URL: URL: URL:
URL:
URL:
URL: URL: URL: |
|
PS, as an aside, the following variants of the macros have been used: Is it worth fixing them up to all be the same? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good @hamishwillee
To answer your question, eventually we want to get rid of all macros, so I'm not sure it is worth the extra effort to normalize the macro calls. The ones you've used here are what I'd use. We've not used the versions with parameters for years, and we don't use "obsolete" on MDN any more.
|
@chrisdavidmills So if I saw the macros |
Hrm, good question. I guess we still want to include something, so yes. |
|
Is OS detection tech really deprecated? |
Yes. I'll comment on your linked issue |
This is is all remaining docs that are marked as deprecated in BCD but that did not have headers in MDN docs.