frontend-разработчик. Фотографирую в инстаграме, готовлю и пишу тексты. Всё написанное не отражает мнения работодателя. 18+

5 заметок с тегом

css

Одностроковый CSS от Google

Сегодня я наткнулся на июньское видео от разработчиков Google Chrome, где Уна Кравец (Una Kravets, @una) рассказывает про современный CSS, который позволит вам создать макет, который поместится в одну строку.

Если ещё не видели, то пожалуйста:

Или почитайте на сайте web.dev (англ.).

Я посмотрел, и мне есть, что сказать, пусть я, конечно, не участвую в разработке браузера Google Chrome и не работаю в Google.

Что нам показали

Прежде всего, я хочу оговориться. На мой взгляд, видео предназначено, прежде всего, для начинающих разработчиков. Может быть для тех, кто всё ещё «верстает» в таблицах (да-да, эти ребята ещё есть в 2020-м году, и они делают совсем не электронные письма, которые должен открыть Microsoft Outlook), либо тех, кто ещё не занимается frontend-разработкой.

Более того, я считаю, что Google большие молодцы, что проводят видео-уроки такого формата, где рассказывают о современных технологиях в web.

При этом вы, как разработчик, должны смотреть не только на технологию, которую вам показывают, но и о том, кто и с какой целью это делает. «Корпорация добра» в видео продвигает свой браузер Google Chrome, что не удивительно. В Chrome всё показанное будет работать. А за его пределами?

Grid

Прежде всего я хочу обратить внимание на главное свойство, вокруг которого строится видео:


.item {
    display: grid;
}

В видео показали, как при помощи достаточно простого свойства, которое задаётся у родительского блока расставлять дочерние элементы, и это круто. Подробную документацию по свойству Grid Layout можно посмотреть на MDN. Там же показали одно из главных преимуществ «грида» — «фракталы», когда вы можете указать относительные размеры элементов и разметить сетку в родительском блоке в *.css-файле, а затем просто разместить эти элементы в вашем *.html-шаблоне.


.wrapper {
    display: grid;
    grid-template-columns: 1fr 1fr 1fr;
}

А теперь перейдём к сайту caniuse.com, на котором собирается информация о поддержке той или иной технологии браузерами (уверен, что этот сайт у вас давно в закладках браузера). Смотрим: свойство не поддерживается в Opera Mini, UC Browser for Android, QQ Browser, Baidu Browser и KaiOS Browser — скажете, что это неважно, потому что к вам на сайт не заходят через эти обозреватели? Окей! Свойство не будет работать в Safari и Chrome на «старом» iOS (с версии ОС 3.2 до 10.2), прощайте обладатели старых телефонов — вы не целевая аудитория. А ещё свойство имеет ограниченную поддержку в Internet Explorer (т. е. вы не будете точно знать, что будет работать, а что нет — поэтому лучше сразу считать, что поддержки технологии нет, чтобы наверняка). IE — это корпоративные пользователи крупных компаний, например в Мегафоне для доступа к внутренним ресурсам пользуются именно этим браузером (причём достаточно старой версией), значит разработчику нужно это учитывать.

Итого мы имеем 91.26% процентов устройств. Много? Достаточно, но многие из них вам могут быть нужны. Например, ваш сайт нацелен на китайскую аудиторию, которая не может или не хочет отказываться от привычной иконки.

Flex

Второе свойство, которое лично мне нравится больше, хотя и имеет недостаток конкретно для использования в качестве однострокового CSS для макета:


.item {
    display: flex;
}

С этим свойством вы легко расставите и упорядочите элементы внутри строки или столбца блока, но ваш html-код будет более загружен. Подробнее на MDN.

Сайт caniuse.com показывает более уверенную работу свойства для устаревших версий браузеров: 94.74% процентов устройств. Для свойства есть больше префиксов, чем для «гридов», и можно увеличить покрытие аж до 97.93%, но мы всё так же будем иметь неопределённость в рамках Internet Explorer, от которого отказаться (как выяснилось) не так-то просто, китайских браузеров и Opera Mini.

