Комментарии 31
Неделя «Я бегло проглядел книжку/сайт по ХХХ, и понял все неправильно» объявили окрытой?
<a id="my-task-card" href="#task=2"> <div id="my-task-card-title">Write CSS</div> </a> <a id="my-task-card" href="#task=3"> <div id="my-task-card-title">Write JS</div> </a>
Я правильно понял, что все представленные способы, кроме использования классов, порождают невалидный html?
конечно
Можно data- добавлять к аттрибутам, будет валиднее. Интересна производительность такого рода селекторов, как думаете быстрее они или медленнее классов?
а зачем это анализировать, если у них предназначение другое?
Затем, что если они по производительности на уровне с обычными селекторами, то можно смело использовать такой способ при необходимости, а если медленнее, то об этом стоит помнить когда настанет момент оптимизации скорости отрисовки страницы.
Насколько я помню, для обработки «data» или «class» придется использовать стороннюю библиотеку (если лень писать свою обработку). Например, jQuery. Т.е быстрее браузерного поиска по «id» точно не получится. Т.к. сначала получим список всех элементов по «getElementsByTagName», а затем будем искать нужный.
http://frontender.info/css-performance-revisited-selectors-bloat-expensive-styles/
Разница чуть менее, чем никакая.
Какая производительность у селекторов по классам и селекторов по атрибутам? Есть разница?
Производительность у селекторов по классам лучше, чем у селекторов по атрибутам. Я видел пару раз сравнения на stackoverflow
Производительность по классам и по атрибутам примерно равна, но по классам быстрые на 10-20 мс, и то при условии, что сравнивается один класс и один атрибут.
В реалиях же селекция по классам часто не ограничивается одним классом, как и в случае с атрибутами, и в таком случае производительность по атрибутам будет более заметно проседать в скорости. Особенно учитывая современные объемы стилей, то такой подход будут виден абсолютно сразу.
Очень все это странно, имхо
Можно использовать бэм или не использовать его. Стили изолированно можно писать как угодно. JS к классам с префиксом js- или, в крайнем случае, к дата атрибутам.
Привязка к именам тегов — это не гибко, в случае статьи — невалидно.
Привязка к id — ограничение на использование один раз этого блока на странице
Можно использовать бэм или не использовать его. Стили изолированно можно писать как угодно. JS к классам с префиксом js- или, в крайнем случае, к дата атрибутам.
Привязка к именам тегов — это не гибко, в случае статьи — невалидно.
Привязка к id — ограничение на использование один раз этого блока на странице
На самом деле никакого ограничения нет — вам наврали.
Я не правильно выразился. Ограничение связано не со стилями, а с использованием блока, если на него завязан js
Тут тоже нет никаких ограничений.
Я прошу прощения, а о чем статья то?
А почему «my-task-card my-task-card_important my-task-card_completed» вместо более простого «my-task-card important completed»? При втором способе еще легче писать стили, особенно используя less.
На вскидку:
Есть 2 набора свойств
1) .foo и .foo-mod
2 ).bar и bar-mod
Теперь появляется элемент совмещающий foo и bar.
Конфликт получается, если нужен только «foo foo-mod bar», но никак не «foo foo-mod bar bar-mod»
Есть 2 набора свойств
1) .foo и .foo-mod
2 ).bar и bar-mod
Теперь появляется элемент совмещающий foo и bar.
Конфликт получается, если нужен только «foo foo-mod bar», но никак не «foo foo-mod bar bar-mod»
Ну в таком случае да. Хотя можно развить холиворчик на архитектурную тему, мол стили должны быть не циклическим деревом.
А еще можно использовать костыль .bar.bar-mod:not(.foo-mod), или как-то так.
А еще можно использовать костыль .bar.bar-mod:not(.foo-mod), или как-то так.
Зачастую невозможно предсказать будущее проекта, сейчас цикличности нет, а потом мы сливаем два проекта и привет, конфликты. Такая поддержка отсутствия цикличности требует нехилых экстрасенсорных способностей в предсказании будущего, мне такой уровень не по силам, и я предпочту длинные изолированные модификаторы.
Вариант с not очень уж костыльный, и совсем не расширяемый: добавление новых стилей не должно требовать модификации уже существующих, а not потребует дописывать новые стили в исключения каждый раз.
====
Я не очень хорош в объяснениях, тут достаточно неплохо описано мотивы длинного именования https://ru.bem.info/methodology/faq/#Зачем-писать-имя-блока-в-именах-модификаторов-и-элементов
Вариант с not очень уж костыльный, и совсем не расширяемый: добавление новых стилей не должно требовать модификации уже существующих, а not потребует дописывать новые стили в исключения каждый раз.
====
Я не очень хорош в объяснениях, тут достаточно неплохо описано мотивы длинного именования https://ru.bem.info/methodology/faq/#Зачем-писать-имя-блока-в-именах-модификаторов-и-элементов
Разумно, но опять же в случае слияния двух проектов можно подчистить стили и в случае очень частого совместного использования сделать общую сущность —
.foo, .foobar {}
.bar, .foobar {}
.foobar {}
.bar.bar-mod, .foobar.bar-mod {}
Если использовать что-то в роде less то будет еще легче с переменными —
.foobar { background-color: @foo-color; border: @bar-border }
Ну а костыль not() на то и костыль что его можно использовать раз-другой и не поощрять такое поведение, если они начинают накапливаться — показатель, нужно уже перетасовать структуру классов.
В общем ИМХО надо по минимуму плодить длинные сущности (как в примере в статье) и использовать стандартизированные классы для «состояния».
.foo, .foobar {}
.bar, .foobar {}
.foobar {}
.bar.bar-mod, .foobar.bar-mod {}
Если использовать что-то в роде less то будет еще легче с переменными —
.foobar { background-color: @foo-color; border: @bar-border }
Ну а костыль not() на то и костыль что его можно использовать раз-другой и не поощрять такое поведение, если они начинают накапливаться — показатель, нужно уже перетасовать структуру классов.
В общем ИМХО надо по минимуму плодить длинные сущности (как в примере в статье) и использовать стандартизированные классы для «состояния».
«Подчистка» стилей, требует ручного вмешательства. Для очень больших проектов это становится существенной задачей (переезд хуже пожара). Это одна из техник изоляции проблем.
.foobar опять требует от меня работы руками для написания .foobar.mod, а идея как раз в том, чтобы сочетать стили, а не писать их заново.
Это похоже на «Наследование VS Композиция» из ООП, вместо общего предка ".mod" предлагается реализовывать trait «mod» для каждой необходимой сущности
.foobar опять требует от меня работы руками для написания .foobar.mod, а идея как раз в том, чтобы сочетать стили, а не писать их заново.
Это похоже на «Наследование VS Композиция» из ООП, вместо общего предка ".mod" предлагается реализовывать trait «mod» для каждой необходимой сущности
У меня подход такой: для стилизации использую классы, иногда бывает удобнее использовать атрибуты, но никогда начинающийся на «data-», ID — практически не использую. Если нужно пометить тег для привязки к нему JS события, тут использую классы с префикс «js-», ни какие стили к нему не привязываю, для передачи данных в JS — атрибут «data-».
хотя это ничего и не ломает.
Ломает. JS у вас корректно работать не будет дальше первого айдишника.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS наших дней