content
content copied to clipboard
mdn
execCommand obsolete
Hi, this article refers to the execCommand which is now marked as obsolete, https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content Shount there be a notice in teh article with suggested alternatives?
https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API
This API is designed to supersede accessing the clipboard using document.execCommand().
document.execCommand() consists of more than just the clipboard :
Should you do a Regex to check all
document.execCommand()? I don't know
And where all these commands are gone? 🤔 Some seems to can be managed via others JavaScript API. Should we provide a mapping or only deletes the references to this obsolete document?
Or... Provide a Yari feature that checks obsolecence in anchors...
Note to my self.
obsolete can be a http header so an app can fetch HEAD (preventing a lot of traffic of HTML for each page) and know if the resource is obsolete.
Example
Content-obsolete: true
(I don't know if there Is a standard way to do this Is a draft)
Regarding the HTTP Header: Would it make sense to pass a timestamp instead? This way, it could be flagged as „obsolete since X”.
Regarding the HTTP Header: Would it make sense to pass a timestamp instead? This way, it could be flagged as „obsolete since X”.
🤔 Obsolete is hardcoded or computed at the origin?
As far as I understood, the API (and thus, the page describing it) became obsolete and replaced by a set of other APIs (and thus documents). I'd see some kind of timestamp declaring the point in time as of when I shouldn't use it anymore (I can see some intersection with BCD here).
As far as I understood, the API (and thus, the page describing it) became obsolete and replaced by a set of other APIs (and thus documents). I'd see some kind of timestamp declaring the point in time as of when I shouldn't use it anymore (I can see some intersection with BCD here).
Intresting 🤔 Wich headers? https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers (I'm not really Expert in http but seems the thing that connect the dots...)
10.4.11 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise. The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
?
- https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
- https://stackoverflow.com/q/13884141/3579536
Wich headers?
Your Content-Obsolete?
(I'm not really Expert in http but seems the thing that connect the dots...)
You can define custom ones. There was a time, when it was common to prefix them with X-, but that is not strictly required anymore AFAIK.
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
It's not „gone”, but „obsolete”. That is, if you run an older browser (e.g. Point-of-sale, bank, enterprise), you can still use it.
@Ryuno-Ki thanks 🙏. Looking forward to find a way to move comments between repositories.
For some reason i can't di this search with the GitHub search anyway i actually count 8 matches of execCommand (hoping Is the right filename, path, extension, branch and repository).
- https://github.com/mdn/content/blob/main/files/en-us/web/guide/html/editable_content/index.html
- https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content
There're more:
$ grep -l execCommand -r files/en-us/
files/en-us/plugins/flash_to_html5/clipboard/index.html
files/en-us/mozilla/add-ons/webextensions/interact_with_the_clipboard/index.html
files/en-us/mozilla/add-ons/webextensions/manifest.json/permissions/index.html
files/en-us/mozilla/firefox/releases/64/index.html
files/en-us/mozilla/firefox/releases/41/index.html
files/en-us/mozilla/firefox/releases/8/index.html
files/en-us/mozilla/firefox/releases/69/index.html
files/en-us/mozilla/firefox/releases/60/index.html
files/en-us/mozilla/firefox/releases/82/index.html
files/en-us/mozilla/firefox/releases/14/index.html
files/en-us/_wikihistory.json
files/en-us/_redirects.txt
files/en-us/web/guide/html/editable_content/index.html
files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/index.html
files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/class_xbdesignmode/index.html
files/en-us/web/api/textrange/index.html
files/en-us/web/api/clipboard_api/index.html
files/en-us/web/api/document/execcommand/index.html
files/en-us/web/api/document/querycommandstate/index.html
files/en-us/web/api/document/index.html
files/en-us/web/api/document/querycommandenabled/index.html
files/en-us/web/api/document/querycommandsupported/index.html
files/en-us/web/api/clipboard/index.html
There're more:
$ grep -l execCommand -r files/en-us/ files/en-us/plugins/flash_to_html5/clipboard/index.html files/en-us/mozilla/add-ons/webextensions/interact_with_the_clipboard/index.html files/en-us/mozilla/add-ons/webextensions/manifest.json/permissions/index.html files/en-us/mozilla/firefox/releases/64/index.html files/en-us/mozilla/firefox/releases/41/index.html files/en-us/mozilla/firefox/releases/8/index.html files/en-us/mozilla/firefox/releases/69/index.html files/en-us/mozilla/firefox/releases/60/index.html files/en-us/mozilla/firefox/releases/82/index.html files/en-us/mozilla/firefox/releases/14/index.html files/en-us/_wikihistory.json files/en-us/_redirects.txt files/en-us/web/guide/html/editable_content/index.html files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/index.html files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/class_xbdesignmode/index.html files/en-us/web/api/textrange/index.html files/en-us/web/api/clipboard_api/index.html files/en-us/web/api/document/execcommand/index.html files/en-us/web/api/document/querycommandstate/index.html files/en-us/web/api/document/index.html files/en-us/web/api/document/querycommandenabled/index.html files/en-us/web/api/document/querycommandsupported/index.html files/en-us/web/api/clipboard/index.html
The problem with editing too many files in 1 PR is that if the CI fails you may not understand which file caused it to fail ... Example (out of execCommand scope) https://github.com/mdn/yari/pull/2279
So what is the official replacement now for the execCommand ? Why is it obsolete ? An example how to solve things without the execCommand would be helpful
Here related:
This spec is to meant to help implementations in standardizing these existing features. It is predicted that in the future both specs will be replaced by Content Editable and Input Events.
source: execCommand
The task here is to add a note to the execCommand page with alternatives as per:
This spec is to meant to help implementations in standardizing these existing features. It is predicted that in the future both specs will be replaced by Content Editable and Input Events.
@mdn/mdn-community-engagement @Rumyra if this isn't already done and hasn't been assigned, I'd like to work on it.
Hello @OphyBoamah , as the issue is still open , please feel free to go ahead and create a pull request with your changes. Thanks
If any of the docs listed below are still unsatisfactory, it makes sense to keep this issue open. I have starred the ones I think are satisfactory, usually because they mention https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API or deprecation, but see my note at the bottom recommending closure.
files/en-us/plugins/flash_to_html5/clipboard/index.html files/en-us/mozilla/add-ons/webextensions/interact_with_the_clipboard/index.html files/en-us/mozilla/add-ons/webextensions/manifest.json/permissions/index.html files/en-us/mozilla/firefox/releases/64/index.html files/en-us/mozilla/firefox/releases/41/index.html files/en-us/mozilla/firefox/releases/8/index.html files/en-us/mozilla/firefox/releases/69/index.html files/en-us/mozilla/firefox/releases/60/index.html files/en-us/mozilla/firefox/releases/82/index.html files/en-us/mozilla/firefox/releases/14/index.html files/en-us/_wikihistory.json files/en-us/_redirects.txt
- I can't find these pages, and didn't bother looking for those listed above: +files/en-us/web/guide/html/editable_content/index.html +files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/index.html +files/en-us/web/guide/html/editable_content/rich-text_editing_in_mozilla/class_xbdesignmode/index.html +files/en-us/web/api/textrange/index.html
- files/en-us/web/api/clipboard_api/index.html
- files/en-us/web/api/document/execcommand/index.html
- files/en-us/web/api/document/querycommandstate/index.html
- files/en-us/web/api/document/index.html
- files/en-us/web/api/document/querycommandenabled/index.html
- files/en-us/web/api/document/querycommandsupported/index.html
- files/en-us/web/api/clipboard/index.html
In fact, I believe this issue should be closed because every page that has "execCommand" on it, according to this search mentions that it's deprecated or can no longer be found.
An simple example how to use the Content Editable and Input Events to achive the same as with execCommnad (and NOT use execCommnad) would be beneficial and answer many questions.
It looks like execCommand provided a lot of useful little shortcuts which are not available through the Clipboard API. While I don't think it's in the interest of MDN to provide a replacement custom Javascript function that would do what execCommand used to do, it's possible and seems like the best way forward for people who would visit https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Editable_content or the original page where execCommand is described as deprecated.
I still recommend closing this issue.
An simple example how to use the Content Editable and Input Events to achive the same as with execCommnad (and NOT use execCommnad) would be beneficial and answer many questions.
The Clipboard API doent provoide functions like bold, add link, etc for such function we need to use Input Events...
Okay, if leaving an issue open on the Editable content page is the best way to signal that to anyone willing to take on the job, maybe the next step here is to identify the following steps:
- List the execCommand features each as a task requiring that code to replace it be added to the page at https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand
- Change the link in the first comment above to point to that document.
- Establish a standard operating procedure for deprecations so that users of the site can expect that a deprecation notice will also include a link to the new way to do what they wanted to do.
There is the little trashcan icon that goes next to deprecated items in our documentation. The mechanism that causes it to appear next to a term should include a way to specify a link to the "modern way". That would take care of #3.
The task list is below but I don't think it's worth doing until there are more parties interested in these features. Deprecation is a sensitive topic because people start relying on something and then it could disappear. I'd like to see MDN work on adding to "software culture" (or perhaps simply embellishing an existing aspect of it) the coupling of a deprecation notice with "the new way" to do the same thing, as I mentioned previously. I don't think this issue is worth working on (except for @daslicht for those execCommand features he wants) until MDN is able to collect enough user input to justify it. Plus, this plan I've concocted is not documentation but actual new software.
- [ ] Add execCommand commands to this task list if they aren't here already
- [ ] Develop a function to be added to an "execCmd" object intended to replace execCommand and point to it from the task
- [ ] Update the document at https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand to direct readers to a new file that has the "execCmd" object and the functions developed.
- [ ] If the "click the trashcan to see this feature's 'best-practices' replacement" strategy is implemented, go through the list of "execCommand" hits earlier in these comments and have it point to the section of the execCommand document where the new "execCmd" object file is presented.
- [ ] backcolor
- [ ] bold
- [ ] contentReadOnly
- [ ] copy
- [ ] createLink
- [ ] cut
- [ ] decreaseFontSize
- [ ] defaultParagraphSeparator
- [ ] delete
- [ ] enableAbsolutePositionEditor
- [ ] enableInlineTableEditing
- [ ] enableObjectResizing
- [ ] fontName
- [ ] fontSize
- [ ] foreColor
- [ ] formatBlock
- [ ] forwardDelete
- [ ] heading
- [ ] hiliteColor
- [ ] increaseFontSize
- [ ] indent
- [ ] insertBrOnReturn
- [ ] insertHorizontalRule
- [ ] insertHTML
- [ ] insertImage
- [ ] insertOrderedList
- [ ] insertUnorderedList
- [ ] insertParagraph
- [ ] insertText
- [ ] italic
- [ ] justifyCenter
- [ ] justifyFull
- [ ] justifyLeft
- [ ] justifyRight
- [ ] outdent
- [ ] paste
- [ ] redo
- [ ] removeFormat
- [ ] selectAll
- [ ] strikeThrough
- [ ] subscript
- [ ] superscript
- [ ] underline
- [ ] undo
- [ ] unlink
- [ ] styleWithCSS
- [ ] AutoUrlDetect
@Rumyra and @OphyBoamah - I did a search across the content repo using GitHub and found these: https://github.com/search?q=repo:mdn/content%20execCommand&type=code
These are primarily pages linking to the primary execCommand page which has a clear deprecation warning. However, there is one instance where the {{Deprecated_Inline}} macro is used. Might it be beneficial to also add it to some of the other instances? I know the project generally wants to move away from macros, but perhaps this is one of the macros that will still stick around for some time. Thanks!
I'm going to close this as completed. We only use Deprecated_Inline in the landing page's API list. There are some remnants in WebExt but that's left for the WebExt team (for example, https://github.com/mdn/content/issues/4864)
