[Foundation 7] BEMIT - AppFramework level compiler. Edit: Foundation level Compiler also!

[IamManchanda]

Hey Community,

Internally there has been a very deep discussion going on these days b/w yetinauts about the sass architecture and namespacing! Yes the first and foremost goal is to make the CSS Environment Agnostic But also concerned about lot of other goals and thus yeti's think that BEM (or BEMIT) is the solution for it.

BEM is applicable to all projects, whether its big or small, avoids the nestings/specificity issues, helps you encapsulates your code for reuse, Arguably a quick way to deliver prototypes and helps you make good decision (ensures that you plan) and most importantly is semantic But again we can't hide the stuff that its really a very long html Thus we yeti's are looking very deep on minimizing the effort of the end user

So last night @ncoden came up with the plan of compiling

Frankly what he said is this

<div bem="myBlock:myModifier as b">
    <div bem="b.myChild:myChildModifier">...</div>
</div>

By this, we can compile and achive the desired result! Not saying that this is the wrong approach but its not that semantic

So i thinked long today and here is what I think Why not create an AppFramework level compiler instead of Foundation level? What that mean is while starting out, we can create App Framework level compiler in three popular frameworks of today (Vue, React, Angular) and also let the community to contribute more compiler for the other framework

As i know bit of Vue.js, Here is the semantic Vue.js based example for the same

<accordion :modifier="{primary, large}">
  <item :parent="accordion" :objects="{bordered, rounded}">
    <heading :parent="{accordion, item}">
      Accordion Heading
    </heading>
    <content :parent="{accordion, item}">
      Lorem ipsum dolor
    </content>
  </item>
</accordion>

which will automatically convert the code into a BEMIT code like this into the DOM

<div class="c-accordion c-accordion--primary c-accordion--large">
  <div class="c-accordion__item o-bordered o-rounded">
    <div class="c-accordion__item__heading">
      Accordion Heading
    </div>
    <div class="c-accordion__item__content">
      Lorem ipsum dolor
    </div>
  </div>
</div>

[IamManchanda]

cc @kball @ncoden @DaSchTour @brettsmason @SassNinja @codetheorist & everyone What do you guys think ?

[kball]

I'm currently dubious... this seems like a pretty large amount of tooling requirement at the usage level, which makes it a lot harder to integrate across a range of environments. It should be straightforward to use Foundation in a rails environment, php environment, wordpress environment, etc without depending on a particular tooling stack at the app side.

I think more advanced tooling in the framework generation side makes a ton of sense, and we should explore that road,

[IamManchanda]

Foundation in a rails environment, php environment, wordpress environment, etc without depending on a particular tooling stack at the app side.

Only the compilation code is dependent ... Those guys can still use BEM or BEMIT Again we should make it easy for others to contribute there environment compilation if want to get easy i guess!

[IamManchanda]

This below code is very semantic

<accordion :modifier="{primary, large}">
  <item :parent="accordion" :objects="{bordered, rounded}">
    <heading :parent="{accordion, item}">
      Accordion Heading
    </heading>
    <content :parent="{accordion, item}">
      Lorem ipsum dolor
    </content>
  </item>
</accordion>

[IamManchanda]

Hey so I thinked about it, Advanced tooling in the framework generation side! What we can do for (rails, php, wordpress etc) environments is to create a global compiler

The Global (Vanilla JS) Compiler with html 5 data attributes may look like this (Based on @ncoden suggestion)

<div data-bem="myBlock:myModifier as b">
    <div data-bem="b.myChild:myChildModifier">...</div>
</div>

But still create atleast 3 ( Vue, Angular, React) App Level compiler so that users of these app frameworks can use the code like my above comment instead of these data-bem.

Bcoz as a Vue (or Angular or React) developer, we would be looking for custom semantic elements! No?

[SassNinja]

We're using BEMIT in my company so I'm not averse to bringing it into foundation. BEM is definitely a great thing and helps me a lot to read other developers' code. But I won't be able to use a JS compiler for BEM because we internally use twig for templating.

So just to make sure I've understood you correctly: All of these compilers you mentioned are optional and I would still be able to write vanilla BEM conform HTML, wouldn't I?

And secondly: Your suggested changes will result in working over the whole SASS & JS code, won't they? Meaning there will be things as for example $elem.addClass('c-button--hover') instead of $elem.addClass('hover')?

