Почему font size не работает

Font size бесполезен, давайте это исправим

Что происходит, когда вы указываете в редакторе «font_size»: 32 ? Я бы вам всё равно рассказал, но хорошо, что спросили.

Попробуем догадаться. Я пользуюсь Sublime Text 4 под macOS:

Если мы измерим сами буквы, то нигде не найдём числа 32:

32 — это не ширина и не высота буквы, и не высота заглавной буквы, и не рост строчных знаков, и не высота верхних или нижних выносных элементов. Что за дела?

Пункты

Во-первых, это размер не в пикселях, а в пунктах. Пункт — физическая единица измерения, равная 1⁄72 дюйма (0,353 мм), она берёт начало из типографики.

Смысл здесь в том, чтобы задавать размер шрифта непосредственно в физических единицах, опуская такие мелочи, как разрешение экрана. Если я хочу, чтобы буквы имели высоту 2 дюйма, то я задаю размер шрифта в 144 pt.

На практике никто этого не делает. Вместо этого для преобразования пунктов в пиксели macOS всегда использует 72 PPI (points per inch, пункты на дюйм). Если вывести macOS на 32-дюймовый и на 24-дюймовый мониторы с одинаковым разрешением 1080p, то мы получим одинаковый размер в пикселях, а не физический размер, что разрушает весь смысл исходной идеи.

Почему число 72? Оказывается, в первых Mac использовались дисплеи с разрешением изображения ровно 72 PPI. Если просматривать на них текст, то его физический размер на экране совпадёт с физическим размером при печати. Удобно! Разумеется, с тех пор разрешение PPI дисплеев Mac повысилось, но традиция сохранилась.

В духе истинного сотрудничества, Windows использует не 72, а 96 PPI. Почему не 72? Не потому, что у компьютеров были дисплеи получше (это не так), а потому, что 72 давали слишком мало пикселей для рендеринга читаемого текста. Поэтому проектировщики решили: почему бы не сделать всё на ⅓ крупнее?

Так они и поступили. Этот стандарт сохраняется и по сей день: текст размером 16 pt в Windows на ⅓ крупнее, чем текст 16 pt в macOS. Весело!

Один и тот же шрифт, одинаковый размер в пунктах, без относительного масштабирования

P.S. Похоже, VS Code берёт значение editor.fontSize напрямую в пикселях. Отличное начало!

Квадрат Em

То есть пользователь, запрашивающий шрифт 32 pt, на самом деле требует 32 пикселя (px) в macOS и 43 px в Windows. Но эти числа всё равно нигде не встречаются.

Так происходит, потому что font-size задаёт так называемый размер «em».

В традиционной печати металлическими литерами размер em — это высота литеры символа (её кегль).

Почему высота называется «размером em»? Потому что так совпало, что буква «m» имеет квадратные размеры, а ширина «m» == высоте литеры символа == размеру em. Всё просто!

Однако в цифровой типографике «квадрат em» — это (цитата из Википедии):

сетка произвольного разрешения, используемая как пространство для дизайна цифрового шрифта.

То есть если я открою свой шрифт Fira Code и начерчу em square, то он не будет вообще ничему соответствовать:

Если вкратце, этот квадрат и есть то чем вы управляете при задании размера шрифта. Если задать размер шрифта 32 pt, то этот квадрат будет иметь ширину/высоту 32/43 px. К сожалению, он невидим и ему не соответствует ни один элемент шрифта.

Проблема

Когда я говорил, что em size совершенно произволен и не связан ни с чем в шрифте, это не было преувеличением. Он действительно не связан!

Это означает, что если задать разным шрифтам одинаковый размер, то внешне их размер может значительно различаться. Например, если сопоставить em square (то есть задать одинаковый размер шрифта) двух разных шрифтов, то мы получим очень разную высоту «m»:

Ещё один пример. Все эти шрифты имеют одинаковый размер — 22 pt:

Я считаю, что размер шрифта обладает следующими проблемами:

