Le DOM devrait-il splitText et normaliser la composition pour donner l'identité ?

Question

Hier, j'ai été impliqué dans une discussion sur les bizarreries de l'implémentation du DOM, ce qui a donné lieu à une question intéressante concernant les comportements de Text.splitText et Element.normalise, et comment ils devraient se comporter.

Dans Noyau DOM niveau 1, Text.splitText est défini comme...

Divise ce nœud Texte en deux nœuds Texte au décalage spécifié, en conservant les deux dans l'arborescence comme frères et sœurs.Ce nœud ne contient alors que tout le contenu jusqu'au point de décalage.Et un nouveau nœud Text, qui est inséré en tant que prochain frère de ce nœud, contient tout le contenu au niveau et après le point de décalage.

Normaliser, c'est...

Place tous les nœuds de texte dans toute la profondeur du sous-arbre sous cet élément dans une forme "normale" où seul le balisage (par exemple, les balises, les commentaires, les instructions de traitement, les sections CDATA et les références d'entité) sépare les nœuds de texte, c'est-à-dire qu'il y a aucun nœud de texte adjacent.Cela peut être utilisé pour garantir que la vue DOM d'un document est la même que s'il avait été enregistré et rechargé, et est utile lorsque des opérations (telles que les recherches XPointer) qui dépendent d'une arborescence de document particulière doivent être utilisées.

Donc, si je prends un nœud de texte contenant "Hello World", référencé dans textNode, et que je fais

textNode.splitText(3)

textNode a maintenant le contenu "Hello", et un nouveau frère contenant "World"

Si alors je

textNode.parent.normalize()

qu'est-ce que textNode?La spécification ne précise pas clairement que textNode doit toujours être un enfant de son parent précédent, juste mis à jour pour contenir tous les nœuds de texte adjacents (qui sont ensuite supprimés).Il semble que ce soit un comportement conforme de supprimer tous les nœuds de texte adjacents, puis de recréer un nouveau nœud avec la concaténation des valeurs, laissant textNode pointant vers quelque chose qui ne fait plus partie de l'arborescence.Ou bien, nous pouvons mettre à jour textNode de la même manière que dans splitText, afin qu'il conserve sa position dans l'arborescence et obtienne une nouvelle valeur.

Le choix du comportement est vraiment assez différent, et je n'arrive pas à trouver de précision sur ce qui est correct, ou s'il s'agit simplement d'un oubli dans la spécification (cela ne semble pas être clarifié aux niveaux 2 ou 3).Des gourous du DOM/XML peuvent-ils nous éclairer ?

Answer 1

Au début, je faisais partie du groupe de travail DOM ;je suis sûr que nous censé pour que textNode contienne la nouvelle valeur jointe, mais si nous ne l'avons pas fait dire c'est dans les spécifications, il est possible que quelques mise en œuvre pourrait créez un nouveau nœud au lieu de réutiliser textNode, même si cela nécessiterait plus de travail de la part des implémenteurs.

En cas de doute, programmez de manière défensive.

Answer 2

Bien que cela semble être une hypothèse raisonnable, je conviens que cela n'est pas explicitement indiqué clairement dans la spécification.Tout ce que je peux ajouter, c'est que d'après la façon dont je l'ai lu, l'un ou l'autre textNode ou c'est un nouveau frère ou une sœur (c.-à-d.valeur de retour de splitText) contiendrait la nouvelle valeur jointe - l'instruction spécifie que tous les nœuds dans le sous-arbre sont mis sous forme normale, non pas que le sous-arbre soit normalisé à une nouvelle structure.Je suppose que la seule chose sûre est de garder une référence au parent avant de normaliser.

Answer 3

Je pense que tous les paris sont ouverts ici ;Je ne dépendrais certainement pas d’un comportement donné.La seule chose sûre à faire est de récupérer le nœud auprès de son parent.