Меня не устраивает тем, что с интерфейсами сайта и браузера я чаще всего работаю мышкой и потому использовать кнопку клавиатуры для этого неудобно. Думаю, у многих поведение схоже, отсюда и огромное количество расширений для браузеров и сайтов, добавляющих такой функционал.
Для себя определил два варианта:
— кодировать генератором (например, таким), когда результат нужен быстро;
— использовать генератор белки-шрифтелки, если нужно что-то посерьёзнее — к примеру, вырезать ненужные символы — в экспертном режиме есть опция «Base64 Encode, embed font in CSS».
В конце концов, после генерации следует удостовериться, что mime-type у закодированного шрифта проставлен в соответствии со спецификацией — application/font-woff (хотя Хром утверждает, что должно быть application/x-font-woff).
Нужно разделять необходимость в этой кнопке «Наверх» и проблемную вёрстку. Сама кнопка полезна тем, что не заставляя снимать руку с мыши позволяет быстро перейти к навигации, которая часто находится наверху длинной страницы.
С другой стороны, если использование этой кнопки недостаточно продуманно, возможны проблемы с небольшими экранами, с ненужными срабатываниями и так далее. Но это проблема не кнопки, а технологов!
Кнопку могло бы сделать лучше то, чтобы она везде работала одинаково, в форме функционала браузера, например.
Почти так.
Всё-таки Google Fonts отдаёт шрифт отдельным файлом, поэтому описываемый мной эффект может наблюдаться. Для его устранения у них есть js-инструмент WebFont Loader.
К тому же, вы даете гарантию, что разработчик, который будет поддерживать код после вас, поймет ваши пляски со шрифтами?
Если это не знакомый мне разработчик, гарантию не дам :)
Но способ задокументирую и уверен, что всё будет хорошо.
данная техника порочна, так как является не нужной оптимизацией и увеличивает размер страницы. Всегда есть вещи, которые можно было бы оптимизировать, чтобы извлечь бОльшую выгоду, чем от данного способа. Например, объединение картинок в спрайты, загрузка шрифтов до скриптов или объединение скриптов в один файл
Вообще, подключаемые шрифты увеличивают размер страницы сами по себе, а в этой статье я пишу только про эффект, с ними связанный.
Своим методом я не отменяю необходимость оптимизации других аспектов. Конечно, всё это — и даже больше — нужно делать, вырезать неиспользуемые символы в том числе.
Для примера к статье я использовал PT Sans Narrow с большим количеством символов, которые я, скорее всего, никогда не буду использовать. Но ничего не мешает мне на реальном сайте их все вырезать, как вы описали.
Да, base64 увеличивает размер шрифта, но gzip практически нивелирует разницу.
Конечно, можно. Это будет максимально доброжелательно для всех посетителей. При этом всё равно нужно указывать альтернативные версии шрифтов — вдруг браузер неверно определится.
В моём случае определять браузер оказалось нецелесообразно; тех, кому пришлось скачивать дополнительную версию шрифта, помимо woff, оказалось меньше половины процента.
К тому же, своим способом я постарался избежать вмешательств в серверную часть.
Пример, который находится по ссылке «Скачать исходные файлы», не готов к работе локально — браузер не сможет загрузить jQuery из-за протокольно-независимого способа загрузки и относительного пути от корня в качестве запасного, который также не работает на локальных фалах.
На самом деле, теперь схож с Тандербёрдом. Такие же большие «ушки» у табов и меню там же.
— кодировать генератором (например, таким), когда результат нужен быстро;
— использовать генератор белки-шрифтелки, если нужно что-то посерьёзнее — к примеру, вырезать ненужные символы — в экспертном режиме есть опция «Base64 Encode, embed font in CSS».
В конце концов, после генерации следует удостовериться, что
mime-typeу закодированного шрифта проставлен в соответствии со спецификацией —application/font-woff(хотя Хром утверждает, что должно бытьapplication/x-font-woff).С другой стороны, если использование этой кнопки недостаточно продуманно, возможны проблемы с небольшими экранами, с ненужными срабатываниями и так далее. Но это проблема не кнопки, а технологов!
Кнопку могло бы сделать лучше то, чтобы она везде работала одинаково, в форме функционала браузера, например.
Всё-таки Google Fonts отдаёт шрифт отдельным файлом, поэтому описываемый мной эффект может наблюдаться. Для его устранения у них есть js-инструмент WebFont Loader.
Если это не знакомый мне разработчик, гарантию не дам :)
Но способ задокументирую и уверен, что всё будет хорошо.
Вообще, подключаемые шрифты увеличивают размер страницы сами по себе, а в этой статье я пишу только про эффект, с ними связанный.
Своим методом я не отменяю необходимость оптимизации других аспектов. Конечно, всё это — и даже больше — нужно делать, вырезать неиспользуемые символы в том числе.
Для примера к статье я использовал PT Sans Narrow с большим количеством символов, которые я, скорее всего, никогда не буду использовать. Но ничего не мешает мне на реальном сайте их все вырезать, как вы описали.
Да,
base64увеличивает размер шрифта, ноgzipпрактически нивелирует разницу.В моём случае определять браузер оказалось нецелесообразно; тех, кому пришлось скачивать дополнительную версию шрифта, помимо
woff, оказалось меньше половины процента.К тому же, своим способом я постарался избежать вмешательств в серверную часть.
А за статью — спасибо!