Насколько плохо на практике переборщить селекторов в SASS/SCSS?

Ответ 1

Это зависит от того, насколько динамические манипуляции с DOM и стилями будут продолжаться после загрузки страницы. Это не страница загружает (в основном) или медленные селекторные файлы при первоначальном макетировании, который решает/перепланирует.

Теперь Стив Соудерс говорит, что на среднем сайте это просто не представляет реальной проблемы. Тем не менее, в веб-приложении или высокоинтерактивном веб-сайте плохо выполняемые правила CSS могут сделать ваши репликации медленнее, чем они должны быть. Если у вас много рецензий...

Отмеченные эксперты, такие как Николь Салливан, Paul Irish и jankfree.org, это не так много селекторов-потомков, что это определенные свойства в определенных контекстах (html5rocks.com), которые делают краски дорогими. Я вижу длинный селектор больше, чем проблему ремонтопригодности (Nicolas Gallagher), чем проблема производительности - учитывая, что ремонтопригодность взаимодействует с производительностью. Высокоподдерживаемый код может быстрее итерации и легче отлаживать (помогая вам находить и устранять проблемы с производительностью).

Теперь, что касается оптимизации Sass. Да, Sass может оптимизировать ваш CSS. Но он не может оптимизировать селектор . 4-уровневый вложенный блок будет выводиться как 4-уровневый вложенный селектор. Sass не может изменить его, не создавая работу CSS. Вы, как автор, должны оптимизировать способ написания Sass для оптимизации вашего вывода. Я лично использую вложенность только ограниченным образом (функция убийцы в Sass для меня @extend с заполнителями). Однако, если вы действительно любите вложенность, вы можете в какой-то степени настроить ваш результат, используя ссылку Sass parent selector (или более новую @на-корень).

Насколько я знаю, ни Sass, ни Compass не имеют встроенного инструмента для анализа селекторов и предупреждения о них. Вероятно, возможно создать инструмент для этого (установите максимальную глубину и предоставьте предварительный процессор), используя AST. Более прямо, Google Page Speed ​​имеет имеющуюся функцию, которая предоставляет некоторую информацию. SCSS Lint имеет вариант вложенности. Там также CSS Lint. (Теоретически их можно добавить для запуска в конфигурации Compass on_stylesheet_saved, если вы еще не используете что-то вроде Grunt или Gulp).

Ответ 2

Просто подумайте о том, как вы хотите написать фактический селектор css. Не вставляйте все только потому, что он является дочерним элементом элемента.

nav li ul li a { 
    /* over specific, confusing */
}
.sub-menu a {
    /* add a class to nested menus */
}

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

Ответ 3

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

Чем сильнее вложен селектор, тем более конкретным является правило CSS (которое вы уже знаете). Поэтому, когда вы хотите "выкопать" это правило в какой-то момент, вам придется написать правило с равной (или большей) специфичностью дальше по каскаду, чтобы отменить первое. Если у вас есть идентификатор, это сделает его еще более специфичным (так что избегайте, если вы им не нужны, и знаете, что вам не нужно переопределять строку).

Чтобы следовать этому логическому завершению, не гнездайте, если вам не нужно. У вас нет правила:

.selector .another .yeah-another {}

Если это выполнит ту же работу:

.yeah-another {}

Это просто облегчает жизнь каждому (включая вас) по линии.

Ответ 4

Не вставляйте CSS. Мы чувствуем себя комфортно вложенными css, потому что это точно отражает то, что мы делаем в HTML. Вложенность дает нам контекст, что .some-child находится внутри .some-parent. Это дает нам некоторый контроль над каскадом. Но не более того.

Как утверждает SMACSS, вместо этого я буду использовать имена классов. т.е. используйте .child-of-parent вместо .parent .child или .parent > .child

Вложение плохое на практике может привести к чрезвычайно медленным страницам. Посмотрите, как github ускорил их diff-страницы. Самое меньшее, что вы должны сделать, это следовать правилам , в котором говорится, что вы не должны встраиваться выше 4 уровней.

Однако я бы сделал еще один шаг и сказал, что мы вообще не должны вставлять CSS. Я написал сообщение в блоге с моими мнениями. Надеюсь, это полезно.

Ответ 5

Мое мнение:

Скажите мне, что хуже на ваших глазах

из op

nav li ul li a {color: $textColor;}

или как было предложено

.nav-menuitem-menu-menuitem-link {color: $textColor;}

Итак...

Вопрос заключается в том, является ли "плохая практика" гиперссылкой в ​​SCSS? "(или это SASS?) Я говорю" нет". Но это вспомогательный аргумент.

Практика WORSE заключается в выходе из SASS (или это SCSS?) вывода, в нем состояние, управляемое машиной, для производства.

S * SS - это единственный инструмент в вашей сумке трюков, отличный от Notepad ++ или Git или Chrome. Его роль заключается в том, чтобы сделать вашу жизнь немного легче, доведя некоторые общие концепции программирования до уровня построения css. Эта роль НЕ строит ваш css. Вы не можете ожидать, что он сделает вашу работу за вас и создаст полностью пригодный для использования, читаемый и исполняемый результат.

Гнездо как можно больше и глубже, затем следуйте Хорошей практике...

... который будет проходить через ваш css после и ручной настройкой. Тестирование, сборка и т.д. С помощью вашего файла с гиперссылкой. И когда S * SS создает мой первый пример выше, дайте этому якорю класс и назовите его nav .class.

Ответ 6

Хотя это не прямой ответ на ваш вопрос, вы можете держать в большой степени вложенные сасы в своих целях, но при этом использовать @at-root. Проверьте здесь.

.parent {
  @at-root {
   .child1 { ... }
   .child2 { ... }
  }
} 

// compiles to ... 

.child1 { ... }
.child2 { ... }