Какой вывод стоит сделать?

Разработчик, в том числе и frontend-developer решает задачи бизнеса, поэтому при выборе технологии тоже стоит уточнять, а кто будет «целевой аудиторией» сайта, в этом вам поможет та же Google Analytics и Яндекс.Метрика, а так же SEO-специалист.

Один из сайтов, которые я делал, был локальным для компании и открывался исключительно в Internet Explorer 6, а системные администраторы не дали доступы. Хотел ли я использовать flex? Очень! Ведь, каждый разработчик хочет не только писать меньше кода, который будет легче поддерживать, но и который будет выглядеть приятнее. Разумеется, в ход шли даже таблицы, а переделка проекта под современные браузеры, когда сменились локальные машины и весь дизайн началась с нуля.

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

Что касается Google, то у них явная цель: популяризировать свой браузер и WebKit, на который перешли почти все разработчики веб-обозревателей (спасибо Mozilla Foundation, что не поддаётся и не останавливается в разработке Gecko). Как разработчику вам не стоит поддаваться призыву писать только такой, простой и красивый код. Нужно следить за задачами бизнеса и прекратить решать за пользователя, через какое окошко смотреть на ваш сайт.

6 причин, почему вам не стоит идти в код-ревьюеры

Каждый из разработчиков хоть раз в жизни сталкивался с проверкой своего кода. Это мог быть быстрый просмотр работы кем-то из коллег, к которым вы обратились с вопросом или проблемой. Мог быть разбор задачи со стороны начальства перед выпуском работы в production. Даже вы сами могли отложить работу, а потом окинуть ее свежим взглядом через некоторое время. А иногда это было полноценное код-ревью специалиста, который проверит код по строгим параметрам: от банальной работоспособности до стандартов, описанных в Style Guide компании.

Впервые я столкнулся с настоящим код-ревью, когда проходил обучение в Яндекс.Практикуме. Если честно, вначале я не верил, что все работы проверяются живым человеком, и, тем не менее, всё именно так. Через какое-то время я подумал: а круто было бы самому стать ревьюером и помогать студентам с кодом...

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

Мои 6 причин, в которых я ни слова ни скажу про внутреннюю кухню своего работодателя.

Это не та творческая работа, что вы ищете

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

Код-ревьюер — не музыкант. Он — дирижёр.

Даже если вы видите очевидное решение, вы не можете, как говорили большинство учителей в школе: «приставить свою голову» — вы должны сделать всё, чтобы автор кода не просто самостоятельно пришёл к нужному решению, но и понял, почему такое решение является правильным.

С каждой итерацией вам нужно направлять человека, давать необходимые источники, чтобы в конце-концов сказать: «Ты молодец! Так держать!»

И тут мы переходим к следующей причине:

Код пишет человек

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

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

Людям, которые не терпят альтернативных решений, не место в команде ревьюеров.

И ревьюер, и разработчик должны работать над проектом в команде. Только вместе можно создать отличный продукт.

Важно понимать: ревьюер — это не полицейский с палкой, который будет очень недоволен, если увидит некачественный код.

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

Именно поэтому нужно уметь обсуждать варианты решения проблемных мест, находить компромиссы. Всё это жизненно необходимо для работы в команде, а без отличных отношений будет сложно получать удовольствие от работы.

Правила, много правил

У каждой команды есть свой чек-лист, и код-ревьюер должен лучше всех понимать, какой из пунктов обязателен к исполнению, а на что стоит «закрыть глаза» и выдать рекомендации.

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

Помните «несправедливость» в школе, когда кому-то из одноклассников ставили оценку выше, а другому её занижали? (Если нет, то у вас были идеальные учителя.) Код-ревьюер не должен ставить кого-то из авторов в больший приоритет. Все равны, а код-ревьюер просто не имеет морального права на ошибку.

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

