Foundation-sites: Foundation 7: CSS Architecture (Suggestion/Proposal) - ITCSS + SMACSS

Created on 25 Mar 2017  ·  19Comments  ·  Source: foundation/foundation-sites

https://github.com/zurb/foundation-sites/wiki/Project-Roadmap#70-november-2017

7.0 (November 2017)

  1. CSS Architecture rework (ITCSS + SMACSS)

Hmmn.. 2 weeks back @ncoden introduced me to an organized css world and had some good amount of research about these types of organized architecture's and now .... i am proposing this below for foundation 7 and i will be very happy to work on this.

smacss-itcss

Source:

  1. https://smacss.com/book/categorizing
  2. https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

PS: Activate is the name given by me, it doesn't exists in SMACSS !

Foundation 7

Most helpful comment

@DanielRuf removing jQuery would be amazing!

All 19 comments

Nice and according to me that Theme part can help build something like Bootswatch type within foundation itself only.

Here is an another thing to consider
=> BEMIT by an another Harry

Hereby, i also would like to propose below types of convention for V7 ...

.o-media-object__image {} // Object, Block, Element
.c-modal--wide@large {} // Component, Block, Modifier, Responsive Breakpoint
.c-accordion__title--vertical {} // Component, Block, Element, Modifier 
.u-text-center {} // Utility, Block
.t-default {} // Theme, Block
.s-healthchecks {} // Scope, Block
._c-footer {} // Hack, Component, Block

Source:


Drawbacks: BEMIT is basically awesome for managing large scale project (Its modular, easy to understand, great for healthchecks, etc) but is it good enough for consideration on small projects where people dont think about these type of things ??

@RamanCool i like your opinion but i think of it as a color switcher

Some cool Examples

  1. Color Switcher's found in templates
  2. [New] Youtube design with an optional dark theme! Go Black or white with a click of a button (switch)

Maybe it should be settings/config/tools/utils/core instead of "Activate" https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

Fan of SMACSS @ncoden
But yes this is debatable...

Plus I am a fan about caring your code and create a pattern out of it
Not sure what I am talking about?
Look into the sidebar and then the code
Look 3-4 times you will understand

BTW i have talked with @kball on this .... and he told me that a theming part can be very useful if we incorporate it to things like material design via "theming" approach (Ofcourse default is what foundation uses from start and will use forever.)

http://codepen.io/prestopasto/pen/oLmgqm?editors=1100

Is the structure above finalized in any way?

The best part of foundation 6 has been its import structure. It became this awesome lightweight and scalable library similar to bourbon while maintaining its ability to be a framework. In many work cases, both I personally and large companies like GM have used foundation purely for the mixins.

So to extend the library-like functionality would it be better to do something like the following?:

// imports just the mixins
@import 'layouts/grid'; 

// import your grid type

// @include foundation-grid;
// @include foundation-flex-grid;
// @include foundation-xy-grid;
@include css-grid-classes;

Then on the javascript side of things do the same with selectors as variables such:

let topbar = `.topbar`;
topbarSelector = document.querySelector(topbar);
// use topbarSelector

Lastly as for using SMACSS/ITCSS, why make the change from 'semantic'?

I understand and completely agree with namespaces for scalability because thats always been really annoying and is especially MORE annoying now that we have three grids type all of which conflict... That said, namespaces honestly only takes a day, maybe three at most to rewrite every class as a string variable.

In foundation 7 legacy flex and float will be dropped as per my best of knowledge

Though nothing has finalized but here is my current vision
68747470733a2f2f692e696d6775722e636f6d2f4a7574576b56662e706e67

I've still never used either flex version lol I know its 'bad' but my clients have needed ie 8-10 :'( support (to my absolute hate)... I understand the plan is to drop ie 10 so it makes sense.

But as for:

@import 'layouts/grid'; 
// @include foundation-xy-grid;
@include css-grid-classes;

I meant that for all components and really want to know if the plan is to change from the library-like functionality because that's going to seriously impact use and maintainability as well backwards compatibility .

Also curious what you thought of using scss string variables like:

$row-class-name: '.row';
#{$row-class-name}{
   // methods
}
// or
$media-object-class-name: '.media-object';
.#{$media-object-class-name}__image {
  //methods
}

That way '-o' isn't imposed or overly opinionated and completely up to the user when they use the settings file. Also the same thing for 'large'. So instead of: .c-modal--wide@large {} we just use:

$modal-class-name: '.modal'; // component level
$large-class-name: '@large'; // part of global or utilities
.#{$modal-class-name}-wide{#$large-class-name} {
  //methods
}

This way the output can be changed from the settings file .modal--wide@large {} can be changed to .modal-small-large {} or whatever, plus now component are potentially backwards comparable but don't conflict unless you want them to.

First of all there is a discussion about not to drop IE 10 and we may get in IE10 also in F7
Secondly,
Please visit this link https://www.microsoft.com/en-in/windowsforbusiness/end-of-ie-support

I'd really love to see Foundation move away from one global settings file containing settings for all the components, and instead use the global settings file only for global settings, moving component specific variables to component specific files where additional css could be implemented as well.

Having used BEM quite a bit over the past year, I would like to add that the __ double underline convention is a hotly debated topic. Some people seem to dislike how it impacts text selection when working within an editor.

Another thing to consider is avoiding using Modules as a folder since it can be confusing especially for frameworks that use modules like Angular 2. Components should be okay listed in the same directory level as base, settings, layout etc.

@lukasklein Funny enough but I just commented in here => https://github.com/zurb/foundation-sites/issues/10610 ... so check that out once

Some people seem to dislike how it impacts text selection when working within an editor.

I have to agree that this is true.

I'm excited to see where Foundation goes and that the jQuery dependency will be removed =) Awesome!

@DanielRuf removing jQuery would be amazing!

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

谢谢

Was this page helpful?
0 / 5 - 0 ratings