This is Google's cache of http://habrahabr.ru/blogs/ie/51982/. It is a snapshot of the page as it appeared on 10 Aug 2010 00:05:05 GMT. The current page could have changed in the meantime. Learn more

Text-only version
These search terms are highlighted: ie innerhtml table  
«Карма кода» или почему innerHTML не работает в таблицах / Internet Explorer / Хабрахабр
войти зарегистрироваться

Internet Explorer whois

индекс
96,27

«Карма кода» или почему innerHTML не работает в таблицах

Это перевод записи «Карма кода» из блога Эрика Вазилика, датированной 2 июля 2006 года.

Я недавно писал о клиентском яваскрипте для интерфейса, основанном на HTML. Во время работы я столкнулся со свойством браузера Internet Explorer, за которое хотя бы частично ответственен уже 10 лет! Давайте, я это объясню, а также причину и эффективный способ обхода.

Я пытался динамически заменить несколько рядов в таблицах с разным наборов из них. Для этого я использовал свойство элемента innerHTML, которое получает строку, делает синтаксический анализ HTML и заменяет его содержимое новым HTML. В данном случае я пытался заменить содержимое TBODY новым набором рядов:

<table>
  <tbody id="rows">
    <tr>....
    <tr>....
    ...
  </tbody>
</table>


var tb = document.getElementsByName('rows')[0];
tb.innerHTML = "<tr>......";

Это прекрасно работает в Firefox. Новые ряды заменяют старые и показывают обновлённые данные. В Internet Explorer, однако, появляется ошибка скрипта, говорящая об ошибке исполнения!

Сначала я подумал, что IE не может перерисовать таблицы, изменённые с помощью innerHTML, но затем вспомнил, что именно я ответственен за это ограничение! Как много разработчиков имеют потом дело с последствиями их решений о продукте? Возможно, немногие. Давайте, я расскажу, как это было.

Примерно 10 лет назад я состоял в команде Трайдент. Трайдент отвечает за синтаксический анализ, интерпретацию и объектную модель IE версий после 3.0. Он известен также как mshtml.dll. Я был разработчиком, ответственным за представление HTML в памяти и динамической работой над ним.

Частью того, над чем я тогда работал, было создание метода innerHTML, а также innerText, outerHTML, outerText и менее известных методов insertAdjacentHTML и insertAdjacentText. Эти методы получают HTML или чистый текст и заменяют или вставляют новое содержимое в документ.

Майкрософт описывает их сейчас как неприменимые для элементов таблиц. Почему? Они об этом не говорят. Я помню, однако, почему.

Когда устанавливается свойство элемента innerHTML, строка, содержащая HTML, проходит через синтаксический анализатор. Анализаторы HTML не столь просты как прямые анализаторы вроде XML. Синтаксический анализатор HTML (блестяще сделанный Дэвидом Бау) получает произвольный текст и, как правило, производит дерево элементов HTML. Например, в результате анализа файла, содержащего только «Foo», в будет дерево:

<HTML><HEAD></HEAD>
<BODY>Foo</BODY></HTML>

Вы можете увидеть это сами, выполнив следующий код в IE (в Firefox не работает, так как в нём не реализован outerHTML):

Foo<script>alert(document.body.parentNode.outerHTML)</script>

На данный момент синтаксический анализ чего-либо вроде «<tr><td>Foo» без тэга TABLE перед TR приводит к тому, что анализатор полностью игнорирует тэг TR. Может быть, это сделано в анализаторе IE для обратной совместимости с браузером того времени Netscape. Фактически, обратная совместимость влияет на большую часть сложности синтаксического анализатора.

Так, попытка установить innerHTML у TBODY равным «<tr>...» приведёт к тому, что содержимое TBODY будет «Foo». Это страшно не «корректный» (англ. «valid») HTML, который можно было бы отобразить. Для того чтобы TR был создан, нужно предварить его тэгом TABLE. Попытка установить содержимое TBODY равным «<table><tr>...», однако, имеет ещё меньший смысл, потому что вставка TABLE прямо в TBODY столь же бестолкова.