• Непредсказуемость: невозможно угадать, что ты получишь. 16 pt — это сколько пикселей?
• Непрактичность: невозможно получить то, чего хочешь. Хочешь, чтобы буквы были высотой 13 пикселей? Не получится.
• Нестабильность. Переключаемся на другой шрифт, оставляем тот же размер, получаем более крупные/мелкие буквы.
• Зависимость от ОС. Получаем разный рендеринг при открытии документа на разных ОС. Нельзя использовать одинаковые конфигурации редактора в macOS и Windows.

Решение

• Указывать высоту прописных букв, а не размер em square.
• Указывать её в пикселях.

Именно прописные буквы человеческий глаз воспринимает как границу текстового блока. Поэтому логично управлять их размером, а не какой-то произвольно выбранной метрикой:

Вот несколько шрифтов, для которых задан одинаковый размер шрифта:

А вот те же шрифты, но с размерами, подогнанными под высоту прописных букв:

На мой взгляд, последний вариант обеспечивает гораздо большую целостность. Например, взгляните на Cascadia и Consolas. Или Hack и IBM Plex Mono. Или Ubuntu Mono и Victor Mono (два последних шрифта).

С высотой строки тоже есть неразбериха

Если уж мы начали говорить об этом, то почему бы не исправить и высоту строки? Не волнуйтесь, это будет быстро.

Во-первых, очевидно, что отсутствует консенсус. Каждый делает что-то своё:

Почему? Проблема высоты строки в том, что она вычисляется по тем же абстрактным границам символа:

Такой стандарт был логичен для металлических литер. В конце концов, нельзя сделать строку меньшей высоты, чем тело литеры:

Но в цифровой типографике это совершенно нелогично! Как и в случае с размером шрифта, количество пустого пространства над и под буквами может быть абсолютно произвольным.

Некоторые шрифты добавляют пространства, другие выделяют ровно столько, чтобы хватало на верхние и нижние выносные элементы:

Но даже второй вариант нас не устраивает! Верхние и нижние выносные элементы не влияют на размер воспринимаемого визуально текстового блока. Строго говоря, разумеется, минимальная высота строки должна без пересечений включать оба вида элементов, но с точки зрения эстетики этот выбор далеко не идеален.

Учитывая ту степень свободы, которую имеют дизайнеры шрифтов при задании границ символов, попытки добиться постоянной высоты строки — это игра в угадайку.

Предсказуемая высота строки

Что же нам делать? Разумно было бы задавать высоту строки непосредственно в пикселях, игнорируя все метрики шрифтов. Или же как процент от высоты прописных букв, но совершенно точно не через font-size или «автоматическую» высоту строки!

Ещё один важный совет: никогда не указывайте высоту строки как пробел между строками (в традиционной типографике это называется «сдвигом»). В противном случае, два разных размера шрифта разрушат ритм параграфа:

Вместо него нужно использовать расстояние между базовыми линиями:

Кроме того, я не вижу никаких причин удостаивать почестей так называемую «стандартную высоту строки». По сути, это личное предпочтение дизайнера шрифта, задаваемое для каждого пользователя шрифта в любых условиях просмотра. Оно может быть любым числом (а часто так и есть)! Но 200% от высоты прописных букв — это всегда 200%.

Подведём итог: вот что есть сейчас — при изменении шрифта мы получаем случайную высоту строки:

А вот чего хочу я: при изменении шрифта все строки остаются точно там же, где и были:

Кажется безумием, что имея все эти компьютеры, мы по-прежнему столь привязаны к особенностям, возникшим в «металлический» век шрифтов.

Эндшпиль

То, чего я пытаюсь достичь всеми этими предложениями, легко показать на одном примере:

1. Я один раз задаю в своём редакторе нужные мне размер шрифта и высоту строки.
2. Я могу попробовать разные шрифты.
3. Мне не нужно перенастраивать размер шрифта и высоту строки каждый раз, когда я меняю шрифт.

