SIFR или FLIR?
Недавно я столкнулся с фейслифтингом, альтернативой sIFR, и мне было интересно, могут ли те, у кого есть опыт работы с sIFR и FLIR, пролить свет на свой опыт работы с FLIR.
Для тех из вас, кто еще не читал о том, как FLIR это делает, FLIR работает, беря текст из целевых элементов с помощью JavaScript, чтобы затем вызывать приложение PHP, которое использует PHP GD для рендеринга и возврата прозрачных изображений PNG, которые размещаются как фон для указанного элемента, где переполнение затем устанавливается как скрытое, а заполнение применяется равным размерам элементов, чтобы эффективно вытеснить текст из поля зрения.
Вот что я понял до сих пор:
Добро
- Без вспышки (+ для мобильных)
- FLIR не нарушит макет
- Размер изображений варьируется от 1 КБ (например, одно предложение h3) до 8 КБ (очень-очень большой заголовок).
- Хорошая документация
- Легко реализовать
- Настраиваемые селекторы
- Поддержка jQuery / prototype / scriptaculous / mooTools
- FLIR реализовал кэш
- Браузеры кешируют сами изображения!
Плохо
- Текст не может быть выбран
- Запросы обрабатываются из всех источников (вам нужно ограничить FLIR обрабатывать запросы только из вашего домена)
Меня больше всего беспокоит, насколько хорошо он масштабируется, то есть насколько дорого стоит работать с библиотекой GD на общем хосте, есть ли у кого-нибудь опыт работы с этим ?; во-вторых, какую любовь поисковые системы получают к реализациям sIFR или FLIR, зная, что а) текст явно не скрыт, б) отображается только на движке JavaScript.
Ответы 5
Я знаю, что с sIFR, и я предполагаю, что с FLIR вы выполняете разметку так же, как обычно, но с дополнительным тегом класса или аналогичным, чтобы он мог найти текст для замены. Поисковые системы по-прежнему будут читать разметку как обычный текст, так что это не должно быть проблемой.
С точки зрения производительности: если вы просто используете это для заголовков (а это не заголовки, которые будут изменять загрузку каждой страницы), то кеширование изображений в браузерах, а также, предположительно, на диске сервера должно устранить любые проблемы с производительностью. . Просто убедитесь, что вы правильно настроили заголовки HTTP!
Поскольку FLIR - это ИЗОБРАЖЕНИЯ, а sIFR - это flash, я могу предположить, что использование sIFR было бы немного более ресурсоемким. Я не проводил никаких тестов, но это кажется логичным.
Поисковые системы ищут sIFR лучше, чем FLIR, потому что некоторые поисковые системы могут переходить к тексту флеш-документа.
да, sIFR потребует больше ресурсов на клиенте, но не на сервере, за что вы обычно отвечаете. FLIR будет тяжелее на сервере. Я думаю, что в обоих случаях поисковая система увидит нормальную разметку, поскольку javascript не будет запускаться.
действительно ли серверу проще создать флеш-документ, чем изображение? я бы так не подумал.
Расс, sIDE полностью клиентская сторона, поэтому сервер ничего не создает. Он просто обслуживает несколько статических файлов.
Чтобы прояснить это, sIFR использует ранее скомпилированный Flash, который получает параметры на стороне клиента. Таким образом, сервер не работает. Это именно то, что говорит Томхей ... В ЛЮБОМ СЛУЧАЕ ответ Расса верен в отношении документов Flash ...
В долгосрочной перспективе sIFR должен лучше кэшироваться, поскольку рендеринг выполняется на стороне клиента из одного единственного Flash-ролика. Текст Flash действует больше как текст браузера, чем изображение, и его легко стилизовать во Flash (разные цвета, вес шрифта, ссылки и т. д.). Вы также можете предпочесть качество текста, отображаемого во Flash, по сравнению с тем, которое отображается библиотекой изображений на стороне сервера. Еще одно преимущество заключается в том, что вам не нужен код на стороне сервера.
Google заявил, что sIFR в порядке, поскольку он заменяет текст HTML тем же текстом, но отображается по-другому. Я бы сказал, что то же самое и с FLIR.
Я мало что знаю о sIFR, потому что FLIR работал, и мне он "казался" лучше, чем Flash. Просто взглянув на Демонстрационная страница sIFR 3 beta, я заметил, что он, похоже, не реагирует на изменение размера текста в настройках браузера. То есть я увеличиваю размер шрифта в Firefox (ctrl- +) и перезагружаю страницу, заголовки остаются того же размера.
Для тех, кто знает sIFR, является ли это фактическим ограничением сценария или они просто неправильно сделали демонстрационную страницу?
Если он действительно не справляется с этим, я бы назвал это большим преимуществом для FLIR, который действительно работает таким образом. Людям с ослабленным зрением, которые не используют программы чтения с экрана, вероятно, не нравится, что размер текста не изменяется в соответствии с их предпочтениями.
Тем не менее, с первого взгляда на API sIFR вы сможете заставить текст с измененным размером работать в sIFR. Я считаю это исправлением ошибки, а не существенным недостатком метода.
Файлы Woff - лучшее решение.
http://www.fontsquirrel.com/tools/webfont-generator
Обратите внимание, что ответы, содержащие только ссылки, не приветствуются (ссылки со временем устаревают). Пожалуйста, отредактируйте свой ответ и добавьте здесь синопсис.
Куфон? cufon.shoqolate.com/generate