Foundation-sites: [CSS Architecture] ECSS

[IamManchanda]

Check this slide => http://ecss.io/slides2/#/

and here is the convention (Rest in book/slides)

[mattbag]

Personally that is too much... I usually go very good with B__E--M

[IamManchanda]

@mattbag

ECSS (with namespace)

.zf-Card_Section-primary
.zf-Card_Section
.zf-Card-primary

vs BEM (with namespace )

.zf-card__section--primary
.zf-card__section
.zf-card--primary

[IamManchanda]

BTW ... you might be looking as eyes of a CSS designer
but I am looking from the eyes of a JS developers (or even other lang guys)

End of the day, this CSS will go to a developer
and, Developers just don't like card__section--primary ... they are not used to this

This is just why CSS in JS has become a popularity, though that's not good

What they do like are camelCase and PascalCase?

---

PS: 2-3 Months back, I didn't fancy this ECSS type naming convention...
But since I am getting into Javascript, It feels FAR more comfortable in ECSS then BEM!
At the end of the day, we need to make dev's comfortable? No?
Especially living in APP era and not static web.

[IamManchanda]

For small benefits

• Works excellently for encapsulated UI components and for handling all related concerns in a single file
• Reduces development time by co-locating styles with components

JS dev's are forgetting these downsides

• Changes how CSS is declared syntactically in a way that makes it less portable between projects, i.e. border-radius becomes borderRadius
• All styles are inlined which means that if you are using a library that uses CSS in JS, your ability to change styles depends on their component API implementation, e.g. the Material UI React library doesn’t provide style API
• Lose the ability to cache CSS in the browser, resulting in possibly longer loading times
• Possibility for divergent styles between components if care is not taken
• Does not handle adaptive/responsive design well
• It is not appropriately suited to most large projects or multiple projects with multiple devs
• Because inline styles cannot be overridden in CSS, it is not easily incorporated into projects that don’t use it overall

---

You might think I am going out of topic but do you really want things to go like this?

const styles = StyleSheet.create({
 button: {
 background: gradient,
 borderRadius: '3px',
 border: 0,
 color: 'white',
 height: '48px',
 textTransform: 'uppercase',
 padding: '0 25px',
 boxShadow: '0 3px 5px 2px rgba(255, 105, 135, .30)',
 },
}); 

And, for me ... To stop JS devs doing this and fight against CSS in JS ...
BEM is not an answer for this!
because the last thing a developer would like is -- or __ (includes me)
... and this includes devs from other languages too!

[IamManchanda]

Also, the thing I like about ECSS is not only about naming convention but is this:

Instead of writing our code like this

html/
- shopping-cart-template.html
- callouts-template.html
- products-template.html

js/
- shopping-cart-template.js
- callouts-template.js
- products-template.js

css/
- shopping-cart-template.css
- callouts-template.css
- products-template.css

We aim for something like this:

shopping-cart-template/
- shopping-cart.html
- shopping-cart.css
- shopping-cart.js

callouts-template/
- callouts.html
- callouts.js
- callouts.css

products-template/
- products.html
- products.js
- products.css

At first glance this may seem like a seemingly unimportant distinction but it brings important benefits.

The code for each component becomes physically self-enclosed. Then, on our enduring project, when features need changing or are deprecated, all associated code for that module (styles, view logic (HTML) and JS) can be easily updated/removed.

When a module is deprecated, all language files associated with it can be easily removed from the codebase in one go; just delete the folder containing the module.

Just to be crystal clear, consider this folder structure for our imagined ShoppingCart component:

ShoppingCart/
   - ShoppingCart.html
   - ShoppingCart.js
   - ShoppingCart.css

Now suppose we create a new shopping cart:

v2ShoppingCart/
    - v2ShoppingCart.html
    - v2ShoppingCart.js
    - v2ShoppingCart.css

As soon as our v2 shopping cart is finished, it's easy to remove the code for the prior version from our code base; we just delete the folder containing the original ShoppingCart.

Original source: http://ecss.io/chapter5.html

---

That said, frameworks users like react would delete that HTML thing but I think that's fine!

[mattbag]

Hey thanks I'll run through your explanations and the site asap!
The last part is definitely correct, it's what is happening with the major libraries already, and it's very useful.

I don't think I worked on projects big enough that require that kind of syntax, and I don't do enough js, thus I totally don't like typing camelcase .

[IamManchanda]

It's not about projects, it's what tech you are doing... Even I didn't wanted these PascalCase and camelCase... that's why only, I have been so vocal about BEM but from last month or two, I am learning Javascript and I can tell you ... I find BEM very hard on my eyes and things like ECSS very easy on eyes. Yes it's personal preference and the person winning with ECSS is JS guys and not CSS guys.

But bro in this App era, if you will try to beat JS guys, they will remove CSS completely (#CSSinJS) ... For me #CSSinJS is like killing a designer... and saying to him... go back to your freaking little photoshop and sketch.... Just stay there, never code and Never Come Back...

[mattbag]

It all makes sense...
I have conflicting feelings about CssInJs. I'm sure everything will find the rightful place soon enough...
Speaking about trends, are you guys thinking to go with vanilla js components for the next version?

[IamManchanda]

Small Answer => YES!

Long Answer
@mattbag The plan for Foundation 7 is to separate out the core state management and "UI logic" (ie what should happen) from the DOM manipulation and then implement "adapters" for each framework to do the DOM manipulation the way it thinks about the DOM.
If you want to contribute into foundation 7, right now best place would be our slack channel
https://zurb-foundation.slack.com

Ping me on Twitter to get Invite. Thank you!

[IamManchanda]

I feel that if you are targeting App Frameworks (which is undoubtedly presently and future of web)

I feel ECSS is the right way to go ... Checkout https://tech.io/playgrounds/9924/the-state-of-css-specificity-part-3

I have made a small React app today (just toggles in out cards) ECSS based approach to showcase how a JavaScript App can implement the power of css without any specificity headaches, without any scoped css and yes without any CSSinJS shit

Here it is => https://github.com/IamManchanda/react-app

As far the foundation-scss is concerned here is the pattern how we can implement that

=> https://github.com/IamManchanda/react-app/tree/master/src/boilerplate

It Includes

1. Activate (or Abstracts from Sass 7-1 Pattern): Functions, mixins, settings file!

2. Base: Base Styles

3. Objects: This is big one so let me mention

=> What is a component?

Ans. Components are YOUR code.

=> What is an object?

Ans. Object is a general purpose component, like media object, accordion, etc.

So for me every foundation components is an object

So there shouldn't be a component folder but just objects with o- namespaced classes

As far the user code is concerned we can recommend them (if App framework) that all scss can live in src/components... the same folder where all frameworks add their JS components.

You can find a small implementation in here => https://github.com/IamManchanda/react-app/tree/master/src/components

On Layout, I think we can drop XY Grid (or atleast a variable to remove XY grid from their project) thanks to wide adoption of CSS Grid and let user lay out their css by their own with CSS Grid

[IamManchanda]

V7 requests are being closed for the time being. We have them labeled so we can readdress them in the future.