[IamManchanda]

I can confirm for sure we will still be able to use normal BEM coding aka normal html... Ofcoursew

[IamManchanda]

@SassNinja first of all sorry for very short comment above but that time was unavailable

---

We're using BEMIT in my company so I'm not averse to bringing it into foundation. BEM is definitely a great thing and helps me a lot to read other developers' code.

That sounds good. Infact you are not alone, see => https://www.webdesignerdepot.com/2017/04/the-state-of-front-end-tooling/

So just to make sure I've understood you correctly: All of these compilers you mentioned are optional and I would still be able to write vanilla BEM conform HTML, wouldn't I?

Ofcourse you would... here we are talking about easing the user with easy and understandable coding by compiling code into bem code without writting these long html. Normal BEM coding would just work fine

But I won't be able to use a JS compiler for BEM because we internally use twig for templating.

No issue, You can keep using normal BEM coding but hey you can contribute the compiler for the same i guess (if that makes sense with other Yeti's like @kball)

Your suggested changes will result in working over the whole SASS & JS code, won't they? Meaning there will be things as for example $elem.addClass('c-button--hover') instead of $elem.addClass('hover')?

Not at all, hover is a state and state is not a modifier See https://csswizardry.com/2015/03/more-transparent-ui-code-with-namespaces/ and visit Stateful Namespaces section ( is-/has- )

For BEMIT, its frankly a SMACSS Approach for state

.is-active {}
.has-dropdown {}

On the question about changing code, yes because you have to move from active to is-active That being this is already been implemented a bit in v6.4 and i dont think this will be a big trouble See => http://foundation.zurb.com/sites/docs/menu.html#active-state

---

I hope i was able to answer on your questions If not let me know!

[SassNinja]

@IamManchanda thank you for the detailed response!

Since normal coding is still supported I won't argue against a BEMIT structure. The idea of providing several compilers to save code & time during templating is great. However I think before creating any compiler there must be well-thought-out concept with plenty of 'realistic' code examples (instead of only abstract ones). No matter what the syntax is going to look, it should have a clear benefit compared to vanilla HTML.

At the moment I'm using a custom emmet filter in SublimeText to save some time while creating the templates, but it's definitely far away from perfect. It will be awesome if there's a twig extension for BEM in the future :smile:

[IamManchanda]

The code input and output is another part of the story... This is just a rough code @SassNinja

Had a talk with @kball last night about compiler's... We are thinking about using compilers as an add-on (maybe as a separate repo) instead of including in the core!

[IamManchanda]

@brettsmason What do you think about it ?? I would want to know your thoughts on this buddy ??

{ PS: Yes i know you are not sold on BEMIT yet but still :wink: )

[marnen]

As a longtime Foundation user, let me explicitly register my strong dislike of BEM, and my desire to not have Foundation infected with it. If Foundation's BEM support is limited to being compatible with an optional postprocessor such as BEMIT, I have no problem with that. However, I don't want a BEM naming scheme to become part of Foundation's core, because I don't want my own sites using Foundation to be forced into using BEM.

I know BEM is popular in the CSS community today, but I think it's a big step in the wrong direction, and it's getting harder and harder to find a Sass framework that doesn't force me into using BEM when I don't want to...

[IamManchanda]

No issue @marnen... Thanks for expressing your dislike... we will surely look into it

As a longtime Foundation user, let me explicitly register my strong dislike of BEM, and my desire to not have Foundation infected with it. I know BEM is popular in the CSS community today, but I think it's a big step in the wrong direction, and it's getting harder and harder to find a Sass framework that doesn't force me into using BEM when I don't want to...

cc @ncoden

[ncoden]

@marnen Please give your reasons for not using BEM in a project / why you dislike BEM / why you do not want BEM to be integrated into Foundation.

[SassNinja]

@marnen I'm also interested in your reasons that argue against BEM.

It helps to understand the code structure and dependencies easier. Besides it forces you to think more object orientated and modularly. The only disadvantage imo is the increased amount of HTML and JS (e.g. when toggling classes). But with the help of the mentioned custom compilers (and hopefully some JS utilities) this probably won't be a problem either. The SASS part won't be a big deal because it's out of the box suitable with a syntax as &__element and &--modifier.

[ncoden]

@marnen @SassNinja Beyond the way you build your components and the maintainability, BEM allow you to (almost) freely use your components by forcing a total separation between your structure (HTML) and your style (CSS), through the "1-everywhere" CSS specificity.

You are not limited to use the components the only way the framework would allow you to :

1. No arbitrary CSS Specificity.
2. Less dependencies between parents/children.
3. No assumption in CSS of your HTML structure.
4. No assumption in CSS of the others components.
5. No properties applied "automatically" (on all children tags / classes).
6. No shared global namespace.

So you can declare, inherit, apply, combine and nest your CSS components way more easily, without having your custom properties being overridden by a vendor component's one (1), without being artificially restricted on the way you place a components children (2) and (3), without complex, arbitrary and inconsistent particular cases in component combination (4), without unexpected, unwanted and hardly resolvable properties applied globally or to all the children of a component (5), without naming collision between components, components' children, states and utilities (6).

And BEM is only a start, a fundamental way to declare your CSS components inspired by OOCSS. There is other CSS methodologies on top of BEM (SMACSS, ITCSS, ITBEM) that give you a lot of others advantages.

CSS is broken by design, we're only trying to push the community to a solution.

[marnen]

Ack, didn't want to derail this topic, but I feel like I need to answer the questions asked. I'll go into more detail if wanted, but I don't want to lose the topic of this thread.

@SassNinja:

Besides it forces you to think more object orientated and modularly.

I already structure my CSS this way. I don't need to rely on ugly redundant class names to make me do so.

@ncoden:

For the most part, I think that the arguments that you advance for BEM (to the extent that I understand them: some of your language is unclear) represent no actual advantages of BEM, but simply a failure to use the cascade and basic CSS selector logic properly. The cascade, along with properly chosen non-BEM selectors, will do everything BEM does (with the possible exception of preventing "inward leaks") if you let it, and won't leak ugly, repetitive class names into your markup.

For example, if you don't want dependencies or assumption of your HTML structure in your CSS, just target your selectors so they don't assume what you don't want them to assume. You don't need BEM to do that. Also, because of the way selectors work, the "shared global namespace" isn't really a shared global namespace: every selector can in principle act as a namespace for its child objects if wanted.

There is other CSS methodologies on top of BEM (SMACSS, ITCSS, ITBEM)

SMACSS is separate from BEM, and predates it AFAIK. Unless something has changed (possible: I'm only passingly familiar with SMACSS), it is not "on top of BEM".

I'll admit, though, that I don't find any of these methodologies terribly helpful except as inspiration. I've had much better luck simply understanding how selectors and the cascade work at a fundamental level, and using those features to get my CSS to behave in the way I want it to, which is always possible without much trouble. That is, I would rather work from first principles than from a methodology in this case.

CSS in broken by design, we're only trying to push the community to a solution.

CSS has some broken aspects (e.g. lack of functions and named constants until very recently), which is why we need Sass/Less/..., but selector specificity is not one of them IMHO. If you don't like the way CSS selectors work, fine, that's your prerogative. But please don't claim that they're not adequate for their intended purpose, when in fact they are.

[IamManchanda]

I strongly dislike @marnen thoughts!

[ncoden]

@IamManchanda Please give reasons.

[IamManchanda]

Short and simple reasons

1. Selector Specificity is a big pain and BEM solves it.
2. ClassNames are not ugly... Its just the wrong thinking... They are very semantic classname specially if bundled up with compilers mentioned above
3. Its many times that you need to pull out a component and its sub components from templates... and BEM makes that very easy!
4. I find all of these methodologies (BEM, SMACSS, ITCSS, BEMIT) very helpful to organize your code in a better way.
5. If i have to think like an app framework developer and the way these frameworks divides components... I will think my best bet would be to choose BEMIT or BEM... If that wont be possible... I would have no choice but writting the CSS within the JS component (Angular, Vue example)

[ncoden]

@IamManchanda

1. Selector Specificity is a big pain and BEM solves it.

As @marnen said, I think, Selector Specificity is not the problem, but the way we use it with arbitrary selectors, aka selectors mapping the HTML structure rather than declaring a component with its contexts and child objects. BEM solves it only by forcing the user to declare selectors properly and to increase the specificity only when needed.

2. ClassNames are not ugly.

ClassNames are ugly. .menu__item__link is ugly. This thing have to be repeated across all the HTML. You have a better solution I take it (the compiler could be one, but it mainly depends on how it would be usable with different tools and stacks). But for now it's not really the question.

3. Its many times that you need to pull out a component and its sub components from templates... and BEM makes that very easy!

I don't understand what that means.

4. I find all of these methodologies (BEM, SMACSS, ITCSS, BEMIT) very helpful to organize your code in a better way.

Even if this is true, this is is not their main advantage. If we're talking about component encapsulation and organization with layers (utilitities / generic components / semantic sections / ...), well there is nothing specific to these methodologies. You can have a more or less clean CSS in your project without them.

5. (...) If that wont be possible... I would have no choice but writting the CSS within the JS component.

It's the bad solution to a deeper problem. Like @marnen said, the main problems in CSS come from the lake of knowledge of how specificity and cascading works and how to take advantage of it. Local CSS does not resolve the problem, it destroy to create a bigger one: code duplication.

[marnen]

While I'll happily debate the merits of BEM, I'm starting to feel that doing so here misses the point. The point is that a general-purpose Sass framework should not impose too much on the structure of user code. If @IamManchanda would like to use BEM with Foundation, I think he should be able to do so (even if I don't think it's a great idea). Likewise, if I want to not use BEM with Foundation, I should be able to continue to do so without going against the nature of the framework.

Foundation has been great in this regard, and all I'm really saying here is that I hope future versions will continue this practice.

[brettsmason]

@IamManchanda sorry I haven't replied yet on purpose as I think it's important to let the discussion grow. I will reply fully though this week, but this sort of sums up concern too:

The point is that a general-purpose Sass framework should not impose too much on the structure of user code

[ncoden]

@marnen Right, we will not use BEM, because no framework should enforce a methodology with no reasons and enclose the user in it. I totally agree with you.

However.

We will take advantage of the specificity and cascading to keep control on the property order, so use the same specificity for all the standard context of our components, and incread the specificity according to the context if CSS doesn't do it natively to ensure context priorities.

We will avoid declaring selectors with artificial dependencies between components and their children when it is not required by the CSS rules themselves, to allow a free use in our components in a complex markup. For the same reason, we will declare style components only, as separated as we can from the markup.

We will split our components into different categories when we know we always expect a priority from some of them over the others because of their semantic particularity.

We will avoid applying properties automatically from the parents because more than preventing the control of the specificity, this lead to unwanted properties in a lot of cases that cannot be resolved without breaking the specificity again, and it goes on...

And all that require a Single Class API.

So we will not use BEM, because you're asking us not to. But we will use what is making BEM BEM, because we have good reasons for it, the same you are defending when you're telling us how BEM is not necessary, and because we know these reasons as explicit rules and simplified principles will benefits to all our users.

[marnen]

@ncoden What do you mean by a single class API?

Also:

But we will use what is making BEM BEM, because we have good reasons for it, the same you are defending when you're telling us how BEM is not necessary

I suspect you're not understanding what I'm arguing for or against, then. But I will defer further discussion of this until I make sure I understand what "single class API" means.

[IamManchanda]

https://www.sitepoint.com/structuring-css-class-selectors-with-sass/

[ncoden]

@marnen A single-class API is a CSS API composed with "one-class" selectors, to ensure an equal specificity of 0.1.0. This mean that instead of

.menu
.menu li
.menu > .link

You have (for example)

.menu
.menu-li
.menu-link

[IamManchanda]

Yes and for that Bem is the right area to move ahead

[SassNinja]

I understand and agree to the arguments @marnen and @ncoden have brought forward. A neutral framework can be used in BEM, SMACSS etc. projects without mixing two naming conventions. Therefore it is probably not a good decision after all to use a specific naming convention for the framework's core.

But as @ncoden pointed out we should aim for a single-class API (what mostly makes BEM BEM) to prevent specificity issues. Apart from that a structure as ITCSS may be used to get more control. We are using such a structure in my company and are quite happy with it.

However I really like the idea of @IamManchanda of creating app level compilers so BEM code may be written without those large, ugly class names! Probably as a separate repo if it won't be part of Foundation. Regarding the popularity of BEM, I'm pretty sure there will be a lot interest in this.

[marnen]

@ncoden Thanks for clarifying. That's exactly what I don't want to see: it makes CSS stupid and redundant. If future versions of Foundation go this way, I won't use them.

[marnen]

...unless you provide enough Sass mixins that I can ignore your CSS class name API. :)

[ncoden]

@SassNinja This an implicit principle in all my previous comments, but it seems this was not clear enough:

BEM is way more than a naming convention. In fact, there is tons of different naming conventions called "BEM". BEM a way to declare "components" implicitly based on the single-class API principle, offering a lot of possibilities.

We don't care about the "BEM" naming convention. We want it as simple as possible. We don't care about the "BEM" component structure. We'll use one according to our needs. What we care about is the possibilities given by the SCA principle, that is a requirement for a reusable and framework-agnostic component library.

For the compiler, I talked about it to @IamManchanda some weeks ago, but I'm working on this idea for almost two years. It would be definitely the time get something out if it. This is totally agnostic to Foundation tho.

[ncoden]

Thanks for clarifying. That's exactly what I don't want to see: it makes CSS stupid and redundant. If future versions of Foundation go this way, I won't use them.

It makes your specificity clear and controllable. It makes your components compatible between them and others, no matter the way you use them. It allows you to explicitly declare your priorities and contexts. It allows you to manage all that with a simple importation order. It gives you a full control on the properties you apply.

...unless you provide enough Sass mixins that I can ignore your CSS class name API. :)