Например, «мейнтейнеры» кода вывели новую технологию, а команда ревью ещё не приняла решение: считается такой вариант корректным и протестированным, или пока нет.

Разработчик использовал новый вариант и отправил работу на проверку.

Ваша задача, будет не просто «на автомате» проверить код и, отметив неподходящую спецификацию, отправить материал на доработку. С этим может справиться и скрипт «линтера». И бесконечно откладывать труд разработчика до принятия решения в команде тоже нельзя.

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

Каждую минуту в мире изобретаются миллионы прорывных технологий и сервисов, которые никогда не увидят свет, потому что команда будет «вылизывать» код до идеала, и каждый раз будет выходить новая технология, спецификация или методология, которая заставят переписать работу ещё и ещё.

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

Работы будет много, очень много

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

Я уже сравнивал эту работу с трудом учителя. Могу сказать профессионально (высшее образование получал как преподаватель иностранных языков): у современных учителей работа не ограничивается парой часов, проведённой с учениками. Большая часть работы — проверка домашних заданий, и это может забирать 8-12 часов чистого времени.

Код-ревьюер не ведёт лекции и семинары, он только проверяет «домашние работы». Множество работ.

Скажете: «Так именно за это ему и платят!» — и окажетесь не совсем правы. Код-ревьюер получает свои деньги за результат, которого добились авторы, и который ушёл в production. То, что мотивация может зависеть от количества работ, итераций или времени — это попытка менеджеров, которые редко когда писали код сами, оценить труд своего сотрудника.

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

Большие проблемы код-ревьюеров: рутина и время.

Если вы долго работаете над одним куском кода, ваш взгляд рано или поздно «замылится». Кстати, и для этого тоже нужны ревьюеры — обращать внимание автора на упущенные моменты.

Я уже писал, что это не то творчество, когда результат зависит только от вас. А если автор присылает новую итерацию уже в третий раз? А если он такой не один? А если вы только сейчас заметили, что что-то упустили в прошлый раз?

Общение с людьми

Многие из разработчиков выбрали эту профессию потому, что можно свести к минимуму всё общение с другими людьми. Не могу согласиться: удобно получать задачи в таск-менеджере, а общаться только с одним-двумя коллегами и то по рабочим вопросам в чате или почте.

Код-ревьюер — это всегда работа с людьми.

Да, в большинстве современных IT-компаний (особенно в режиме «самоизоляции») разработчики и ревьюеры сидят дома, а иногда и живут в разных частях страны, а то и в соседних государствах.

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

При этом вам с каждой проверкой надо будет общаться с людьми. С новыми людьми в больших проектах, или с одной и той же командой. Но общаться придётся. Это можно сравнить с письмами: вам написали, вы написали. Пинг-понг. Шар на вашей стороне, на стороне вашего партнёра, снова у вас. Раз за разом. День изо дня.

Это часть работы, и от этого никуда не деться.

Опыт, достаточный опыт

И тут мы подошли к финальному пункту: код-ревьюер должен обладать достаточным опытом разработки.

Достаточным — это не просто большим.

Например: «Я делаю landing pages уже 3 года, могу я быть отличным код-ревьюером в команде frontend-разработки?» — нет, если ваши страницы вы делали на Tilda, а вся работа заключалась в выборе шаблона из списка, и добавления текста, присланного заказчиком.

Код-ревьюер обязан разбираться в той технологии, с которой он работает.

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

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

Знать абсолютно всё невозможно. Но уверены ли вы, что знаете достаточно, чтобы выполнить роль наставника, а не машины, которая просто отклоняет результат, не совпадающий со своим скриптом?

Тут я должен ответить на вопрос: «Всегда ли код-ревьюер должен выступать в роли ментора для разработчика? Или это особенность Яндекс.Практикума, как площадки для обучения новых специалистов».