Примерно так (высота прописных букв и высота строки в точности совпадают):

Интерфейс моей мечты:

Второй пример использования тоже довольно прост: мне нужен предсказуемый и надёжный способ центрирования текста на кнопке.

Это всегда было проблемой для веба, но недавно эту болезнь подхватила и macOS:

Учитывая то, что мы не всегда можем управлять выбираемыми для рендеринга страницы шрифтами, отсутствие инструмента для надёжного выравнивания текста кажется недоработкой.

Ссылки

Getting to the bottom of line height in Figma. Приключения Figma в поисках компромисса между тем, что нужно людям и что делает веб.

Deep dive CSS: font metrics, line-height and vertical-align. Превосходная статья, демонстрирующая, как конкретно работает алгоритм высоты линии шрифтов и CSS. Кроме того, обратите внимание, что я не единственный человек с ужасным цветом фона на веб-сайте.

Capsize. JS-библиотека, позволяющая делать уже сегодня именно то, что я описал в этой статье, учитывая ограничения веба.

Leading-Trim: The Future of Digital Typesetting. О том, как leading-trim (то есть примерно то же, что и высота прописных букв) может упростить жизнь каждого.

На правах рекламы

VDS для размещения сайтов — это про наши эпичные! Все серверы «из коробки» защищены от DDoS-атак, скорость интернет-канала 500 Мегабит, автоматическая установка удобной панели управления VestaCP для размещения сайтов. Лучше один раз попробовать 😉

Источник

Не изменяется размер шрифта через CSS

Всем привет!
Я тут новичок и совсем начинающий пользователь веб-разработки.

Вопрос, собственно вот в чём:

При указании в подключенном к html-документу файле CSS для тега размера шрифта:

Он не работает. Шрифт не изменяется по своему размеру. Но если в «голове» уже самого html-документа поставить:

То размер шрифта внутри ссылок уже меняется.
В принципе, если оставить как есть, то всё в порядке. Но мне интересно, с чего вдруг размер шрифта нельзя поменять через CSS-файл? Такого же вроде как не должно быть, таблицы стилей для того и существуют, чтобы не в хэде всё писать?

Подскажите, как через CSS-файл поменять размеры шрифта? Испробованы уже все размерности (пиксели, пункты, относительные размерности и т.д.), но толку никакого.

Помощь в написании контрольных, курсовых и дипломных работ здесь.

Почему размер шрифта не изменяется?
Почему не меняется размер шрифта, указанный в процентах? Также подключил javascript вот этот.

Изменяется размер шрифта в разных браузерах
Добрый день! Подскажите, почему в Хроме шрифт нормально отображается, а в Мозиле и Эксплорере.

Не изменяется размер шрифта, его цвет
Не изменяется размер шрифта, его цвет, меняю значения font, убрала жирность, но все равно изменений.

Как поменять размер шрифта в css?
Здравствуйте никак не могу поменять размер шрифта в css,кто подскажет как именно поменять? Нашел в.

Источник

Проблемы CSS. Часть 1

Впервые css был представлен примерно в 1995 году, и был предназначен для стилизации простых текстовых документов. Не веб сайтов. Не приложений. А именно текстовых документов. С тех пор, css, прошел долгий путь. Возможно слишком долгий.

Для многих вещей, css, не был предназначен изначально, например для таких как: многоколоночность, отзывчивый веб дизайн и т.д. Вот почему он стал языком полным хаков и глюков, как какая-то древняя машина с кучей расширений.

В лучшем случае — работу с css можно назвать веселым занятием. И это то, благодаря чему мы имеем работу. Потому что, как я считаю, генерация эффективных и кроссбраузерных css стилей невозможна и не будет возможна в ближайшее время.

Перейдем к сути, ведь я здесь не для того, что бы высказать свое мнение о css. А для того, что бы рассмотреть ряд часто встречающихся в css проблем, и их возможных решений.

Я старался выбрать несколько действительно очень распространенных:

