ownerDocument
 

Обясните суть смысла данного атрибута node.ownerDocument?
Для чего он используется, чем хорош.

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

Это я в интернете прочитал, а на примере можно показать. Не могу понять. Это тоже самое, что вызвать parentNode элемента узла в котором он находится?

parentNode вернёт родительский элемент (который в DOM выше на 1 уровень), а ownerDocument вернёт "самый" родительский элемент (который в DOM на 1 уровне), т.е. объект document.

cool,
Сказать node.ownerDocument все равно, что пальцем на Адама показать. )))

with-love-from-siberia,
что значит сей каламбур?

Короче, я так понял вы сами не понимаете этого.
Те вещи которые понятны нам, нужно уметь объяснять. Вы можете сказать, я же точно так же описал, только мне понятно и хорошо, а вы сами догадывайтесь.

Другими словами у нас существует объект или документ:
xmlDoc.documentElement
window.frames[0].document

document = element.ownerDocument

Предположим, что мы не знаем кто является у нас главным, мы используем метод ownerDocument, чтоб определить родителя всей структуры.

Это тоже самое что вызвать node.parentNode, чтоб узнать кто является родителем элемента.

Причём здесь parentNode?

то что ты не понял сказанное тебе-говорит лишь только об одном-о твоей ограниченности,но не говорит о том что здесь не знают ответ:D

Хм-м… попытаюсь объяснить и я. Интересно, получится? :)

DOM — «Document Object Model», то-бишь, объектная модель документа. Модель — это не имплементация. В модель не входит программирование непосредственно, а лишь описание объектов, свойств и методов и того, как они должны работать.

document.documentElement.appendChild(document.createElement("body")).setAttribute("class", "my");

$document->documentElement->appendChild($document->createElement("body"))->setAttribute("class", "my");

Языки разные, имена методов одинаковые, результат и там и там одинаковый — в корневой элемент документа вставляется новый элемент body, которому сразу присваивается класс.
И про то и про другое можно сказать, это DOM.

Но можно ли вставить напрямую объект DOM из одного языка в документ на другом языке?
Нет. Можно, конечно, перевести в XML в одном месте и вставить из XML в другом, но это что угодно, а не «напрямую».

Теперь представьте, что Вы написали свой собственный движок DOM на php. С нуля, мегакрутой, шустрее и менее затратный по памяти, чем libxml+DOMDocument.
Естественно, Ваши методы и свойства будут называться так же: appendChild, insertBefore, parentNode, и т.д. И ожидаемые значения и действия их будут такими же. Иначе какая ж это модель DOM, хехе?

Вопрос номер два: можно ли вставить элемент класса MyMegaCoolDOMEngineElement как childNode объекту DOMElement (стандартному)?
В общем случае нет, Вас мягко пошлют, ссылаясь на то, что вы попытались вставить в документ какой-то инопланетянский объект.

Вот и выходит, что DOM как модель над имплементацией себя не властна. А значит, может гарантировать лишь то, что всё это будет работать только в пределах одного отдельного документа.

Как это реализовать? При создании любой ноды задавать ей свойство ownerDocument, которое содержит ссылку на тот документ, в котором она была создана. Не обязательно, прикреплена, именно создана. И если ownerDocument ссылается на что угодно, кроме текущего документа, при попытке, скажем, appendChild отвечаем мягким но настойчивым отказом (Exception ERR_WRONG_DOCUMENT), ибо за последствия такого действия отвечать никто не станет.

Так было до DOM версии 3. В третьем DOM появились методы adoptNode и importNode, позволяющие присваивать и копировать (соответственно) ноды из других элементов. Изменяя при этом ownerDocument, разумеется. Да еще и приписка «если производитель движка уверен, что все будет ОК, можно применять эти методы автоматически, не утруждая программера пониманием того, что есть из себя ownerDocument». Ну, а если не «OK», то ловите по-старинке Exception ERR_WRONG_DOCUMENT.

Ну… как-то так.

cool,
Иногда нужно проверить какому документу принадлежит элемент, в этом свойстве и хранится ссылка на него(document)

var div = document.createElement("DIV");
 
alert(div.ownerDocument === document);

var i = document.createElement("IFRAME");
	document.body.appendChild(i);

	//сравниваем ownerDocument с document-ом IFRAME-a
