Использование оправдано текст на веб-давно Tricky, как линия иногда может быть вынесено с Богом ужасное слово промежутках. Это в значительной мере объясняется тем фактом, что делает двигатели не достаточно умны сами по себе знать, когда и где hyphenate слова. WP-Hyphenate призван добавить смарт дефиса для блогов WordPress.
Нету ли у Вас ощущения, что пользователи присытились социальными сетями подобными Одноклассникам и вКонтакте? Если так, то что, по-Вашему, станет следующим бумом в интернете?
Возможно вам поможет jQuery. Вы генерируете окно, в нем размещается контент (и возможно он не влазит, но зато теперь библиотека может рассчитать его ширину), затем jQuery имея ширину контента плюсует к нему нужные вам отступы и присваивает результат суммы ширине окна. Окно принимает, таким образом свой размер после генерирования наполняющего его контента.
Я не уверен, что это сработает (потому как особо не приходилось делать поп-апы), но, думаю, вполне может.
Вся страница (я только о коде .html файла говорю) весит 89 Кб. Если грохнуть ненужные элементы, то размер ее станет значительно меньше. Больше всего на хабре весят не комменты, а скрипты (283 Кб) да CSS-файлы (~ 98 Кб). Посему — не в ДОМе проблема.
<html>
|--- <div id="wrapper">
|--- <div id="main-content">
|--- <div id="coments">
|--- <ul class="hentry">
|--- и понеслась нелегкая в виде элементов списка.
Ничего такого уж сверхъестественного нету, на мой взгляд. В конце концов комментарии здесь не намного сложнее для отображения, нежели форумы, скажем. Разделяй и властвуй, что называется.
Вообще, я думаю, что разработчики Хабра знают о том, что нужна «хендхелд»-версия, но, как это обычно бывает в таких случаях, она оставлена на потом.
Не за что :)
А в чем с комментами проблема? Вновь таки при помощи того же CSS-файла отменить их сдвиги, и разделять примитивной границей какой-то (ветка | следующая ветка | и т. д.), попутно «дисплеем: нон» чистить от всего ненужного. Вообще это может быть непросто, однако вполне реально, если задаться такой целью.
При указанном display:none многие браузеры понимают, что грузить элементы с этим свойством не нужно. Если говорить о мобильных, то Opera Mini ведет себя именно таким образом.
Замечательная статья! Все очень обстоятельно разъясняется. Тем, кто стоит перед выбором между двумя методами дана пища для размышлений. Я же в свою очередь добавлю ссылку на эту статью к своей. Также предлагаю перенести в блог «Веб-разработка».
Теперь по теме. Ко всему сказанному здесь, думаю, уместным будет добавить, что поддержка Оперой typeface.js не за горами. Я задался этой темой и нашел замечательный скрипт под названием Base2 и оповестил о нем разработчика. Думаю теперь этот момент — лишь дело техники. Таким образом вопрос кроссбраузерности будет решен.
На счет генерить один раз или много — вопрос, ответ на который лежит в плоскости той или иной задачи. Для создания заголовков, оформления цитат и (возможно) меню способ создания изображений локально мне видится более удобным, потому как он на выходе дает результат, который максимально «похож» на то, как если бы у нас не было проблем с использованием нестандартного шрифта.
Насчет CSS. Думаю не будет, в связи с тем, что скрипт не призван превращать в изображение всю страницу. С несколькими же заголовками/цитатами/пунктами меню он управится. Можно даже привязать к визуальному редактору. Нужно лишь присваивать элементам класс, а остальные параметры регулируются обычынми инлайн-стилями.
Дело в том, что «файл шрифта» это условное название. Это не обычный .ttf файл, а его SVG/VML модель. Библиотека же нужна для интеграции оной и отображения готового изображения в том виде, который вы задали при помощи CSS.
Так и правда проще. Однако нету возможности регулировать параметры свойства текста через CSS и на лицо проблемы с SEO (заголовки картинками — больше не заголовки), скрин-ридеры (для людей с проблемами зрения) также не читают картинки. Посему плюсы очевидны. Только бы подтянуть кроссбраузерность (за этим я думаю дело не станет) и придумать что-нибудь с размером файлов шрифтов.
Да, я пробовал. Но не в Опере (ИЕ и ФФ 3.0.3). Все нормально. Были проблемы с кодировкой и неправильным «называнием» шрифтов в недрах стиля. Когда разобрался, все стало на свои места.
На счет Оперы. Данный недостаток документирован и находится в списке «ТО DO» разработчика.
Я согласен, что скрипт сыроват, но не настолько, чтобы не написать о нем здесь. Если дело не заглохнет и человек будет заниматься этой штуковиной, то выйдет очень неплохой инструмент.
Да. К сожалению в зависимости от гарнитуры размер файл может существенно колебаться. У меня в другом шрифте (к сожалению не вспомню его точное название сейчас) при включенных кириллическом и латинским вариантах написания вышло около 50-ти килобайт.
Я не особо посвящен в суть работы sIFR, поэтому сказать сложно. В данном случае не нужен плагин Flash и отрисовка изображения производится средствами самого браузера.
Вообще эта статья написана не с целью сказать: «Смотрите, есть замена sIFR!». Здесь скорее: «Смотрите, можно и вот так еще!» :)
Спасибо за славный генератор и приятные воспоминания о щенячем восторге, когда был обнаружен тот школьный портал.
Я не уверен, что это сработает (потому как особо не приходилось делать поп-апы), но, думаю, вполне может.
Вся страница (я только о коде .html файла говорю) весит 89 Кб. Если грохнуть ненужные элементы, то размер ее станет значительно меньше. Больше всего на хабре весят не комменты, а скрипты (283 Кб) да CSS-файлы (~ 98 Кб). Посему — не в ДОМе проблема.
<html> |--- <div id="wrapper"> |--- <div id="main-content"> |--- <div id="coments"> |--- <ul class="hentry"> |--- и понеслась нелегкая в виде элементов списка.Ничего такого уж сверхъестественного нету, на мой взгляд. В конце концов комментарии здесь не намного сложнее для отображения, нежели форумы, скажем. Разделяй и властвуй, что называется.
Вообще, я думаю, что разработчики Хабра знают о том, что нужна «хендхелд»-версия, но, как это обычно бывает в таких случаях, она оставлена на потом.
А в чем с комментами проблема? Вновь таки при помощи того же CSS-файла отменить их сдвиги, и разделять примитивной границей какой-то (ветка | следующая ветка | и т. д.), попутно «дисплеем: нон» чистить от всего ненужного. Вообще это может быть непросто, однако вполне реально, если задаться такой целью.
display:noneмногие браузеры понимают, что грузить элементы с этим свойством не нужно. Если говорить о мобильных, то Opera Mini ведет себя именно таким образом.media="hendheld", где отрубят лишний хлам, я думаю у них ничего не отвалится.Теперь по теме. Ко всему сказанному здесь, думаю, уместным будет добавить, что поддержка Оперой typeface.js не за горами. Я задался этой темой и нашел замечательный скрипт под названием Base2 и оповестил о нем разработчика. Думаю теперь этот момент — лишь дело техники. Таким образом вопрос кроссбраузерности будет решен.
Еще раз спасибо автору за труд.
habrahabr.ru/blogs/typography/23280/ :)
Насчет CSS. Думаю не будет, в связи с тем, что скрипт не призван превращать в изображение всю страницу. С несколькими же заголовками/цитатами/пунктами меню он управится. Можно даже привязать к визуальному редактору. Нужно лишь присваивать элементам класс, а остальные параметры регулируются обычынми инлайн-стилями.
meyerweb.com/eric/thoughts/2004/09/03/sliding-faux-columns/
На счет Оперы. Данный недостаток документирован и находится в списке «ТО DO» разработчика.
Я согласен, что скрипт сыроват, но не настолько, чтобы не написать о нем здесь. Если дело не заглохнет и человек будет заниматься этой штуковиной, то выйдет очень неплохой инструмент.
Вообще эта статья написана не с целью сказать: «Смотрите, есть замена sIFR!». Здесь скорее: «Смотрите, можно и вот так еще!» :)