Après avoir essayé de mettreUne fois que l'éditeur de message est cadré, la fonctionLa présence de la métaframe devient une condition de blocage, empêchant le contenu de l'éditeur de se charger dans l'iframe et rendant ces avantages des iframes indisponibles :

• Isoler les CSS des blocs et des thèmes de l'interface utilisateur de l'éditeur
• Précision des requêtes de médias et des unités CSS liées à l'affichage

Ces avantages sont importants pour permettre la réutilisation des CSS dans l'éditeur et le front-end, ainsi que pour simplifier le développement des blocs et des thèmes. Même si les métaframes existent, les membres de la communauté ont travaillé pour les intégrer dans l'éditeur de billets, mais après la publication de l'articletentative(précédé d'une clause de condition ou de raison) pas jusqu'à ce quedéfinir Comment ajuster l'interface pour séparer la boîte méta du contenu de l'article.

présent .Mise en place d'une vue fractionnéeCette modification permet la visibilité simultanée du contenu de l'éditeur et des méta-boîtes. Cette modification garantit une expérience WYSIWYG cohérente entre l'éditeur et la vue frontale. En outre, les métacadres sont plus faciles à utiliser qu'auparavant et permettent un référencement intuitif de n'importe quelle partie du contenu de l'article lors de l'utilisation de n'importe quelle métacadre, et vice versa.

Exceptions restantes pour les iframes

Actuellement, la dernière condition qui empêche une iframe d'être toujours utilisée est qu'un bloc utilise sa fonctionapiVersionMoins que l'inscription3. Cependant, même cette condition peut être supprimée dans une version ultérieure, et si le site utilise la fonctionGutenberg et que le thème basé sur les blocs est actif, il y a déjà une exception.

Conditions de bord et compatibilité

Les développeurs de plugins qui ajoutent des métaframes doivent être conscients de deux choses. Premièrement, les conteneurs métaframe clippent maintenant les éléments de débordement, donc si une interface utilisateur popup (comme un menu déroulant) s'étend vers le haut à partir du conteneur métaframe, elle sera coupée. Cependant, si elles sont rendues dans une partie du DOM en dehors du conteneur, cela ne posera pas de problème. Deuxièmement, si votre plugin ajoute également un formatage de texte riche et que l'interface d'édition est ancrée à la sélection de texte, son implémentation doit être compatible avec les iframes. Il ne s'agit pas d'une nouvelle exigence, mais elle peut être négligée par les plugins qui ne font qu'étendre l'éditeur de billets.

écrêtage des débordements

Pour vous assurer que cela ne pose pas de problème, vous pouvez soit faire en sorte que toute interface utilisateur ressemblant à une fenêtre contextuelle s'ouvre vers le bas dans la métaframe, soit rendre la fenêtre contextuelle dans une partie du DOM qui ne se trouve pas à l'intérieur du conteneur de la métaframe. Par exemple, cette dernière solution est la méthode de travail par défaut pour les composants etPopover(math.) genreListe déroulanteutiliserMenu déroulantils (pour les objets inanimés)@wordpress/componentspermet de s'assurer que l'interface utilisateur n'est pas coupée, même si elle dépasse le haut du conteneur de la métaframe.

Ancrage de l'interface utilisateur en format texte enrichi

Si le plugin implémente un code personnalisé pour ancrer ou positionner l'interface utilisateur, cela peut être inquiétant. Si le plugin utilise déjà la fonctionuseAnchorvenir de (un lieu)@wordpress/rich-texttout, alors cela devrait fonctionner correctement. Si ce n'est pas le cas, vous pouvez vous référer à la page de Gutenberg intituléeInterface utilisateur de l'éditeur de lienspour un exemple typique de son utilisation.