Check Levi9 best QA positions to Backbase team!
×Закрыть

Использование дочерних селекторов или лишние классы, что хуже?

Добрый день, хотел еще раз для себя прояснить при написании не больших проектов, скажем до 10 страниц, что считается более правильным плодить классы? Или писать в стиле:

.navbar{...}
    ul{...}
        li{...}
            a{...}
👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

а как ты потом адаптивный дизайн сделаешь если у тебя нету классов ?

что лучше — пихать дополнительный метод в этот класс или заводить дополнительную цепочку, соединяя объекты через композицию?

однозначного ответа нет.
вот, если появляется запятая в селекторах — лучше вынести в отдельный класс.
или если появляется !important — перерефакторить в отдельный класс + композиция.
а так, плоская структура определенно проще в поддержке. Пока свойства в двух классах не начинают конфликтовать(что говорит о необходимости порефакторить их, исключив конфликт).

Но если весь проект уже на «лесенках», то цеплять плоскую структуру будет сложно :-/
[UPD] пропустил про «10 страниц». Тут скорее, от возможности развития зависит. Вложенные селекторы определенно сложнее менять. И стрёмнее реюзать, безопаснее написать новое чуть ниже(или пихать через запятую все возможные варианты, что тоже лажа).

Большим злом считается сорвать сроки. Не морочь яйца, пиши и пусть работает. Я бы это даже проектом не стал называть.

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

решение есть — инлайновые стили.

так вам чтоб на других страницах не поменялось или чтоб удобно?)

ну так я могу покопировать этот тег в разные шаблоны а потом кто то решит что надо поменять цвет или что то ещё)

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

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

ЕСЛИ это всего 10 страниц, так и сделай.

ну, ему еще надо БЭМ сначала презентовать, у него ж явно не оно :)

Я читал документацию и уроки смотрел, мне кажется для маленьких сайтов это геморой, это больше для больших проектов которые командами пишут

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

насчет БЭМ у меня еще вопрос, его вообще где то испрользуют кроме снг?

Если можно вопрос, мне вот тяжело это все представить как оно реализуется даже на простых задачах. В БЭМе написан порядок как называть класс: блок__элемент_модификатор, вот как назвать мне «а» в моем примере выше, при том что nav то я тоже как то назвать должен, а он ведь тоже имеет минимум 2-3 родителя

в БЕМе не должно быть родителей

насчет БЭМ у меня еще вопрос, его вообще где то испрользуют
ashleynolan.co.uk/...m=email#css-methodologies
Или писать в стиле:
Nesting in CSS is a bad thing, because it:

1) increases specificity (which should always be well managed);
2) introduces location dependency (a hallmark of an inflexible system)
3) reduces portability (meaning we can’t move things around if we need to);
4) increases fragility (nesting means more chances for the selector to go wrong).

Потом оборачиваешь какой то из этих тегов в другой в будущем и всё ломается

Подписаться на комментарии