execCommand() est maintenant obsolète, quelle est l'alternative ?

Question

J'avais l'intention d'utiliser Document.execCommand() ainsi que la méthode contenteditable pour construire mon éditeur WYSIWYG personnalisé. Mais lorsque j'ai vérifié l'attribut documentation para Document.execCommand() J'ai découvert qu'il est maintenant obsolète. Quelle est l'alternative moderne (ou existante) ?

Answer 1

J'ai créé l'éditeur riche pour les besoins de l'édition XML (HTML5 + XHTML) de ma plateforme. Je ne dirais pas que document.execCommand() est complètement mort parce que certaines parties fonctionnent encore très bien. Malheureusement, le problème principal pour moi était que les navigateurs utilisent beaucoup de code différent pour générer ces styles qui sont pas reconnu par les lecteurs d'écran utilisés par les personnes aveugles ou quasi aveugles.

De plus, le bug le plus coûteux en temps que j'ai eu à vaincre était un bug de Gecko/Presto où les sélections visuelles et techniques (pourquoi ce n'est pas la même chose, ne me demandez pas) avaient pour résultat de modifier une partie du DOM que l'utilisateur n'avait pas l'intention de modifier et cela venait du fait que le nombre de pixels par caractère est faible donc si l'éditeur riche faisait pas des sélections visuelles honorables, un utilisateur s'en irait très vite. Il fallait donc quatre mois à conquérir et il y a aussi d'autres bugs.

En fin de compte, c'est un effort difficile mais réalisable, mais si vous avez l'intention de construire un éditeur HTML/XML comme je l'ai fait, vous devriez prévoir au moins six mois si vous avez l'intention non seulement de le faire correctement mais aussi de le tester au point de détester le gâteau pour ensuite que quelqu'un vienne et signale un autre bug.

Votre primaire Le JavaScript devrait se concentrer sur les points suivants :

• document.createRange()
• window.getSelection()
• appendChild
• insertBefore
• insertBefore + nextSibling
• replaceChild

Au lieu du code incohérent généré par l'utilisation de execCommand() Vous devriez vous en tenir aux éléments suivants, que vous pouvez non seulement contrôler, mais qui sont également compatibles avec les lecteurs d'écran :

• em pour l'accentuation (ou "italique", <i> est déprécié).
• strong pour un texte fortement lu (ou "gras", <b> est déprécié).
• u pour le soulignement (assurez-vous que vos ancres sont stylisées de manière à les différencier des éléments u.) u pourrait être considéré comme "déprécié", bien que je renverserai cela lorsque je corrigerai les normes dans les dix prochaines années environ, utilisez-le de manière appropriée).
• sub pour le texte de sous-ligne qui apparaît verticalement plus bas que le texte normal.
• sup pour le texte de supper-ligne qui apparaît verticalement plus haut que le texte normal.
• Faites pas utiliser le <span> pour ajouter spécifiquement ces styles, car les lecteurs d'écran vont pas comprendre ou révéler un comportement bogué ; il s'agit toujours d'un élément inline générique valide. lorsqu'ils sont utilisés de manière appropriée .

En fait, j'avais l'intention de réviser mon Rich Editor (il a été corrigé mais pas encore vraiment réécrit), mais vous êtes invités à regarder le code source lorsqu'il se charge sur une page de blog sur le site lié à mon profil. Le projet original m'a pris 11 mois, mais avec mon expérience actuelle, je pense qu'il me faudrait environ trois à quatre mois. Si vous êtes sérieux, je vous recommande vivement de rester à l'écart des frameworks et des bibliothèques. "Mais ... mais, ils rendent la vie plus facile !" ... jusqu'à ce que vous vouliez utiliser une nouvelle version et que vous deviez réécrire tout le projet. Utilisez du JavaScript pur dès la première fois et évitez toute maintenance inutile. Bonne chance !

Answer 2

On dirait que l'alternative sera Événements d'entrée Niveau 2 .

Bien qu'il soit très tentant de créer soi-même un éditeur WYSIWYG, je m'en tiendrai personnellement à execCommand jusqu'à l'arrivée de la nouvelle norme. Parce que nous allons tous programmer un éditeur complet par nous-mêmes, au lieu de réutiliser les solutions actuelles.

Answer 3

L'alternative à document.execCommand() est l'API du presse-papiers, via navigator.clipboard . Par MDN Web Docs ( https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API ) :

Cette API est conçue pour remplacer l'accès au presse-papiers à l'aide de document.execCommand().

EDIT : Comme mentionné dans le commentaire ainsi que dans le texte cité ci-dessus, cela ne répond qu'à un sous-ensemble des exigences (accès au presse-papiers).

Answer 4

El documents de référence le dit comme un avertissement.

Il est prévu qu'à l'avenir, ces deux spécifications soient remplacées par Contenu modifiable y Événements d'entrée .

Et comme toute prédiction, il suffit d'attendre pour être sûr.