dom1n1k

Если говорить об альтернативах с более-менее ощутимой популярностью, то мне известны три:
- Semantic UI
- Foundation
- Bulma

Ключевые слова в сообщении об ошибке - "cross-origin data".
Это стандартная и многократно описанная проблема. На тостере тоже была неоднократно.
Просто погуглите "canvas cross-origin".

line-height: auto - это значит дефолтный интерлиньяж, прописанный внутри шрифта. Да, в большинстве случаев он составляет около 120-130%, но не обязательно. Это значение не регламентировано никакими стандартами и может плавать (в некоторых случаях даже очень сильно плавать).

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

Замени Chrome на ungoogled chromium или хотя бы Brave. А хром, если стоит задача сохранять такою приватность, нужно вообще удалить с компьютера. Там и телеметрия, и сложно отключаемая служба обновлений, и встроенный антивирус(!!!), который шарит по твоему диску.

В фотошопе/авокоде прописываются размеры шрифта и высоты строки, всегда учили отнимать от второго первое, делить на два и вот вроде разница, которую нужно учитывать, но на практике это всё равно дает погрешность.

Да, погрешность будет, потому что реальная высота букв не равна font-size, она меньше. А font-size - это размер кегельной площадки, то есть включая запас на всевозможные выносные элементы (заплечики). Реальная высота букв варьируется от шрифта к шрифту, но в среднем по больнице заглавную и строчную можно грубо принять за 70 и 50% от font-size соответственно. Если хочется абсолютной точности, можно специальными инструментами выяснить эти величины для конкретного шрифта.

Но вообще этим вычислениям пора кануть в лету, потому что ФШ (с его неудобным для верстальщика управлением текстом) уходит со сцены веб-дизайна. В новых приложениях типа Фигмы и Скетча такой проблемы нет, там высота контейнера текста равна line-height, поэтому ничего вычислять не нужно - сколько отступ есть, столько и делаем.

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

Вы сами себе придумали проблемы на ровном месте.

Трекинг у Adobe указывается в тысячных долях em. Указываете letter-spacing и всё. Проще всего в em, но можно и в px пересчитать. В чём проблема?

Кернинг который Optical, вручную никогда не делается, используется то самое свойство font-kerning - и всё, дальше браузер разбирается сам. Несколько процентов браузеров его не поддерживает - ничего страшного, это не влияет на функциональность, поэтому graceful degradation.
В крайне редких случаях (почти никогда) может использоваться ручной кернинг, например, для создания какого-то специального декоративного эффекта. Для этого есть js-библиотеки, которые помогают манипулировать буквами. Опять-таки особой проблемы тут нет, потому что никто не применяет это к большим объемам текста, только к очень крупным заголовкам.

То что текст может переноситься на другую строку не совсем так, как было в макете - это совершенно нормально и это всегда нужно учитывать. Если верстка ломается от непредсказуемого переноса, то это глючная верстка.
Pixel perfect для текста невозможен по определению, разные системы рендерят его по-разному (но вполне возможен на уровне блоков).

Я понимаю, приятно побухтеть в кулуарах на тему вот мы дартаньяны, а они нет :) Но в данном случае ничего такого особенного дизайнер не сделал, абсолютно рабочие параметры.

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

Открыл дев-тулзы, посмотрел что вы там крутите, и в глаза бросились ваши спрайты - их 11 штук и каждый размером 2000x2000px. Кажется, это дофига.
Я не знаю, в чем именно ваша проблема. Но подозреваю, что внутри мобильного Safari задан некий лимит памяти на 1 вкладку, при превышении которого браузеру велено проводить агрессивные оптимизации даже ценой ущерба для точности. Не то чтоб я это оправдываю, но выглядит похоже на то.
Ну и простой вопрос: зачем вам на мобиле текстура аж 2 тыщщи пикселей? Одной тысячи разве не хватит?

MS Office срет в реестр настолько широко и обильно, что если для вас принципиально важно вычистить абсолютно всё - боюсь, вас спасет только чистая установка Windows.

Всё так и есть, по-хорошему экран должен использоваться только в масштабах с целой кратностью - то есть либо 100, либо 200%, все остальные будут заметно хуже. Но правда, хуже тоже по-разному - "полукруглый" масштаб 150 выглядит всё-таки получше, чем 125 или 175.

Выкинуть нахрен все маски. Пусть пользователь заполняет телефон в произвольном формате - со скобочками или без, через пробел или дефис, да хоть через двоеточие.
Единственное, что стоит проконтролировать - это общее количество цифр (чтоб не меньше нужного) и наличие/отсутствие плюса (для понимания формата). Всё.
Дальше на стороне сервера все посторонние символы вычищаются, остается только номер.

Мой первый опыт с тогда ещё Jade - это где-то лет 6 назад. И был он, мягко говоря, спорный. Отчасти понравилось, но больше всё-таки нет. Были проблемы, которые многократно перекрывали экономию от укороченного синтаксиса. Я писал где-то на Хабре комментарий на этот счет. В общем, забросил.

Потом несколько раз возвращался и постепенно пришел к выводу, что если наловчиться, то некоторую пользу всё-таки извлечь можно. И важно, что со временем авторы пофиксили некоторые проблемы. Это не значит, что я полюбил Pug, но хотя бы смог использовать его без постоянного раздражения.

Какие именно плюсы? Якобы более чистый код с отступами, отсутствие закрывающих тэгов - это всё ерунда. Может и достоинства, но точно минорные. Главное функционал, полностью отсуствующий в нативном HTML: миксины, автогенерация однотипных блоков, наследование шаблонов. Этого правда не хватает.

Но есть два но.
1. Подобный функционал есть в любом другом шаблонизаторе? Верно. И я посмотрел несколько (нунчаки, slim, haml, дуст). И везде я сталкивался с какими-то раздражающими нюансами или чего-то не хватало. А раз святой грааль не был найден, то я не нашёл для себя аргументов для смены шила на мыло.
2. Мне удобнее решать такие вопросы на фронте. Если вам удобнее делать всё то же самое в PHP - тогда да, выходит, что особого смысла нет.

На том ведре работать будет нельзя.
Во-первых, 4 гб оперативки очень мало (один ФШ столько съест и еще попросит). Сейчас абсолютный прожиточный минимум 8, а рекомендуется 16+.
Во-вторых, у дешевых ноутов катастрофически медленные диски.
И лучше собрать за похожие деньги десктоп с нормальным (а не 1366*768!) монитором.

Дмитрий Кирсанов, "Веб-дизайн".
Книге скоро стукнет 20 лет, так что во всех технических разделах она безнадежно устарела.
Но разделы, посвященные теории - вне времени и изложены очень хорошо.

Я бы не переключал два текста на одной кнопке, а сделал бы две разные кнопки.
Ну потому что "Заказать сейчас" и "Узнать больше" - это разные функции и ведут они куда-то в разные места.

Использование размера шрифта в vw (в чистом виде, без calc) - это плохая идея.
Во-первых просто нет смысла. Во-вторых, в браузере перестает работать Ctrl+/-

Алгоритм примерно такой:
1. Картинки переводятся в пространство CIE Lab. Можно предварительно их уменьшить для ускорения (хотя с уменьшением там свои нюансы).
2. Все имеющиеся на картинке цвета кластеризуются и выделяются 2-3 доминантных кластера. Алгоритмов кластеризации очень много, читайте википедию.
3. Похожесть доминантных цветов двух картинок определяется по формуле DeltaE, она тоже есть в википедии. Можно не заморачиваться с продвинутой версией DE2000, скорее всего будет достаточно обычной DE1976.