Здесь требуется то, что я называю «контекстным синтаксическим анализатором HTML». Это режим анализа, в котором ветвь существующего HTML «скармливалась» бы анализатору с контекстом, где должна быть обработана строка. Поэтому если есть ответвление тэгов, где имеются (начиная с самого вложенного) TBODY, TABLE, BODY, HTML, и требуется разобрать «<tr>...», «контекстный синтаксический анализатор HTML» будет знать, что можно создать TR, так как его непосредственным родителем гарантировано будет TBODY, который может содержать TR.

Отличная концепция — этот контекстный синтаксический анализ. Проблема в том, что у нас никогда не было достаточно времени для реализации такой функциональности. И я запретил действие на таблицу innerHTML и других методов для попыток её изменений.

Альтернативой этому было «подделать» что-нибудь. Например, я мог проверить, что innerHTML у TBODY устанавливался во что-то, начинающееся с «<tr>». В таком случае я мог присоединить в начале строки «<table>» и затем выдернуть все TR из конечного дерева и заменить ими содержимое TBODY.

Звучит достаточно просто, пока вы не начнёте учитывать все варианты. Вроде подающейся строки, например как «<!-- новые строки --><tr>...». Довольно скоро вы начнёте делать всю работу, которую настоящий синтаксический анализатор должен выполнять сам.

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

Интересно, как это реализовали в Firefox. Может быть, я когда-нибудь найду время глянуть на его код…

Способ обхода на самом деле не так уж и плох. Что я сделал, так это вставил тэг SPAN в мою страницу со стилем visibility, установленным в hidden. Когда надо заменить ряды, я устанавливаю innerHTML этого тэга равным чему-то вроде «<table><tbody><tr>...». Так как элемент невидим, это не приводит к перерисовке страницы. Затем я использую метод DOM replaceChild элементов для удаления старого TBODY и заменой его полученным. В результате таблица правильно изменяется и перерисовывается!

<table>
  <tbody id="tb">
    <tr>....
    <tr>....
    ...
  </tbody>
</table>
<span id=temp style='visibility:hidden'></span>


var temp = document.getElementsByName('temp')[0];
temp.innerHTML = '<table><tbody><tr><td>New Row';
var tb = document.getElementsByName('tb')[0];
tb.parentNode.replaceChild(temp.firstChild.firstChild, tb);

Вы можете увидеть это в действии.