We already discussed about a way to generate different naming conventions. I think this is a good idea as long as we are consistent with the convention we use for the examples and documentations. But as explained before, SCA is not really a "naming convention" but a fundamental architecture principle. We cannot change it based on an user option, because the whole framework architecture is based on it.

However, I would love you to stay engaged in this discussion to give your opinion about the naming convention we should provide/allow/use as default. I am sure you will help.

[marnen]

@ncoden: Unless I am misunderstanding, all the benefits you claim for a single-class API, with the possible exception of the last, are equally well delivered by thoughtful use of the cascade and CSS specificity. (If I am misunderstanding, I'd love more details about where you see the differences.)

Moreover, a single-class API makes redundant class names leak into the markup. Using the example you gave, let's say I have a <ul> that I'd like to mark as a menu. In semantic HTML, it should be sufficient for me to add one semantic class name to the container:

<ul class='menu'>
  <li>Item One</li>
  <li>Item Two</li>
</ul>

and that class name provides sufficient context and specificity to unambiguously style anything within the component:

.menu { background-color: white; color: red; }
.menu li { border: 2px solid blue; }

A single-class API would not simplify the CSS at all, but would make the HTML more complex and redundant:

<ul class='menu'>
  <li class='menu-li'>Item One</li>
  <li class='menu-li'>Item Two</li>
</ul>

.menu { background-color: white; color: red; }
.menu-li { border: 2px solid blue; }

Class menu-li is redundant: it is already deducible from the DOM that the elements it applies to are <li> elements within a container of class menu. It is non-semantic: because it is redundant, it adds no useful information for the client. Since it's important to me to deliver properly structured semantic markup to the client, I don't consider this pattern appropriate for the work I do. (It also makes maintenance more difficult, though that's a lesser issue.)

Moreover, I don't see that this profusion of extraneous class names in my markup provides any benefit to make up for it. Yes, a thoughtful use of the cascade is needed with the way I do it, but that's required for any CSS development beyond the most basic, single-class pattern or not; it's simply the nature of the beast.

But as explained before, SCA is not really a "naming convention" but a fundamental architecture principle.

Again, the problem with that as a framework choice is that it forces your users' hands. If the framework's CSS looks like the last example, then I have no choice but to pollute my HTML with a lot of otherwise unnecessary class names; otherwise the framework will not work for me. So I either have to write HTML in a way that I consider distasteful, or I have to not use the framework. This is in fact the exact reason that I don't use Bootstrap when I have a choice: while I like a lot of its components, its class naming scheme is so awful to me that I cannot in good conscience consider using it. I don't want Foundation to go the same way.

Foundation does have a leg up on Bootstrap in this respect, and it's a big part of why I use it: most of its components are actually implemented with Sass mixins, so that I'd probably actually do something like this:

.menu { @include totally-awesome-menu-component; }

and keep framework class names out of the markup entirely. (But here again, it would be nice, if less essential, for the framework to do something like

@mixin totally-awesome-menu-component {
  background-color: white; color: red;
  li { border: 2px solid blue; }
}

so that a single @include gets the whole component. Something like

.menu { 
  @include totally-awesome-menu-component;
  li { @include totally-awesome-menu-item; }
}

is a lot less nice for the framework user, though not a deal-breaker.)

When I have to use Bootstrap, I often use @extend for this purpose, but of course that doesn't work nearly as nicely as using an actual mixin.

We cannot change it based on an user option, because the whole framework architecture is based on it.

Well, yes, using a single-class pattern for the framework would force users of the framework to follow that pattern. I think that not using a single-class pattern would actually have less impact on users of the framework, because as far as I can tell, that would still be compatible with single-class naming for those who want to use it, while not forcing single-class naming.

However, I would love you to stay engaged in this discussion to give your opinion about the naming convention we should provide/allow/use as default. I am sure you will help.

Glad to hear it. I was afraid I was wearing out my welcome... :)

Since you asked: having been thinking about it over the last few days, for my purposes what I'd love is if Foundation were distributed with no CSS class names defined at all, and simply implemented everything by means of Sass mixins, letting the user choose his own class naming scheme and @include mixins in those classes any way he wants to, more like the way Bourbon does things. I realize, though, that that would make Foundation less of a drop-in CSS library, and so I don't know if it's consistent with Zurb's goals for the framework...

[ncoden]

@marnen Thanks for your long explaination. I will read and reply to it soon.

[brettsmason]

Glad to hear it. I was afraid I was wearing out my welcome... :)

