Доброго времени суток. Где можно посмотреть UI Elements Naming Convention (соглашение как называть тот или иной контрол графического интерфейса), используемый в Яндексе?

Здравствуйте. Я прототипирую в Axure. Портал крупный и сложный. Внедряю в прототип бэм.

Сейчас возникла задача описать прототип многоуровневым вложенным списком. Примерно так: Раздел 1 -Шапка --лого --навигация -блок1 --эл1 --эл2

То есть, это тот же самый прототип, просто описан он словами. Начал майндмэпить в xmind. Столкнулся с банальной проблемой - если меняется блок, то приходится в ручную его править везде, где он есть. Решения два: где-нибудь на холсте описать блок (перечислив его элементы) и либо 1) от нужных элементов пустить стрелочки в те страницы, где они встречаются, 2) на страницах просто указывать название блока и перечислить только нужные элементы этого блока тупо их порядковыми номерами. Начал работать по второму решению. Перечислять элементы блока необходимо, потому что, допустим, один и тот же блок выглядит по разному при разных правах доступа. Например, у админа портала подгрузятся кнопки, позволяющие редактировать элементы. Про модификаторы вообще молчу - их несколько и у блока, и у элементов.

И опять столкнулся с банальной проблемой. Указав на страницах чисто блоки с номерами их элементов, мне все равно приходилось всё и везде править в ручную когда менялась нумерация или названия блоков.

Теперь, что мне нужно (обязательно первое условие, последующие были бы просто очень приятным дополнением): 1) возможность добавления мастер шаблона для блоков. То есть, прописал один раз блок, а потом расклонировал его по разделам карты ума - и клоны автоматически апдейтятся при изменении мастер-шаблона. 2) возможность быстро менять список нужных элементов в клонах. Хотя бы галками, или галками в выпадающем списке. 3) возможность сопоставить словесной карте ума графические эквиваленты, чтобы потом можно было нажать на кнопку "сгенерировать" и вуаля - мы имеем наглядный графический прототип портала.

Есть ли такие инструменты? Или придётся разрабатывать свой инструмент (думаю, с помощью простого html и работой с файлами, а не программой вроде xmind это вполне реально). Если да, то как лучше создать такой инструмент (или алгоритм действий), учитывая что я дизайнер и программировать не умею (разбираюсь только в html)

Спасибо!

Здравствуйте!

Подскажите пожалуйста, как правильно организовать код для стилизации hover состояний у элементов блоков.

Структура такая:

b-control
    __title
        b-control__title.less

   __descr
       b-control__descr.less

b-control.less

При таком подходе получается, чтобы навесить при наведении на блок b-control hover для заголовока b-control__title я должен внутри файла b-control.less сделать следующую запись:

.b-control {
    &:hover {
       .b-control__title {
           color: @green;
       }
   }
}

Мне кажется не правильным прописывать внутри файла b-control.less стили для состояния элемента, который описан в другом файле. Как правильно с точки зрения БЭМ реализовать такой кейс? При условии что навешивать на сам заголовок hover я не могу, нужно чтоб при наведении на контейнер он изменялся.

Здравствуйте. По этой ссылке http://jsbin.com/xulado/7/edit размещено два экземпляра виджета табов. Примеры выдернуты из рабочего проекта. Цель — сделать виджеты, которые не поломают верстку и JS. К стилю контейнеров применены селекторы тем. Интересует насколько приемлемо с точки зрения методологии БЭМ применять такой способ изменения внешнего вида блоков. Может будет лучше дописывать к каждому элементу модификатор?

У меня есть некий блок с Голосованием (.vote). В нем есть две кнопки "За" и "Против" (button.voteaction). Так же у меня есть блок Кнопка (.btn). Кнопки "За"/"Против" должны быть блоками Кнопка (button.voteaction.btn) - т.е. микс получился. При клике на кнопки "За" или "Против" я хочу, что бы они выделялась цветом, например зеленым. Для этого у блока Кнопка есть модификатор green (.btn_theme_green) Т.е. при клике на voteaction с помощью JS я добавляю ей модификатор voteaction_active, но при это я должен добавить и класс btn_theme_green. Использовать в JS классы btn и btn_theme_green не хочется ибо кнопки могут быть заменены на другие (например, .btn34).