Во-первых, знать абсолютно всё невозможно, а потому быть разработчиком значит учиться на протяжении всей своей карьеры. Часто случается так, что долго работая над одним (не обязательно даже legacy-) продуктом, специалист замыкается в технологии. Он видит проторенные решения, и следует им на автомате. При этом языки программирования не стоят на месте, и там, где раньше изобретали велосипед, сейчас работает framework. Стоит ли об этом написать автору кода? Да! Ведь это сэкономит время и разработки, и проверки, а ещё деньги на выпуск проекта конечному пользователю.

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

Ну и, наконец, в-третьих, код-ревьюер не просто «подгоняет» работы специалистов под некий, принятый в компании Code Style Guide. Если разработчик не привык ставить так необходимые всем точки с запятой в конце каждой строки в JavaScript, ему поможет Pretier, но если он не может писать код по принятым стандартам (например ООП) — работа код-ревьюера донести необходимость их соблюдать.

Вместо заключения

Я не могу сказать, что код-ревьюеры не нужны. Нужны, и очень нужны. Если я буду искать новую работу, я постараюсь попасть в команду, где есть такая опора.

Во-первых, в команде с ревьюером вы гарантированно получите поддерживаемый код. Через полгода или год, когда вы забудете, что хотели сказать тем или иным выражением (а может и не вы вовсе делали тот самый коммит), вы легко вернётесь к задаче.

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

В-третьих, код-ревьюер — это ментор, который сможет помочь специалистам вырасти из «джунов» или «миддлов» в «сеньоров», и стать востребованными специалистами на рынке. Ведь ценится не просто программист, выдающий код по Style Guide, а человек, который умеет работать быстро, качественно, в одиночку или в команде.

При этом я убеждён, что эта работа подходит далеко не для всех.

Не все игроки в футбол или баскетбол становятся классными тренерами. Но при этом они могут стать отличными игроками.

Если вы уверены в своих силах, вам стоит попробовать.

Если вам понравится, значит это ваше. Останется только совершенствоваться, потому что разработчик учится всю свою карьеру. А прочитать про код-ревьюеров конкретно в Яндексе можно в статье на Яндекс.Академии.

Табуляция vs. пробелы

До конца 2019 года я был ярым сторонником табуляции и никогда не использовал пробелы для отступов в коде. Причина была простая — я никогда не могу запомнить сколько пробелов стоит ставить, а нажать на Tab — это проще простого.

В 2020-м я считаю, что два пробела — это лучшее решение, которое может быть: во-первых, с двумя пробелами код становится сильно компактнее (а это критически важно, если вы пользуетесь ноутбуком, или решили заглянуть на свой github с мобильного телефона, чтобы дать ответ собеседнику); во-вторых, пробел всегда имеет одну и ту же ширину, а табуляция может зависеть от настроек (посмотрите в своей IDE параметр indentation) — это значит, что компактный код у вас может оказаться совершенно нечитабельным у тех, с кем вы работаете.

В 2020-м году я всё ещё нажимаю Tab для создания отступов или пользуюсь умной табуляцией в моём VSCode. Перевод из одного параметра в другой делает за меня editorconfig. Добавьте файл .editorconfig или добавьте плагин в свой редактор. Почитайте документацию на русском языке и настройте файл под себя, и забудьте забудьте о «табах», не меняя привычек.

Разумеется, это не относится к тем случаям, когда в вашей компании есть другой Style Guide и вам приходится использовать его (тогда просто настройте свой Editorconfig так, как вам будет удобно и просто пишите код так, как вам удобно).

1 мес   css   html   vscode   код

Модифицировать и положить на место

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

Чтобы этого избежать, стоит определить общие правила и их придерживаться.

В Яндексе продвигают методологию БЭМ, но ей пользуются не только там.

Я попробовал, разобрался и мне понравилось.

По БЭМ весь ваш код делится на три части: блок элемент и модификатор.

Приведу аналогию:

  • у вас есть полка. Полку можно поставить в любое место и она всегда останется полкой.
  • у вас есть книга. Книга останется книгой и на полке и у вас в руках. Это тоже блок.
  • если вы поставите книгу на полку, то книга станет элементом полки с книгами.
  • а если вы поместите книгу в суперобложку, то она будет выделяться, и станет блоком с модификатором.