alert(div.ownerDocument === window.frames[0].document);

var span = window.frames[0].document.createElement("SPAN");

	//сравниваем ownerDocument элемента из IFRAME-a с текущим document

alert(span.ownerDocument === document);

Но похоже ты и сам уже разобрался

Да впринципе там не сложно, только запутался изначально для чего же этот метод используют, еще подумал такая запись большая.

Всем спасибо.

Subzey, спасибо, всего не прочитал, но по сути ты затронул корень темы. Конечно важно, но мне надо было пару примеров, в итоге сам разобрался.

subzey, круто, вот только непонятно, как мы перешли от "Но можно ли вставить напрямую объект DOM из одного языка в документ на другом языке?", "можно ли вставить элемент класса MyMegaCoolDOMEngineElement как childNode объекту DOMElement (стандартному)?" к "А значит, может гарантировать лишь то, что всё это будет работать только в пределах одного отдельного документа." Т.е. может там действительно какие-то есть проблемы, но по-крайней мере для меня они не очевидны

x-yuri,
Эх, я не преподаватель, и объясняю путанно.

Представьте себе: в браузер IE 6 добавляется плагин SVG, который XML. На странице есть собственно страница и DOM от неё и SVG и его собственный DOM. И тут мы пытаемся вставить элемент из SVG в HTML. Скажу сразу, это не получится. Но как проверить, а вдруг, можно?
Если element instanceof HTMLDocument, то, получается, что элемент из какого-нибудь xhr.responseXML тоже вставить нельзя. А, вот, его, как раз, можно (если я ничего не путаю).

Чисто теоретически, нужно проверить, позволяет ли имплементация принимающего документа принять элемент определенной имплементации. Ну, в смысле, человеку можно перелить кровь другого человека, а, вот, собаку к ноге пришить — не вариант.

W3C (WHATWG) — ужасные перестраховщики. Может быть, так и надо, если пишешь нормативную документацию для того, что будет работать отныне и вовеки веков. :) И они намеренно абстрагируются от имплементации (так и пишут, мы, мол, не классы описываем, а интерфейс, и мало волнует, как именно вы заставите это работать). А, значит, никакой нормативной документации про имплементацию написать не могут — не их епархия.

К DOM3, конечно, разродились абзацем, ну, который про importNode. Но, ведь, DOM начался с 1 версии. И там, по всей видимости, решили, что раз мы не можем обеспечивать целостность всех объектов класса интерфейса DOM, то будем обеспечивать хотя бы внутри одного. Я имею в виду document, рассматривая все ноды «внутри» него так или иначе его свойствами.

Ладно… Надеюсь, я пояснил, а не запутал еще дальше. :-?

сразу скажу, что xml-элемент можно вставить в опере и ff. Chrome/safari выдают "WRONG_DOCUMENT_ERR: DOM Exception 4", ie 6, 7, 8 - "No such interface supported", ie 9 - "DOM Exception: HIERARCHY_REQUEST_ERR"

<!doctype html>
<html>
<head>
    <meta charset="utf-8">
    <title></title>
</head>
<body>
    <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/mootools/1.3.0/mootools-yui-compressed.js"></script>
	<script type="text/javascript">
		new Request({'url': 'test.xml': function(r, doc){
			try {
				document.body.appendChild(doc.documentElement);
			} catch(e) {
				$(document.body).appendText('exception: '+e.message);
			}
		}})
			.get();
	</script>
</body>
</html>

test.xml:
<?xml version="1.0" encoding="utf-8" ?>
<root>test</root>

но я в общем-то о том, что я не вижу проблем с перемещением элементов между одинаковыми "типами" документов. По-крайней мере я так понял твою фразу :) (может гарантировать лишь то, что всё это будет работать только в пределах одного отдельного документа)

а ownerDocument как решение проблемы перемещения элементов между разными типами документов мне кажется странным. По-моему надо по исключению определять невозможность, либо метод какой-то проверочный придумать

по поводу перестраховщиков... мне кажется сейчас не все так печально (с появлением whatwg). Да и на перестраховку это не очень похоже. Ладно, не именно это. Именно это вообще ни на что не похоже :) А w3c мне неслабо напоминают architecture astronauts, хотя и их понять можно :)