Скажите как правильно огранизовать взаимодействие этих двух блоков в JS?

Здравствуйте. Занимаюсь сабжем. Я - дизайнер, на проекте совмещаю две работы - проектирую/прототипирую интерфейс, а после согласовки - рисую его красиво. Я - ни разу не программист/верстальщик/кто-либо другой.

Давно вожу жалом в сторону БЭМ; он привлекает меня даже не потому, что иногда приходится общаться с программистами, а потому, что вижу в нём помощь в самоорганизации. Проблема старая и всем знакомая - проект крупный, и всё в башке нереально удержать, приходится как-то структурировать.

В общем, довольно прелюдий, вот мой ламеронубский вопрос.

Очевидно, что шапка сайта - блок. Она есть на всех страницах. А внутри шапки еще довольно-таки самостоятельные блоки: логотип, выпадающий список с языками, меню навигации, поп-ап с формой логин/пароль/войти, поп-ап с регистрацией. Или же эти объекты нужно считать элементами блока "шапка"?

То есть, у меня проблемы с логикой методологии, помогите разобраться.

Второй вопрос из этой же серии. В статье на хабре ( http://habrahabr.ru/company/yandex/blog/234905/ ) сказано:

Примеры элементов: навигационное меню (блок), содержащее пункты меню (элементы), таблица (блок), внутри которой строки, ячейки и заголовки (элементы).

В таблице - ячейки. Ячейка - элемент. Допустим, внутри ячейки мы имеем какой-то интерфейс, допустим - форму ввода каких-то данных, грубо говоря - пару полей и кнопка вроде "сохранить". Вот этот интерфейс внутри ячейки считать блоком? Блоком со своими элементами? То есть, может ли элемент внутри себя иметь блок? Как их в таком случае лучше называть? Допустим, таблица - блок с названием b-table. Следовательно, имя ячейки - b-table__cell. А как тогда назвать нашу формочку внутри ячейки, учитывая что она тоже блок? b-table-cell-form? b-cell-form? b-form?

После нескольких попыток подобраться к данной технологии, стало ясно - отсутствие документации никак не продвинет технологию в массы.

Читать, что-то на форумах, в каких-то статьях и не понятном разделе "Руководства" - очень интересно, но кроме каши не дает ничего.

Первая проблема, это из-за развития технологии, что-то очень быстро устаревает, и получается, читая статью, изучаешь уже не актуальный подход.

Нет примеров кратких но самодостаточных, большинство тем возникали на форуме.

Нигде не сказано, что новым трендом в данной технологии является выделения mVc в отдельный bundle design. Изобилие bem и enb в разных статьях, в документации должно быть что-то одно.

Ситуация вводящая в ступор:

• создаем страницу bem create -l desktop.bundles -b index на выходе получаем один файл index.bemjson.js;
• компилируем bem make, на выходе еще получаем 10 файлов.

WTF? Что за файлы, за что отвечают, являются ли они build файлами и не подлежат ручному редактированию? Почему финишные файлы называются по разному, например index.html _index.css _index.js? Нельзя ли результат компиляции, что не подразумевает ручного редактирование перенести в подпапку distr например?

Очень нужна документация, по каждой технологии, устаревшие технологии документировать не первостепенно. Показывать примеры и с подгрузкой данных через API, и динамическое изменение DOM.

Из того, что не критично, но хотелось бы получить:

1. право переопределять константы BEM_CLASS и BEM_PARAMS_ATTR, ну не нравится мне i-bem и data-bem, хочу получить js и data-js;
2. не нравится именование модулей i-bem__dom, i-bem как-то не вписывается в Code Style.

Из документаций которые покрывают 99% вопросов мне нравится https://docs.djangoproject.com/en/dev/ http://symfony.com/doc/current/index.html http://git-scm.com/doc - это те документации, которые рассказывает и о различных приемах, и о назначении, и полноценные use case.

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