CSS: изменение набора правил против использования селекторов для переключения классов / применения стилей

Question

В последнее время я удивлялся редактированию стилей элементов не путем переключения их классов на dom, а путем изменения фактического набора правил для класса или селектора css.Поэтому вместо чего-то вроде

$('.some').hide()

или

$('.some').addClass('hidden')

Почему бы не изменить правило напрямую с помощью document.styleSheets и прочего?Разве этот подход не был бы в целом более производительным, по крайней мере, со многими элементами, так как мы позволили бы браузеру обрабатывать изменения набора правил изначально?

Вы можете, например, добавить стиль к .some, например display: none; и все .some элементы будут немедленно скрыты.Нет необходимости перебирать все эти элементы в js и скрывать их вручную (как в примере выше).

Непосредственное изменение наборов правил будет более вероятно поощрять классы, которые осведомлены о контексте (или как бы вы это ни называли).), поскольку вы скрываете все #persons > .item или что-то в этом роде.

Я до сих пор не знаю лучших практик в отношении классов, которые названы с учетом контекста, как, например, имена элементов управления, такие как .calendar .ticket.item, в отличие от отдельных функциональных классов, таких как .hidden .left .green, поскольку мне обычно нужны оба типа соглашений.

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

Кроме того, что, по вашему мнению, является хорошей практикой, что вы считаете хаком?

кашель javascript и взлом кашель

Answer 1

Манипулирование document.styleSheets сложно из-за различных реализаций и отсутствия API селектора правил.В настоящее время, если вы хотите манипулировать правилом в таблице стилей, вы должны пройти через этот процесс:

iterate over document.styleSheets
    iterate over rules within current styleSheet object
        if rule matches our class, edit the rule styles

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

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

Итак, манипулирование styleSheets теперь выглядит не слишком привлекательно, не так ли?Придерживайтесь переключения классов, поверьте мне.Использование jQuery и современных API-интерфейсов, таких как querySelectorAll, значительно ускоряет работу, а браузер по-прежнему выполняет всю тяжелую работу, такую ​​как пересчет значений стилей.

Answer 2

Такой хитрый вопрос: (

Но если взять, например, шаблон, у него есть несколько стандартных классов, таких как:

/* Hide from both screenreaders and browsers: h5bp.com/u */
.hidden { display: none !important; visibility: hidden; }

/* Hide only visually, but have it available for screenreaders: h5bp.com/v */
.visuallyhidden { border: 0; clip: rect(0 0 0 0); height: 1px; margin: -1px; overflow: hidden; padding: ; position: absolute; width: 1px; }

 /* Hide visually and from screenreaders, but maintain layout */
 .invisible { visibility: hidden; }

Там, где это сложно, если вам нужно что-то скрывать из-за JS, то вы должны скрывать это ТОЛЬКО с JS. Тогда он будет работать, если JS отключен. Если это что-то, что не зависит от JS, то вы скрываете это в HTML.

Итак, функция JS = скрыть с помощью JS (либо с помощью JS, либо добавив классы скрытия)

Базовый HTML скрыть = скрыть с помощью класса HTML

Переключение стилей против переключения JS

В основном JS-переключение дает вам возможность добавлять эффект и т. Д., Просто используя предопределенные классы, которые несколько ограничивают это. Но хотелось бы увидеть некоторые сравнения ресурсов:)