@marnen Definitely not wearing out your welcome, its great to see others engaged in this discussion 😄 It's an important topic that will shape Foundations future 👍

[IamManchanda]

Since you asked: having been thinking about it over the last few days, for my purposes what I'd love is if Foundation were distributed with no CSS class names defined at all, and simply implemented everything by means of Sass mixins, letting the user choose his own class naming scheme and @include mixins in those classes any way he wants to, more like the way Bourbon does things. I realize, though, that that would make Foundation less of a drop-in CSS library, and so I don't know if it's consistent with Zurb's goals for the framework...

This is not possible! Instead of doing that we need to add a docs page where we can tell the user on how to only import the sass mixins only and don't include the foundation built in css

[ncoden]

This is not possible!

@IamManchanda This is totally possible. Since I am at Foundation, I push for we have a complete Sass API that provide at least all the components and modifiers of the CSS API. So we can try to make Foundation "Sass first", and still provide a CSS API from that for prototyping or user comfort.

@marnen I wanted to use Bourbon at first for a project I worked on, but finally used Foundation because Bourbon did not have components as I expected. I like the "Semantic classes" approach with everything built in Sass (creating tons of classes in CSS to do everything is not scalable for now), but it lead to a lot of code duplication. It would be great if you have a solution to this problem.

[IamManchanda]

