Comments 20
Годно, продвигайся в том же духе!
До меня дошли слухи, что многие фронтэндеры не особо любят цсс-фреймворки за то, что они не namespace-friendly, так сказать.
Тоесть, если бы мне, к примеру, очень хотелось легко и просто взять меню из допустим бутстрапа, то есть риск нарваться на то, что классы .nav .active уже заняты чем-то.
Следовательно, нужно перекомпилить весь бутстрап в что-то вида:
.btsp-nav .btsp-active.
Однако, это убьет весь JS который писался основываясь на этом.
Поэтому, если вы решите эту проблему, то будет круто.
Если решили, то ее стоить как-то рекламировать, потому-что я не понял как у вас обстоят с этим дела.
Discl: я в верстке и JS разбираюсь как краб в оленях, поэтому прошу прощения если фигню сморознул.
Тоесть, если бы мне, к примеру, очень хотелось легко и просто взять меню из допустим бутстрапа, то есть риск нарваться на то, что классы .nav .active уже заняты чем-то.
Следовательно, нужно перекомпилить весь бутстрап в что-то вида:
.btsp-nav .btsp-active.
Однако, это убьет весь JS который писался основываясь на этом.
Поэтому, если вы решите эту проблему, то будет круто.
Если решили, то ее стоить как-то рекламировать, потому-что я не понял как у вас обстоят с этим дела.
Discl: я в верстке и JS разбираюсь как краб в оленях, поэтому прошу прощения если фигню сморознул.
Серьёзные front-end фреймворки создают абстрактный уровень над всем стеком html/js/css.
Если вы создаёте какие-то специфичные кнопки, радиогруппы, то следует предоставлять и описание необходимого DOM дерева в формате, подходящем для автоматизированного «приклеивания» к существующей вёрстке. Обновление дизайна на новые версии как правило требует изменения и html, но по-хорошему он должен меняться сам. Шаблоны должны на абстрактном уровне описывать какие блоки мы хотим где видеть, а сторонняя библиотека должна собирать из этого конечный шаблон.
Также приличная библиотека должна сама разруливать зависимости и влияния классов на внешний вид.
Если вам нужно будет сменить внешний вид какой-то кнопочки, вы же не будете перебирать все свои шаблоны и менять html — это не технологично.
Лично я не люблю «css фреймворки» только из-за названия. Никаких фреймворков там нет, это скорее просто библиотеки. Чего я не пойму так это почему люди так избегают прекрасного слова «библиотека».
На больших проектах эти библиотеки к сожалению не работают, так как придают проектам безумную инертность и безмерно увеличивают трудозатраты по поддержке.
Если вы создаёте какие-то специфичные кнопки, радиогруппы, то следует предоставлять и описание необходимого DOM дерева в формате, подходящем для автоматизированного «приклеивания» к существующей вёрстке. Обновление дизайна на новые версии как правило требует изменения и html, но по-хорошему он должен меняться сам. Шаблоны должны на абстрактном уровне описывать какие блоки мы хотим где видеть, а сторонняя библиотека должна собирать из этого конечный шаблон.
Также приличная библиотека должна сама разруливать зависимости и влияния классов на внешний вид.
Если вам нужно будет сменить внешний вид какой-то кнопочки, вы же не будете перебирать все свои шаблоны и менять html — это не технологично.
Лично я не люблю «css фреймворки» только из-за названия. Никаких фреймворков там нет, это скорее просто библиотеки. Чего я не пойму так это почему люди так избегают прекрасного слова «библиотека».
На больших проектах эти библиотеки к сожалению не работают, так как придают проектам безумную инертность и безмерно увеличивают трудозатраты по поддержке.
Задача, собственно, стоит такая, чтобы сложность поддержки уменьшить. npm, на мой взгляд, с этой проблемой прекрасно справляется. Аналогичного для css пока не было, на сколько я знаю.
Ни коим образом не умаляю достоинства вашего программного продукта и вашего труда, и даже больше скажу — мне нравится исполнение, но это другой уровень абстракции — более низкоуровневый, когда я всё ещё должен быть в курсе какие классы писать, поддерживать html вместе с css.
Это моё личное отношение к слову «фреймворк» — его суть я вижу несколько шире.
Это моё личное отношение к слову «фреймворк» — его суть я вижу несколько шире.
Я решал данную проблему вешая js не на классы а на атрибуты data-
По моему для этого можно использовать так же атрибут role.
Возможно, я ошибаюсь, пожалуйста поправьте меня.
По моему значения role уже предопределены и ограничены в спецификации.
Да, тем не менее нагуглил следующий подход blog.nocorp.me/2011/12/25/role/
Используется плагин github.com/kossnocorp/role
Используется плагин github.com/kossnocorp/role
Расскажите, пожалуйста, об этом подробнее.
Все просто. Делаем не так:
А так:
Когда необходимо использовать `.parent()` используем примерно так:
Это позволяет сильно менять верстку не сломав js.
<script>
$('.login').find('.button').click(...);
</script>
<div class="login">
<button class="button"></button>
</div>
А так:
<script>
$('[data-login]').find('[data-login-button]').click(...);
</script>
<div class="login" data-login>
<button class="button" data-login-button></button>
</div>
Когда необходимо использовать `.parent()` используем примерно так:
<script>
$('[data-login]').find('[data-login-button]').click(function () {
$(this).parents('[data-login-overlay]').css(...);
});
</script>
<div class="login" data-login>
<div class="overlay" data-login-overlay>
<button class="button" data-login-button></button>
</div>
</div>
Это позволяет сильно менять верстку не сломав js.
Интересно, а есть ли какие-то сравнения скорости выборки по атрибутам, например, с выборкой по классам, не в курсе?
Кстати, ваш метод наверное идеологически правильней, чем вариант с role, и писать меньше.
А можно сделать выборку, например только тех элементов, где есть data-item и data-item-active. Как это будет выглядеть?
Заранее спасибо.
А можно сделать выборку, например только тех элементов, где есть data-item и data-item-active. Как это будет выглядеть?
Заранее спасибо.
Если вы создаёте какие-то специфичные кнопки, радиогруппы, то следует предоставлять и описание необходимого DOM дерева в формате, подходящем для автоматизированного «приклеивания» к существующей вёрстке
Мне кажется, я именно это и имел ввиду.
А вообще, спасибо за информацию к размышлению.
Интересное решение. Небольшой совет: поменяйте интерфейс на английский при записи ролика (что на главной странице вашего фреймворка) на английском языке.
Sign up to leave a comment.
В поисках идеального css-фреймворка. Maxmertkit widget manager