dom1n1k

Никак, если только не рассматривать вариант с картинкой.
Смириться, понять и пгастить.

Откровенно говоря, не нашел в описании задачи оснований для выбора ноута. За 60к можно купить отличный стационарник, который будет рвать равноценный ноут в пух и прах. Ноут это либо для передвижений (о которых у автора ни слова), либо для гламурных понтов. Нормально работать лучше на десктопе. И вдвойне не понимаю ноуты 17" - неудачный компромисс, который и таскать с собой тяжело, и стационарно использовать неудобно.

Возможно, применять к фоткам оператор Собеля (или подобный), потом Threshold и уже сравнивать результаты?

Хотя лично для меня намного более сложной проблемой представляется поворот неба, нежели шум на изображении.

Если плейсхолдер нативный, а не какой-то js-библиотечный прикрученный поверх - боюсь что никак.

Точно не знаю, но по ощущениям что-то кустарное (в 90-е годы многие западные шрифты русифицировались умельцами на коленке и потом это гуляло по рукам). Я бы не искал, а подобрал замену поприличнее :)

В общем-то ничем, только нужно помнить, что умолчальные паддинги сбросятся также у инпутов и кнопок (где они все-таки нужны). То есть для всех кнопок нужно будет вручную прописывать высоту и/или паддинги. Но я бы не назвал это недостатком, поскольку часто это всё равно делается так и так. Это просто особенность подхода.

В текстовых файлах.

Попробуй инпуту и кнопке принудительно указать одинаковый шрифт (или просто обоим inherit). По дефолту он не равен шрифту у body.
Теоретически, разный шрифт и разная высота базовой линии могут раздвигать.
Кроме того, я бы отделил подпись "введите номер телефона" в отдельный блок, чтобы она не мешала своей базовой линией.

Практически никак. То есть какие-то отдельные проблемы решить можно (запретить зум мета-тегом, запретить все лишние скроллы), но в целом все равно ощущения цельного, нативного приложения не будет. Обязательно будет что-то съезжать, ворох анимаций будет тормозить... Будет суррогат ни рыба ни мясо.

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

Сам проходил Jade и тоже остался им не совсем доволен. Были плюсы, но были и минусы и в целом выходило не лучше, а просто как-то по-другому. Тоже смотрел на альтернативы, и они нравились ещё меньше.
Twig и ему подобные - кмк, хороши в качестве шаблонизаторов, но не HTML-препроцессора, то есть тоже мимо.
Так что вернулся на голый HTML. Можно опционально добавить Emmet, но у меня как-то не пошёл он.
А потом оказалось, что циклы хорошо реализуются в Angular/React/Vue (подчеркнуть нужное по вкусу), так что прикручивать ещё и препроцессор стало вообще лишним.

Ну очевидный вариант - Ютуб. Если он по каким-то причинам (например, не устраивает сторонняя реклама) не подходит, то...

Если набор видеороликов будет небольшой и фиксированный (т.е. их можно заранее все подготовить и дальше только показывать), то выгоднее всего свой сервер. Физический или в облаке, это уже кому как больше нравится.

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

Спросить - нормально.
Не ответить - тоже нормально.
Обидеться, что не ответил - ненормально.

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

Если исходная картинка имеет приличный запас по разрешению, то вполне рабочий выход - делать масштабирование в несколько этапов, чтобы на каждом шаге коэффициент был 2 (кроме, возможно, одного). Я так делал, результат получается действительно намного лучше.
Если же исходная картинка не сильно больше требуемой - канвас, увы, не вариант, он будет сильно портить картинку. Нужно использовать что-то совсем стороннее.

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

Например, если выбрать в карточке сотрудника пол "мужской", то полю "дата последнего гинекологического осмотра" я бы поставил атрибут disabled.

Даже не знаю, как еще объяснить, по-моему всё предельно очевидно.

Лучше, конечно, не иди туда - освободи место для того, кто этого хочет.

1. Разделяем отзывы на прямые ("А отличный, Б плохой") и относительные ("А лучше Б").
2. Присваиваем прямым отзывам некие оценки.
Например: ужасно 0, плохо 1, так себе 2, нормально 3, хорошо 4, отлично 5.
Вычисляем среднюю по каждому товару.
3. Аналогично присваиваем некие коэффициенты относительным отзывам.
Что-то типа такого: намного лучше x2, лучше 1.5, слегка лучше 1.25, слегка хуже 0.8, хуже 0.6, намного хуже 0.4.
Вычисляем среднее для каждой пары товаров.
4. Складываем все в кучу с некими весовыми коэффициентами: прямую оценку самого товара и оценки всех конкурентов/аналогов, помноженных на относительные коэффициенты.

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

То, что GF отдал css-файл с кучей языков, включая вьетнамский - это нормально.

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

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

В свое время эта фича убила у меня несколько часов отладки:
Почему может не работать знак рубля в iOS?
Это был момент, когда Хром уже поддерживал автовыбор субсетов, а Сафари - ещё нет. Соответственно моя ошибка проявлялась только на Сафари и оттого казалась глюком.

Короче, всё нормально, оставь GF в покое.

Значит приходят свойства нестрокового типа.
Выводи их в консоль и смотри что там за данные.
Может там какие-нибудь undefined.