Должен ли DOM splitText и нормализовать compose для идентификации? - PullRequest
7 голосов
/ 27 августа 2008

Вчера я был вовлечен в дискуссию о причудах реализации DOM, в результате чего возник интересный вопрос о поведении Text.splitText и Element.normalise и о том, как они должны себя вести.

В DOM уровня 1 Core , Text.splitText определяется как ...

Разбивает этот текстовый узел на два текстовых узла с указанным смещением, сохраняя оба в дереве как родственные элементы. Этот узел содержит только весь контент вплоть до точки смещения. И новый текстовый узел, который вставляется как следующий брат этого узла, содержит весь контент в точке смещения и после нее.

Нормализовать это ...

Устанавливает все текстовые узлы на всю глубину поддерева под этим элементом в "нормальную" форму, где только разметка (например, теги, комментарии, инструкции по обработке, разделы CDATA и ссылки на сущности) разделяет текстовые узлы, т.е. , нет смежных текстовых узлов. Это можно использовать для обеспечения того, чтобы представление DOM документа было таким же, как если бы оно было сохранено и повторно загружено, и полезно, когда должны использоваться операции (такие как поиск XPointer), которые зависят от конкретной древовидной структуры документа.

Итак, если я возьму текстовый узел, содержащий «Hello World», на который есть ссылка в textNode, и сделаю

textNode.splitText(3)

textNode теперь содержит содержимое «Hello» и новый брат, содержащий «World»

Если я, то

textNode.parent.normalize()

что такое textNode ? Спецификация не проясняет, что textNode должен все еще быть дочерним по отношению к его предыдущему родителю, просто обновлен, чтобы содержать все смежные текстовые узлы (которые затем удаляются). Кажется, что это поведение соответствия для удаления всех смежных текстовых узлов, а затем воссоздания нового узла с конкатенацией значений, оставляя textNode указывающим на что-то, что больше не является частью дерева. Или мы можем обновить textNode таким же образом, как и в splitText, чтобы он сохранил свою позицию в дереве и получил новое значение.

Выбор поведения действительно совсем другой, и я не могу найти разъяснения относительно того, что является правильным, или если это просто упущение в спецификации (кажется, что это не разъясняется на уровнях 2 или 3) , Могут ли какие-нибудь гуру DOM / XML пролить свет?

Ответы [ 3 ]

4 голосов
/ 05 сентября 2008

Я был в рабочей группе DOM в первые дни; Я уверен, что означало , чтобы textNode содержал новое объединенное значение, но если бы мы не сказали это в спецификации, возможно, что некоторая реализация может создать новый узел вместо повторного использования textNode, хотя это потребует дополнительной работы для разработчиков.

Если сомневаетесь, программируйте в обороне.

1 голос
/ 05 сентября 2008

Я думаю, что все ставки здесь сняты; Я, конечно, не зависел бы от любого данного поведения. Единственное, что можно сделать, это снова получить узел от его родителя.

1 голос
/ 29 августа 2008

Хотя это может показаться разумным предположением, я согласен с тем, что в спецификации это явно не разъяснено. Все, что я могу добавить, - это то, как я его читаю, один из textNode или его новый брат (т.е. возвращаемое значение из splitText) будет содержать новое объединенное значение - оператор указывает, что все узлы в подпрограмме -tree помещаются в нормальную форму, а не в то, что поддерево нормализуется к новой структуре. Я полагаю, что единственная безопасная вещь - это сохранить ссылку на родителя до нормализации.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...