Нигде не говорилось, что нельзя. Каналы можно и нужно использовать. Этот пост конкретно про группы, а не про каналы. Причём каналы тоже можно использовать как группы (см. второй способ).
Отличная идея для бота-модератора. По определённым правилам можно парсить сообщения и, если что-то найдёт, будет выдавать предупреждение. А если нарушит, например, 3 раза подряд, то отправляется в бан на определённый срок. Классическая схема модерации.
Делал подобный селект с учётом того, чтобы закрывался при потере фокуса. codepen.io/felixexter/pen/RNGeap
Есть свои минусы, например, зависит от количества, но если опций немного, то решение вполне годное.
Ещё помогает свойство -webkit-backface-visibility: hidden;, хоть у него назначение и другое, также оно пригождается для тех случаев, когда элементы, которые используют трансформации, распологаются на неожиданном месте, например, при поворотах и со смещённым центром в свойстве transform-origin.
Время на поиск свойства практически не затрачивается, если ты уже привык писать в таком порядке.
В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
Было бы интересно увидеть аргументы для табов и пробелов.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
codepen.io/felixexter/pen/RNGeap
Есть свои минусы, например, зависит от количества, но если опций немного, то решение вполне годное.
Ещё помогает свойство
-webkit-backface-visibility: hidden;
, хоть у него назначение и другое, также оно пригождается для тех случаев, когда элементы, которые используют трансформации, распологаются на неожиданном месте, например, при поворотах и со смещённым центром в свойствеtransform-origin
.В том примере лишь малая часть свойств, все свойства описывать здесь нет смысла.
Большинство разработчиков, работая в командах, придерживаются их внутреннему стандарту, в котором задекларирован порядок этих свойств, и все пишут как один.
Кстати, для причесона порядка свойств можно использовать CSScomb, у него же есть и заготовки, которые можно использовать как есть или же подогнать под себя.
Аргументы в пользу табов:
— по ним удобнее перемещаться, чем по каждому пробелу, хотя в современных IDE для пробелов такое тоже поддерживается;
— фактически в любой IDE настраивается размер под себя (мне привычен 4), но при этом символ всего 1;
— если код не минифицируется, то он будет весить меньше, по сравнению с пробелами.
Если код встраивается в качестве примера (например, в блогах), то лучше было бы задать свойство tab-size.
Гораздно удобнее группировать по их назначению.
А чем плохи алиасы из нескольких букв в командной строке?
display: inline-block;
в этом примере лишний.Если задаётся
float: left;
, то элемент автоматически будетdisplay: block;
.А вот исправленный вариант.
Будет ли в БЭМ считаться исключением такой вариант, когда нужно при наведении курсором на блок изменить свойства элемента?