комментарии (83)

  • «Это не ужасно «правильный» или отображаемый HTML. „

    Перевод компьютерный? Просто в процессе чтения, я немного сбиваюсь, т.к. не могу понять смысл некоторых фраз. Было бы неплохо увидеть человеческий перевод, или хотя бы адаптацию данного под человека
    • «This is not terribly „valid“ or displayable HTML.»

      Это человеческий перевод, выполнен лично мною. Если есть претензии, то они, скорее всего, к автору.
    • извиняюсь, перевод человеческий, но абзац с цитатой приведенной выше и следующий после него все же немного неправильны
      • Это режим анализа, в котором ветвь существующего HTML была «скармливается» анализатору с контекстом

        вот тут, мне кажется, надо убрать «была». Я не придираюсь, просто это слово сбивает))
        • Действительно. Исправил.
      • Спасибо за доброе слово! Прошёлся по статье, переписал её более по-русски.
  • Первая мысль: я ничего не понимаю.
    Вторая мысль: вот индусы!
    • Да не индусы, просто менеджмент, как обычно, сроки поджимает.
      • Ну, значит менеджеры — индусы. Кто-то из всех этих людей должен быть индусом 100%. В Firefox же всё отлично сделали.
        • Увы, далеко не всё. Есть баги с таблицами, с плавающими элементами и др. Некоторые живут много лет в багзилле. Баг с переключением раскладки был легендой, пока его не починили в программы, где давали деньги за багфиксы.
          • рамках программы
          • Ясен пень! В любой программе есть ошибки! Только вот я не знаю ни одного топика про то, что «xxx не работает в Firefox, я покажу как надо это делать через yyy».
            Ну и судя по вашему посту, в Майкрософт за багфиксы денег не платят.
            • Это на самом деле большая удача, когда какой-то баг можно обойти лёгкими способами. Я, например, не знаю такого способа обхода бага с плавающими элементами (когда несколько несколько флоатов вложены тоже во флоат).
              • А что за баг, где несколько флоатов лежит в флоате? Никогда проблем не возникало.
                • Я уже не помню что имел в виду :-). Съезжают, наверное (возможно с отступами). Или float:right растягивает нафиг.
                  Не помню даже какой имелся в виду бразуер. В IE точно частенько возникают проблемы. Когда прижатый к низу футер вдруг оказывается не внизу. Решение: обрамлять каждый ряд флоатов.
                  • Ни разу не имел проблем с флоатами. Ваши слова подтверждают, что проблемы не существует.
                    • У вас, наверное, не было достаточно сложных случаев.
        • нужно еще взять во внимание то, что Firefox выпустили в 2004 году, а IE 3 в 1998…
          • извиняюсь IE3 — дата релиза 96 год =)
    • Вот уж действительно карма кода. Сперва они не успевали доработать как следует mshtml из-за сроков (и дело не в табличках, дело в жуткой неэффективности этой библиотеки), а теперь мы вынужденны были не успевать в сроки, выделывая пируэты оптимизации под IE`шные браузеры.

      Очень легко убедится, зайдите на сайт inthecity.ru браузером (FF, Opera, Chrome), а потом зайдите IE (6/7). Разница очевидна.

      Блин… Ну почему, почему им тогда не дальше больше времени? Это решение настолько затормозило развитие целой индустрии под названием rich web applications…
      • Microsoft не мало за это критикует, но ей это даже в чём-то оказалось выгодно: некоторые приложения конкурируют с продуктами Microsoft. С другой стороны, если IE был бы очень хорошим браузером, его монополия была куда сильнее. А так сейчас мы видим несколько довольно приличных альтернатив, да Еврокомиссия решила, что Windows не должна поставлятся только с IE.
  • Перевод во многом смотрится как машинный. Человечней надо было подойди.
    Однако, все равно спасибо за статью.
    • Да-да, уже сделал.
      • Но многое осталось :)

        Особенно вот это
        >>Это не ужасно «правильный» или HTML, что можно отобразить.
        Это звучит по-английски. Но по-русски режет глаз.
        Возможный перевод
        «Это не самый валидный код, да и отобразить его невозможно»

        В русском языке вот так:
        >>Попытка установить содержимое TBODY равным «...», однако,
        Однако, попытка установить содержимое TBODY равным «...»

        Вот тут вообще ничего не было ясно. Да и переведено неверно
        >>Поэтому если где, в ответвлении тэгов присутствуют (от самого вложенного) TBODY, TABLE, BODY, HTML
        Оригинал
        >Thus, if the branch of tags were (from the bottom) TBODY, TABLE, BODY, HTML
        Надо было перевести как
        Поэтому, если ветка тегов (в обратном порядке) представляет из себя TBODY, TABLE, BODY, HTML

        >>для реализации такой функциональности
        такого функционала

        >>Альтернативой всему этому было бы что-то «подделать»
        Альтернативой было бы «подделать» что-нибудь

        Работа переводчика нелегкая :)
        • Я, конечно, указал далеко не все. Перечитайте текст, стараясь думать на русском.
        • Спасибо за комментарии, но поспорю.

          > Особенно вот это
          >>>Это не ужасно «правильный» или HTML, что можно отобразить.
          > Это звучит по-английски. Но по-русски режет глаз.
          > Возможный перевод
          > «Это не самый валидный код, да и отобразить его невозможно»
          Это жаргонизм и, вообще говоря, не по-русски. В качественном переводе такого быть не должно.

          > В русском языке вот так:
          >>>Попытка установить содержимое TBODY равным «...», однако,
          > Однако, попытка установить содержимое TBODY равным «...»
          Это как раз по-английски. По-русски будет вариант, использованный мной. Это не я придумал, это нас так учила в институте очень крутая преподавательница.

          > Вот тут вообще ничего не было ясно. Да и переведено неверно
          > >>Поэтому если где, в ответвлении тэгов присутствуют (от самого вложенного) TBODY, TABLE, BODY, HTML
          > Оригинал
          > >Thus, if the branch of tags were (from the bottom) TBODY, TABLE, BODY, HTML
          > Надо было перевести как
          > Поэтому, если ветка тегов (в обратном порядке) представляет из себя TBODY, TABLE, BODY, HTML
          Бывает со мной, запятою промахнулся. Исправил.

          > >>для реализации такой функциональности
          > такого функционала
          Спорно. Мне кажется, «функциональности» звучит лучше.

          > >>Альтернативой всему этому было бы что-то «подделать»
          > Альтернативой было бы «подделать» что-нибудь
          Согласен, пропустил. Исправлено.
          • >>Это жаргонизм и, вообще говоря, не по-русски.
            Замените на правильный.

            >>Это не я придумал, это нас так учила в институте очень крутая преподавательница.
            Порадовали :))
            «Однако» в конце предложений (в том числе простых предложений в сложном) и не по теме в середине предложений ставят только представители одной национальности, однако.
            Ваша учительница была не той национальности, однако? :)

            Простите. Это шутка, конечно. Но в каждой шутке…

            >>«функциональности» звучит лучше.
            Функциональность в русском является суб-термином usability.
            Функциональное устройство == удобное устройство
            Нефункциональное == неудобное

            — В любом случае мое дело предложить правки. Ваше дело отказаться.
            Однако, с таким упорством не по делу вам будет трудно на Хабре (да и судя по описанию в профиле, вам уже нелегко).
            • > Замените на правильный.
              Заменил всё предложение на «Это страшно не „корректный“ HTML, который можно было бы отобразить.»

              > «Однако» в конце предложений (в том числе простых предложений в сложном) и не по теме в середине предложений ставят только представители одной национальности, однако.
              Не знал. Это какой? А вообще, сложное предложение и простое, это, на мой взгляд, разные случаи. И в конец простого предложения я «однако» не ставлю :).

              > Функциональность в русском является суб-термином usability.
              > Функциональное устройство == удобное устройство
              > Нефункциональное == неудобное
              С чего вы это взяли? Можно легко привести много примеров функциональных, но неудобных в некоторых отношениях или даже полностью вещей. Например, ноутбук, с которого, я пишу функционален, но гулять с ним, нося до 3 кг веса не очень-то удобно. Или официальный клиент ICQ функционален, но очень многим не нравится именно по причине неудобства.
              С другой стороны, можно привести пример малофункциональных, но довольно удобных вещей. Например, кровать может быть малофункциональной: на ней можно только спать, но зато это очень удобно.

              А моё «упорство» заключается лишь в продуманности и обоснованности многих моих мнений. И менять мнение по первому веянию, если это необосновано, мне не с руки.
              • Вы его уже поменяли :D Не обманывайте себя. И правильно сделали.
                Удачи!
                • Спасибо! Но я не зря сказал про обоснованность ;). Если тупо стоять на своём ничему не научишься. И чужие мнения тоже надо воспринимать (необязательно при этом с ними соглашаться).
            • Добавил примечание в скобках (англ. «valid»), теперь должно быть понятно и по-русски ;).
  • > Что я сделал, так это вставил тэг SPAN в мою страницу со стилем visibility,
    > установленным в hidden. Так как элемент невидим, это не приводит к перерисовке страницы.
    Я всегда это знал. Разработчики экплорера индусы, не знают технологий, под которые пишут браузер. visibility: hidden элементы невидимы, но их изменение ПРИВОДТ к перерисовке страницы.
    • Да ещё таблица вставляется методом innerHTML в строчный элемент SPAN.
  • просто кур ебать не надо извращаться не надо и все будет ок
    • ну и где волшебные html теги хабрахабра? там должен был быть страйк
      • Карма ниже страйка.
        • значит не юзерфрендли
          должен пропасть блок «вы можете использовать хтмл теги»

          фсе ф шоке. как можно говорить о веб девелопменте на сайте, где нифига не по феншую все?
      • НЛО прилетело и опубликовало эту надпись здесь.
        • семантичнее? вы ничего не перепутали? может быть вы хотели сказать «было бы лучше», а не «семантичнее»? ;)
          • новояз: готично, опричЪно, гламурно, семантично.
  • Много лет пинали MS за то что он ввел в оборот innerHTML, теперь когда все остальные броузеры научились им пользоваться, MS пинают за то что десять лет назад он ввел его не так как через семь-восемь лет его реализовали в другом броузере. Причем пинает тот кто этот innerHTML разрабатывал.
    Не пойму я этого.
  • только мне кажется, что там следовало бы

    var tb = document.getElementById('rows');

    там же
    • Скрипт по ссылке вообще оригинальный, заменяет innerHTML у tbody на table, точнее на "<table><tbody><tr><td>New Row" ;). В IE ошибка, а в других браузерах невалидный код. Видимо, автор скор на руку и не утруждает себя повторным осмотром кода.
    • да задан ID а поиск ведут по Name меня тоже в ступор поставило — поправьте плиз
      • Так у автора, от меня лишь перевод. Это же IE, в нём так работает.
        • э-э-ээ правда так в нем работает? что-то я недопонимаю наверное? разъясните для меня тут очевидный парадокс. Особенно в месте где работает в FF
          • По-видимому, имеется ввиду quirks mode. В примере именно он.
          • НЛО прилетело и опубликовало эту надпись здесь.
            • абалдеть. спасибо
      • В «в действии» задан и name тоже.
  • блин, я боюсь писать коментарии, все путевые каменты минусуют а смешные плюсуют :(
    а вообще, я полностью согласен с тем что у table не должно быть innerHTML потому как есть методы insertRow и insertCell они вполне компенсируют это!
    ps: считаю innerHTML ламерским подходом (хотя сам его часто использую=)) потому как если используете ДОМ, будьте любезны, используйте его в полной мере!
  • блин, я боюсь писать коментарии, все путевые каменты минусуют а смешные плюсуют :(
    а вообще, я полностью согласен с тем что у table не должно быть innerHTML потому как есть методы insertRow и insertCell они вполне компенсируют это!
    ps: считаю innerHTML ламерским подходом (хотя сам его часто использую=)) потому как если используете ДОМ, будьте любезны, используйте его в полной мере!
    • > блин, я боюсь писать коментарии
      Они это почувствовали ;)
  • блин, я боюсь писать коментарии, все путевые каменты минусуют а смешные плюсуют :(
    а вообще, я полностью согласен с тем что у table не должно быть innerHTML потому как есть методы insertRow и insertCell они вполне компенсируют это!
    ps: считаю innerHTML ламерским подходом (хотя сам его часто использую=)) потому как если используете ДОМ, будьте любезны, используйте его в полной мере!
    • извените, глюк вышел, не знаю как появились 3 сообщения :(
    • Метод innerHTML производительней альтернатив, так как синтаксический анализатор браузера быстрее чем набор команд на яваскрипт (даже скомпилированных, за исключением, быть может, совсем простых случаев, когда достаточно одной). Если, конечно, браузер нормально сделан.
      • Именно. Вообще, как говорит в одной из лекций Дуглас Крокфорд, разбор html — это единственное, что браузеры делают действительно хорошо (эволюция заставила :).

        Если приложению нужна скорость, то innerHTML может ее дать. Совсем другой вопрос, что если вашему приложению совсем никуда без innerHTML, то велика вероятность что оно плохо спроектировано или как минимум имеет архитектурные изъяны.
      • я не спорю что innerHTML быстрей работы с DOM-ом, но если везде пичкать его, то получится ужасная мешанина JS и HTML, а это не лучший способ программирования. собственно я это имел ввиду.
        • А при работе с DOM будет завуалированная мешанина :).
          • то что Вы написали в народе называется «говнокод», а должен получиться строго структурированный ОО код, для работы с обьектной моделью дерева документа :)
            а вообще ОО подход гибче, так как если надо будет с созданной структурой поработать подольше, то у Вас будут готовые обьекты, которые можно элементарно кэшировать, изменять (не ища по айди среди документа) напрямую итд.
            • Вот у вас пришёл HTML по AJAX, где вы будете кешировать изменять и т.д.? В пришедшой переменной вида строки или сначала парсить, потом динамически менять и выводить кучей document.createElemend, documend.appendChild? Посмотрю я, как будет конкурировать ваше приложение с таким тормознутым выводом.
              • 1 у меня не приходит HTML по AJAX, у меня приходит JSON, который я кеширую и с которым дальше работаю
                2 Вы хоть раз создавали табличку клиенту на 2500 ячеек из приходящих данных? (это насчет тормознутого вывода)

                кстати в том тесте можно увеличить скорость дома процентов на 30 если * засовывать как innerHTML а не как обьект, потому как это текст, в отличии от ячейки или ряда
                • 1. Я где-то говорил про XML? Или вы из объектов JSON генерируете HTML?
                  2. Всю таблицу можно и при помощи innerHTML сделать. И всё равно это будет быстрее, чем через DOM и особенно через методы таблиц.

                  Не понял вашу фразу про тест. Он же сравнивает разные методы.
                  • я про XML тоже ничего не говорил, да, я из JSON генерю HTML при необходимости.
                    про тест: все методы полезны, и innerHTML тоже, но его не надо пичкать везде, и вставка таблицы через innerHTML это неправильный подход помоему
        • Мм, вовсе не обязательно. Никто не мешает использовать шаблонизаторы на клиенте.
    • жжешь
  • А где ссылка на оригинал? Не знаю кому как, а мне так и не стала ясна причина почему это не работает.
    • Там же где и везде на хабре: справа от рейтинга и даты, между звёздочкой и хабраником.
      • Оно, конечно, правильно, там и должно быть. Можно и только там. Но HTML-ссылка в первой строчке, там, где даётся текстовая ссылка, тоже смотрелась бы неплохо. Да и удобно — не надо проматывать экран за экраном. Хотя это, конечно, на вкус и цвет… Но два «имхо» уже совпали :)
      • Кстати, я понимаю, как достали уже правки с переводом, а тут ещё и это замечаньице. Это так, несущественно. Может послужит рекомендацией во время написания следующей статьи. А может и не послужит :)
        • Вообще-то думал об этом сразу, создавая статью, но решил что опытным хабраюзерам будет достаточно ссылки в обычном хабраместе. Видимо, я ошибался. Специально для вас вставил название с ссылкой в начале статьи.
          • Уже не первый раз начинаю считать себя «опытным хабраюзером», а потом обнаруживаю очередную фичу, и понимаю — «видимо, я ошибался» :)) Да и не все же опытные, иногда можно и скидочку новичкам сделать :)
          • Спасибо, кстати. Завидую вашему терпению и трудолюбию.
  • понятно что работа с нодами везде работает. Например стабильно везеде будет работать что-то вроде такого кода (jQuery):
    var firstTr=$j("#tatgetTable tr:first");
    var newTr=firstTr.clone();
    newTr.insertBefore(firstTr);
    • Это один ряд, а когда нужно много? Получается не очень удобно и не слишком быстро.
  • Господь услышал мои молитвы — создатель ИЕ пишет js для него же! Чуствую себя отомщенным.
  • Я тоже столкнулся с проблемой InnerHTML внутри таблицы несколько месяцев назад. Что касаемо предложенного Workaround, то он меня не устраивает из-за не универсальности. Хотелось иметь код, который одинаково хорошо вставляет как элементы как внутри таблицы, так и снаружи. В свое время перепробовал много вариантов остановился на DOM парсере, но так и недоделал корректную модификацию атрибутов под IE, если кто хочет продолжить мою работу над универсальным InnerHTML всегда рад пообщаться на эту тему.

    function loadXMLString(txt)
    {
    txt = '' + txt + '';
    try //Firefox, Mozilla, Opera, etc.
    {
    var xmlDoc = new DOMParser().parseFromString(txt,«text/xml»);
    return(xmlDoc);
    }
    catch(e)
    {
    try //Internet Explorer
    {
    var xmlDoc = new ActiveXObject(«Microsoft.XMLDOM»);
    xmlDoc.async = «false»;
    xmlDoc.loadXML(txt);
    return(xmlDoc);
    }
    catch(e) {alert(e.message)}
    }
    return(null);
    }

    function dom2html(domnode, htmlnode)
    {
    var child; for(var i=0; child=domnode.childNodes[i]; i++)
    {
    if (child.nodeType==1)
    {
    var temp = document.createElement(child.nodeName);
    var attr; for(var j=0; attr=child.attributes[j]; j++)
    {
    temp.setAttribute(attr.name, attr.value);
    // newatt=document.createAttribute(attr.name);
    // newatt.nodeValue=attr.value;
    // temp.setAttributeNode(newatt);
    }
    htmlnode.appendChild(temp);
    if (child.hasChildNodes()) {dom2html(child, temp);}
    } else
    if (child.nodeType==3)
    {
    var temp = document.createTextNode(child.nodeValue);
    htmlnode.appendChild(temp);
    } else
    {
    // alert(child.data);
    //var temp = document.createCDATASection('');
    //var temp = document.createElement(child.data);
    //var temp = document.createCDATASection(child.data);
    //htmlnode.appendChild(temp);
    }
    }
    }

    Пользоваться этим кодом следует так:
    var dom = loadXMLString(arrhtml[id]).documentElement;
    while (element.firstChild) element.removeChild(element.firstChild);
    dom2html(dom, element);

    1 строчка создает DOM из строки с HTML разметкой.
    2 строчка чистит все внутри element
    3 строчка вставляет DOM внутрь element
  • Я столько времени угрохал на отладку своего JS-кода в IE. Он великолепно работал в Firefox.
    Хорошо хоть сейчас появилось объяснение этой проблемы.
    Спасибо за перевод.
    • Вообще это довольно давно известная штука. Обход долгое время существует, например, в prototype.js. Мне показалась интересной история, поэтому и перевёл.
  • Похожая проблема есть со вставкой, через innerHTML/insertAdjacentHTML, в элемент SELECT html кода c option-сами.
    В IE оно не вставляется, только если заново создавать весь селект.
    За наводку на решение проблемы спасибо.

    P.S. insertAdjacentHTML воистину не недооцененный метод, его кстати легко эмулировать в браузерах его не имеющих
    if(
      typeof HTMLElement!='undefined'&&
      typeof HTMLElement.prototype.insertAdjacentHTML=='undefined'
    ){
      HTMLElement.prototype.insertAdjacentHTML=function (sWhere,sHTML) {
        var t=this,
        r=t.ownerDocument.createRange(),
        a={
          'beforebegin':['setStartBefore',t.parentNode,t],
          'afterbegin':['selectNodeContents',t,t.firstChild,!0],
          'beforeend':['selectNodeContents',t,null,!1],
          'afterend':['setStartAfter',t.parentNode,t.nextSibling]
        }[sWhere.toLowerCase()];
        r[a[0]](t);
        a.length==4 && r.collapse(a[3]);
        a[1].insertBefore(r.createContextualFragment(sHTML),a[2])
      }
    }
    
    • «!= 'undefined'» и «== 'undefined'» — зло используйте «!== 'undefined'» и «=== 'undefined'» :)
Только авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.