Больше всего вопросов вызывают следующие вещи:

  • у вас есть несколько блоков, как их расположить относительно друг друга, если описывать положение в стилях блока нельзя?
  • как сделать файловую структуру?
  • модификатор не изменяет значение родительского блока, если создать правильную файловую структуру!!!

Разберёмся по очереди.

Как поместить один блок в другой

Блок действительно не должен влиять на своё положение в пространстве.

Согласитесь, если бы ваша полка говорила: «я стою у окна» — то вы не смогли бы поставить её в другое место, и блок потерял бы главное свойство блока в методологии БЭМ: свою универсальность.

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

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

Посмотрим на код на примере полки на книге.


<div class="shelf">
     <div class="shelf__book book"></div>
</div>

Теперь книга это и блок сам по себе, и элемент родительского блока. Если посмотрите внимательно, то .book — это класс обозначающий стили блока «книга», а .shelf__book — это описание, где книга лежит на полке, как элемент «полки». Такое использование двух классов вместе называется миксами. А правила такого расположения написаны в официальной документации.

Как сделать файловую структуру

Если вы делаете проект по БЭМ и хотите получить один стиль, вы всегда можете взять кусок кода из одной страницы или с одного своего сайта и вставить в другой. Ничего не сломается.

Чтобы вы не искали код в длинном CSS-файле, frontend-разработчики, которые выбрали БЭМ, помещают каждое описание классов: блоков, элементов, модификаторов — в отдельные файлы и папки.

Выглядеть ваш сайт будет следующим образом:



src
 blocks
  shelf
   __book
    shelf__book.css
   _library
    shelf_library.css
   _kitchen
    shelf_kitchen.css
  shelf.css
  book
   _red
    book_red.css
   book.css
 pages
  index
   index.html
   index.css
   index.js

Внутри всё это дело подключается через @import url();, поэтому файл index.css выглядел бы так:


@import url(../../blocks/shelf.css);
@import url(../../blocks/book.css);

/* тут можно указать какие-то глобальные стили, но по правилам БЭМ. Например, задать шрифт странице */

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

Поэтому модификаторы элементов подключаются в корневых *.css-файлах элементов.

Создать подобную структуру, конечно, занимает время, но задачу можно легко решить при помощи терминала. Если у вас macOS или Linux, устанавливать ничего не надо: Git Bash уже установлен в системе, а если вы работаете под Windows, стоит зайти по ссылке и скачать файл.

После этого вы сможете через простое перечисление создать нужную структуру.


$ mkdir src #создали папки
$ mkdir src/blocks src/pages
$ touch src/pages/index.html src/pages/index.css src/pages/index.js #создали файлы
$ cd src/blocks #зашли в папку
$ mkdir shelf book
$ mkdir shelf/_library shelf/_kitchen shelf/__book book/_red
$ touch shelf/_library/shelf_library.css shelf/_kitchen/shelf_kitchen.css shelf/__book/shelf__book.css shelf/shelf.css book/_red/bookd_red.css book/book.css

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

Модификатор не изменяет значения родительского блока

Это происходит потому, что у модификатора не хватает «веса», а подключается он, как и положено, в начале страницы, поэтому родительский класс его переписывает. Подробнее про специфичность есть в статье.

Исправить эту вещь можно двумя способами:

Добавить «вес»

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

Если у нас все книги синие, и только одна в красной супер-обложке, то запишем код:


/* файл book_red.css*/
.book.book_red {
    color: red;
}


/* файл book.css*/
@import url(_red/book_red.css);
.book {
    color: blue;
}

То же самое будет справедливо, если вы хотите «усилить» элемент блока. Ведь элемент не может использоваться в отрыве от блока.


/* файл shelf__book.css*/
.shelf .shelf__book {
    margin-right: 10px;
}


/* файл shelf.css*/
@import url(__book/shelf__book.css);
.shelf {
    margin: 0;
}

