С точки зрения функционирования сайта нет никакой разницы, в каком файле описан блок. Это исключительно вопрос удобства разработки и (возможно) применяемых инструментов сборки.
С проблемами большой вложенности не сталкивался. Да и не такая уж большая она там получается. В стародавние времена, когда верстали таблицами, а любые эффекты типа скругленных уголков делали обертками, вложенность выходила гораздо больше.
Ну это уже надо смотреть по вкусу и по ситуации. Кто-то выносит вообще все блоки в отдельные файлы. Кто-то описывает "родственные" блоки вместе. Это уже больше вопрос удобства организации workflow и принятых в проекте соглашений. Фишка в том, что конечный результат, который мы видим в браузере, от этого не зависит никак.
Да, зависит от порядка файлов и стилей в этих файлах.
А ещё может быть случай, что это свойство - font-size, задаваемое в em (то есть в единицах относительно предыдущего уровня). Тогда оно не перезатрется начисто, а унаследуется в непредсказуемом порядке.
Абсолютно любое свойство. Если оно по каким-то причинам окажется указанным и для обертки, и для блока - одно из значений будет затерто, другое останется. Но какое именно - зависит от порядка стилей в файле/бандле, который даже автор часто не помнит наизусть, не говоря уж о коллеге, подключившемся в проекту позже. А если там это всё еще перекручено с медиа-запросами, например, найти баг будет ещё сложнее.
Hyubert, что такое header__block? Оформлено как элемент, но называется почему-то блок.
Если всё-таки элемент, то смиксовать container__header и header в принципе как бы и можно, но практика показывает, что это опасно и может быть чревато проблемами. Любое css-свойство, указанное и там, и там - будет перекрыто и затерто в труднопредсказуемом порядке.
Дмитрйи, если строчному элементу нужно дать фон, то это значит, что фон будет присвоен некому врапперу. Это нормальная практика, но! - тогда этот враппер и назвать нужно соотвествующе. То есть он будет не some-class__button, а некий условный some-class__buttons-wrapper или что-то подобное. А именно &__button он быть не может, потому что button - это только сам button и никто другой. А автор вопроса (вольно или невольно) подразумевает именно это. То есть в авторской постановке вопроса - истина всё-таки одна.
Промежуточные обертки нужны, если в них вкладывается БЭМ-блок. Потому что блок должен знать только своё устройство, но ему нежелеательно вмешиваться в своё позиционирование.
А тут не блоки, а элементы вышестоящего блока. Причем если с заголовком ещё как-то можно за уши притянуть, то с кнопкой вообще нелогично смотрится.
Вот если сделать блок "кнопка" - тогда обертка обретет смысл.
> чем занимаются эти самые 0,1% серьёзных программистов?
На самом деле их больше, на мой субъективный взгляд порядка 2-3%.
Занимаются они чем угодно, с одним условием - они создают что-то новое.
Остальные 97% фактически собирают ПО из готовых кирпичей (фреймворки, библиотеки), скрепляя их раствором из собственного шаблонного кода.
Если потребности задачи покрываются готовыми библиотеками - математика действительно не нужна (ну разве что самая-самая базовая), нужно знание прикладных технологий. Но как только нужно влезть на пару уровней абстракции ниже - она всплывает. Вообще где угодно: в играх, графике, базах данных, обработке звука, операционных системах, микроконтроллерах, банковской сфере, поиске, соцсетях, рекламе, где угодно.
Про таймлайны - знаю и согласен. Как частный случай принимается. Но вот программисту - незачем.
Про медицинский софт, напротив, сильно сомневаюсь. Может я чего-то не знаю о жизни, но те медицинские спецмониторы, которые я видел, наоборот тяготели к квадрату или даже вертикальному прямоугольнику.
Я понимаю, что разбитый 32:9-монитор устраняет некоторые побочные минусы двух физических мониторов (рамки, цветопередача). Но мне в принципе не нравится такая конфигурация, когда есть два равноправных монитора - чувствуешь себя буридановым ослом. Я за главный большой центральный монитор и (опционально) меньшие вспомогательные по бокам.
Задумка хорошая, только показывает чушь :) Потому что цвета ищутся по неперцептивному пространству RGB. Да это даже по результату видно - там есть пары почти неотличимых цветов.
Ну это обычные профнепригодные провинциальные "дизайнеры" (неуместное центральное выравнивание, дефис в роли тире, капс без трекинга и пр).
Карточки должны идти по строкам, текстовые списки - по столбцам.