You guys mean to remove all css by default... sorry but ...I am strongly against it cc @kball @rafibomb ??

[brettsmason]

@IamManchanda that's not what @ncoden and @marnen were saying. Nicolas was saying create the framework as primarily a Sass mixin library (like Bourbon) but also have the ability to output classes as we do now.

I think thats a great suggestion and would be a good step forward in my opinion.

We could have a global selector map, then all CSS generating mixins could get their selectors from that. So the suggestion by @marnen could be output with a class child selector or an element. Maybe even an option to set to nested or single class... Just brain dumping now :smile:

[ncoden]

Nicolas was saying create the framework as primarily a Sass mixin library (like Bourbon) but also have the ability to output classes as we do now. (@brettsmason )

Exactly. CSS is limited. No variables (for now), functions, reusable code, logics in general or inheritance without a dedicated architecture. People should understand that building their components from atomic classes directly in the HTML is limited. We cannot generate an infinite number of classes for all possibilities.

They have to write custom CSS one time or an other. And at this point there would be no difficulty to move to Sass and create their own classes by inheriting the Foundation Sass components. This is definitely better than having to ask Foundation to add this or that very specific feature.

But I still want Foundation to provide a standard CSS library, and a very simple way in Sass to generate all the default components, like we are doing now.

Maybe even an option to set to nested or single class