Тут стоит быть внимательным и «усиливать» элементы только родительским блоком. С чужим блоком такой фокус не пройдет.

На самом деле, этот способ не совсем корректный и применяется только в виде исключения из правил. Правильно делать так:

Не указывайте свойства, которые могут измениться

Вернёмся к книгам. У нас есть книги одинакового размера и формы, но разного цвета. Все синие и одна красная. Правильная запись в таком случае будет выглядеть так:


/* файл book_red.css*/
.book_red {
    color: red;
}


/* файл book_blue.css*/
.book_blue {
    color: blue;
}


/* файл book.css*/
@import url(_red/book_red.css);
@import url(_blue/book_blue.css);
.book {
    width: 200px;
    height: 400px;
}


/* файл index.html*/
<div class="shelf">
    <div class="book book_blue"></div>
    <div class="book book_red"></div>
    <div class="book book_blue"></div>
</div>

Немного более загруженный *.html-файл, но всё работает так, как нужно.

1 мес   bash   css   html   БЭМ   код   учебник

Специфичность в CSS

Ваш HTML-код состоит из множества «элементов»:

  • Селекторов <header>
  • Классов .header
  • ID #header
  • Атрибутов [attr=value]
  • Псевдоэлементов ::after
  • Псевдоклассов :first-child
  • и многих других... —

каждый из них называется «селектор», и его внешний вид в вашем готовом HTML-файле определяется тем, какие стили будут даны ему в самом HTML-файле (styles у «селектора» или внутри кода <styles> на странице) или в подключенных к нему CSS-файлах.

Способ, с помощью которого браузер будет определять как выглядит «селектор» на странице называется «специфичность».

Правило первое

Код ниже имеет больший приоритет при равном «весе» всех элементов страницы

Допустим, что у вас есть такой код на странице


.first {color: red}
.second {color: green}


<p class="first">Первый абзац</p>
<p class="second">Второй абзац</p>
<p class="first second">Третий абзац</p>

Получаем следующий результат:



Первый абзац
Второй абзац
Третий абзац

Первый абзац стал красным потому, что у него один класс, браузер обратился к этому классу и получил его цвет. Второй стал зелёным по тому же принципу. Смотрим на третий абзац. Он стал зеленым, потому что браузер читает код всегда сверху вниз. Он смотрит, так, вот третий абзац с классом first — класс требует покрасить текст в красный, красим. Читаем дальше, этот же селектор имеет класс second — класс требует покрасить текст в красный, красим. Последним изменением будет применение второго класса в CSS-файле, браузер сделает изменения ещё во время загрузки, так что вы увидите уже готовый вариант.

Правило второе

Стиль каждого селектора имеет свой «вес». Чем больше «вес», тем более приоритетен стиль для селектора.

«Вес» селектора традиционно показывается в виде числа 0.0.0.0. Когда мы пишем определённые стилевые правила для наших элементов страницы, мы изменяем это число.


