Имеем простейший HTML-файл, который несложно привести к XHTML виду, когда будем запихивать его в EPUB.
Имеем разные jQuery-плагины, которые на лету строят DOM и заполняют контентом элементы, превращая таким образом первичный HTML в очень разнообразные макеты. Т.е. jQuery-плагины позволяют нам создать энное количество базовых типов макетов. Например: «текст со скролом и фикисед-позишен картинкой в углу», или «текст с картинкой в разрер полосы» ну и т.п.
Так вот, создание контента для этих "страниц", которые формируются из базовой jQuery-плагинами ведётся в intranet-портале.
И там, не реализован пока ни WYSIWYG-редактор, ни контроль синтаксиса. Только поля для ввода HTML-разметки и визуализатор. Так вот, контент из полей скармиливается jQuery-плагину, а затем iframe с визуализатором перезагружается.
И вот там некоторые ошибки прощаются. По крайней мере Firefox-ом.
(jQuery-плагины оперируют .html() или .append())
А вот что будет когда плагин будет работать в среде движка EPUB-читалки - тут я пока уверенности не имею...
С закрытием тегов еще более менее ясно - нужно строго подходить.
А вот с использованием сущности для одиночного амперсанда, например - не ясно.
Если бы из intranet-портала выходили модифицированные HTML-страницы, в которые прописан контент - тут понятно.
Но оттуда выходит по сути одна и та же HTML-страница. Разница только в jQuery-плагине, которая она вызывает и конфигурации (JSON) полей, которые передаются jQuery-плагину, чтобы он формировал вёрстку на лету...
Нет, не нативный innerHTML, а с помощью .html() или .append() jQuery.
Затрудняюсь сказать - там коррекция ошибок вряд ли есть?
И под закрытием тагов я имел ввиду не закрытие самого тага угловой скобкой, а "забывание" добавить закрывающий таг.
Насчёт XML - это не про сайты, а про EPUB-контейнер.
Насчёт HTML-сущностей - ясно, что есть варианты. Дело в том, что XHTML требует & вместо одиночного &
И если в браузере одиночный амперсанд не вызовет ошибку, то в EPUB-читалке - не знаю.
У нас несколько проблем. Сперва мы из белого получили серый (допустим, F7). А дальше в Firefox при масштабировании серый меняется в диапазоне 5-10 бит произвольно.
Благодарю за развёрнутый ответ.
Я предполагал, что, если в шрифте есть юникод, то он просто перекрывает однобайтовую кодировку...
Вот например, выбираю символ с кодом в диалоге Word-а 0061 (hex).
Вставляю в документ Word.
Копирую из Word в простой текстовый редактор (встроенный в FAR) и вижу код символа: 61537.
Но что странно, при выборе шрифта в диалоге вставки в Word, кодировки только две: Символ (шестн.) и Символ (дес.)
В том время как у системного (Win7) Arial вот так:
Юникод (шестн.), Юникод (дес.), ASCII (дес.), ASCII (шестн.), кирилица (дес.), кирилица (шестн.)
Получается, тот шрифт поддерживает двухбайтовую кодировку, но она не Unicode? Такое бывает?
В целом, мы сейчас решили проблему, написав макрос, который ищет в Word символы, для которых установлен это шрифт и принудительно меняет их на другие и ставит шрифт NewtonPhonetic (OTF), у которого такой лабуды не происходит.
Спасибо, то ли искал по другим ключам, то ли ibm.com меня смутил :)
Я не уловил точно - проблема только в обязательно подгрузке файлов по действию пользователя или запуск - тоже.
Буду экспериментировать.
И - да. Кажется можно спастись использованием подгружаемых шрифтов. Но выяснилась еще одно.
Например имеем текст: А. А. Иванов
пробелы - обычные, не неразрывные
IE на десктопе, андроид и iOS рвут после первой "А."
А firefox и chrome на декстопе - только после второй А.
Случайность или браузеры "понимают", что это инициалы?
Т.е. нужно строго ставить неразрывные пробелы, иначе не только можем получить не только разрыв там, где не ожидалось, но и наоборот...
Хочу также уточнить один момент. Нужно ли в дестрое удалять обработчики, которые висят на событиях на элементах моего же виджета? Я же их все похерю в дестроее: $(selector *').remove().
Можно ли удалять только с тех элементов - которые вне виджета и, соответственно, останутся жить? Они точно могут вызывать утечку памяти и, более того, буду продолжать срабатывать.
По идее, если элемент убран из дерева, все его обработчики и так сдохнут?
bind-ов я там не использовал для упрощения кода, но с ns-ами вроде бы всё понял
Только вот что вы имели ввиду насчёт - "без namespace, если обработчиков меньше 1-2.", мне не ясно.
Вопрос в том, как понять, перебирая обработчики на body, например, где - чей? Где - от какого виджета? Который мы должны отвязать при дестрое? Функция в плагине, который вешается на событие, может быть как атрибутом объекта, так и просто функцией внутри замыкания плагина, которая живёт только за счет того, что привязана к событию. Вроде так? В общем, неймспейсы - оптимально.