@marnen About what I said before:

But as explained before, SCA is not really a "naming convention" but a fundamental architecture principle. We cannot change it based on an user option, because the whole framework architecture is based on it.

I thought about it and changed my mind. Components need to be built a particular way in Sass to make SCA possible (all properties in their respective elements, strict component organization), but then it cost nothing to use a selector or an other (like .menu > li instead of .menu-item). It's sad, it's too bad for the user and will probably cause problems, but at this point we don't care. We have what we want, a SCA framework, we'll try to teach our users about it, but if they still want to code "à la Bootstrap" we should not artificially limit them.

[ncoden]

And:

You guys mean to remove all css by default... sorry but ...I am strongly against it

Please. Give. Reasons. ;)

[IamManchanda]

If thats the case we should be creating separate repo Foundation Sass or Sass Activate or F7 Sass Activate (Just like Bourbon) and then use that same code mixins for Foundation 7 css ??

If people want different implementation unlike what foundation 7 gonna have... then simply they can install that lightweight repo only and create there own code ??

[ncoden]

we should be creating separate repo for [ similar product with some little differences ]

It's never a good idea (maintenance division, bugs/fix/features duplication...).

If people want different implementation

We're talking about different CSS implementation. Our CSS is currently generated by Sass mixins. Nothing prevent us from making mixins that can be used to generate our current CSS and a SCA.

