Считаю, что это косяк верстака. За такое надо лупить и посильнее.
Похоже, что сделано на отвали.
Нужно либо использовать компонент общий, заранее созданный, либо писать новый, но с четким обоснованием (новый дизайн, разительно отличающееся поведение и проч).
Но опять же - всё упирается в процессы, построенные внутри команды разработки.
1. Если бы было в начале время на создание гайдов по стилям, html страницы с типографикой, базовых компонентов, то большая часть проблем была бы решена еще на старте. Главное - при смене верстака (в данном случае) требовать исполнения стайл-гайдов и поддержку уже существующей верстки. Приведенный пример смахивает на латку, лишь бы сбагрить побыстрее.
2. В идеале нужен человек, который бы ревьювил верстака. Почему-то принято считать, что ревью нужен только программерам.
Честно говоря, не вижу проблемы.
Когда на бэкенде пишут код, тоже плодятся всевозможные хелперы, утилсы и прочие помогаторы, в которые выносят общий функционал, который может быть переиспользован.
Нужно взглянуть под другим углом на те стили, которые для вас превращаются в "портянку" из-за отсутствия понимая "для чего".
Есть два подхода к верстке - либо фреймворк либо верстка уникальными компонентами.
Если на проекте подключен фреймворк, верстак просто использует готовые кирпичи, оборачивая в случае необходимости в дополнительные классы-модификаторы по месту.
Упрощение и лаконичность в разметке тянет за собой усложнение в стилях.
Т.е. вместо дописывания класса, в котором сбрасываются проблемы с float (к примеру), вам придется в каждый оборачивающий класс дописывать эту чепуху из 3-4-х строк (утрирую)
БЭМ же не от хорошей жизни придумали. На больших проектах с десятками шаблонов страниц и сотнями уникальных элементов без унификации будет просто жесть.
И представьте, если все стили будут написаны не в виде .model-show__pub_date а, к примеру, ,a119 )))
Для начала надо смотреть на стили у оборачивающего контейнера. Если там используется флекс, text-align работать не сможет, и надо разбираться со стилями в условиях флекса, решать на уровне родителя, align-items к примеру.
Для понимания процесса - див переносит строчный объект в новый параграф. В примере - это для упрощения восприятия результата. В реальной вёрстке все определяется по месту .
Производительность современных устройств позволяет закрывать глаза на излишки в разметке, и можно не придерживаться аскетизма в разумных пределах. Учитывайте это в случаях, когда после вас будут работать с вашим кодом. Тут скорее нужно использовать более человекопонятные классы для стилей. А будут ли использоваться универсальные контейнеры или мтили будут ложиться прямо на изображение - зависиь только от воли верстальщика.
На флекс гораздо проще. И желтый блок добавить псевдоэлементом на css на обертку, с отступами и позиционированием абсолют. Всем элементам контента релатив, чтоб остались поверх.
Тогда в разметке будет меньше тегов декоративных.
Svg mask может помочь, можно и на чистом css с keyframes для анимации монеты. Если требуется адаптив - всё сильно усложнится написанием дополнительных инструкций под иные разрешения.
К родителю обратиться нельзя. Когда браузер парсит ваш класс, он начинает справа. Все что слева - фильтрует выборку. Т.е. .red a сначала найдет все теги a, а потом отфильтрует те, у которых в оборачивающих тегах есть .red
Таким образом повлиять на родителя опираясь на значение ребенка просто нельзя.
Ну и не стоит в стилях указывать теги вместо классов. Это притормаживает парсинг страницы и последующий рендер.
Как разработчик из энтерпрайз-компании могу сказать, что фрилансеров могут привлечь на помощь для покрытия части крупного проекта. Это шанс посмотреть на промышленное производство изнутри. А заодно прокачать скиллы и нарастить экспу.
И часто это будет не банальный сайтик ))
Работаю в компании. Воркфлоу совпадает. Бывают конечно мелкие нюансы.
Могу добавить в комплект - подключаю генератор иконочных шрифтов из svg, если дизайн на это наталкивает.
Похоже, что сделано на отвали.
Нужно либо использовать компонент общий, заранее созданный, либо писать новый, но с четким обоснованием (новый дизайн, разительно отличающееся поведение и проч).
Но опять же - всё упирается в процессы, построенные внутри команды разработки.
1. Если бы было в начале время на создание гайдов по стилям, html страницы с типографикой, базовых компонентов, то большая часть проблем была бы решена еще на старте. Главное - при смене верстака (в данном случае) требовать исполнения стайл-гайдов и поддержку уже существующей верстки. Приведенный пример смахивает на латку, лишь бы сбагрить побыстрее.
2. В идеале нужен человек, который бы ревьювил верстака. Почему-то принято считать, что ревью нужен только программерам.