Comments 23
при большом количестве элементов в dom, браузер начнет задыхаться. Именно поэтому все данные сразу и не выдаются, ну и еще больше для экономии траффика.
Повторюсь: Если данных будет очень много будем использовать другой способ или комбинировать.
На данный момент при текущем положении дел это способ идеален.
Для теста на большое количество данных есть отдельная страница: search.archimeta.ru/search_extrime.htm
Тестируйте.
На данный момент при текущем положении дел это способ идеален.
Для теста на большое количество данных есть отдельная страница: search.archimeta.ru/search_extrime.htm
Тестируйте.
Какой смысл отказываться от переноса логики с JS на CSS, если вы все равно оставляете джаваскриптовую обертку?
Поскольку мы всё равно в конечном итоге играемся с CSS свойством display так почему бы это не делать самому CSS. Да и getElementsByClassName не у всех современных браузеров есть а этот метод поддерживают почти все.
Это какой браузер вы современным назвали? :) Но и для него есть костыли, например
web.izjum.com/getelementsbyclassname-on-javascript
web.izjum.com/getelementsbyclassname-on-javascript
Тоже вариант.
Классно вышло. И работает как то шустрее
При больших объёмах он будет притормаживать при каждом выборе. Поэтому я оставил кнопку. Сначала выбрать параметры а потом запросить результат.
Вот для сравнения на больших объемах.
Мой вариант: search.archimeta.ru/search_extrime.htm
Вариант SelenIT2: search.archimeta.ru/search_extrime2.htm
Мой вариант: search.archimeta.ru/search_extrime.htm
Вариант SelenIT2: search.archimeta.ru/search_extrime2.htm
На самом деле CSS-only вариант вполне можно ускорить, как минимум чуть-чуть поменяв структуру.
Вот, можно сравнить, разница должна быть заметна:
— старый вариант: dabblet.com/gist/1528271
— исправленный вариант: dabblet.com/gist/1528281
Тут смысл в том, что селектр «~» — не самый быстрый, потому для длинного списка для последних пунктов движку браузера приходится долго-долго идти по всему дому в самое начало. Но если добавить враппер и матчиться уже на него, то это очень сильно облегчает жизнь движку: ему в таком случае надо смотреть на минимальное количество элементов.
Вот, можно сравнить, разница должна быть заметна:
— старый вариант: dabblet.com/gist/1528271
— исправленный вариант: dabblet.com/gist/1528281
Тут смысл в том, что селектр «~» — не самый быстрый, потому для длинного списка для последних пунктов движку браузера приходится долго-долго идти по всему дому в самое начало. Но если добавить враппер и матчиться уже на него, то это очень сильно облегчает жизнь движку: ему в таком случае надо смотреть на минимальное количество элементов.
(оба варианта сделал на dabblet.com чтобы можно было адекватно их сравнивать в одинаковом окружении)
Я думаю больше ресурсов тратится на отображение/скрытие элементов на странице чем на отработку непосредственно правил. Поэтому с каждым изменением свойств элементов приходится перерисовывать страницу. Если новое правило ничего не меняет то отработка проходит незаметно. FF 8.0
Нет :) В данном случае на перерисовку тратится некоторое время, но на поиск элементов времени таки тратится больше: это можно заметить если открыть оба примера и, выбрав какой-то радиобатон (кликнув и нажав таб для активации фокуса), попереключать их с клавиатуры быстро нажимая влево-вправо-влево-вправо. В Вебкитах исправленный вариант работает моментально, не исправленный — тормозит. В ФФ (у меня 9.0) исправленный вариант не моментален, но заметно (более чем в 2 раза) быстрее, чем не исправленный.
Это, кстати, достаточно хороший тест-кейс, демонстрирующий влияние одного только поиска элементов по селектору в CSS на время рефлоу. И видно, что правильно использоанные селекторы в больших проектах могут дать ощутимый рост производительности, особенно если используется какая-то анимация, которая может триггерить рефлоу. Вполне можно использовать как пример для пропаганды БЭМ :)
Это, кстати, достаточно хороший тест-кейс, демонстрирующий влияние одного только поиска элементов по селектору в CSS на время рефлоу. И видно, что правильно использоанные селекторы в больших проектах могут дать ощутимый рост производительности, особенно если используется какая-то анимация, которая может триггерить рефлоу. Вполне можно использовать как пример для пропаганды БЭМ :)
Id говорят быстрее.
Ну там даже в таблице видно, что id не везде быстрее, а где быстрее — то разница минимальна. При этом проблемы с использованием id того не стоят совершенно: классы гораздо, гораздо гибче. Потому id для вёрстки, на самом деле, бессмысленно использовать: только в качестве якоря и/или для использования :target, во всех остальных случаях оправданнее использовать классы.
Sign up to leave a comment.
Пусть css ищет или база данных в HTML 2