@ *.blocks -> blocks/*

[belozer]

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

common.blocks
desktop.blocks
desing.blocks

blocks/common
blocks/desktop
blocks/desing

таже история и с *bundles.

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

[belozer]

@pvlv думаю лучше в issue репозитория писать, т.к. здесь другая тема вопроса ;)

[pvlv]

@tadatuta у меня "блок" ассоциируется с html-блоком

html без css - может существовать css без html - нет, зависим от html

Получается, что html первичен - может существовать сам по себе(с некоторыми допущениями) => это сущность => блок , а css - не может существовать в отрыве от html => не может быть сущностью => не может быть блоком, тоже самое касается картинок(они зависимы от html) и тд.

Что касается js, тут все иначе

js - не просто описание чего-то, это логика, он заимодействует с блоком, влияет на блок

Если мы добавим к блоку(с зависимостями -> css -> img) js файл - можно теперь блок называть "блоком"?

В React эту ситуацию разрулили так:

• компонент, который рендериться - "тупой" компонент, или просто компонент
• компонент, который имеет логику - "контейнер"

React component == React container // true React component !== React container // true

от сюда следует

1. element == component == block == module == box == container // true
2. element !== component !== block !==module !== box !== container // true

Или вот в основных определениях: «Блок — логически и функционально независимый компонент страницы».

соответсвует 1 выражению, а 2ого выражения у БЭМа нет ввиду исторических особенностей

Считаю, что в текущих реалиях эту ситуацию нужно пересмотреть, взвесить все "за" и "против". Возможно, скоректировать развитие БЭМа в сторону разработки среды(не бандлер, не методология, не раннер) для работы с подобными сущностями(у меня есть пару идей на этот счет, если интересно могу поведать о них). Но это уже другая история.

[pvlv]

@belozyorcev это был не вопрос, я просто акцентировал внимание

[belozer]

@pvlv

это был не вопрос, я просто акцентировал внимание

Если ты про именования репозитория, то акцентируй его и здесь ;) #157

а css - не может существовать в отрыве от html

А вот по поводу CSS ты немного заблуждаешься. Он существует и без HTML. Например для SVG, или, например в рабочем окружении GNOME используется CSS.

тоже самое касается картинок(они зависимы от html) и тд.

*:after { content: "", background: url('bem_image.png') }. В html невозможно создать :after. Это псевдоэлемент, который создаёт именно CSS.

у меня "блок" ассоциируется с html-блоком

https://ru.wikipedia.org/wiki/Блок Блок — в программировании: часть кода, которая воспринимается как единое целое.

upd По поводу react ты прав. Они сделали просто шустрый view и всё. Единственно чем мне симпатичен React - это VirtualDOM (без него React не был бы так популярен ИМХО). Но мне воспринимать его сложнее, чем блоки в БЭМ. Вокруг БЭМ сложилась дурная репутация из-за того, что люди не так всё поняли, или пытались с ним работать пару лет назад. Также о БЭМ часто всегда узнают только через длиннющие CSS классы, а не о том, как стоить интерфейсы блокам. Или пробуют что-то сделать, а в проект внедрить не могут. Здесь я высказывал своё мнение по этому поводу #159

[pvlv]

А вот по поводу CSS ты немного заблуждаешься. Он существует и без HTML. Например для SVG

SVG - в отрыве html/xml не может существовать (контекст - вэб).

... или, например в рабочем окружении GNOME используется CSS.

Интересно, а как вы css будете рендерить? Там не html, но что-то(лень искать) на что влияет css.

Сделать background зеленым, которого нет. Это как?

*:after { content: "", background: url('bem_image.png') }. В html невозможно создать :after. Это псевдоэлемент, который создаёт именно CSS.

А как же тег <img>? Учитывая ваше замечание, можно сказать, что "картинки имеют зависимость как от html, так и от css"(но это не меняет картины)

https://ru.wikipedia.org/wiki/Блок Блок — в программировании: часть кода, которая воспринимается как единое целое.

А где я написал, что блок не является единым целым? Текст после обзаца объясняет, что я имею ввиду.

upd

Вокруг БЭМ сложилась дурная репутация из-за того, что люди не так всё поняли, или пытались с ним работать пару лет назад

Продать/объяснить можно все, что угодно. Вопрос в мотивации. До React`a у twitter была(и есть https://flightjs.github.io/) похожая идея, но не взлетело.

[belozer]

@pvlv

...но что-то(лень искать)

GTK+

А где я написал, что блок не является единым целым? Текст после обзаца объясняет, что я имею ввиду.

bemtree описывает структуру сущности? Да. bemhtml преобразует сущность в html? Да. css перекрашивает только эту сущность? Да. js управляет только этой сущностью? Да.

Значит всё это зависимо и воспринимается как едино целое. Считаю дальнейшее обсуждение неуместным, т.к. оно уже ушло от темы. Но ты можешь создать issue на форуме и подробно всё описать.

[pvlv]

@belozyorcev

bemtree описывает структуру сущности? Да. bemhtml преобразует сущность в html? Да. css перекрашивает только эту сущность? Да. js управляет только этой сущностью? Да.

Все верно это "блок", который состоит из bemhtml, bemtree, css, js

Примеры блоков

1. Блок bemhtml, bemtree, css
2. Блок bemhtml, bemtree, js
3. Блок bemhtml, bemtree, css, js

1. Блок == 2. Блок == 3. Блок

Они блоки и все, и поэтому они равны

Но

Если их стравнивать "строго"

1. Блок !== 2. Блок !== 3. Блок

, то они не будут равны

цель(Блок 1) != цель(Блок2) != цель(Блок3)

Другие примеры

• уже приводил пример с React
• в функционально программировании есть такие понятия как "чистые функции", "функции высшего порядка" и тд. Они все являются функциями, но для того, что бы лучше понимать их предназначение, используют термины(дополнительный уровень абстракции)
• и тд

Блоки блоками, но назначения/цели/задачи могут быть разными у этих блоков => они должны называться по разному

[belozer]

@pvlv в БЭМ тоже используют контейнеры. Это те блоки, которые состоят из блоков. Например блок page. Другое дело как именовать их. Можно например container-page. Всё зависит от разработчика, как ему удобней.

[tadatuta]

@pvlv

а css - не может существовать в отрыве от html => не может быть сущностью => не может быть блоком

Разве мы где-то утверждали, что CSS — это сущность или блок? Мы говорили все на той же странице про основные понятия БЭМ, что «блоки могут быть реализованы в одной или нескольких технологиях, например: поведение — JavaScript, CoffeeScript; внешний вид — CSS, Stylus, Sass; шаблоны — Pug, Handlebars, XSL, BEMHTML, BH; документация — Markdown, Wiki, XML».

Еще раз повторюсь: всякий раз, когда ты читаешь слово «блок» на bem.info, считай, что там написано «компонент». Именно такой смысл вкладывается в это слово. Это синонимы. Примерно как кекс и маффин ;)

[pvlv]

«блоки могут быть реализованы в одной или нескольких технологиях, например: поведение — JavaScript, CoffeeScript; внешний вид — CSS, Stylus, Sass; шаблоны — Pug, Handlebars, XSL, BEMHTML, BH; документация — Markdown, Wiki, XML»

моя цит.

Получается, что html первичен - может существовать сам по себе(с некоторыми допущениями) => это сущность => блок , а css - не может существовать в отрыве от html => не может быть сущностью => не может быть блоком, тоже самое касается картинок(они зависимы от html) и тд.

и

Все верно это "блок", который состоит из bemhtml, bemtree, css, js Примеры блоков Блок bemhtml, bemtree, css Блок bemhtml, bemtree, js Блок bemhtml, bemtree, css, js

@tadatuta А где я написал, что блоки должны использовать определенную технологию? Вместо этих вставьте другие.

---

Еще раз повторюсь: всякий раз, когда ты читаешь слово «блок» на bem.info, считай, что там написано «компонент»

цит. из моего коммента

element == component == block == module == box == container

Я это прекрасно понимаю. И наглядно показал. @tadatuta Чему будет равно это выражение (вы умеете приводить "не строгому неравенству"). Подсказка - сначала к 1...)

@tadatuta А что быдет если мы будем "строго сравнивать"? И чему это выражение будет равно?

element !== component !== block !== module !== box !== container

цит.

Блоки блоками, но назначения/цели/задачи могут быть разными у этих блоков => они должны называться по разному

они(блоки) не равны между собой => (следовательно) => должны называться по разному для лучшего понимания происхоящего.

---

Примерно как кекс и маффин ;)

Яндекс - надменность

[belozer]

@tadutata я вот подумал... А может действительно нужно ввести понятие бокса или контейнера, как абстракцию над управляющим блоком? Чтобы блоки продолжали означать маленький компонент, а контейнер - наиболее полный компонент чтобы можно было понять где ветвь (контейнер), а где ягодки (блоки).

[belozer]

Например:

form-box - наш "основной" блок/компонент, который состоит из маленьких, примитивных блоков.

[pvlv]

в БЭМ тоже используют контейнеры. Это те блоки, которые состоят из блоков. Например блок page. Другое дело как именовать их. Можно например container-page.

@belozyorcev В БЭМе, должно быть четко прописано как должен именоваться подобный блок.

этой идеи почти 10 лет, что все крутиться вокруг "блока"

Раньше это не требовалось, но сейчас это важно.

---

Всё зависит от разработчика, как ему удобней.

Ага, и возвращаемся до БЭМ времена.

---

я вот подумал... А может действительно нужно ввести понятие бокса или контейнера, как абстракцию над управляющим блоком? Чтобы блоки продолжали означать маленький компонент, а контейнер - наиболее полный компонент чтобы можно было понять где ветвь (контейнер), а где ягодки (блоки).

cпс тебе, именно это я имел ввиду

они(блоки) не равны между собой => (следовательно) => должны называться по разному для лучшего понимания происхоящего.

[tadatuta]

@pvlv

Я еще один последний раз попробую с аналогиями.

Есть тег <div>, а есть <iframe>. Если попытаться «сравнить» по твоей схеме, то, видимо:

<div> == <iframe> // true
<div> === <iframe> // false

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

Да, очевидно, что блоки могут быть разными. В той же степени, в какой Web Components могут быть разными. Но они при этом вполне могут продолжать называться веб компонентами.

[tadatuta]

@belozyorcev

А может действительно нужно ввести понятие бокса или контейнера, как абстракцию над управляющим блоком? Чтобы блоки продолжали означать маленький компонент, а контейнер - наиболее полный компонент чтобы можно было понять где ветвь (контейнер), а где ягодки (блоки)

Большинство блоков на практике могут быть контейнерами. И даже элементы зачастую контейнеры.

Давай возьмем простой пример со списком. Сегодня был блок list со списком (каждый айтем был листом), а завтра в элементы списка насыпали ссылок — элементы оказались контейнерами (теперь ссылки — листы). Послезавтра в ссылки добавили иконки и теперь ссылки тоже контейнеры, а листы — иконки. А тут оказалось, что иконки на SVG и нам нужно повлиять на какой-то вложенный в иконку узел.

К списку, его айтемам, ссылкам и иконкам вполне могут быть примиксованы другие блоки или элементы с богатым внутренним миром. Или наоборот, один блок может быть разнесен по нескольким несвязанным DOM-узлам.

А представь эту же историю на более серьезных примерах. Будем на каждый чих их переименовывать? Какую задачу это решит?

[pvlv]

@tadatuta,

<div> == <iframe> // true

потому, что div- это тег(1), iframe - это тег(1) =>тег == тег // 1 == 1

<div> === <iframe> // false

false, потому, что

div-тег(ЦЕЛЬ/НАЗНАЧЕНИЕ/СУТЬ - является блочным элементом и предназначен для выделения фрагмента документа с целью изменения вида содержимого)

iframe(ЦЕЛЬ/НАЗНАЧЕНИЕ/СУТЬ - является контейнером, содержание которого игнорируется браузерами)

Цель(div) !== Цель(iframe) // true

Поэтой причине div и iframe называются по разному, но при всем при этом они являются тегами(блоками)

А что будет если они будут называться одинаково?

// БЭМ сейчас
<div class="tadatuta tadatuta--mod"> // блок состоящий из блоков 
<div class="tadatuta2 tadatuta2_elem"></div> // блок
</div>

Или все таки лучше так ?

// Что я хочу от БЭМа
<div class="tadatuta tadatuta--mod"> // Блок, который является контейнером
- <div class="tadatuta2 tadatuta2_elem></div> // Блок, который является блоком
</div>

Пример:

Блок который включает в себя другие блоки - называется контейнером(пример) Блок, который находится в другом блоке - называется блоком(пример)

А структура папок будет следующая(очень упрощенная) и это наглядный пример

/blocks
-- /tadatuta
----*.css
----*.js
----tadatuta.html
--/tadatuta2
----.*css
----.*js
----tadatuta2.html
/components
-- components.html // инклюдит в себя html/pug/nunjucks из блоков tadatuta и tadatuta2, не подключаем css и js идет в общий бандл(собираются gulp или webpack)
/app
- index.html / результат сборки
- *.css
- *.js

Итог сборки

index.html
-*.css
-*.js
// включает в себя
- components.html
-- include tadatuta.html
-- include tadatuta2.html
- another-components.html
-- include another-tadatuta.html
-- include tadatuta2.html

Компонент, как блок высшего порядка должен только включать блоки.

Компонент, могут быть вложенными.

Блоки могу существовать в отрыве от компонентов - тогда это называется статик блок (например) и тд

Слово "компонент" можно заменить любым другим словом - box, container и тд.

Чтобы понять, что они отличаются, достаточно знать их названия.

Что бы знать название, нужно знать как называть. Пока везде блоки в блоках на блоках через блоки.

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

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

А где я сказал, что блоки нужно запретить называть "блоками"? (см.выше)

Да, очевидно, что блоки могут быть разными.

А если блоки разные, почему они называются одинаково?(см.выше)

[tadatuta]

@pvlv

А где я сказал, что блоки нужно запретить называть "блоками"?

Как, где? В этом самом треде:

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

или

понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

 

А если блоки разные, почему они называются одинаково?

А если <iframe> и <div> разные, то почему они называются одинаково тегами?

Блоки называются по-разному: блок my-cool-video-player и my-great-page-container. Но при этом и то и другое блоки (или компоненты).

Получается, что одинаковое название «тег» для <input> (не может быть контейнером) и <div> (может быть контейнером) не напрягает, а одинаковое название «блок» для <input class="input"> и <div class="my-container"></div> вызывает когнитивные затруднения?

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

[pvlv]

@tadatuta

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

Да не надо ни чего двигать,есть блоки и лежат в папочке /blocks. Блоки не изменны. Они просто есть. Нужно делать include в другие блоки - тем самым создавать новую сущность. Эта сущность должна комбинировать блоки, возможно иметь логику.

/blocks
- /block1
- /block2
- /block3

Теперь создаем компонент1(или box или container)

/blocks
- /block1
- /block2
- /block3
/components
- /component1
-- component1.html

структура component1.html

<div class="component1">
include '/block1/block1.html'
include '/block1/block2.html'
<div>

Создадим еще 1 компонент component2.html

/blocks
- /block1
- /block2
- /block3
/components
- /component1
-- component1.html
- /component2 // <- новый компонент
-- component2.html //

структура component2.html

<div class="component2">
include '/block1/block1.html'
include '/block1/block3.html'
include '/components/component2.html' // <- в компоненты можно инклюдить другие компоненты
<div>

А теперь предположим что нам нужно изменить в componet1.html И что нам делать? Правильно, добавить block4 и сделать component3.html

/blocks
- /block1
- /block2
- /block3
- /block4 // <- новый блок
/components
- /component1
-- component1.html
- /component2 
-- component2.html
- /component3 // <- новый компонент
-- component3.html 

структура component3.html

<div class="component3">
include '/block1/block1.html'
include '/block1/block4.html'
include '/block1/block2.html'
<div>

и итоговый index.html будет выглядеть вот так

<html>
<heade></header>
<body>
include 'components/component1.html'
include 'components/component3.html'
include 'blocks/block3.html'
include 'components/component2.html'
</body>
</html>

А где я сказал, что блоки нужно запретить называть "блоками"? Как, где? В этом самом треде:

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

понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов.

Тут я не правильно выразился, извиняюсь.

[awinogradov]

@tadatuta ты там держись ;)

Sent from my iPhone

On 31 Jul 2016, at 16:12, Ivan Pavlov notifications@github.com wrote:

@tadatuta

В твоем примере, если внезапно потребуется внутрь блоков tadatuta и tadatuta2 вложить еще несколько блоков, а потом вложить что-то внутрь их чайлдов, ты будешь каждый раз удобно двигать их из папки в папку? А когда к ним будут примиксованы еще пяток сущностей?

Да не надо ни чего двигать,есть блоки и лежат в папочке /blocks. Блоки не изменны. Они просто есть. Нужно делать include в другие блоки - тем самым создавать новую сущность. Эта сущность должна комбинировать блоки, возможно иметь логику.

/blocks

• /block1
• /block2
• /block3 Теперь создаем компонент1(или box или container)

/blocks

• /block1
• /block2
• /block3 /components
• /component1 -- component1.html структура component1.html

include '/block1/block1.html' include '/block1/block2.html'

Создадим еще 1 компонент component2.html /blocks - /block1 - /block2 - /block3 /components - /component1 -- component1.html - /component2 // <- новый компонент -- component2.html // структура component2.html

include '/block1/block1.html' include '/block1/block3.html' include '/components/component2.html' // <- в компоненты можно инклюдить другие компоненты

А теперь предположим что нам нужно изменить в componet1.html И что нам делать? Правильно, добавить block4 и сделать component3.html /blocks - /block1 - /block2 - /block3 - /block4 // <- новый блок /components - /component1 -- component1.html - /component2 -- component2.html - /component3 // <- новый компонент -- component3.html структура component3.html

include '/block1/block1.html' include '/block1/block4.html' include '/block1/block2.html'

и итоговый index.html будет выглядеть вот так include 'components/component1.html' include 'components/component3.html' include 'blocks/block3.html' include 'components/component2.html' А где я сказал, что блоки нужно запретить называть "блоками"? Как, где? В этом самом треде: Считаю, что нужно отказаться от понятия "блок" при организации файловой структуры проекта. Сейчас есть более подходящий термин для этого - "компонент". или понятие "блок" в БЭМ стеке (я не беру во внимание css по БЭМу) тормозит распространения самого БЭМ стека, как иструмента для разработки и поддержки веб-проектов. Тут я не правильно выразился, извиняюсь. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[belozer]

@pvlv Просто нужно сразу было описать проблему и предложение. Ты начал с далёкого от темы и у нас много времени ушло на обсуждение чего-то далёкого от темы, не по существу. :)

А по поводу разбивки по контейнерам (мне больше нравится правда "box") нужно попробовать поработать таким способом. И если оно окажется удачным, то продвигать его в массы. Я сейчас сам занимаюсь оптимизациями разработки в таких направлениях, эксперементирую.

// БЭМ-БОКСЫ

Суть правда только в принципах разработки, но не в инструментах

[tadatuta]

@pvlv

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

[belozer]

@tadutata box можно воспринимать как конечный набор для пользователя. Вспомни как мы рекомендуем передавать данные между блоками. У нас есть родительский блок, который знает о своих дочерних блоках, дочерние блоки ничего не знают о родителе.

Сами блоки представляют собой "тупые" компоненты. Они ничего не могут реализовать на практике. Они даже не знают как будут использоваться, сугубо говоря. Блоки могут предоставлять только своё API (могут иметь дочерние блоки, но всё также "тупые". Просто для расширения своих возможностей).

Объясняем человеку простоту блоков, что они ничего не могут самостоятельно и полностью независимы. И теперь нам поря собрать умный бокс/кейс, который знает зачем он нужен, знает, что ему нужно для своей работы (Знает о дочерних блоках и использует их API).

Бокс строит bemtree из дочерних блоков. А также конектит события между блоками.

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

header-box
-- logo
-- list
-- button

header-box слушает события из блока button. После наступления события он вызывает API блока logo и блока list и что он ещё может сделать, так это отправить какие-то данные на сервер.

И ещё раз повторюсь. Мы всегда рекомендуем использовать именно такой подход для коннекта блоков. Но не всегда понятно, какой же блок является мостом/передатчиком. Просто можно добавить рекомендации по именованию именно таких блоков. Чтобы разбить блоки на "глупых" (легко переносимые библиотеки) и "умных" (заточенных под нужды конкретного проекта).

[tadatuta]

@belozyorcev Все-таки не совсем так. Есть, казалось бы, тупой блок select. Он всего лишь контрол выбора какого-то значения для отправки на сервер, но в нем лежат блоки button и popup. popup, казалось бы, еще тупее, но в нем могут лежать очень разные по сложности штуки, вплоть до огромных сложных форм. Но в нашем конкретном случае с select-ом там тупое menu. Однако не настолько тупое, чтобы не быть контейнером для menu-item-ов. А они, при всей своей простоте, бывают разных типов и могут включать как просто текст, так и, скажем, блоки link, внутри которых окажутся блоки icon с svg внутри.

PS: А «умный» box внезапно окажется не родителем select-а, а миксом к нему.

[veged]

@pvlv давайте я сэкономлю всем кучу времени и сил, хотя, возможно, это покажется слишком грубым и категоричным (заранее извиняюсь) — мы НЕ будем переименовывать понятия Блок, Элемент и Модификатор, можно дальше не ломать копья по этому поводу

[veged]

@belozyorcev зачем нужны префиксы @? если их убрать, ничего не ухудшится

[belozer]

@veged Для явного обозначение уровней.

Если директория начинается с префикса @, то это название уровня/платформы, где лежат конечные блоки.

blocks/desktop
blocks/touch
blocks/my_level

blocks/@desktop
blocks/@touch
blocks/@my_level

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

Основная цель данного топика - сделать структуру стартового проекта чистой и понятной.

Ведь проще объяснить человеку, что:

Категории начинающиеся с @ обозначают название уровня/платформы и содержат в себе конечные блоки.

чем:

1 ступень иерархии blocks обозначает платформы/уровни, в которых содержатся конечные блоки

[veged]

повторюсь — по моему без @ всё вполне очевидно

[Yeti-or]

можно еще сделать как технологию

blocks/button/button.js
blocks/button/button.css
blocks/button/button.levels/
blocks/button/button.levels/desktop
blocks/button/button.levels/touch-phone
blocks/button/button.levels/desktop/button.css
blocks/button/button.levels/desktop/button.js

2016-08-03 12:31 GMT+03:00 Sergey Belozyorcev notifications@github.com:

@veged https://github.com/veged Для явного обозначение уровней.

Если директория начинается с префикса @, то это название уровня/платформы, где лежат конечные блоки.

blocks/desktop blocks/touch blocks/my_level

blocks/@desktop blocks/@touch blocks/@my_level

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

Основная цель данного топика - сделать структуру стартового проекта чистой и понятной.

Ведь проще объяснить человеку, что:

Категории начинающиеся с @ обозначают название уровня/платформы и содержат в себе конечные блоки.

чем:

1 ступень иерархии blocks обозначает платформы/уровни, в которых содержатся конечные блоки

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bem/project-stub/issues/158#issuecomment-237189352, or mute the thread https://github.com/notifications/unsubscribe-auth/ABur3MM3aYnlvCMvwBwwmStmuEFY7lIgks5qcF_8gaJpZM4JTsZi .

[pvlv]

@veged прочитайте, пжл, внимательно все, что я написал. Речь не шла про переименование божественных "блоков". Если кратко, идея - добавить дополнительный уровень абстракции при формировании структуры проекта.

[belozer]

@pvlv слишком много текста чтобы это было явно понятно. Ты начал просто тему издалека. Чтобы дальше разговор был более конструктивен, предлагаю более явно пояснять/предлагать реализацию абстракции.