p {color: #5D4037}


<p class="first">Первый абзац</p>
<p class="second">Второй абзац</p>
<p class="first second">Третий абзац</p>

Выглядеть результат будет так:



Первый абзац
Второй абзац
Третий абзац

Все абзацы стали коричневыми потому, что мы изменили число «веса». В случае с «селектором» мы изменили самое правое число. Оно стало 0.0.0.1

Теперь предположим, что мы сохранили классы элементов из прошлого примера. И для большего понимания, я запишу их выше нового обозначения стилей для «селектора».


.first {color: red}
.second {color: green}
p {color: #5D4037}


<p class="first">Первый абзац</p>
<p class="second">Второй абзац</p>
<p class="first second">Третий абзац</p>

Получаем следующий результат:



Первый абзац
Второй абзац
Третий абзац

Добавляя класс, мы меняем второе число справа в порядке 0.0.1.1. Стоит понимать, что 0.0.1.1 > 0.0.0.1, поэтому первый абзац стал красным, второй и третий зелеными (почему это произошло в третьем, посмотри первое правило).

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


a[target="_blank"] {color: black}
.first {color: blue}
.second {color: green}
a {color: red}


<a href="/" class="first">Первый абзац</a>
<a href="/" class="second" target="_blank">Второй абзац</a>
<a href="/" class="first second" target="_blank">Третий абзац</a>

Получаем следующий результат:


Первый абзацВторой абзацТретий абзац


Добавляя стиль атрибута, мы меняем третье число справа в порядке 0.1.1.1. Поэтому вторая и третья ссылка стали черными.

И наконец добавим одному из элементов ID.


#yandex {background: #ffcc00}
a[target="_blank"] {color: black}
.first {color: blue}
.second {color: green}
a {color: red}


<a href="/" class="first">Первый абзац</a>
<a href="/" class="second" target="_blank" id="yandex">Второй абзац</a>
<a href="/" class="first second" target="_blank">Третий абзац</a>


Первый абзацВторой абзацТретий абзац


Добавляя стиль для ID, мы меняем первое число слева в порядке 1.1.1.1. Поэтому вторая ссылка получила нужный цвет.

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

Не рекомендуется использовать как самый крупный «вес» для стилей «селектора» (например ID), так и самый мелкий (например P). Одинаковых ID на странице быть не может, поэтому, если вы будете задавать стили именно для него, ваш CSS-файл разрастётся, а если вы решите изменить стиль добавив класс, у вас ничего не получится, «вес» класса меньше «веса» ID. Оставьте ID элементов для вашего JS-файла.

Так же не стоит добавлять стили для «селектора» (например <p>), потому что если у селектора будет хотя бы один класс, будет использоваться именно он. Обратите внимание, именно на «специфичности» созданы такие удобные файлы как: reset.css и normalize.css. Сохраните ссылки, они вам ещё понадобятся. Файлы сделают отображение вашего кода одинаковым во всех браузерах, избавившись от их «фирменных» встроенных стилей.

Правило третье

!important; имеет максимальный приоритет


.third {color: #ffcc00!important}
#yandex {background: #ffcc00}
a[target="_blank"] {color: black}
.first {color: blue}
.second {color: green}
a {color: red}


<a href="/" class="first">Первый абзац</a>
<a href="/" class="second third" target="_blank" id="yandex">Второй абзац</a>
<a href="/" class="first second" target="_blank">Третий абзац</a>


Первый абзацВторой абзацТретий абзац


Как видим, !important; просто переписал правила установленные всем прочим кодом.

Если вы можете не использовать !important;, не используйте его!

Во-первых, такие правки сложно отследить. Если вы полюбите !important;, однажды вы столкнётесь с тем, что в другой части кода есть и другой !important;, который к тому же, имеет больший «вес» или находится ниже. Придётся переписывать код.

Во-вторых, браузеру сложнее обработать !important;: он проходит по коду сверху вниз, определит последовательность и нарисует страницу, потом определит «вес» и снова перерисует, а затем ему надо будет сопоставить все `!important;`, которые вы использовали.

Подсказка

Если !important; использовать не рекомендуется, можно просто добавить вес вашим элементам. Например, вы можете показать, что какой-то элемент для получения нужного стиля должен обязательно находиться внутри другого или один тег «модифицирует» родителя. Это «наследование».


.first .paragraph {color: grey}
.paragraph.paragraph_recolor_blue {color:blue}
.paragraph {color: red}


<div class="first">
    <p class="paragraph">Первый параграф</p>
</div>
<div class="second">
    <p class="paragraph">Второй параграф</p>
    <p class="paragraph paragraph_recolor_blue">Третий параграф</p>
</div>



Первый абзац
Второй абзац
Третий абзац

«Вес» первого параграфа 0.0.2.0, он больше, чем 0.0.1.0, поэтому у него серый цвет.

Теперь вы легко сможете понять почему тот или иной элемент имеет определённый внешний вид.

Литература

1 мес   css   код   учебник