• Очистка float`ов.
• Как победить отступы между элементами с inline-block?
• Понимание абсолютного позиционирования.
• Когда использовать width / height равный 100% (часть 2)
• Как не облажаться с z-index. (часть 2)
• Что такое свертывание границ(margin collapsing)? (часть 2)

Очистка float`ов.

Мне кажется, что это самый распространенный вопрос в css. Он стар как мир, честно, я на тысячу процентов уверен, что каждый, кто хоть когда нибудь писал на css сталкивался с ним.

Простыми словами его можно описать так: когда внутри элемента содержатся только элементы с float, он схлопывается так, как будто в нем вообще нет дочерних элементов. То есть, по факту, элементы с float выпадают из общего потока.

Есть несколько способов для решения этой проблемы. Раньше мы использовали пустой div со стилем «clear: both» в самом низу контейнера. Затем, мы заменили его на тег hr, что не на много лучше.

И наконец Nicolas Gallagher предложил новый путь очистки float`ов без необходимости трогать разметку совсем. После продолжительных дискуссий и тестов, мы получили минимально необходимый, для его работы, набор стилей, вот его последняя версия:

На самом деле я солгал, она не последняя, она самая короткая. Но если вам нужна поддержка IE 6/7, то вам нужно добавить еще вот это:

Для работы необходимо добавить класс .clearfix в свой проект, а затем применять его к элементам разметки. Это самый простой и чистый способ для работы с float`ами.

Как победить отступы между элементами с inline-block?

Продолжим с размещением элементов в строку, в этот раз не с помощью float, а с помощью inline-blocks. display: inline-block долгое время был недооценен, и все же мы разобрались, как он работает и почему это круто. Сегодня, все больше и больше front-end разработчиков предпочитают использовать inline-block взамен float`ов, когда у них есть такая возможность.

Главный плюс inline-block в том, что нам не приходится отчищать float`ы и мы не сталкиваемся с другими проблемами которые могут возникнуть из-за элементов спозиционированных с помощью float`ов. Просто установив свойство элемента display в значение inline-block получим гибрид строчного элемента и блока. Они могут иметь размер, отступы, но их ширина, по-умолчанию, зависит от контента, а не занимает всю ширину родителького элемента. Таким образом они размещаются горизонтально, а не вертикально.

Вы можете спросить: «В чем же тогда проблема?». А проблема в том, что они на половину строчные, а значит имеют отступ друг от друга размером равным пробелу. Со стандартным шрифтом размером 16px, он составляет 4px. В большинстве случаев размер отступа можно рассчитать, как 25% от размера шрифта. Так или иначе, это может помешать нормальному расположению элементов. Например, возьмем контейнер размером в 600px с тремя элементами внутри, размер которых 200px и задано свойством display: inline-block. Если не убрать отступ, то нам не удастся разместить их в одну линию (200 *3 + 4 * 2 = 608).

Есть несколько путей, как убрать ненужный нам пробел, каждый со своими плюсами и минусами. Если честно, то пока нет идеального решения. Давайте взглянем на все по очереди!

Уровень разметки: удаление пробелов

Для всех наших тестов воспользуемся следующей разметкой.

Как я уже говорил ранее, дочерние элементы не станут в одну линию, потому что есть дополнительный символ пробела между каждым из них (в нашем случае перевод строки и 4 пробела). Первый способ решить проблему — полностью удалить пробелы.

Это действительно работает, но делает не удобным чтение нашего кода. Хотя, мы можем, немного реорганизовать наши элементы, что бы сохранить читаемость:

И если быть уж совсем крутым, можно сделать и так:

Да — это работает! Конечно я не рекомендую такой подход, потому что он не интуитивен и делает код уродливым. Давайте, лучше, попробуем, что нибудь еще.

Уровень разметки: комментируем пробелы

Что если закомментировать пробелы вместо того, что бы удалить их?

Да, так гораздо лучше! Код читаем и работает. Да, способ выглядит не привычно на первый взгляд, но не так и сложно к нему привыкнуть. Я и сам использую такой способ, когда мне надо удалить пробелы между элементами с inline-block.

Конечно, кто-то скажет, что это не идеальное решение, так как оно работает на стороне разметки, а проблема должна быть решена на уровне css. Действительно. Большинство из нас на самом деле используют css решения.

Уровень css: расстояние между символами

Свойство letter-spacing используется для задания отступов между символами. Идея заключается в том, что бы установить отступ таким, что бы он нивелировал отступ между нашими элементами, затем, нам придется сбросить letter-spacing для дочерних элементов, что бы текст в них выглядил нормально.

Эта техика используется в Griddle — основанной на Sass системе сеток за авторством Nicolas Gallagher, так что, как вы видите, это достаточно серьезное решение. Хотя, честно говоря, мне не нравится тот факт, что мы полагаемся на магичиские числа в стилях. Плюс с некоторыми шрифтами, это число может меняться например на 0.31em и т.д. То есть, его необходимо подгонять под каждый конкретный случай.

Уровень css: отрицательный margin

Еще один подход к решению задачи, очень похож на предыдущий, но с использование отрицательного отступа. Главный его недостаток он не работает в IE 6/7. Плюс нам необходимо убрать отступ с первого элемента, что бы они ровно встали внутри нашего контейнера.

Если вам не требуется поддержка IE 6/7, я считаю что это достаточно неплохе решение.

Уровень css: font-size

Ну и на последок, вы можете установить размер шрифта родительского блока в 0, что бы сделать пробел равным 0px, а затем восстановить размер шрифта для дочерних элементов.

У этого решения есть несколько своих проблем и ограничений:

• Вы не сможете восстановить шрифт для дочерних элементов используя em как размер шрифта
• Пробелы не удаляются на устройствах с Android до Jellybean
• Текст с использование @font-face может потерять сглаживание в Safari 5
• Некоторые браузеры игнорируют font-size: 0, например Китайская версия Chrome, в таком случае font-size сбрасывается до 12px

Так что, это не лучшее решение. Как я уже говорил ранее, скорее всего буду использовать путь с комментирование пробелов. Если для вас он выглядит неудобным, вы можете вернуться к float`ам или же вообще использовать flexbox.

