Разработчики Mozilla попытались (https://blog.mozilla.org/security/2013/09/24/introducing-htm.../) создать удобную альтернативу innerHTML для вставки статичных HTML-блоков без необходимости предварительного ручного разбора строковых данных. Метод innerHTML очень популярен благодаря своей простоте, но он далёк от оптимальности, небезопасен и его использование считается плохим стилем.
Прототип альтернативной системы оформлен в виде библиотеки html2dom (https://github.com/freddyb/html2dom), которая на основе строки с HTML генерирует JavaScript-код для корректного создания элементов DOM, т.е. заменяет единый вызов innerHTML на серию простых обращений к DOM. Указанный подход позволяет избежать запуска HTML-парсера для длинных HTML-строк, что положительно влияет на производительность и позволяет защититься от XSS-атак через подстановку в обрабатываемый через innerHTML ввод нежелательных тегов.URL: https://blog.mozilla.org/security/2013/09/24/introducing-htm.../
Новость: http://www.opennet.me/opennews/art.shtml?num=37989
ха !! якобы проще избежать инжекции - путем использования JS-крапа, чем громоздкого, но безопасного html ? :) когнитивный диссонанс, однако. ужО второй десяток лет как - инжекция кода чрез JS - основной путь малвари на компы )
и вообще, пора уже учить html/nosql+sql связку веб-мастерам, JS-трэш - откровенно задолбал.
А ты намерен «избежать инжекции»?
Каким путём?
Предоставлением для посещений своего личного, свободного от малвари сайта?
А как это «избежит от инжекции» в отношении миллиончика не твоих сайтов?
о, есть десятки проектов на тему, вы удивитесь.
из них - добрая треть концентрируется на отсечении 3-rd party контента.
остальные - на enforce-инге HTTPS/HSTP, веб-сокетов итп, замене кукисов на странных, но легковесных мутантов керберос и ldap, но ISC и IETF не спешит это утверждать. оно и понятно, персонал АНД и Оффиса Директора НАцразведки, Госдеп - не зря З/П получают ;)
Разработчики фреймворка GWT наоборот утверждают что innerHTML лучше чем доступ через DOM. хз уже кому верить.http://www.gwtproject.org/doc/latest/DevGuideUiCellWidgets.html
These widgets are designed to handle and display very large sets of data quickly. A cell widget renders its user interface as an HTML string, using innerHTML instead of traditional DOM manipulation. This design follows the flyweight pattern where data is accessed and cached only as needed, and passed to flyweight Cell objects.
может быть потому что GWT уже сам всё проэскэйпил?
GWT овнище тормозное, не сильно сложный проект с несколькими окнами а-ля проводник + топология сети в виде значков весит 40 метров, тормозит страшно, на мобильных девайсах через одно работает - только на тех, для которых в GWT условно говоря ifdef прописан.
Аналогичное приложение на js + jquery и kendo - порхает как бабочка.
Я не фанат GWT, но 40 МБ приложение показывает только экстремальную кривизну рук программистов такого приложения. Не самое маленькое приложение, с extGWT во все поля (плюс ещё пара-тройка библиотек) за мегабайт так и не перешагнуло. И это без оптимизации.
Библиотека исправляет разметку. По крайней мере, незакрытые теги успешно закрывает.
Они говнокод специально поощряют?
в смысле "говнокод"? С спецификации явно указано, когда и где можно не закрывать теги. Вы наверное и не читали вовсе, но осуждаете?:)
Тогда нафига что-то "исправлять", простите?
Я думал, речь идет о тегах, которые нужно закрывать, а они не закрыты.
А у нас все браузеры идеально поддерживают спецификацию? Хотя бы распространенные? Хоть один?
Учи мат часть. innerHTML всегда автоматом закрывал теги
>Метод innerHTML далёк от оптимальности, небезопасен и его использование считается плохим стилем.Что за бред?! Кем считается? Говнокодерами, или NIH-ерами?
innerHTML он быстрее цепочек createElement Apendchild когда нужно просто вставить статический текст в тег с минимальным парсингом и соответственно doc.outerHTML=doc.innerHTML когда нужно просто убрать шелуху, например из ссылки сделать текст (убрать анкер) или тому подобное.
Просто быстро и безопасно, при этом кросбраузерно.
innerHTML является костылём, не описан в стандартах, и навязан Microsoft в Internet Explorer. То что его добавили в остальные браузеры для совместимости с IE погоды не делает.
> innerHTML является костылём, не описан в стандартах, и навязан Microsoft в Internet
> Explorer. То что его добавили в остальные браузеры для совместимости с
> IE погоды не делает.вообще-то, в документе от whatwg innerHTML ещё как описан. вместе с outerHTML и insertAdjacentHTML. you're welcome: http://domparsing.spec.whatwg.org/#extensions-to-the-element...
В whatwg скорее констатация фактического положения, некий стандарт де-факто. Официальный http://www.w3.org/TR/DOM-Parsing/ пока на стадии черновика.
ага, официально у нас HTML5 не особо есть — однако никого это не останавливает.
Да, этот мир несовершенен. Теперь ты знаешь это
Да начхать кто придумал полезную возможность. Доступна всем - что еще надо?
Ну конечно, html распарсеный JS в серию JS вызовов изменяющих DOM он будет быстрей, чем innerHTML распарсеный нативным движком браузера напрямую и пакетно добавленым в дерево. Вот именно производительность от такого выигрывает!
Супер "новость".
Это, несомненно, самая важная новость дня, нет -- новость года. Премию автору! Во-первых, она революционно изменит весь подход к программированию в браузере, заставив отказаться от innerHTML и вообще всего-всего, кроме String.fromCharCode().
Во-вторых, без сомнения, произойдёт революция в браузерах, innerHTML и все прочие ранее "полезные" вещи будут заменены на библиотеку html2dom.
И конечно же, эта новость революционно изменит жизнь юзеров. Предвижу, что теперь в формах нельзя будет ничего ввести, так как у всех по умолчанию введённый в форму текст обязательно вставляется в страницу с помощью innerHTML.
И вообще, я не понимаю, какого хрена ещё в браузерах не внедрили интерпретируемый x86-ассемблер с обязательной встроенной защитой от XSS? Надо бы написать...
> Во-первых, она революционно изменит весь подход к программированию в браузере, заставив
> отказаться от innerHTMLЗаставит использовать стандартные методы, а не костыль, добавленный в Internet Explorer.
> Заставит использовать стандартные методыто есть, HTML5 не использовать, потому что он не стандарт (а в HTML5 это свойство есть, см. #63)… стой! а ведь в до-HTML5 и DOMParse того-с… отсутствует! долой библиотеку, которая использует нестандартный интерфейс!
>какого хрена ещё в браузерах не внедрили интерпретируемый x86-ассемблеТы хоть на ассемблере писал то? Спрашиваю потому как у тебя типично хейтерский пост получился
Опять внешние фреймворки ....
> Опять внешние фреймворки ….это какие? DOMParser, который в стандарте? или страшный паттерн visitor, которым обрабатывается выхлоп этого парзера?
Парадигмы усложняющие DOM дерево, хватает одного только JQuery .... который разрос
в прототипе используют обычный innerHTML , обходят элементы используя DOM и строят JS.
непонятно зачем это может быть нужно.
Стабильней работать точно не будет
Благодаря безмозглому переводчику-фантазеру действительно сложно понять о чем на самом деле новость и для чего нужна эта библиотека.
Данная либа НЕ подключается к готовому сайту наподобие jquery, knockout или еще что-то. Она НЕ предназначена для вызовов из js кода. Она НЕ нужна для статического HTML. Она используется для создания js кода. А уже созданный ею код вставляется программистом на страницу вместо использования innerHTML и строки текста с HTML шаблоном, в который подставляются пользовательские данные. Этой либе нет необходимости быть кроссбраузерной, так как использоваться она будет только на компе разработчика, а не клиентвов. Кроссбраузерным должен быть код, который она генерирует.
Надо отметить, что либа создает код, который использует document.createDocumentFragment(), то есть не делает типичную ошибку тех, кто создает ноды напрямую в документе и удивляется почему innerHTML оказывается быстрее.