Например вот так

.button_theme_islands
{
    &.button_button_search
    {

    color: rgb(255, 202, 0) 
    border: 1px solid rgb(255, 202, 0)

    }

}

т.е. создаешь в папке common_blocks папку button, в ней папку _theme с файлом button_theme_islands.styl

Изначально предполагается, что islands — это конкретная тема. Поэтому если хочется что-то менять, то есть смысл скопировать _theme_islands под новым названием и там менять под себя.

А нельзя наследоваться от неё? ;-)

@zxqfox на свой страх и риск. Стили темы не рассматриваются как API и не гарантируются между версиями библиотеки.

@tadatuta Странное решение. Не сложно же циферку щелкнуть, если что-то сильно меняется?

Как «сильность» измерять? Кто-то завязался на цвет и оформил свои блоки аналогично, кому-то измерения размеров взорвут макет. По сути придется любое изменение считать мажором.

@tadatuta Передергиваешь ;-) То, что надо решить что именно считать мажором, что минором — это бесспорно, но это не что-то невозможное, просто надо договориться. Опять же, темы это не только CSS, но и HTML, JS.

Например, мажорные изменения:

• смена логики (ховеры, фокуседы?);
• смена анимаций;
• сильная смена шаблонов (структуры блоков, структуры элементов?);
• и т.д.

Минорные:

• смена реализации, без изменения отображения;
• смена оттенков (не цветов) — а когда последний раз менялись?),
• новые стили (что-то непокрытое ранее, jaws, i18n, etc.).
• новые элементы, незначительные (не трогающие структуру блоков: теги, атрибуты, пр.) изменения в элементах.

Патчи: в основном, правки багов.

@tadatuta Если коротко, то изменения оттенков цветов и правки размеров на единицы нельзя считать мажорным изменением, потому что это улучшения, и минорные изменения не редко что-то взрывают, на то они и минорные. Если же изменения идут на порядки, или же изменения структурные, и логические — то их явно следует считать мажорными.

@zxqfox не надо так... ренейм темы сильно лучше. Или как бутстрап менять циферку раз в год

@voischev Т.е., других вариантов нет? ;-) Можно, например, как хром — каждую неделю мажорную версию выпускать ;)

@zxqfox есть конечно варианты. Но что-то гарантировать сложно же ;) :)

@voischev Жить вообще сложно, а жить для других — так вообще. Но если уж делаем открытую библиотеку — то непонятно, почему на часть реализации у нас семвер работает, а на остальное — нет. Избирательная логика какая-то. Проблемы мозаичного мышления (а о другом, как известно, не известно, по определенным причинам, о которых не говорят в слух).

Я же привел список характеристик, которые вполне можно оценить: цвета и оттенки (в процентах по hsl, например), изменения структуры (добавление новых элементов, удаление имеющихся, изменение схемы), изменение стилей (паддинги, маржины, бордюры, и др. — например, добавление бордюра к элементу явно сильно отличается от его изменения с 2пкс на 3пкс, верно?), по скриптам есть обкатанные методики оценки, можно их взять как есть. Это все формализованные характеристики, которые можно обсуждать без оценочных субъективных характеристик (типа слабо, сильно, очень, не очень, и т.д.).

@zxqfox может стоит тогда тему выносить в отдельную репу?

@voischev все тебе лишь бы выносить! а делать кто будет? ;-)

@zxqfox так я так делаю) bem-components - это каркас из js+html. либа есть про стили, которая ушла давно по семверу сильно вперед ;)

@voischev Надеюсь, что ты не предлагаешь тему вынести из bem-components ;-)

@zxqfox почему надеешься? Зачем эта тема в библиотеке? Чем плохо повышение модульности? Почему не завести репозитории с разными темами на bem-components?

@apsavin С 99% уверенностью могу сказать, что мы её забросим в момент разделения репозиториев.

@zxqfox Значит она никому не нужна?

@apsavin Не совсем так, я бы сказал, что в качестве отдельного пакета она почти никому не нужна. И у этих «почти никого» врядли будет время на поддержку yet another library. Можно потолковать об этом на следующем бемапе или тип того.

@zxqfox А в чем разница для этих "почти никого", в отдельном пакете файлы или в bem-core?

@apsavin В том, что в отдельном пакетике поддержка будет целиком на плечах пользователей. :-)

Тема islands нужна, как минимум, проектам Яндекса и она будет поддерживаться нами. Действительно, её можно вынести в отдельный пакет bem-components-theme-yandex и переименовать из islands в yandex.

//cc @veged как ты смотришь на такое развитие событий в bem-components 3.0 ?

Я против по ряду причин:

1. Наличие в репозитории темы вообще никак не аффектит пользотелей, которым она не нужна.
2. Тестировать изменения в bem-components без темы по умолчанию станет сложнее.
3. Сборка для тех пользователей, которым тема подходит заметно усложнится.
4. Разработка потребует синхронизации коммитов, документации, релизов в 2 репозитория — лишние накладные расходы на пустом месте.

Единственная причина, по которой вынесение может иметь смысл — это раздельное версионирование темы и ядра. Но вряд ли те, кто не используют тему, сильно пострадают от того, что инкрементнется мажор, затрагивающий лишь тему.

@vithar +1 к @tadatuta

и по изначальной теме @koloskof +1 к ответу @tadatuta: _«Изначально предполагается, что islands — это конкретная тема. Поэтому если хочется что-то менять, то есть смысл скопировать _themeislands под новым названием и там менять под себя.»