Недавно я столкнулся с подтяжкой лица, альтернативой sIFR, и мне было интересно, могут ли те, у кого есть опыт работы с sIFR и FLIR, пролить свет на их опыт работы с FLIR.
Для тех из вас, кто еще не читал о том, как FLIR это делает, FLIR работает, беря текст из целевых элементов с помощью JavaScript, чтобы затем совершать вызовы в PHP-приложение, которое использует PHP GD для визуализации и возврата прозрачных изображений PNG, которые помещаются как фон для указанного элемента, где переполнение затем устанавливается в скрытое, а дополнение применяется равным размерам элементов, чтобы эффективно вывести текст из вида.
Это то, что я догадался до сих пор:
Добро
Плохо
Моя основная проблема заключается в том, насколько хорошо он масштабируется, то есть, насколько дорого работать с библиотекой GD на общем хосте, есть ли у кого-нибудь опыт ?; во-вторых, какую любовь делают поисковые системы для реализации sIFR или FLIR, зная, что a) текст явно не скрыт b) отображается только на движке JavaScript.
В долгосрочной перспективе sIFR должен кэшировать лучше, потому что рендеринг выполняется на стороне клиента, из одного Flash-фильма. Flash-текст больше похож на текст браузера, чем на изображение, и легко стилизовать текст внутри Flash (разные цвета, шрифты, ссылки и т. Д.). Вы также можете предпочесть качество текста, отображаемого во Flash, в сравнении с качеством, отображаемым библиотекой изображений на стороне сервера. Еще одно преимущество заключается в том, что вам не нужен код на стороне сервера.
Google заявил, что sIFR в порядке, поскольку он заменяет текст HTML одним и тем же текстом, но отображается по-разному. Я бы сказал, что это верно для FLIR.
Я знаю, что с sIFR, и я полагаю, что с FLIR вы выполняете свою разметку так же, как обычно, но с дополнительным тегом класса или аналогичным, чтобы он мог найти текст для замены. Поисковые системы все равно будут читать разметку как обычный текст, поэтому это не должно быть проблемой.
Производительность: если вы просто используете это для заголовков (и они не являются заголовками, которые изменят загрузку каждой страницы), то кеширование изображений в браузерах, а также, предположительно, на диске сервера должно устранить любые проблемы с производительностью , Просто убедитесь, что вы правильно настроили свои HTTP-заголовки!
поскольку FLIR – IMAGES, а sIFR – flash, я бы предположил, что для использования sIFR было бы более ресурсоемким. Я не выполнял никаких тестов, но это кажется логичным.
Поисковые системы поиска sIFR лучше, чем FLIR, потому что некоторые поисковые системы могут перейти в текст флэш-документа
Я не знаю много о sIFR, потому что FLIR работал, и он «чувствовал» меня лучше, чем Flash. Просто посмотрев на демо-страницу sIFR 3 beta, я заметил, что она не реагирует на изменение размера текста в браузере. То есть, я увеличиваю размер шрифта в Firefox (ctrl- +) и перезагружаю страницу, заголовки остаются того же размера.
Для тех, кто знает sIFR, это фактическое ограничение скрипта или они просто делают демо-страницу неправильно?
Если это на самом деле не справляется с этим, я бы назвал это основным преимуществом для FLIR, который работает именно так. Люди с ослабленным зрением, которые не используют программы чтения с экрана, вероятно, не понимают, что текст не изменяется по своему усмотрению.
Тем не менее, быстро взглянув на API sIFR, вы должны иметь возможность изменять размер текста в sIFR. Я считаю, что ошибка исправлена, а не существенный недостаток метода.
Файлы Woff – лучшее решение.