Понимание абсолютного позиционирования.

Позиционирование элементов — каверзный процесс и всегда им был. Позиционирование, начинающим, дается с большим трудом. Они часто (не)используют свойство position. Это свойство определяет как элемент может перемещаться с помощью смещений (top, right, bottom and left). И принимает следующие значения:

• static — по-умолчанию, смещения не действуют
• relative — смещения двигают визуальный слой, но не сам элемент
• absolute — смещения двигают элемент внутри контекста (первый не static элемент)
• fixed — смещения позиционируют элемент внутри viewport`a и не важно где он расположен в документе

Проблемы появляются при использовании position: absolute. И наверняка вы с ними уже сталкивались: вы определили элемент с абсолютным позиционирование, потому что хотите, что бы он был в верхнем правом углу своего родителя (например кнопка закрыть у модального окна).

… а он оказывается в верхнем правом углу документа. У вас промелькает мысль «Какого черта?». На самом деле, это нормальное поведение браузера. Ключевое слово тут контекст.

Код выше просто говорит: «Я хочу что бы мой элемент был спозиционирован в верхнем правом углу контекста». Так что же такое контекст? Это первый элемент со свойством position не равным static. Это может быть непосредственно родительский элемент, или родитель родителя, или родитель родителя родителя. И так до первого элемента с position != static.

Эта концепция часто оказывается сложной для понимания новичками, но когда вы ее поняли она открывает обширные возможности по работе с элементами спозиционированными абсолютно.

Небольшая демка иллюстрирующая вышесказанное. Два родителя, в каждом по одному дочернему элементу спозиционированному абсолютно со смещение top: 0 и right: 0. Слева правильный родитель с position: relative, справа неправильный с position: static.

Источник