[Foundation 7] BEMIT - AppFramework level compiler. Edit: Foundation level Compiler also! #10430
Comments
|
cc @kball @ncoden @DaSchTour @brettsmason @SassNinja @codetheorist & everyone |
|
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, |
Only the compilation code is dependent ... Those guys can still use BEM or BEMIT |
|
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> |
|
Hey so I thinked about it, Advanced tooling in the framework generation side! The Global (Vanilla JS) Compiler with html 5 data attributes may look like this <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 Bcoz as a Vue (or Angular or React) developer, we would be looking for custom semantic elements! No? |
|
We're using BEMIT in my company so I'm not averse to bringing it into foundation. So just to make sure I've understood you correctly: And secondly: |
|
I can confirm for sure we will still be able to use normal BEM coding aka normal html... Ofcoursew |
|
@SassNinja first of all sorry for very short comment above but that time was unavailable
That sounds good. Infact you are not alone, see => https://www.webdesignerdepot.com/2017/04/the-state-of-front-end-tooling/
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
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)
Not at all, 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 I hope i was able to answer on your questions |
IamManchanda
changed the title
|
@IamManchanda thank you for the detailed response! Since normal coding is still supported I won't argue against a BEMIT structure. 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. |
|
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! |
|
@brettsmason What do you think about it ?? { PS: Yes i know you are not sold on BEMIT yet but still 😉 ) |
|
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... |
|
No issue @marnen... Thanks for expressing your dislike... we will surely look into it
cc @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. |
|
@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 |
|
@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 :
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. |
|
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.
I already structure my CSS this way. I don't need to rely on ugly redundant class names to make me do so. 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.
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 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. |
|
I strongly dislike @marnen thoughts! |
|
@IamManchanda Please give reasons. |
|
Short and simple reasons
|
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.
ClassNames are ugly.
I don't understand what that means.
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.
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. |
|
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. |
|
@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:
|
|
@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. |
|
@ncoden What do you mean by a single class API? Also:
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. |
|
@marnen A single-class API is a CSS API composed with "one-class" selectors, to ensure an equal specificity of .menu
.menu li
.menu > .linkYou have (for example) .menu
.menu-li
.menu-link |
|
Yes and for that Bem is the right area to move ahead |
@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 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 😄 |
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.
@marnen About what I said before:
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 |
|
And:
Please. Give. Reasons. ;) |
|
If thats the case we should be creating separate repo Foundation Sass or Sass Activate or F7 Sass Activate (Just like Bourbon) 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 ?? |
It's never a good idea (maintenance division, bugs/fix/features duplication...).
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. |
👍 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 |
|
This is not a build process. |
|
Yes - it would be a global variable to turn off the class output. There will still need to be suggestions for markup structure. |
|
I wanted to add this in so adding it. Even Google/Alphabet have started using BEM |
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
? 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.)
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). |
|
Also, @ncoden:
If you can describe the problem in more detail, perhaps I can help solve it. :) |
Yes.
It's sad in my point of view, because we have a framework that is "SCA-compatible". You are sure it will not apply properties you don't want, fuck up your specificity, etc... And people will use Bootstrap-like selectors "because it's more convenient" then stack dirty fixs over dirty fixs to have the render they want. But. "at this point we don't care.". We provide a framework, we don't rule the world. Let's create good tools and make people learn why they should use them. But we should not artificially restrict anyone, it's just useless.
No (see above). But this is false too. We can provide (like we are doing sometimes) one mixin for each block/element/modifier AND a component mixin that generate the CSS component with arguments/configuration-based selectors. This is almost what we are doing for ZF grids. This allows the user to change the generated selectors for all the components through the config, and to inherit a whole components (or a part of it) with one mixin call.
Nothing, that's the point. a SCA framework is compatible with and can be converted to any other architecture. The limitation is in the way you create your components.
I do not :D . I know there is a whole palette between BEM and Bootstrap. I like the "scope"/"scoping modifier" principles (I already talked about it on some issues I think) that are a good compromise in some contexts.
I like playing the devil's advocate, it may help :).
The idea behind this is : instead of generating tons of CSS selectors, and making the inheritance when applying them in the HTML (for example The problem is: we cannot use PS: I did not forgot your post above. I found back some aspects of BEM+compilor I did not liked and I'm looking for solutions. |
|
[Look at your line-breaking after block quotes—it doesn't do what you think it does. :) ] I'm still not quite understanding all of your issue, but I will say this: I consider |
|
@ncoden Ah...I may have finally understood another piece of the puzzle. Are you objecting to the duplication that |
Maybe, but for example a common grid with 3 columns generate 30+ properties. This is a piece the user should not duplicate to create its own semantical "layout classes". Generated CSS files would be around 10MB instead of 100KB |
|
Yes, that would be a reason for I'll admit that I don't generally worry much about the size of my CSS files (they don't wind up being very large, and they're cached anyway), but I understand that as a framework author you have to. (Of course, if a file is that repetitive, it's a good candidate for gzipped delivery, but we certainly don't want to force that.) |
|
...and with this realization, I understand now what %placeholders might be good for: removing the unused selectors and having less repetition in the generated code. Hmm. |
|
@marnen and @ncoden thank you very much for your input. I feel like you guys are preaching to save the heart and soul of the framework lol @IamManchanda if you disagree its cool but when you are the only one thumbs downing something/someone and not stating the reason(s) it comes across as kinda brash and discourages conversation about a serious issue... That being said, I fully agree with marnen and ncoden when they talk about keeping it more like bourbon as a library of mixins for component. If the framework enforced BEM or any other type then I and a lot of others would probably stop using. Personally I would like to see foundation 7 built on what made v6 great which is it's flexibility. More over, I think the focus of Foundation 7 should be a component driven framework rather than a site driven framework like foundation 6 but avoiding the mistakes of foundation for apps. One of the major (css) mistakes of F4A was the naming/grid. Lets face it, the grid was aweful. It was weirdly named and functioned strange (XY is a MAJOR improvement). That being said, the original purpose of this topic "AppFramework level compiler" is interesting but I worry it could quickly become another F4A like scenario and that would be devastating to the community which primarily uses sites. I would love to see a working example (demo/proof of concept) for angular, react and vue before any major BEM, etc is implemented. As for ugly syntax: However the sematic version below is actually really interesting: |
|
No issue... thanks for your concern @HansUXdev { PS: Please don't use slang's which can be seen as double meant! FWIW I have edited your comment with a synonym! } |
|
@IamManchanda by the way, again I think a AppFramework level compiler is a great idea. But being devils advocate, aside from maybe a vanillia-js approach that can be plugined into vue, react, angular, how is it different then advanced css modules? More importantly why would a tool like this, require changing the entire framework's naming schema? |
|
Simple Answer => Because its not #CSSinJS |
|
@IamManchanda how are we doing with the BEM plans? will this be for v7? |
|
Closing this issue out. We can reopen for discussion in V7. |
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
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
which will automatically convert the code into a BEMIT code like this into the DOM
The text was updated successfully, but these errors were encountered: