Ещё стоит помнить, что термин «каскадный» из названия технологии, это не про составные селекторы «div .class», а про каскадное применение правил из разных деклараций. БЭМ эту идею не убивает, а использует на полную катушку. Использования селекторов по БЭМ неймингу, позволяет избегать неоправданного повышения спецефичности селектора, при сохранении изолированности. Таким образом, достигается более предсказуемое применение стилей.
Я именно это и сказал. Однако с точки зрения пользователя существует проблема: «Используя приложения на Андроид, я не могу предугатать что произойдёт при нажатии кнопки Назад если открыто боковое меню.» Пользователю без разницы чья эта проблема: приложения, концепции или экосистемы. Но репутация страдает в первую очередь не у приложения.
Проблема в том, что разработчики приложений реализуют поведение для кнопки по разному. Действительно, во многих приложениях (Gmail, прочие стандартные) кнопка назад скроет боковое меню, а, например, в feedly свернёт приложение. И это жуть как не интуитивно и бесит.
В дополнение в защиту: модуль написан с помощью модульной системы ymodules, использует фреймворк i-bem.js являющегося частью bem-core. Простите, чтобез ссылок, я с телефона. Просто загуглите что это за стек такой :)
Причём тут Яндекс? С этим вопросом надо было обращаться в правоохранительные органы. А вам озаботиться безопасностью своих учётных данных надо. Где и как вы слили свой пароль от Яндекса даже самому Яндексу не может быть известно.
Ну выбирать то, скорее всего, будет не кондиционер, конечно. Он только заранее уведомляет, что ему в принципе требуется регулярное техобслуживание и сигнализирует о его необходимости в ближайшее время или в случае нештатных ситуаций.
Человек может самостоятельно выбрать обслуживающую фирму и предоставить её агенту доступ к этим сигналам или же доверить этот выбор ещё одному виртуальному агенту, оставив за собой лишь право окончательного принятия решения.
Оба ваших негативных сценария действительно возможны при неправильном проектировании взаимодействия. Не допустить их — как раз одна из задач составления онтологий.
Возможно ли это? Незнаю. Но ничто не мешает мечтать об этом и пытаться претворить в жизнь.
Ох как это знакомо. Испытывал подобное с другим стеком технологий. Сначала куча материалов в несколько подходов и только после некоторой накопленной массы знаний очередной подход сделать что-то на практике увенчался успехом и более глубоким познанием стека.
Не совсем так. Я конечно слегка слукавил и как минимум интересовался происходящим в мире фронтэнда. Это не относилось напрямую к мои рабочим обязанностям поэтому погружения никогда не было. Тем не менее фреймворки, библиотеки, системы контроля версий, менеджеры пакетов, сборщики проектов, полифиллеры, транспилеры и даже системы контейнеризации мне знакомы. Про что то я просто читал статьи, где-то углублялся в документацию и пробовал что-то сделать.
Параллельно по работе в мультипроектной среде на 150 человек стали выявляться потребности общих интерфейсов и компонентов. Я долго блуждал в области living style guides, atomic design и прочего добра. В процессе я натолкнулся на БЭМ и показалось, что он подходит для решения такой задачи. Попытки понять что из себя представляют технологии стека по документации и видеозаписям были слегка безуспешными. Сложилось популярное впечатление, что это мощная сложная штука решающая проблемы Яндекса и что понять что же там происходит довольно сложно. Попытки были прекращены, но глубоко засела мысль, что это то что нам подходит. Второй подход был уже более с практической стороны. К этому моменту я подтянул знания по вёрстке и решил сделать нечто конкретное. Результат в репозитории, проект оценен на конкурсе БЭМ проектов а у меня в голове осталось понимание принципы работы технологий стека.
Сегодня переработанный вариант этого меню интегрируется мною в существующий проект на angular, со сборкой на gulp и browserify. Завтра этот же компонент будем подключать на другой проект с requirejs и kendo ui с беком на ASP.NET. В итоге мы проверим применимость технологий стека для поддержки общих компонентов в общей стилистике на довольно разных проектах. Сейчас это два SPA проекта, но если следующий потребует рендеринга шаблона на сервере этого легко можно добиться.
Так то можно всё в одном файле писать. Здравый баланс всегда стоит соблюдать.
Выносить следует всё, что кому-то может не понадобится и это можно исключить из конечной сборки.
Очень актуально для общих библиотек.
На проекте, скорее всего, раскладывание всего и вся по папочкам окажется избыточным.
Ещё раз сделаю акцент. Я не верстал до этого вообще ничего. Не сделал ни одного сайта или приложения. И программистом (ни на js ни на чём либо ещё не был). Мой бекграунд:
* годы админства/эникейства со скриптингом батников/питончиков
* js был прокачан немного на Google Apps Scripts
* html и css меня всегда пугали сложностью поддержки
Сам проект не достижение, а показатель что в БЭМ стеке возможно разобраться на неплохом уровне если просто попытаться начать что-то делать. Да были проблемы с документацией, но поддержка на форуме нивелировала этот недостаток.
Ну и конечно же от БЭМ мы хотим взять унификацию терминов для всех кто работает с UI и создание единой компонентной базы для проектов компании. Технологии БЭМ стека, как мне показалось, позволяют достичь этого более эффективно.
Ты конечно прав, но на слова Aetet стоит обратить особое внимание. Он хорошо сформулировал основные «проблемы» восприятия технологий стека. У меня были практически ровно теже мысли почти про каждый аспект. Только постепенные попытки сделать что-то осмысленное и твоя оперативная поддержка на форуме помогли разобраться в предназначении, плюсах, минусах и способов применения технологий БЭМ стека.
Сегодня мне было бы сложно сформулировать тоже самое, ведь у меня довольно быстро прогрессирует БЭМ головного мозга.
Нет. И вообще до января этого года к верстке и разработке прямого отношения не имел, но за 2 месяца смог сделать такое github.com/guria/bem-drawer-menu
Простите, но я снова БЭМ вставлю. Очень хороши их декларативные шаблонизаторы bh и связка bemtree+bemhtml. Рендерятся также универсально в браузере или nodejs.
* каскад www.w3.org/TR/2009/CR-CSS2-20090908/cascade.html#cascade
* специфичность developer.mozilla.org/ru/docs/Web/CSS/Specificity
Человек может самостоятельно выбрать обслуживающую фирму и предоставить её агенту доступ к этим сигналам или же доверить этот выбор ещё одному виртуальному агенту, оставив за собой лишь право окончательного принятия решения.
Оба ваших негативных сценария действительно возможны при неправильном проектировании взаимодействия. Не допустить их — как раз одна из задач составления онтологий.
Возможно ли это? Незнаю. Но ничто не мешает мечтать об этом и пытаться претворить в жизнь.
Для ангуляра никто не оборачивал?
А вот как в десктопном его запустить не знал.
Параллельно по работе в мультипроектной среде на 150 человек стали выявляться потребности общих интерфейсов и компонентов. Я долго блуждал в области living style guides, atomic design и прочего добра. В процессе я натолкнулся на БЭМ и показалось, что он подходит для решения такой задачи. Попытки понять что из себя представляют технологии стека по документации и видеозаписям были слегка безуспешными. Сложилось популярное впечатление, что это мощная сложная штука решающая проблемы Яндекса и что понять что же там происходит довольно сложно. Попытки были прекращены, но глубоко засела мысль, что это то что нам подходит. Второй подход был уже более с практической стороны. К этому моменту я подтянул знания по вёрстке и решил сделать нечто конкретное. Результат в репозитории, проект оценен на конкурсе БЭМ проектов а у меня в голове осталось понимание принципы работы технологий стека.
Сегодня переработанный вариант этого меню интегрируется мною в существующий проект на angular, со сборкой на gulp и browserify. Завтра этот же компонент будем подключать на другой проект с requirejs и kendo ui с беком на ASP.NET. В итоге мы проверим применимость технологий стека для поддержки общих компонентов в общей стилистике на довольно разных проектах. Сейчас это два SPA проекта, но если следующий потребует рендеринга шаблона на сервере этого легко можно добиться.
Выносить следует всё, что кому-то может не понадобится и это можно исключить из конечной сборки.
Очень актуально для общих библиотек.
На проекте, скорее всего, раскладывание всего и вся по папочкам окажется избыточным.
* годы админства/эникейства со скриптингом батников/питончиков
* js был прокачан немного на Google Apps Scripts
* html и css меня всегда пугали сложностью поддержки
Сам проект не достижение, а показатель что в БЭМ стеке возможно разобраться на неплохом уровне если просто попытаться начать что-то делать. Да были проблемы с документацией, но поддержка на форуме нивелировала этот недостаток.
Ну и конечно же от БЭМ мы хотим взять унификацию терминов для всех кто работает с UI и создание единой компонентной базы для проектов компании. Технологии БЭМ стека, как мне показалось, позволяют достичь этого более эффективно.
Если надо только сделать меню за 2 часа и забыть, то ничего этого не нужно. См. habrahabr.ru/post/255195/#comment_8367443
Сегодня мне было бы сложно сформулировать тоже самое, ведь у меня довольно быстро прогрессирует БЭМ головного мозга.