Вы же понимаете, что идеальный солнечный элемент — это абсолютно черная поверхность? И чем идеальнее тем чернее будет экран? О какой фиче вообще может идти речь если экран не будет выдавать требуемую яркость.
То, что материал никак не влияет — очевидное вранье.
Простите, а чем не подошёл baron, ссылка на который даже есть в статье? Удовлетворяет всем пунктам кроме последнего — отключение на мобильниках «из коробки», что решается трёхстрочной обёрткой.
Вы не пробовали прикинуть, у скольких пользователей от -prefix-border-radius, набранных вами, сайт стал лучше отображаться, и насколько увеличилось суммарное время загрузки у всех остальных пользователей из-за лишних байтов кода?)
На высоконагруженных сайтах получаются (суммарно) десятки часов в месяц.
Главный минус любой такой штуки один: CSS перестаёт быть самостоятельным и его уже нельзя просто взять и переиспользовать — за ним тянутся препроцессоры.
Облегчаем css на 500 байт и увеличиваем js на 2 500 + увеличиваем время инициализации приложения на 40 мс — странная затея ради нескольких пользователей.
Если кнопка должна быть одинаковой везде (или хотя бы в 2-3 разных блоках) — делаем отдельный блок для кнопки.
Если какая-то кнопка должна быть в авторском стиле — оставляем авторский стиль не примешивая к нему собственный.
Что касается поддержки внешнего (к кнопке) блока, то тут важно понять следующее: блок это не ветка DOM дерева, а лишь её часть. Поддерживаться должна только она, причём из расчёта, что на неё можно приклеить хоть хвойные иголки, хоть листы дуба.
О возможности смены листиков разработчика блока должны предупредить заранее, конечно.
Предположим, я хочу, чтобы все кнопки на сайте у меня выглядели не так, как это хочется автору блока, а в соответствии с единым, продуманным стилем.
В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде» и вставляете её в любой блок где она вам нужна.
В том же bembl есть блок b-link, который навешивается на большинство ссылок.
Так же я искренне не понимаю зачем используя БЭМ:
1. Использовать префиксы в названиях блоков;
2. Отказываться от контекстной зависимости внутри блока;
3. Отказываться от селекторов по псевдоклассам и псевдоэлементам.
Методология она потому и методология, что является набором принципов, а не догм и синтаксических правил.
Шикарное решение! Правда, кроме неподдержки ie8, есть ещё один досадный недостаток — заголовки вообще перестают реагировать на мышь, и в них даже текст нельзя выделить. Но в комментарии CSS добавлю.
> Я о том и говорю, что если скроллбар попал в окружение таким образом то, что-то пошло не так.
Никак нет) Тенденция превращения длинных многостраничных сайтов в одностраничное приложение есть, и это факт. В таких приложениях у окна скролла нет вообще.
Это можно сделать форком, но независимость baron от jQuery — ключевая его особенность и одно из основных наших требований.
Скажу больше: в будущей стабильной версии, скорее всего, baron вообще никогда не будет использовать jQuery у себя внутри, поскольку требование IE8+ делает возможным использование plain js для добавления классов, стилей и обработчиков событий без заметного увеличения объёма кода.
Сейчас единственный объект в глобальном пространстве — baron с двумя методами. Всё остальное в замыканиях. О других библиотеках baron js мне не известно, поэтому ограничение — только на глобальную переменную baron.
То, что материал никак не влияет — очевидное вранье.
Теоретически, то же самое можно сказать про ширину.
Если там чего-то не хватает, что-то не работает — пишите ишью, или пишите мне любыми доступными средставми коммуникации — я с радостью поправлю.
Контролы сделаю в ближайшее время.
Также подключение горизонтального скролла описано в readme.
Но вы можете вычислить и точное значение если хотите — это offsetWidth — clientWidth при обнуленном бордере.
Внешний скролл / скролл произвольных размеров и позиций также возможен.
diokuz.github.com/baron
На высоконагруженных сайтах получаются (суммарно) десятки часов в месяц.
Если какая-то кнопка должна быть в авторском стиле — оставляем авторский стиль не примешивая к нему собственный.
Что касается поддержки внешнего (к кнопке) блока, то тут важно понять следующее: блок это не ветка DOM дерева, а лишь её часть. Поддерживаться должна только она, причём из расчёта, что на неё можно приклеить хоть хвойные иголки, хоть листы дуба.
О возможности смены листиков разработчика блока должны предупредить заранее, конечно.
В этом случае вы делаете блок «кнопка-которая-должна-выглядеть-примерно-одинаково-везде» и вставляете её в любой блок где она вам нужна.
В том же bembl есть блок b-link, который навешивается на большинство ссылок.
Так же я искренне не понимаю зачем используя БЭМ:
1. Использовать префиксы в названиях блоков;
2. Отказываться от контекстной зависимости внутри блока;
3. Отказываться от селекторов по псевдоклассам и псевдоэлементам.
Методология она потому и методология, что является набором принципов, а не догм и синтаксических правил.
barTop отменён, позиционирование делается через css родителю bar`а (см. папку demo в текущей версии baron)
Спасибо за пул-реквест)
Есть опыт общения с багтрекерами вебкита и ff — тикеты висят годами, ибо не критичные.
Один только баг анимации псевдоэлементов в вебките правили 2 года и 3 месяца — и это только до попадания в канарейку хрома.
Никак нет) Тенденция превращения длинных многостраничных сайтов в одностраничное приложение есть, и это факт. В таких приложениях у окна скролла нет вообще.
Скажу больше: в будущей стабильной версии, скорее всего, baron вообще никогда не будет использовать jQuery у себя внутри, поскольку требование IE8+ делает возможным использование plain js для добавления классов, стилей и обработчиков событий без заметного увеличения объёма кода.
Сейчас единственный объект в глобальном пространстве — baron с двумя методами. Всё остальное в замыканиях. О других библиотеках baron js мне не известно, поэтому ограничение — только на глобальную переменную baron.