So people can install the same repo, import or not the Sass mixins in their Sass project and import or not the CSS files in their HTML/build process.

[IamManchanda]

build process

:+1: I would say build process @ncoden

# For only sass mixins
foundation new --framework sites --styling sass-mixins-only

# Sass mixins and CSS
foundation new --framework sites --styling full-box

[ncoden]

This is not a build process. foundation new is a generator. It create a basic project structure, but do not create your distribution files (like we are with gulp).

[rafibomb]

Yes - it would be a global variable to turn off the class output. There will still need to be suggestions for markup structure.

[IamManchanda]

I wanted to add this in so adding it.

Even Google/Alphabet have started using BEM See https://deepmind.com/

[marnen]

@ncoden:

Components need to be built a particular way in Sass to make SCA possible (all properties in their respective elements, strict component organization), but then it cost nothing to use a selector or an other (like .menu > li instead of .menu-item). It's sad, it's too bad for the user and will probably cause problems, but at this point we don't care. We have what we want, a SCA framework, we'll try to teach our users about it, but if they still want to code "à la Bootstrap" we should not artificially limit them.

I'm trying to understand what you meant by this…and failing. Can you clarify?

When you say that components need to be built a particular way in Sass to make SCA possible, are you referring to a structure such as this

@mixin menu { ... }

@mixin menu-item { ... }

as opposed to

@mixin menu {
  ...
  .item { ... }
}

?

If so, then I agree with your claim. But in that case, what do you mean by

It's sad, it's too bad for the user and will probably cause problems, but at this point we don't care.

?

Are you referring to the fact that you can't include a component with one mixin if you structure your Sass this way?

If that is the case, BTW, what's preventing this?

@mixin menu { ... }
@mixin menu-item { ... }

@mixin menu-complete {
  @include menu;
  .item { @include menu-item }
}

(Perhaps it's not worth it. Just an idea.)

We have what we want, a SCA framework, we'll try to teach our users about it, but if they still want to code "à la Bootstrap" we should not artificially limit them.

I hope you're not meaning to claim that these are the only two options. For myself, I use neither the single-class pattern or the Bootstrap pattern.

---

On another note, I really appreciate what I'm seeing here of the way the Foundation community seems to function. I was fully expecting my initial post in this thread to be disregarded or considered off-topic, but I'm really pleased that we've wound up in an apparently constructive discussion as a result. Suffice it to say that this gives me a much better feeling than discussions I've with the maintainers of several other similar libraries, and gives me the impression that Foundation has a better chance of remaining viable for my work (though there are certainly things I'd like to see it do differently).

[marnen]

Also, @ncoden:

I like the "Semantic classes" approach with everything built in Sass (creating tons of classes in CSS to do everything is not scalable for now), but it lead to a lot of code duplication. It would be great if you have a solution to this problem.

If you can describe the problem in more detail, perhaps I can help solve it. :)