Worddoc: посмотрел в общем твой сайт. У меня эта проблема только на странице "обо мне" заметна. Там высота блока как раз больше чем высота экрана получается, так как часть контента скрыта внизу
Данияр Кудайбергенов: в зависимости от сложности задачи. По хорошему, главный человек (может быть любым из оставшихся трех) должен понимать примерно сколько стоит работа каждого участника. Если бэкенду надо только натянуть верстку на шаблон в вордпрессе, то платить ему за эту работу столько, сколько в среднем эта работа стоит на фрилансе.
Александр Логинов-Солоницын: проблема уже давно решена, так как есть ответ, помеченный решением. Искать лучший минификатор методом перебора не самое лучшее вложение времени.
Nekto_Habr: так составление палитры и основано на математике по сути. Есть определенные законы, по которым определяют сочетаемость цветов, например если визуально посмотреть на любой подход, то там будет гармоничное расположение точек на цветовом круге - хоть монохромное сочетание, хоть аналогичное и все прочие. В музыке также - можно наугад ткнуть по клавишам и получить аккорд случайный, но средствами математики, можно этот аккорд вычислить и не нажимая клавиш.
Дмитрий: у меня такой же шрифт используется и никаких проблем нет)
Там какие то специфичные для сафари псевдоклассы применены видимо, типа font-smoothing
А толщину шрифта не увидел с телефона)
Показалось что он просто прозрачнее там
Не совсем то, что нужно((
Я искал "математический" принцип для выбора этих цветов)
И на светлом и на темном фоне они должны быть достаточно контрастны, а так же сочетаться с цветами основной палитры
Nikita Schipilov: попробуй всетаки вручную написать transition: 0.6s )
либо выкладывай сам миксин)
еще как вариант попробуй на ховере только opacity менять без бэкграунда
Дмитрий КовальскийRyuk ...: "Но дело в том, я как программист, не хочу за каждым пуком обращаться к заказчику или аналитику для разъяснений. "
Вот для того, чтобы не обращаться каждый раз, все основное надо выспросить у заказчика на начальном этапе при первой встрече, а потом, если вдруг всплывет что то неожиданное, то можно и уточнить, но никак не делать на свое усмотрение, если конечно заказчик не дал вам карт-бланш на действия такого рода.
Возможно я не прав, но я стараюсь объективно смотреть на ситуацию. С одной стороны, не профессионал не сможет дать четкое определение тому, что он хочет получить, так как он не знает нюансов реализации того, что он задумал. Он может поверхностно описать и ткнуть пальцем в понравившийся дизайн. С другой стороны - разработчик хочет иметь документ, который регламентирует его работу и защищает его от новых хотелок клиента и "игр со шрифтами". Истина, как всегда, лежит по середине - работа делится на автономные модули, которые согласовываются и оплачиваются либо авансом, либо по факту выполнения. То что уже согласовано не может быть пересмотрено клиентом, кроме как за отдельную плату.
И еще такой психологический момент:
Когда клиенту выкатывается готовый продукт, у него возникает ощущение, что ему впаривают нечто сделанное по шаблону. Постоянный диалог с клиентом важен по той еще причине, что у него создается мнимое чувство того, что он контролирует процесс и стоит у руля. Соответственно, в случае каких либо недочетов, ему остается винить только себя, так как это он повелел сделать красную кнопку на зеленом фоне, несмотря на предупреждение разработчика о том, что обычно это плохая идея )
Назар Мокринский: еще вопрос немного не в тему)
А как обстоят дела с SimpleClever CMS?)
Искал в интернете инфу о скорости обработки запроса у разных CMS и наткнулся на вопрос на Тостере, где Вы рассказывали о своем творении , при этом приводя ссылку на SimpleCleverFramework (https://toster.ru/q/240249)
Почитал на гитхабе вводную часть информации и заинтересовался)
Дмитрий Ковальский: мы подбираемся ближе к истине)
Уже и ГОСТ становится вроде как ненужен (нахрена фрилансеру ТЗ по госту? Чтобы хранить в архиве рядом с ордерами на гарнитур генеральши Поповой?))
