Я сейчас перечитал вопрос автора и понял, что он сформулирован расплывчато, и каждый может понять его по своему. Объясню подробнее, в каких случах спрашивать бюджет можно и нужно.
Неважно, фриланс у нас или не фриланс. Важно, насколько задача конкретна или, напротив, расплывчата.
Поменять розетку - это очень конкретная задача, её цена в зависимости от подробностей меняется в довольно ограниченных пределах. Исполнитель задаст несколько уточняющих вопросов и без проблем выставит конкретную оценку.
Теперь представим, что заказчик приходит с задачей "построить дом". Это очень нечёткая задача. Какой дом? Их может быть миллион вариантов с разбегом по цене в несколько порядков. В этом случае вопрос о бюджете - это не обязательно признак деньгоотсоса. Это попытка исполнителя сориентироваться, в какой сегмент рынка смотреть, что предлагать клиенту и какие обозначить клиенту ограничения.
Теперь ситуация из IT и личной практики. Клиент говорит, что он торгует такими-то товарами и ему нужен сайт. Какой сайт?! Лендос-визитка или полноценный магазин с полной обработкой заказа и интеграцией с 1С?! Сложность, стоимость и сроки этих вариантов различаются многократно. А клиент поначалу и сам не знает. Точнее, он хочет всё и сразу, но совершенно не понимает, во что ему это обойдется. В этой ситуации спросить ориентировочный бюджет, на который рассчитывают - это нормально.
Разумеется, если клиент четко понимает, чего хочет, данный подход не работает. Но таких мало.
Так и я про то. Ввод телефона через маску не помогает пользователю, а наоборот мешает, потому что в ней нужно разбираться.
При этом трудно даже понять - а в чём собственно проблема у разраба? Ведь очистка номера от лишнего мусора ну ваще легко делается, одна регулярка.
Единственная полезная помощь - указать инпуту type="tel", чтобы смартфоны показали нужную клавиатуру.
Горизонтальный скролл там будет появляться совершенно ожидаемо. Именно поэтому я и написал в соседнем ответе, что это не очень корректное решение. Причина в том, что 100% != 100vw.
В любом, если речь идет о младших позициях в рядовых компаниях. Ну, при условии, что вакансия у них вообще имеется.
Разумеется, если вы хотите в крутую контору на крутую з/п - всё иначе.
Senseich, лично я пишу сгруппированные селекторы до.
Важно отметить один момент. Я группирую селекторы только в том случае, если значения общих свойств не просто равны, а тождественно равны. И группировкой я не столько экономлю пару строк кода, сколько подчеркиваю: равенство значений - не случайное совпадение, а следует из логики макета.
Условно говоря, у меня есть логотип и меню и они имеют одинаковую высоту 100px. Указав эту высоту для них вместе, я подчеркиваю, что они обязаны быть равными по высоте всегда и нельзя менять им высоту раздельно.
Я бы написал ниже. Любые составные селекторы (вложенность, плюсовый и тп) всегда пишу ниже первых упоминаний всех составных частей. Не может, например, p + p идти выше, чем p - только ниже.
Senseich, "ничего не знает о том, что происходит снаружи" - это концепция, по которой компоненты должны обладать только необходимым минимумом информации друг о друге. Чем меньше компонент знает лишнего, чем меньше он полагается (явно или неявно) на эти знания, тем более он независим и легче поддается модификации в будущем.
Как правило, блок/элемент обладает информацией о своих потомках (ну потому что это его потомки, он ими управляет), но не должен ничего знать о вышестоящем уровне. И даже о своих братьях (блоках/элементах с того же уровня в дереве), по возможности, лучше ему не знать.
Сергей delphinpro, Неа. Назначить-то класс на ссылку нормально, но не в этом случае.
Модификатор first для item уместен, потому что итемов в меню пять и среди них есть первый и последний. Ссылка внутри своего итема - одна, всегда одна. Это чисто класс оформления ссылки, она не знает что там творится извне. И совершенно нормально тут написать так:
.top-menu__item_first .top-menu__link {
...
}
Тут кстати можно провести аналогию с теми же псевдо-селекторами. Если мы будем использовать :first-child - к какому элементу он будет применен?
С любого выпуска. Огромное количество классических алгоритмов были придуманы в 50-80-х годах. И на практике часто их более чем достаточно. Самые передовые алгоритмы, которые придуманы в последние 1-2 десятилетия - это, как правило, уже что-то сложное, предназначенное либо для особых случаев, либо для очень больших объемов. Их изучать если и понадобится, то в любом случае после классики.
"Просто" - понятие слишком относительное.
Смотря для кого (одно дело есть опыт в других языках и совсем другое, если не программировал вообще).
Смотря с чем сравнивать (по сравнению с C++ наверное действительно просто).
Смотря какие критерии качества результата (я видел разрабов, творчество которых можно непрерывным потоком транслировать на говнокод.ру, но это никого не парит и они числятся мидлами).
Неважно, фриланс у нас или не фриланс. Важно, насколько задача конкретна или, напротив, расплывчата.
Поменять розетку - это очень конкретная задача, её цена в зависимости от подробностей меняется в довольно ограниченных пределах. Исполнитель задаст несколько уточняющих вопросов и без проблем выставит конкретную оценку.
Теперь представим, что заказчик приходит с задачей "построить дом". Это очень нечёткая задача. Какой дом? Их может быть миллион вариантов с разбегом по цене в несколько порядков. В этом случае вопрос о бюджете - это не обязательно признак деньгоотсоса. Это попытка исполнителя сориентироваться, в какой сегмент рынка смотреть, что предлагать клиенту и какие обозначить клиенту ограничения.
Теперь ситуация из IT и личной практики. Клиент говорит, что он торгует такими-то товарами и ему нужен сайт. Какой сайт?! Лендос-визитка или полноценный магазин с полной обработкой заказа и интеграцией с 1С?! Сложность, стоимость и сроки этих вариантов различаются многократно. А клиент поначалу и сам не знает. Точнее, он хочет всё и сразу, но совершенно не понимает, во что ему это обойдется. В этой ситуации спросить ориентировочный бюджет, на который рассчитывают - это нормально.
Разумеется, если клиент четко понимает, чего хочет, данный подход не работает. Но таких мало.